协同作为企业级的管理软件，注定其需求管理是复杂的，应用交付也只能是顾问式的，要走到纯纯的产品交付模式还需要一段不小的距离。

昨天刚刚拜访了一家客户，发现客户的需求与他在招标文件中所写的还是有比较大的差距，而且很多客户的需求是属于静默中的大多数，是没有表达出来的，如何采集到有效的需求对于产品开发这种严重滞后的需求响应变得更加的重要。

以下几点是我这些年总结出来的，给产品经理和做项目的同好们分享：

1. 选准客户中的具体的部门和人员，如果是探索定位，找到客户高层几乎是必须的，如果是关键应用需要访问到具体的使用用户，如果是信息技术和最新的环境需求，找信息部即可；

2. 关注核心需求，直接客户不像渠道伙伴和行业内的人事，他们不可能也不会深入全面思考行业的发展，而是关注自己企业的事，因而他们的需求也是最直接和有效的，需要关注的是客户的需求是重要的吗？客户是否愿意为此付费，愿意付多少，往往这一类的发问和分析对于需求的价值获取非常重要，也是客户价值主张的关键；

3. 客户为什么有这些需求，需求是谁提出来的，为什么他（她）会提出这种需求，这种需求的应用场景是什么，给客户带来的价值究竟是什么，这里的价值指使用价值；

4. 客户的需求要求急迫吗？这个问题看似一个显而易见的问题，实际上不是的。一般需要整理和回答客户是有难度的，因为客户不会告诉你答案。准确地获取结果需要分析这个需求响应和不响应对于客户的行为的影响，这一点特别重要，必须要思考的是没有系统之前客户是怎么解决这一类问题的，有了之后行为会有什么变化？

5. 客户为什么是现在而不是过去或者未来上系统，上系统对于信息部、关键用户部门（如办公室）、领导意味着什么，掌握时间阶段和节奏有利于对需求响应列出时间轴或者产品路标，而不仅仅是拍脑袋。

6. 需求归类，以客户应用模型和方式的归类是客户应用体验提升的关键，这里需要考虑客户哪些事件会集中处理，行为过程如何，注意杜绝假设而不验证假设。还要注意产品应用需求提炼的完备性和整合性，如何将多个需求整合以降低成本，这是另外一个方面的归集。这些年来个人犯的比较多的错误往往是以成本作为关键因素而不是需求，提醒同好不要有这样的思考错位，因为只有做出有价值的东西，成本才是有效果的。

当然，需求采集完成后，做出一个模型就变得很重要了，这里不再列出。

最后，多和开发人员沟通，你会发现他们比你想象的聪明，并且很多方面比你更懂系统，更有体系化的思考。。。