某公司承担一个大型软件项目的开发，该项目的计划工期为2年，实际工期为2.5年。该项目为本公司新进入的一个行业，公司在其他行业里有相近软件的开发经验，但是对进入的这个行业并不熟悉。本项目采用了瀑布模型，高峰期70多人参与，最少时也有30多人参与。投入了接近100人年的工作量，而浪费的工作量大概在25人年，需求返工的比例占了40-50%。项目结束后做了复盘，我作为外部咨询顾问参与了项目回顾过程。现将关于需求工程方面的经验教训总结如下：
需要保持的做法：
1 小范围的需求沟通与交流效果更好。
在项目进展过程中，曾经把多个岗位的多个人集中在一起进行访谈，发现效果很差，大家讨论的效率比较低，意见难以统一，而且有的人不发表意见，交流效果很差。而当和客户小范围的沟通时，能够把需求沟通的比较清楚透彻。
2 在需求调研阶段，每天召开了例会。
通过例会做了调研的准备，明确了调研的任务分工、调研重点。通过调研的总结，沟通了调研结果，识别了新的问题，调整了后续调研任务。
3 到客户现场与客户面对面沟通需求。
仿造别人的产品来开发新产品存在对需求的理解太肤浅、容易走弯路的现象，实际接触客户，才能深刻理解需求，知道客户为什么要这个需求。本项目对需求进行了多轮调研，需求调研阶段有50多人次的现场调研，客户也有20多人次来公司沟通需求。
需要放弃的做法：
1 没有领域专家参与需求调研与分析。
公司以前只是做过其他类似行业的项目，没有这个行业的领域专家，导致在获取需求时，客户说做成什么就是什么，开发团队的人员不能引导客户提出更合理的需求，只能被动接受客户的需求。在此过程中对客户的需求也理解的不透彻，导致在开发进行了12个月后，给客户的产品演示效果很差，客户认为我们没有真正理解需求。
2 不要相信中间人传递的需求。
负责系统实施的工程人员全程参与了本项目，有时由他们传递的客户需求导致开发团队的理解错误，很多需求返工由此发生。
3 销售人员给客户的承诺太多。
在售前阶段，销售人员给客户承诺的功能太强大！导致客户的期望值很高，认为系统是万能的，并提了很多不切实际的需求。需要给销售人员定义作业规范，明确规定什么样的需求是不能承诺客户的。
4 客户方的项目经理实际就是接口人，不能进行及时的需求决策。
一定要对需求，对系统的方向有决策权的人参与到项目组的活动，否则可能存在客户不确认需求，或者确认了需求而后又不认账，或者延期很久才确认需求的现象，不负责任的甲方项目经理是项目失败的重大风险。
5 不能让客户在投入很多工作量的开发后才进行阶段性的确认。
本项目是进展了一年之后才让客户对初期版本进行了确认。结果客户很不满意，认为我们已经跑偏了，需要大规模返工。因为我们应该尽早的让客户参与进来进行确认，确保及时纠偏。
6 本项目有很多人参与了需求调研，但是大部分人没有经过需求工程的专业训练。应该对参与需求调研的人进行需求调研方法的培训，避免有的人没有经验而导致需求质量比较差。
需要新增或加大投入的做法：
1 在需求描述中应该明确告知客户什么是本系统能做到的，什么是不能做到的，通过描述不能做到的来澄清需求的范围。
2 组织级应定义需求有关的规范，指导需求人员进行需求分析。
3 在需求访谈之前应该准备好问题清单。
4 在需求调研之前要事先了解客户的背景、业务、企业文化。
了解了客户的背景、企业文化才能知道为什么客户会有这些需求。
5 测试人员应该参与需求的调研，在需求评审前或需求评审时要评价需求的可测试性。
6 客户确认了需求原型之后再进行开发。否则可能在错误的方向上做了很久了，才发现跑偏了，造成大量返工。
7 在本项目结束后对本项目的领域经验进行总结，形成知识库，包括所有的业务术语，业务规则等。以便于后来参与到项目组的成员了解业务。
8 紧急需求的修改可以采用结对设计、结对修改的模式。
综上所述，当我们再做类似的项目时，应遵守的铁律为：
1 一定要有领域专家参与项目！
2 一定让客户进行阶段性验收。最长每3个月让客户确认一下产品完成情况！
3 采用迭代或增量模型开发，不采用瀑布模型！
4 在动手开发之前采用原型法让客户确认需求！
5 甲方一定要有对本项目真正负责的人参与进来！
大项目的失败总是处在项目管理的宏观策略上。事后看我们得出这些结论很简单，但是当我们在“局”中的时候却没有这些清醒的认识，当在项目进行中却总是认为当前的选择是正确的。前车之鉴，后事之师，惨痛的教训让我们成长！
