|
真正领会客户需求，形成指导开发人员的需求文档或者需求规格说明书是非常难的一件事情。
1）不要夸大；
2）有条件的一定要写明条件，如：在 ** 条件下，性能指标是多少…..
3）在满负荷下，性能会有衰减，要说明清楚。甚至要标明衰减比例。
（1）说需求的人几天后可能会忘记。
（2）记录需求的执行人，可能会碍于面子说同意。但没有真正领悟需求点。
场景如：“小王，你把现在系统的两个模块整合在一起，两天时间完成”。
对于上面的场景，电话基本很难领会需求人意图，电话很难评估工作量，电话很难保证双方理解是否一致，电话很难确保1方的反悔。无证据无任何保障，后期实现完若不满足需求的几率非常大。
好的做法是：
1）邮件通知，有记录、有证据。
2）接到口头需求后，要再次以文档的形式（列举需求点1,2,3）以邮件形式确认。
这样，邮件确认完备后再去实现会更高效。
1.代码中对异常的处理和考虑非常欠缺。
2.模块负责人一定要对自己的代码负责任，进行完备的代码单元测试（写表格测试用例进行边界值、打桩测试等自测）。
1.常见的bug、简单Low级别bug还非常多的话，可以打回开发人员自我验证充分后再做测试。
2.需求阶段的bug成本最低，其次是设计阶段，再次是开发、测试阶段，成本最高的是交付后阶段。所以，要把bug消灭在最开始的阶段。
1、务必提供详尽的需求文档、需求规格说明书，且与代码实现同步更新。
2、开发人员务必进行完备的单元测试。
3、开发结束后务必进行完备的归档（源码、交付安装包、安装/部署手册、需求文档、设计文档、变更需求文档等）。
|
