需求调研不充分是一个“坑”“泛项目”注定项目失败

项目管理是一种实践，其本质不在于知而在于行；其验证不在于逻辑，而在于果。

项目干系人（特别是发起人Sponsor）往往会对项目团队成员说“这个项目任务你跟进一下”、“这个项目任务要在一个星期之内完成”。

但“跟进一下”是什么意思？项目干系人并没有把要“跟进”到什么程度给项目团队说清楚（不遵循SMART法则），在执行过程中，我们不能奢求每个干系人都能把“跟进到什么程度”说的很清楚，但是作为专业项目管理者我们能决定的是，自己会用怎样的态度去对待这个任务：如何理解这个需求、如何安排这个任务、如何监督这个任务的执行工作等。

项目的任务必须满足SMART法则。所谓SMART法则，即目标必须是明确的（Specific）,必须是可以衡量的（Measurable），必须是是可以达到的（Attainable），必须和其他目标具有相关性（Relevant），必须具有明确的截止期限（Time-based）。而且这五个原则缺一不可。

关于这个法则，在我的相关著作、博客、网站上都有详细的探讨和实例，读者可以参考。这里我主要探讨项目任务执行的过程中需要注意的问题。

一．“泛项目”注定项目失败

现实的项目中，真正能够理想化地将工期、费用和质量目标在启动前就能够定义清楚的项目、能够完全按照商业合同来规范启动的项目只是少数。

更多的是我们可以称之为“泛项目”的项目，即不能预先将项目目标、范围等定义清晰、只能大致明确其目的的项目。

伊拉克战争就是“泛项目”，人们在发动前只能确定它的开始时间，不能确定其结束时间，也不能确定其费用、WBS、Gantt图等规范项目管理中需要的数据和方法；同样，新产品研发（如抗SARS药物的研制）也是“泛项目”，人们无法预知该项目将遇到何种技术难题、它们究竟需要多长时间才能攻克。

“泛项目”占了各类组织项目中的大多数，真正能够规范定义的项目在数量上只是少数。通常“泛项目”不像大型的、正规的商业项目那样引人注意，但由于其数量极多，如果不加注意，它们会像《笑傲江湖》中任我行的吸星大法一样将组织的资源消耗殆尽。

二．需求调研不充分是一个“坑”

在软件行业，在界面设计没有正式展现给客户之前，所有的工作都处于需求调研阶段。其实房地产行业已经给我们做好了先例：客户买房子之前是先要看看样板房和模型的，什么都看不到这房子你敢买么？除非你不是自己住！

我们的软件工程模型中，也有三个阶段：需求调研、需求分析、概要设计。

在客户把他们想要管理的业务模块以及与之相关的业务数据、流程、表单交付你的时候，你千万不要把这个阶段定性为需要调研结束，认为写出《需要规格说明书》就可以了。大量的实践证明，在概要设计阶段所衍生出来的需求工作量是之前的5~10倍，甚至更多，因为这要看设计人员的业务沟通能力和建模水平。

有实施经验比较丰富的项目管理人员总结说，在中国实施软件项目，必须以咨询方式展开：要推出自己的方案，而不能完全按照客户来提需求作项目。这是一种很好的解决思路，但无法解决所有实施项目的难题。这种解决方案的前提，要么项目实施者有成熟的业务模型，要么有成熟的产品(包含了成熟的业务模型)，否则是不可能做到的。但如果没有3~5年在同一行业，同一领域的实施经验和理论总结，没有哪家IT企业能达到这样的前提要求。

其实得出这样结论的深层原因，是因为国内多数企业管理思想不成熟，更谈不上完善的业务模型，所以客户的思维一定程度是发散的，还未形成系统。甚至还有些客户的领导，脑子中有很多新鲜的点子，他都有可能想在企业信息化的实施过程中加进来，这对把控项目范围和项目实施效果来说，都可能是灾难的开始。

所以，要做好实施项目，实施者必须有很好的业务建模能力，快速的给客户展示合理的软件原型软件Demo。

根据多年的项目实施经验，软件实施项目，一定要给用户看到样板房软件Demo，才算需求调研结束！

三．确认需求并执行到位

项目干系人在提项目需求的时候也许没有明确说明他想要一个什么样的结果，但是作为项目经理必须要明确你要给干系人一个什么样的可交付成果他才会满意。

如果你只是想要尽快完成项目需求，却不去考虑要做到一个什么样的程度、验证标准、提交时间等，那绝对是对项目管理工作的一种亵渎。项目经理应该有能力帮助干系人将需求明确到符合SMART法则的程度。

任何一个需求，只要双方确认了，就有责任把执行到位，第一次就把事情做到100%，让自己满意，让干系人满意。

备注：原创文章，未经许可不得随意转载使用。