一、前言
历时4个月的挖机销售报价系统进入收尾阶段，由我直接负责与业务方对接，这中间各种折腾真是一言难尽，项目开发过程中还要维护POS系统以及牛奶配送系统，本项目我们采用的是迭代开发，今天讲一下具体的开发过程以及本项目业务架构。
注：这是我这5年在公司第三比较大的项目，第二个项目见 《窗帘销售平台技术架构的一点思考》，这也是我负责产品设计第二个项目。
二、迭代开发
上面方框中就是一个迭代周期，每一个迭代周期时间在1~2周左右，形成一个可演示版本，并且部署到澳洲生产环境机器上，交付给业务方进行试用，然后根据试用的结果再梳理出下一迭代需求。
1、需求阶段
业务方很难讲清楚需求，在第一次需求会上给我们看了一个Excel表格，有接近100多个字段，说他们主要是用这个表格来管理所有的挖机主机和零部件从采购、库存、客户、销售报价、出库、财务、售后一系列工作，现在需要开发一个软件来管理。
注：几乎所有业务方都很难讲清楚自己的需求，毕竟他们不是做系统的，我们做为专业人士要理解这一点，如果能够是需要尽量引导业务方讲出他真正需要做的功能。
3、设计阶段
我们团队总共8个人，人人都是产品经理，所有人都需要参加与需求方的沟通会以及考虑自己所负责模板的产品原型，在这过程中我更多的是负责思考整个项目要拆分成哪些功能模块，每个模块需要几个交互页面，页面之间逻辑是怎样的，业务流程是什么，数据流是怎样的，要建哪些表，表之间的关系以及明确每张表的关键字段，具体细节由各位开发自己去考虑。
4、开发阶段
团队分工合作，我一直认为如果做业务技术，团队成员水平一定是阶梯式的， 由技术扎实的开发负责基础架构搭建和技术难点解决，比如 报价模板在线签名，权限管理、延迟队列、库存管理抽像等，业务经验较丰富的负责核心业务开发，在开发过程中有业务逻辑问题反馈给我，我考虑清楚重新调整产品逻辑与页面原型。
注：架构中间件团队对技术人员的要求是不同的，这种团队需要开发人员水平比较均衡，在搭建业务技术团队的时候要招好两个角色，一个做技术架构，另一个更能从客户角度思考需求，一般来讲对技术比较痴迷人对业务逻辑不会有太大兴趣，而能更多从客户需求考虑的人只会把技术当成解决问题一个工具，所以一个比较完美的团队最好有这两个角色并且能通力合作。
5、测试阶段
我一直认为一个专业的测试是相当重要的，搞不清楚为何很多大厂在削减测试人员，以我这么多年带技术团队经验观察的结果，开发的思路和测试是完全不同的，要想让开发做到无Bug上线几乎是不现实的，尤其是像POS系统、报价系统这些直接影响销售收入的软件，如果没有测试把握完全无法想像。我对测试人员要求是必须搞清楚数据流，每一笔业务操作写到表的哪个字段都要搞清楚并且对产品功能逻辑问题进行有效反馈，然后我再重新考虑产品原型的调整，所以我比较清闲。
注：我一直认为一个技术管理者最重要的就是做好工作安排，老板是不会考核你个人的产出的，他要考核的是整个团队的产出，你撸不撸代码老板是不Care的，但团队成员理不清楚思路或者技术难点你必须搞定，这也是技术管理者该做的事情。
6、功能演示
做完一个小版本我们就给澳洲业务方做本次迭代的功能演示，然后业务方通过具像化可运行的产品去思考本次迭代的功能需要做哪些优化以及下一个迭代还要做哪些功能，这样版本从0.1演变到0.8，每个小版本都与业务方有充分沟通，整个产品进行逐步完善，再做两个小迭代，就可以交付正式使用。
注：这种迭代模式一个比较大的问题就是业务方经常对已经完成的功能模板提出新的需求。
三、业务架构
上图是报价系统的业务架构图，整个系统是以商品和客户为核心进行构建。
1、客户CRM模块
客户是CRM模块的核心，围绕着客户将其在系统中的每一个事件都进行汇总，并且记录每一事件中销售与客户的沟通记录，这样销售在跟进一个客户时，可以清晰地知道与客户交互的所有情况，我们会生成一个时间轴，什么时间接到客户电话，什么时间进行报价，什么时间与客户签订合同，以及这中间所有的沟通记录，然后给客户分成不同等级，当客户变成非活跃时，会及时提醒销售进行跟进。
2、商品模块
商品模块有点复杂，这与窗帘销售不太一样，想了很长时间才想清楚，主要是主机和零部件的管理是完全不同的，主机价值都比较高，对于每一台主机是需要全链路跟踪的，这个关键点在于主机的序列号，需要通过主机序列号串起从供应商发货到入库、在哪个仓库，在仓库哪个区位，然后报价生成合同生成时关联到起来一直到该主机出库甚至后续的售后，而对于零部件来讲就相对简单，采购后供应商可以分批次发货，在入库时需要指定放到哪个仓库哪个货架，但零部件在货架上多少数量是不需要管理的，也没有办法管理，只维护某个型号的零部件当前在哪个仓库哪个区位什么货架上即可。
注：在产品设计时一定要考虑哪些是必须要做的，哪些是不需要做的，很多功能做出来实际业务流程限于企业的管理成本也没有办法用起来。
3、财务模块
财务模板也想了很长一段时间才想清楚，还好我自学了一段时间会计，后来想明白了就比较简单了，其实把应付款和应收款管理好就可以，应付款对应采购合同，应收款对应销售合同，一个合同可以开1张或多张发票，一张发票可以进行一次或多次付款，只有财务进行发票确认的采购价和销售价才是最准确的，最终利润是根据发票上销售价减去采购价再扣减分摊的物流成本进行计算，这样我们就能够精确计算每一台主机的销售利润。
注：这张图是报价选商品的主流程，我们将服务、安装费都打包成基础产品，这样整个系统架构会更简单一些。
四、技术要点
1、采用最简单的单体前后端分离架构，除了牛奶那个系统其它系统我们都没用分布式架构，牛奶业务零售再过两个月左右就会完全停掉，到时再把系统架构整理出来，纪念一下我是如何搭建年销售额百亿的系统架构的，但这是一个有点悲伤的故事。
2、报价模板生成涉及到解析Word模板、动态生成PDF报价文件，在线签名，邮件发送给客户。
3、操作日志 解析BinLog 记录了每张表每个字段变更前后的值。
4、ToB的系统没有高并发的挑战，但业务复杂度是远远超过ToC的业务，这里仅简单介绍一下，实际项目中更复杂，每一个下拉框选择不同的类型都会触发一系列业务规则。
注：一个产品从0到1还是挺有难度的，需要理清客户真正需求，平衡好需求与开发进度的关系，如果掌握不了一个度，任何一个点你可能都需要花一两周时间去做，然后整个项目进度无限期拖延。