架构设计 - 需求分析篇

前言

一个开发项目的成立最初是由一群有开发需求的人提供了自己的想法，思路。根据一系列需求发起者的描述，反馈，总结形成了我们的开发项目。

本文就这个过程展开讨论，分析出在沟通过程中可能遇到的问题点，想起一个段子。

需求发布者描述的是战斗机 > 产品理解成了空客机，之后产品给技术描述>程序员理解成了直升机 > 最终产生的产品为 直升机

探讨

1、需求发布者有完善的需求体系，但对方描述的需求模棱两可，抓不住她的想法点，怎么办？
多沟通，要仔细了解清楚对方的需求中心点（如商超的需求中心在与 买和卖，数据的需求中心在于 查和存和管理，OA办公的需求中心在于 标准和管理），抓住需求中心点后围绕需求中心点展开向对方提问，根据对方的反馈明确需求内容。然后设计系统方案（思维导图），之后根据系统方案继续和对方沟通，直到没有可沟通的内容为止，最终得到的就是用户完整的需求。

2、需求发布者自己只知道一个大概的方向，没有形成体系的需求反馈，怎么办？
这种需求发布者很多，很多人都只知道我想要这个东西，但这个东西具体是什么样的又说不出个所以然。

这个时候就可以发散思维。抓住对方的需求中心点，围绕这个中心点设计系统方案（思维导图），给用户描绘我设计的系统有什么功能，能帮助你完成什么事情，如何引流，如何扩客，如何使用等。 这时候就可以加深和对方的沟通了，对方看到这个以后他的想法和思维就开始灵活了，在此基础上你就可以对自己的方案进行调整，最终得到的就是用户完整的需求。

3、当自己理解需求后，现在组建了一个小团队来开发这个项目，如何让自己的组员能和自己的思维同步，思想不滑坡？
先开一个长会，让所有的同事先从宏观上了解系统需要解决的问题，以及需求发布者明确需要解决的内容。然后细分功能板块给不同的同事，并单独对这些同事私下沟通对应负责板块的具体细节（这里是重点，这里一定要沟通好）。让每个同事对这个项目有一个全局的了解，并对自己负责的板块有一个深入的了解。

4、需求发布者提供的需求一会儿一个版本，今天是这个需求，明天是那个需求，后天又改回原本的需求，怎么办？
事先就和需求发布者沟通好，明确需求版本。如需求发布者确实有特殊需要，如今天这个流程要这样走，明天这个流程要那样走，后天这个流程又要换一种形式，针对这种情况，需要和技术说明，让技术采取相应手段，对不同的流程做处理。给需求提供方说明使用规则。

5、需求本身就有冲突，但还是强制要求你完成1+1 = 3这种情况？
直接反馈。

总结
需求的明确在于多沟通，只要沟通的内容足够多，理解的内容才会多。