今天下午开了关于“项目经理如何对接需求”的会议，受益良多，简单梳理一下。

1.0 目前的“软件”分为哪几种形式，我们能做什么形式的“软件”？

（1）无纸化“软件”

脱离纸张...

（2）流程化软件

ERP 系统等...

（3）智能化系统

根据企业存在问题，提出解决方案...

主要做前两种，第三种要求较高，是我们努力的目标。

2.0 对于需求，我们分为哪些，同时对应几个阶段？

需求分为业务需求和开发需求。业务需求是在与客户交流的阶段，通过各种方式挖掘痛点，找出客户真正需要的；
开发需求是在开发阶段，根据业务需求制定的关于系统开发方方面面的，细节性的功能的需求。

3.0 如何挖掘用户的业务需求

3.1 客户在你面前，你是否存在不知如何入手？

进行“破冰”，让客户打开话匣子，聊起来，双方不再尴尬，再过渡到深入挖掘客户的需求。

不知如何入手原因：
（1） 知道要讲什么，但性格原因，不善于打交道
（2） 擅长打交道，但不知道要讲什么
（3） 不知道要什么，不擅长打交道
一些解决方案：
大声读文章 --》对着镜子背诵，观察面部表情 --》去街上进行调查问卷

3.2 客户总是很“啰嗦”地说自己企业的业务流转情况，你觉得很烦躁，甚至觉得客户“傻逼”？

客户可能很啰嗦，说不到重点。我们不能表现出不耐烦，不能让客户看出我们觉得他很“傻逼”，这不仅表现出我们缺乏基本的礼仪，有损个人形象，而且会损害本公司的形象，不利于与客户的进一步交流。我们应当认真倾听，从“啰嗦话”中挖掘客户真实需求。若能力足够，尽可能礼貌地引导客户到正确的方向。

3.3 你是不是觉得客户什么都不懂，只知道说一些不着边际的所谓业务情况？

类似于 3.2
了解客户所在行业情况，脑海中要有系统的雏形，再与客户进行系统可行性相关的、各种实现细节的论证。

3.4 你是不是觉得害怕自己提出的东西被否定？

用于提出自己的意见，有上级领导、公司做你的后盾，但不能过。东西被否定，也是好现象，说明客户知道自己想要什么。对接需求是双向的，相互交流，相互反馈，利于工作进展。

3.5 你觉得还有什么？

3.6 你能够根据用户的企业情况，通过自己做过的，或者知道的项目情况，有没有在脑子里认为客户可能需要做什么样的东西？

这个需要大量项目经验的积累，经验不足的情况下，寻找大量优秀的系统，分析其需求，内化为自身知识。

业务需求最重要的是什么？

将实际需求、客户的真实需求融入到系统开发之中。

4.0 根据几种形式的“软件”，我们在对接需求的时候，需要注意什么？

4.1 脱离无纸化的“软件”，我们要注意什么？

比较“简单粗暴”，可能只需要将单据融合到系统中就可以，风险、周期可控。但是要注意：单据格式正确、单据数据齐全，确保单据是我们系统所需要的。

4.2 有一定业务流程甚至是 ERP 类型的流程性的系统，我们要注意什么？

尤其注意体量大的、多部门的公司，甚至集团，业务流程极其繁杂。
（1）没有专门的负责人，可能需要与很多领导协调，不利于工作进展。建议对方有单一对接人，或者说能拍板的人。
（2）需求对接周期很长，对接前请示领导。
（3）客户需求变更频繁。对于已经确认的需求，我们最好立马让客户在需求文档或者流程文档上签字，以防以后需求变更导致的种种问题。

关于项目经理如何带项目

检验控制
（1）让所有人理解需求，且能复述出来；
（2）看页面，指出存在问题，并要求后面的模块遵循相同要求；
（3）看代码，团队统一代码规范，团队成员间互相阅读无障碍；
周期控制
开发周期 + 测试周期 + 改 bug 周期

关于项目 A 存在的问题及反思

（1）病态的合同关系
客户甲与公司乙签订合同，项目有公司乙完成；公司乙再与公司丙签订合同，把项目外包给公司丙做。
公司乙所理解的需求与客户甲的真实需求有所偏差。公司丙理解的需求与公司乙有所偏差，与客户需求则偏差更大。需求问题是个大坑。

尽量不做二包，最好能直接与客户交流。

（2）初期没有让客户确认需求
仅靠口头约定，客户可能会出尔反尔，或者强加各种额外需求。

为避免这种情况，对于已经确认的需求，我们最好立马让客户在需求文档或者流程文档上签字。如果有需求变化，增加工作周期，提高项目价格。