刚踏入计算机行业那一年，单纯的我觉得“只要技术足够牛，就能使项目成功 。”但随着时间这把剃头刀不断地推高发际线，越发察觉到有一股技术以外的力量起着更大的作用。这也促使我跳出“写代码”边界，思考代码以外的发生的事情，下面是一些不成熟的小思考。
这是代码人生系列的第五篇，系列文章目录如下：
价值链流动
image
图中的直线表示项目价值链的正向流动，而曲线表示价值链的反向流动，所有的反向流动都降低了交付速度和质量。
-
“开发到需求”：表示在编码段研发察觉的需求不完备，不合理的地方，向产品反馈，导致需要的微调。
-
“测试到开发”：表示测试阶段发现的代码和需求不符的地方。
-
“测试到需求”：这条反向流动有多种情况，比如测试和开发对需求的理解不一致，谁也说服不了谁，只能一起去找产品。再比如测试阶段发现需求的不合理之处，和产品沟通后，在交付前夕变成新的需求。
如何减少价值链的反向流动是所有项目组成员需要思考，努力的方向。
需求共识
为减少价值链反向流动，除了提高个人业务和沟通能力之外，还有一个值得努力的方向：提高所有人对需求的共识。
需求就像文学作品，1000 个 读者心里有 1000 个哈姆雷特。
虽然这个比喻有点夸张，有也些许吐槽需求文档不够详尽的意味。但这个锅产品一个人背不了。即使产品文档写的像数学定理一样严谨，整个价值链流动的过程中，产品、设计、开发、测试，这四方对需求理解的偏差无法彻底消除。所以沟通是必不可少的。
偏差拖慢了项目推进的速度，降低的项目的质量，偏差越晚发现对项目影响越大，最坏的结果是大家对需求理解的不一致拖到测试阶段才一起暴露出来。
既然偏差无法避免，是不是可以让它早点暴露出来。 在整个价值流动过程中越早发现理解偏差，越早治疗，损失越小。
产品需求会、测试用例会、服务端接口会都为早崩溃做出了很大贡献。（若迭代周期只有一周，就没时间开这么多会，欢迎短周期迭代的小伙伴留言，分享下你们如何处理理解偏差。）
产品照本宣科地读文档，研发漫不经心地恭听，冗长的产品会听着听着便掏出了手机是常见的现象。最要命地是听产品读了一遍文档后并未加深我对需求的理解，动手开发之前还得精读一遍。
是不是可以先让研发精读产品文档？深入思考需求甚至构思一下详细设计，以便发现没有考虑到的边界情况、不能自洽的产品逻辑、性价比低的产品设计。
可不可以转换下角色？把产品需求会变成 “需求答疑会” ，让研发主导，提出对需求的疑问和建议。
这样会不会调动起研发的主动性？在过需求的时候就把更多的“理解偏差”都暴露出来？
模块归属
在需求答疑会之前，得先做好开发分工，这引出了另一个问题：
“短期的模块分工要不要变成长期的模块归属？”即业务模块是有产权的，让一个模块长期的归属于一个研发，这个模块的需求，他主导开发，这个模块的 bug，他主导修复，所有对该模块的修改都需要经过他的 Review。
在不熟悉的模块中改动代码是一件事倍功半的事情。就算该模块代码逻辑清晰，低耦合，易于扩展，也可能因为不熟悉具体的业务逻辑，改出 bug。更何况大部分的代码是，逻辑混杂，高耦合，牵一发则动全身。
程序员多少都一些工匠情节，对自己亲手打造的代码都“细心呵护”，就好像自己雕琢的工艺品，这种情愫会推动他不断地自驱动地优化代码。但若是别人的工艺品，这种动力则会大打折扣。
只有分工才能专业化，只有专业化才能提高质量。
模块归属也让“集中式的代码 Review”变成“分布式的代码 Review”，原来所有的代码都是让团队的 Leader review，但 Leader 怎么可能了解所有业务模块的细节？所以只能泛泛地 Review。何不让最了解这块代码的人 Review ？
知识共享
模块归属也会增加风险，即会显著地降低“巴士因子”。巴士因子描述的是项目知识的集中程度，即一辆巴士撞死几个研发，整个项目就可以宣告 GG。
某个模块的知识只掌握在某个人手里，就好像把所有的筹码放在一个篮子里。他生病了、离职了，该模块就会瘫痪。
如果团队的大部分知识只集中于少数人手里，不利于提高整个团队技术水平和抗风险能力。
知识是多种多样的，业务知识的共享可以降低团队开发和维护成本，通用知识的共享可以提高团队的编码质量。
每个研发擅长的领域不同，知识的边界也不尽相同，如果知识能够在团队中无障碍的流动，如果大家的知识可以做并集，不仅可以提高整个团队的技术水平，还可以形成很好的技术氛围和粘性。
“集体Code Review” 可能是一种可以尝试的知识共享方式。它鼓励双向沟通：将一段代码公之于众，接收大家的 Review。条条大路通罗马，你实现的那条可能不是最短路径，或扩展性不佳，或性能不好。这正是集体智慧发光发热的地方，对同一段代码的集体审视可能会迸发出很多思想的碰撞，真理总是越辩越明，集体智慧的光芒可以让在场的所有人从中受益。
网友评论