需求的重要性在痛苦中领悟

       需求重要吗？重要。你做了需求分析吗，有需求规格说明书吗？ 没有。很多人、企业在重复这样的老路，我就走在这样的路上。至于为什么---这块不在我的权限范围内，建议过无效。这里只当是从一线开发人员的角度说下自己对需求重要性的体会吧。

       一路走来，对需求的重要性的认识也是逐渐加深的。即使你一毕业就进入一牛逼，一大公司，一很正规的单位，一上班就让你参与到需求相关的工作中，也不会有多深刻的体会，甚至是懵懂的，无感觉的。更何况，我还在一个小城市的小公司里了。需求的沟通就是，QQ，电话，面谈，沟通完了也不会有完整的文档留下来，最多一个草稿上画的示意图。接下来就是码代码了，中途发现有遗忘，遗漏，不解的，再QQ，面谈，再回去码代码。好不容易码完了，自己也测试了，运行通过。准备给甲方试用了。内部测试？省了。

      结果是甲方一用，问题就来了：

     数据没显示（检查发现甲方用的SQL Server2000，开发用的SQL Server 2005），“靠，不早说”；

     这个报表怎么不能直接看数据，要导出后才能看？“当初就说报表数据导出功能，要在线预览？（要啥预览）”，“当然了！”；

     “这个上传excel数据的功能怎么不好用，数据传不上，停在那没反应”，“那个excel发给我调试下”。发现是excel里数据格式不符合要求。简单的就直接和甲方说excel里数据格式不对，改下再上传。有些甲方会要求，“那加个下载导入模板的功能呗，不然我们也不知道怎么填数据”，看，工作量就这样增加了。

      需求都知道重要，因为她是后续工作的基础。却由于过度自信（做过类似的项目）或者自身业务、技术能力有限，草草了事，急着进入开发阶段。到了开发阶段，甚至后续的测试，上线阶段发现重大问题，才想起问谁做的需求，去确认需求。这时就开始暗生隐患（什么隐患？很多，后面会提到）

     需求做得不到位，带来的直接影响就是，返工，项目范围扩大。当然如果有经验的，敏感的开发员在码之前发现需求问题了，会找经理或甲方确认下，再开始，避免了一次返工；至于说项目范围扩大，这是大概率事件，很少说需求变了，项目范围缩小的。接着就是开发周期延长可能性增加，交付上线时间推后，成本增加，合同额会有扣款。

     我就遇到一个项目，20w的项目计划1年完成，光开发人员平均3-4人，结果做了5年，明摆着是亏钱做。技术不行吗？都不是第一天做程序，也不是公司的第一个项目，最大最根本的问题还是在需求。可能会好奇，这是把需求做成什么样了，才能搞成这样。绝大部分模块都改版3次以上，很多达到5次，能不延期吗。没有需求管理，变更控制吗？像样的需求说明书都没有，这些又怎么会有。再者是客大店小，主动权在人家那。这里也就不去讨论什么管理，规范问题了。只为说明需求的重要性。

     上面说到需求出现问题时，会暗生隐患。到这里隐患都开始浮现出来了。上面也只说到一点，延期、成本上升。还有其他隐患：影响人员斗志士气，影响团队稳定。虽不是打仗但也讲究这个。

     开始做新项目了，多少有些兴奋的。慢慢的就是烦躁，抓狂，离职。团队不稳定，水平也就不稳定了。听到过甲方说“你们怎么又有人离职啊，我这个项目还有多少人在做”。真有些项目是能把人做跑的。

    作为小负责人你就要不断的给新加入的人培训，还得解决他的各种琐事，什么找不到依赖文件，什么开发环境配置不好；偶尔来次什么误删除啊，你就头大了。最后整个团队都没斗志了。想不延期都难了

     需求不明还有一个隐患就是，技术选型受阻，都可能要重签合同。在正式开发前都会进行架构设计，技术选型，选组件，选框架。本以为满足项目要求的，后面却发现不行，要重新设计，要用到高深的，复杂的，不熟悉的技术时，开发起来都觉得心是颤抖的，万一开发到一半进行不下去了，是自己去造轮子，改造轮子，还是另找轮子。自己造时间不好把握，另选轮子，之前的工作可能要推倒重来，骑虎难下，两难选择，能把人愁死。

    需求的重要性不言而喻，却是在多少人填了多少坑，抓了多少狂才意识到的。只希望以后少些坑，少些抓狂。没有是不现实的，因为唯一不变的就是：需求变更。