现在很多软件公司经常会遇到这样的问题。
以用户为代表的业务方抱怨不知道如何描述所谓的需求，因为产品或需求人员总是问一些“奇怪的问题”；我们提出的需求要么实现速度慢，要么根本就没解决我们的问题。
需求分析人员总是抱怨和客户沟通不能，他们不能理解我们在说什么，我们不能理解他们想要表达什么；他们总是有各种理由在正在开发的版本中增加新的功能。
其实大家都在很好的履行本职工作。
业务方关注的是把自己遇到的问题描述清楚，期待技术团队能够帮自己解决问题。
需求分析/产品团队关注实现细节，通过各种方法将客户需求有效的表达清楚，追求这一实现过程的最优解。
但是，不知道大家有没有发现，这中间少了一层。
少的这一层就是“需求架构”。
之前我写过一个系列文叫做“又见树木，又见森林”。
我们在做解决方案也好，产品也好，在做之前首先要弄清楚目标和方向。
架构就是站在顶层，自顶向下，由整体到局部进行事项解决的一种方法。
——《软件需求十步走》
需求架构师就是将业务诉求和价值远景进行组织和分析后，对需求进行规划，然后再给到需求开发人员，也就是我们的需求分析师和产品经理。
其实，在很多公司有这样的角色，他们会负责写MRD，进行高层级的价值分析。
需求规划具体来说包括6项任务。
《软件需求十步走》中描述的比较“教科书”，我顺道对每点谈谈我自己的经验。
业务研究
主要是对业务资料进行采集、收集，然后进行分类整理。
这是我们熟悉的一项任务，但是在需求规划过程中，这个业务研究的范围会更大一些。
因为我们要做规划，并不是做需求开发，所以除了一些常见的业务资料，比如业务流程、人员分工等，还需要对客户的企业规划、市场动向、我们所在企业的发展目标进行资料的收集和分析。
这不是一个短期就能完成的任务，最好我们能有计划有目的的在日常的工作中就开展起来，不断积累。
这样就不至于临危受命，两眼一抹黑。
要知道，信息量不全的情况下，做任何的决策，风险都是巨大的。
资料的完备程度越高，业务研究的越深入，决策的风险就会大大减轻。
应用建模
用结构化的形式和功能数据归约的方法对业务研究成果进行研究。
我们在业务研究之后，还需要进行应用建模。
比如使用流程图还展示业务过程，使用组织架构图来展示角色关系，使用时间轴来展示发展历程等等。
鉴于大部分的信息和资料都是描述性的，我们需要使用抽象的方法，将这些研究成果进行结构化、可视化的整理和建模。
系统规划
根据业务研究中的组织结构、业务事项、业务数据规模和用户对业务目标的期望，并结合应用建模的成果，对支撑这种规模和应用所需的所有信息进行规划。
一家公司想要做知识管理系统，我们通过业务研究和应用建模，再结合客户的软硬件条件发现需要分阶段实现。
那么每个阶段要实现什么目标，建设什么内容，都属于系统规划的内容。
更常见的应用是制定“产品路线图”。
分析计算
将上述三步的结果录入到仿真分析平台中，进行业务逻辑正确性分析、业务所需系统支撑能力、业务发展能力的计算，并给出数据结果，对上述三步的结果进行修正。
所谓的分析计算使用什么工具，如何具体执行，在我看来，取决于你的项目和产品类型。
大部分的互联网产品，或者重前端的产品，可以使用原型进行分析，通过制定一些指标来获取反馈。
而有部分的产品或项目在进行底层框架选择的时候，可以使用一些POC进行分析验证。
如果发现之前的一些信息不一致或者无法很好的达成目标，那么就需要对之前的产出进行修正并再次进行验证。
报告编制
对上述产出进行文字化的正式的描述和说明。
不要无视这个步骤，因为你自己都很清楚，过上两三个月，很多出自你口的信息，你也记不清了。
规划评审
规划评审的主要目的是为了让各个关键关系人达成一致，获得认可。
在规划阶段发现问题并去解决，影响会小很多。
规划影响的是方向
方向如果不正确，再多的努力不仅是事倍功半，更可能是自掘坟墓。
在规划结束后就进入了我们熟知的需求开发环节，包括：需求获取、需求分析……
我们做了太多“埋头拉车”的工作，要知道“抬头看路”更加重要。
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
