理顺软件开发各个环节-3
4 需求管理
需求管理，属于需求工程（Requirements Engineering,RE）范畴，一般情况，不做区分。
需求（Requirements）是软件产品的起点。询问软件人员，什么对软件产品最重要，大部分人的答案是需求，可见需求在软件开发中占据的重要位置。
然而，据我所知，大多数软件人员对需求的理解并不准确，结果导致软件开发常常遭遇需求困境。软件开发没有阶段性里程碑，需求加入很随意，结束更是遥遥无期，更有甚者，某些需求与本系统关系不大，也被硬塞进来，系统结构越来越臃肿，系统弹性越来越差，令人抓狂！
4.1 需求的三个层面
我认为，需求分三个层面：用户需求、产品需求和软件需求。
用户需求，是产品需求的驱动和源泉，来源有：竞品分析，潜在客户的调研，已有用户的提供的资料、调研、建议和投诉，往往由市场人员、销售人员、客服人员收集。有时候，用户需求是不清晰的，因为用户自己也无法描述清楚其到底需要什么！
产品需求，是从用户需求中裁剪出来一个需求集合，这个需求集合能够发挥公司的优势或者符合公司的战略发展方向。确定产品需求的时候，必须要承认，企业资源和能力是有限的，不可能让所有人都满意，有所为有所不为，这就是产品经理的工作职责所在。
产品需求，是用业务语言表述的，基本是用户可理解的，通常表现为特性需求列表，即feature list。
软件需求，是根据产品需求，进行分析，整理，并辅以初步的架构设计。针对每一个需求项目，描述各类用户类型的用户场景，正常过程、可选过程、异常过程及非功能需求。还应包括性能需求和各种质量属性需求、接口需求等。
软件需求分析，是将产品需求转换为软件开发人员能够理解的需求项，软件需求和产品需求并非一一对应关系，但软件需求的全集应该可以覆盖所有的产品的需求，并且软件需求还可能增加软件自身的某些需求，如抽取某个公共模块以提高模块可重用性、提供多模块化框架需求等。
4.2 用户需求收集
用户需求的收集是持续的。
产品在任何阶段，都需要持续关注用户需求。
不同用户的需求权重是不同的，需求优先级也不同，一般情况是市场或销售会反馈用户的需求，新的竞品也需要研究。
对于项目类软件，即使目标用户单位确定，也不意味着用户是一类，仍然需要保持沟通，收集有用信息。
客户投诉也是一类用户需求，表明产品已有功能存在缺陷，影响用户体验或工作开展。
用户需求应归拢到产品经理那里，由其组织人员进行需求分析，裁剪需求，确定在哪个版本支持新需求或对已有需求进行变更。
还有一类资料来自于客户，但只是技术文档，如接口文档，这类可以直接交给开发团队，作为外部接口文档。
用户需求有必要进行管理，如使用知识库之类工具进行管理。
如果公司产品较多，客服、销售或市场一时难以区分归属哪个产品经理负责，公司也可以安排一个需求收集的产品助理，由其与各产品经理沟通。
4.3 产品需求分析
产品需求分析是软件产品的起点。产品需求分析的输入是用户需求，输出是产品需求规格书。
一个合格的产品经理不是客户需求的简单传递者，而是将各类用户需求综合考虑，再结合公司的战略发展方向和资源优势及限制，产品采用的商业模式，确定产品需求集合。
产品经理对目标市场、目标用户了解的程度，决定了产品需求分析的质量。
我认为，产品需求应重点考虑下列情况：
-
可用性，不会因为某些功能缺失或性能障碍导致用户实质上无法使用产品；
-
产品有哪些类型的用户，不同类型的用户诉求是什么？现状情况有哪些痛点？
-
竞争产品的哪些优点必须保留，能否进一步强化；
-
不要轻易去改变用户的使用习惯，如果需要，要准备付出市场教育的成本；
-
特色功能（卖点）的价值论证要充分；提高特色功能的易用性；
-
研究有哪些商业模式，对软件产品的需求会有什么影响？
4.3.1 产品可行性分析
理论上，产品可行性分析在产品立项时已经论证。但随着产品需求的明确，各需求项的可行性仍然需要仔细分析，如果代价太大或有法律风险，应及早想法应对。
对用户需求进行裁剪，分析整理出产品特性需求，即feature list。
针对每一条产品特性需求，应说明：
-
用户类型是什么？
-
提供什么价值或解决什么问题？
-
需求的优先级；
-
有何限制条件？
-
实现是否有技术障碍？
-
实现代价多大（大中小量级）？
-
是否有专利、监管等法律风险？
必要时，产品经理可组织预研工作，以验证技术可行性，消除技术障碍。
如果一切没有问题，即与最初的可行性研究报告没有大的冲突，表明一切顺利；否则就需要评审或公司高层决定进行相应调整。
然后可进入下一个环节。
4.3.2 产品版本规划
产品版本规划，即将产品需求集合划分不同的子集合，并计划产品路线图，明确各里程碑的功能集合。
产品版本规划，可以给各方一个整体产品轮廓，在哪个时间节点提供哪些产品特性。
实际上，很多时候前几个阶段规划相对靠谱，后面的阶段随着用户使用产品给出的反馈，往往会有较大的调整。
4.3.3 MVP规划
最小可行产品（Minimum Viable Product，简称MVP）。快速地构建出符合产品预期功能的最小功能集合，这个最小集合所包含的功能足以满足产品部署的要求并能够检验有关客户与产品交互的关键假设。用最快、最简明的方式建立一个可用的产品原型，这个原型要表达出产品最终想要的效果，然后通过迭代来完善细节。
如果采用MVP开发模式，需要确定当前MVP及下一个MVP迭代的产品需求集合。
MVP的迭代方法，相当于是先从产品需求集合中抽取出骨架，然后逐渐丰富血肉，从粗糙的原型逐步过渡到精细的产品。
MVP迭代方法，可以确保核心功能和系统结构的稳定性，即使有问题，也是最早被验证和发现的，因此，开发代价最小，且始终与用户保持着沟通，反馈，符合敏捷开发的精神。因此，值得提倡和推广。
规划MVP需求集合，可从回答下列问题出发：
-
核心用户是谁？
-
核心功能是什么？
-
围绕核心用户和核心功能，还需要哪些次级功能和更周边功能？
-
次级功能和更周边是否必须开发实现？能否直接先配置数据，暂不开发？
-
性能指标、并发可用性、系统可靠性、数据规模和积累速度等有何需求？
规划了MVP迭代的功能集合，然后进入产品需求细化阶段。
4.3.4 产品需求细化
不管是否使用MVP迭代开发模式，产品的feature list对于开发来说，实在是太粗线条了，因此需要细化。
如果有交互的功能需求，一般会进行UI&UE的交互设计，这方面有一些交互设计软件，如比较流行的Axure RP软件。
UI&UE设计，如果采用MVP迭代，不必一开始做得很精细，即采用低保真模型即可，避免原型有问题被丢弃产生太大浪费。
在瀑布式开发模式时代，会要求整理一份产品需求规格书，现在，即使是敏捷开发模式，这份文档同样需要。有时候，为了减少文档工作量，可以针对相关的功能集合，出一份脑图。
4.3.5 产品需求评审
产品需求评审，由于涉及人员较多，分不同目的评审为佳。
产品版本规划或MVP评审：
-
用户代表（市场、销售、运营、客服人员等）：审查需求优先级和需求完整性；
-
公司管理者：了解产品的成本、开发代价、产品特色和竞争力；
-
项目经理：项目实施组织者；
-
技术人员：一般是系统分析员，审查需求的技术可行性；
-
开发项目经理：了解产品的需求，开发资源是否可以保障项目实施；
-
测试经理：了解产品的需求，测试资源是否可以保障项目实施；
-
运维经理：了解产品的部署需求，运维资源是否可以保障项目实施；
-
其它必要的人员：如法务等。
产品需求评审：
-
用户代表（市场、销售、运营、客服人员等）：审查需求优先级、完整性和需求描述是否清晰；
-
项目经理：项目实施组织者；
-
技术人员：一般是系统分析员，审查需求的技术可行性；
-
开发项目经理（或代表）：了解产品的需求，开发资源是否可以保障项目实施；
-
测试经理（或代表）：了解产品的需求，测试资源是否可以保障项目实施；
-
运维经理（或代表）：了解产品的部署需求，运维资源是否可以保障项目实施；
-
开发组成员：了解产品的需求，便于后续开发工作；
-
测试组成员：了解产品的需求，便于后续测试工作。
评审是软件产品质量保障体系的一个重要环节。是集公司众人之能力，减少差错、降低风险的一个流程节点。
4.3.6 录入用户故事
在敏捷开发时代，用户故事是一个高频词汇。
用户故事代表了一个产品的需求项，当然一个用户故事可以分拆为更多下一级的用户故事。
非常认同网上的一个观点，用户故事是产品经理与开发的一个约定，大家一起将此需求澄清。
因此，那种认为用户故事就是产品经理的事的观点，绝对有问题。这种观点的结果，往往是开发人员经常抱怨产品经理给的需求不清晰，相互扯皮，影响开发进度和质量。
关于用户故事怎么写，网上有太多的资料，我的理解：
-
故事名称：含义明晰，无二义；
-
故事描述：角色、需求、目的表述准确；
-
故事唯一的产品需求编号：稳定性；
-
需求优先级必须有；
-
验收标准：必需项，如一时无法确定，可留待软件需求分析后补上；避免标准过于严苛或太宽松。
用户故事可能包含的附件有：交互设计原型，外部接口文档；还有部分需要软件需求分析后进行补充，包括软件需求规格书（SRS）和数据字典（DD）。用户故事可以引用相关章节或编号。
