CRM复盘总结

crm

author： 赵亮
email ：weston_contribute@163.com

摘要： CRM系统历时一个多月，从立项、需求评审、项目计划、画流程图、编码、自测、提测、灰度测试，同事们按照既定的计划，在规定的时间内完成，虽然因为一些原因没有上线，但是对我个人来说已是胜利完成，在这个过程中，每一个同事积极沟通，努力完成自身工作的同时并其他同事，经常加班很晚，其优点多多，就不在这里赘述。而我就项目参与的过程中遇到的可以改善的问题从产品、技术、代码规范及测试几个方面在这里探讨，其内容如下：

产品

CRM系统的需求评审我们花了两三周的时间，这种现象不合理存在的原因我人认为有以下几点：
1. 需求考虑不全。我们在讨论需求的时候，经常发现因为一个问题会迁出另外一个没有考虑问题，这是我们应该记录问题，会后跟产品经理商讨解决方案，下次再进行需求评审。而我们没有适可而止，每个人在会上提出自己的解决思路，七嘴八舌，我并不是说人人发表意见不好，而是我们临时提出的解决思路并一定都是基于全局去考虑这个问题，往往不太可靠。
2. 采用定式思维思考产品的逻辑。当看到列表查询时，我们很自然的想到各种搜索条件，其实很多搜索条件是不是真的需要，例如公海客户列表有根据来源时间的起止时间查询，我们假设自己就是那个用户，我会不会用到这个搜索，这个搜索能满足我哪个业务需求，如果我们每次都是以用户为中心的思路去思考产品逻辑，就会很清晰的知道很多条件查询是否存在的必要。
3. 开会形式需优化。
（一） 会议没有组织者，每次一开会产品经理就是讲需求，有第一次来参与需求评审的同事都不知道今天的会议到底讨论需求的哪部分评审。（二）会议没有人把控时间，任凭头脑风暴的发生，是不是当我们一定时间内讨论不出结果，要终止讨论并记录问题，会后详细思考后再来。这样也能节约与会者的时间，是事情更有效率。（三）没有完整的会议记录，如果让一个新人来了解CRM，每次需求评审的记录文档就是很的材料，他可以知道为什么需求会定义这个样子，其因果逻辑什么。

技术

在项目开发过程也遇到一些可以改善的问题：
1. 理解不一致。研发过程中跟产品确认需求时一些细节问题我们需要记录。不仅要记录沟通的结果，时间；还要记录为什么会形成这个问题。
2. 数据库表设计可以优化。 （一）有些表字段是否有必要冗余，其冗余字段是基于什么样的动机考虑的，如果连以后可能用到的可能性都说不出，那我们是否可以考虑先不冗余。（二）我们在列表查询时一定要考虑性能问题及索引的建立，适当的时候还要权衡需求。（三）注重数据库优化人才和大数据人才的培养，以后CRM系统，客服系统及用户交互行为都会随着时间的推移数据量会不断增加。
3. 我们应该建立项目的文档库。在CRM项目整个开发过程中，会涉及到原型模型，架构设计图，数据库建表文档，数据库配置环境流程文档，流程图文档，接口文档，索引文档，部署文档... 这么多文档我们没有统一管理，我们可以将文档放在SVN上，便于索引和管理。
4. 统一管理固定值字段。 比如成本类型（costType）1表示付费，2表示免费，项目中还有很多这样的值，比如终端类型。这些应该有统一的文档管理，如果只是在本系统用还没什么影响，如果多系统使用就会出现不一致的情况。应该将其放在统一的文档里，各个系统遵循此文档，没有则定义并添加。这样能保证一致性，前端在使用时也能快速找到其值对应的含义。
5. 基础数据的键值对不应使用自增id作为其值。在做数据导入时，就出现数据导入时，其id并没有从1开始自增，导致出现问题。应添加一个字段存储具有业务意义的值，而不应该将自增id赋予具体业务意义。

代码规范

1. 个人在代码编写的过程中还是没有完全的遵照要求的代码规范，代码规范没有什么好坏之分，但是一旦有了代码规范，我们开发的每个同事都应该遵循，为后续自己修改代码和新人接管代码降低复杂性。
2. 王波分享的代码规范值得推广，通过协定和代码规范的辅助工具来提高代码的规范性。

测试

测试部门测试出的很多问题其实是可以在自测过程中发现的，当然有自身的原因也有需求不明确，需求变更没及时沟通导致的问题。所以我们再自测过程中，要对需求理解，写测试用例两方面下功夫。