研发阶段注意事项

题记：以下是研发各阶段易出问题的小结，越小细节，越容易犯错误。需要多注意！

最主要的还是说，所有的东西都要有证据，对你自己是最有利的。
证据的记录方式就是通过文档，邮件，视频等等。
研发阶段：客户-》获得需求-》分析-》设计-》封装-》测试-》纳品（交货）

一、需求方面

1.需求文档

真正领会客户需求，形成指导开发人员的需求文档或者需求规格说明书是非常难的一件事情。

2.需求文档中对性能指标要做到：

1）不要夸大； 
2）有条件的一定要写明条件，如：在 ** 条件下，性能指标是多少….. 
3）在满负荷下，性能会有衰减，要说明清楚。甚至要标明衰减比例。

3.口头上的需求没有证据很难执行落地。

（1）说需求的人几天后可能会忘记。 
（2）记录需求的执行人，可能会碍于面子说同意。但没有真正领悟需求点。 
场景如：“小王，你把现在系统的两个模块整合在一起，两天时间完成”。 
对于上面的场景，电话基本很难领会需求人意图，电话很难评估工作量，电话很难保证双方理解是否一致，电话很难确保1方的反悔。无证据无任何保障，后期实现完若不满足需求的几率非常大。 
好的做法是： 
1）邮件通知，有记录、有证据。 
2）接到口头需求后，要再次以文档的形式（列举需求点1,2,3）以邮件形式确认。 
这样，邮件确认完备后再去实现会更高效。

二、封装方面

1.代码中对异常的处理和考虑非常欠缺。 
2.模块负责人一定要对自己的代码负责任，进行完备的代码单元测试（写表格测试用例进行边界值、打桩测试等自测）。

三、测试方面

1.常见的bug、简单Low级别bug还非常多的话，可以打回开发人员自我验证充分后再做测试。 
2.需求阶段的bug成本最低，其次是设计阶段，再次是开发、测试阶段，成本最高的是交付后阶段。所以，要把bug消灭在 
最开始的阶段。

四、几个务必

1、务必提供详尽的需求文档、需求规格说明书，且与代码实现同步更新。 
2、开发人员务必进行完备的单元测试。 
3、开发结束后务必进行完备的归档（源码、交付安装包、安装/部署手册、需求文档、设计文档、变更需求文档等）。

五、感激真正指着鼻子骂过你的客户，你会学到很多，成长更快！

程序员，加班两个词成了必然的联系。想到程序员就想到加班。甚至晚上打车听到滴滴广播也是软件园区域打车的人超级多。深圳是这样，北京更是如此。我们乐此不疲的加班的同时，也要静下心来思考：程序员，你为什么加班？ 
以下仅以我当前项目（出差紧急验收）为例展开讨论，不具有普遍适用性。如：一线公司百度、腾讯、华为、某服公司加班是常态甚至固定加班则可以排除在外。

一、项目进度延期 
分析为什么延期？ 
1、工作量层面：工作量远远大于预期。或者工作估算不准确。 
2、技术层面：后期遇到疑难bug，影响进度。 
如：本次遇到的典型bug:IOCP程序正常或者非正常退出，但只在VPN网络下出现，原因可能和IOCP机制有关，根因很难排查。 
3、人员层面：核心人员离职。 
4、需求层面：临近交付，需求有大的变更，且很难短期实现。（这次项目便是这个原因） 
5、测试层面：多家单位没有联调，自己模块测试非常不充分，或者没有测试。

二、需求变化如何应急解决？ 
需求的突变是程序员的痛点，时有需求引起的“血案、命案”。 
1、及时沟通，给出方案。 
如何尽快处理，思考为什么改需求？改动的难度以及改动的工作量评估。如果难度大且改动对用户无关紧要可以不改；如果是用户强烈要求，且评估也认为必须要改，要给出时间、工作量估算、投入人数后再改。 
核心一点：如果是功能可以，只是体验的因人而异的问题真的可以不改。可以放在后面版本改进。 
2、充分考虑改动的后果和可能影响？ 
有版本出现过改动后出现“连锁反应”，“牵一发而动全身”。分析原因：前期代码扩展性差。 
3、对于甲方拍脑袋，一言堂的情况处理？ 
此时乙方领导不能熊。“兵熊熊一个，将熊熊一窝！”必须以身作则，和团队共患难。明确：解决问题的方法肯定比问题多。

三、如何让程序员高效加班？ 
1、项目经理甚至主管定好改动后的需求。 
2、.架构师审核新的设计是否合计并给出指导意见。 
3、项目经理给出明确的版本时间节点和进度安排。 
4、项目经理能自己或者协调高层调配人员，如美工。 
5、程序员加班双薪，解决疑难Bug物质或非物质奖励（书籍、电影票等）。 
6、解决程序员出差的一日三餐，让其无后顾之忧。

四、反思 
1、流程规范的重要性。没有流程规范，很多口头需求变化会成为一纸空文，没有约束力。必须写下来，或者有邮件来往、RTX聊天记录作证。 
2、关注点随时间推移由功能变为性能及稳定性 
3、管理人员对应急需求的处理，及时发挥团队的力量。 
4、甲方乙方的协调对接很重要。乙方对甲方蛮横需求的应急公关处理很重要。