非标题党，最近接手公司一个新项目。该项目已经另一个同事接手一年多，有需求文档、架构设计、用户提供的方向文档等资料。看似资料很多。但真正跟两个资深同事去问：该项目的具体需求点到底是什么？他们说不清楚，并且说用户也不清楚。
你有没有碰到过这种奇葩情况？你是如何解决的？
1、反思同事为什么接手项目一年，需求都没有定？
反思后，总结原因如下：
1.1 商务合作形式一直没彻底谈拢。
1）高层只是签署框架合作协议，甚至设定好利益分层。谈的都是大、宽泛、利益相关问题。具体可行性分析、需求、项目周期估算都未具体涉及。
2）多次调研都被客户所左右，只知道客户人脉很广，能打通关系。但仅限于此。
3）沟通多以口头沟通为主，几乎没有邮件来往记录。没有任何证据留下，换新接口人的我们了解信息非常不对称、非常有限。双方前期借口人甚至都不知道说过什么。
1.2 项目一直没有正式启动。
1）商务层面没有到位，导致项目迟迟没有启动。
2）走访用户后，没有形成说明文档记录用户真正需求。仅仅是根据沟通猜测用户需求可能是什么？成文后也没有给用户反馈确认。沟通大忌讳——单向沟通，以为自己都说非常明白了，实际对方没听懂。
1.3 人员对接不到位。
对方一直是销售人员在和我们研发人员对接。导致沟通结果是：对方销售人员说，我们需要个基于XX标准的XX数据平台，赶紧做出来给客户展示，再谈进一步需求。但作为研发的我们真正需要的是：用户的真正的需求点是什么？如：
1）标准涉及的业务能否讲解下？
2）标准如何数字化、字典化？
3）标准细化后正确性如何考量？
4）是先数字化，还是先制定接口规范？
5）接口规范使用什么规范？RESTful API 还是其他？
6）需要什么样的数据平台？
7）数据来了仅是存储吗？
8）数据需要分析、展示吗？
9）用户想要哪方面展示？
10）用户需不需要搜索数据？
11）以什么格式交互数据？JSON、XML还是其他？
12) 各子平台如何跟我们交互数据？
13）各子平台目前数据是如何存储的？
等等等等…….
这些点都没有做过任何沟通过。
1.4 需求未达成共识。
1）有大致几个需求点，但是不是用户想要的需求。没有确认过，从这点讲，需求未达成共识。
2）几乎没有任何对方提供的需求的文字化资料。全是口头转达的，之前也有分析，信息传达中，太多太多不对称。
2、开发必然基于需求。
不论是瀑布模型开发、迭代/敏捷开发，我个人认为，开发必须基于需求，这是铁的事实。
项目、产品实践经验多次表明，即便有需求，实际开发中也会基于各种因素导致需求变更，影响项目整体进度，更有甚者导致项目重来。
没有需求的开发，开发人员无法进行总体设计、详细设计，也就无法编码，整个项目无法开展。
3、需求总会有的——从业务入手深挖用户需求。
对方的确不懂技术，但至少对方非常懂业务啊？我们要变被动为主动，从以下三个方面入手，引导对方、梳理清楚对方需求。
3.1 以业务为抓手，梳理对方需求点。
方式一：通过全方位沟通，了解用户需求。做到：不厌其烦，直到问明白为止。
方式二：现场去实地考察、跟进其办公，深入了解客户需求。
3.2 引导对方表达需求。
对方表述的时候，可能只善于描述业务。可以通过类比的形式，问他是不是想要这个——比如：类似“百度的搜索框”，输入任何信息都能检索出来。
其实翻译成技术人员的话，就是对方需要进行全文检索。
正确的方向性引导非常重要。
3.3 产品经理形成文字找对方确认。
有了一些阶段性的需求后，要梳理成文字。以邮件形式给对方确认。确认后，1：ok，那就让对方说明下ok。2：需要修改，对方会提进一步需求。那么就在此邮件确认，重复1,2。直到全部ok为止。
这样以后，需求才是客户真正想要的需求。
没有搞不定的需求，只有不善于动脑的技术团队或者负责人。
4、 变更项目负责人是个极大的风险因子。
项目负责人选定的时候，就要进行全面的考核。跟了一年了，再换负责人，说明了：
1）之前评估不到位，选人出现问题，要反思。
2）该负责人的确有某些缺陷，不适合跟进该项目。如需求不定的情况下，不积极主动沟通、态度问题等。
3）该项目负责人有新的更适合的项目、紧急重要程度高的项目要处理。
但以上3点，在项目负责人选定的时候都要综合评估。后期的换人，的确对团队会有很大影响。适应性、时间、进度方面都会受很大影响。
2016-6-1 pm23:59 思于家中床前
作者：铭毅天下
如果感觉本文对您有帮助，请点击‘顶’支持一下，您的支持是我坚持写作最大的动力，谢谢！
