编辑导语：在我们的日常工作中会接收到来自不同方面的需求，一个产品是由很多需求慢慢组建而成，需求对于每个产品来说是非常重要的；从初期的需求分析到后期的实现，中间要经历一个漫长的周期；本文作者详细分析了一个需求完整的生命周期，我们一起来了解一下。

作为软件行业从业者，无论岗位是产品、UI、测试或是开发人员，我们每天都在面对着不同层次、不同性质的需求处理方案；有的需求条条顺顺，大家都能理解这个忽然产生的idea，有的需求则不然，每个小时都可能变了变样子。

需求，是横在产品与各岗位之间难以跨过的长长沟壑。

本文将从需求的产生开始，按照如何产生、如何进行分析，再到需求实现落地，需求变更的行文思路进行阐述；试图分析一个需求完整的生命周期，将过往工作中踩过的坑暴露出来，对其进行总结复盘，提升自己对需求理解的同时也为刚入行的产品从业人员或有志于进入本行业的相关人员起到建议与帮助。

需求生命周期

一、需求的产生

无论是ToB，还是ToC，一个需求的产生离不开业务逻辑与产品本身。

笔者认为，需求首先来源与外部，在由外部逐渐过度到内部迭代，之后会进入外部内部同时并行的状态；外部需求不断产生，为产品注入新鲜血液，使产品更好的发展，内部需求则不断完善自身，为了适应新需求不间断的提供支持。

象限图

需求从来不是凭空产生的， 但是很可能很表面或看起来不合理，每一个看似不合理的需求都有目的性，而这个目的性不一定是不合理的，产品从业者的目标则是将需求的不合理翻译为本身合理，并判断其目的的价值。

1. 翻译需求

这是一个专门的学问，前辈们花了无数的口舌也无法对每个步骤都讲的清楚明白；在本篇文章内笔者只对自己的工作方式进行简短描述，合适与否则根据工作流程与习惯的匹配程度有关。

我常常会在工作中采用这样的方案，本质上是基于WHY、WHAT、HOW的工作法则。

2. 需求的组成

一个需求的价值由于它的使用场景决定的，一碗面，在景区、飞机场等场所，由于运输不便，食材稀缺等等原因，可以买到88块甚至更多一碗，但是在大家小区楼下也就是十几元一碗就可以买到；同样，将梳子卖给和尚，也是由于场景决定的价值所在，所以我们在在考虑一个需求的组成时，可以给出这样的结论：

• 需求的使用场景带来需求的价值；
• 需求的价值决定需求的真伪；

需求的组成部分

3. 多问为什么

即在每个需求提出时，需要让需求提出者尽可能的多描述需求，包括为什么想要这个功能？是否是原来功能的迭代升级就可以满足？实现了这个功能之后打算什么做？是否会有后续的计划？找到每个回答里的关键字在进行延伸，总之，就是抛出一切能想到的问题。

但是很多时候，一个问题的提出者，在提出问题时并不明白究竟想要一个什么样的回答，没关系，解决办法就是不要在无谓的争论下去；在大概的商讨过按照你自己的想法做出来第一版原型稿后，他总能知道哪些不是他想要的，这时，就会拿出很多想法与“建议”，毕竟，否定别人对每个人来说都很容易。

需求翻译方法论

4. 多沟通

多沟通是指多跟项目内部的技术人员沟通，如果你不能通过硬实力说服Team内的技术人员按照你的的方案实施，那么最好有那么一两个关系较好的；在想要做某个功能，或在工作过程中遇到了哪些问题，可以多跟他们商量。

有时技术会提出更好的解决方案，对于刚入行还不太懂技术也不太懂需求的产品人员来讲，避免出现类似“根据手机壳更换主题颜色”的需求是十分必要的。

另外，开发人员作为最下游的实施人员，大多数时候只是被动执行产品做好的规划，我们在问其对某个需求的意见时，也意味着我们希望开发人员能够主动参与到需求规划中，让开发人员有一种“我也为需求贡献了想法并有机会能够实施”的认知；这种行为的好处会直接体现在对功能细节的处理程度上，他们会更加认真对待你的需求，因为产品在前期也尊重了他们意见。

5. 多天马行空

要知道并不是指对需求天马行空的想象，我们首要确定的就是对某个需求的定义，如果需求变来变去，今天是A，明天是B，那你只会离你的需求越来越远。

所谓想象是指在保持一个标准下进行的，每个功能并不是只有一种解决方案，每一个按钮也可以放在不同的位置。我们在处理每个功能的时候，尽量进行不同的功能结构方式，有时会有意想不到的效果。

二、示例

我前阵子接手了一个管理社区精神病患者的项目，项目背景是，近年来，精神病患者肇事肇祸、扰民害民的案（事）件在各地时有发生；如何创新管理模式，减少精神病患者肇事肇祸行为的发生，正在成为各地普遍面临的一个难题。

针对这个背景，里面有一个具体的需求是为精神病人设置电子围栏；社区、社工认为，精神病患者虽在平日里与正常人无异，但是一旦发病则无法控制自身行为，对社会、群众安全及患者本身都存在一定隐患；因此，社区提出了建立电子围栏的想法，如果精神病人发病或超出围栏边境时自动发出警告通知，及时采取防范措施。

需求分析表

按照上文所讲的分析方法，可以快速的帮助理清思路，从而得到一个较为清晰的需求分析表，我们已经确定自己已基本了解本需求产生的原因与想要达到的目的，在假设已满足其余关键需求的基础上。

接下来，请你以你的理解为中心，大刀阔斧的尝试设计一下本功能吧~

以下是我能够提供的需求设计方案：

设计方案

GPS定位

电子围栏报警

轨迹追踪

SOS警报

三、管理你的需求

1. 需求池

管理需求的方式似乎容易了很多，“提出的时间”、“优先级”、“需求的描述”、“处理人”或者“实施的版本”；这些关键字你在任何一个项目协同的平台上都能够找得到，并且还能够根据需求不同来自定义相应的字段，十分的好用。

但有的时候，现实没有我们想象的那么方便，比如你们公司对数据的保密性很强，不肯将项目内容转移到线上，亦或者公司环境导致同事大多习惯使用EXCLE、WORD等方式进行处理数据，那么推进大家使用线上协同进行工作的难度就一下子增加了很多。

为了你自己好，最好不要过多依赖过于便捷的内容，过于简单就能得到的帮助会逐渐剥夺你思考的能力，一旦脱离平台，你会忘记如何配置他们，所以在多数情况下，你需要建立属于自己的需求池。

本文不会对需求持的要素进行大篇幅的介绍，这些内容其他作者的文章会有更好的见解，不同的组合方式会适应不同的场景，如何将别人的变成自己的才是正经事；如果你一定要在本文找到答案，在文章的末尾我会附上一些内容。

2. 需求沉淀

在实际的工作过程中，经常会需要客户/用户每天每时每刻都在反馈系统某处出现了BUG或提出问题，而有的产品人的解决方案是收到了BUG就原封不动转述提交给=进行更改或开发，停留在BUG只是BUG的层面上。

不仅会造成重复的工作量，也会打断开发人员正在进行的工作或书写的逻辑；产品无法对负责的需求负责，也会给人造成只是需求的中间人，无法把控需求的印象。

我倾向于将BUG作为广义上的需求的一种，狭义需求当作一种正向需求，而产生的BUG先定义成待确定、未进行分析的需求

无论是通过某种方式分析后，你有可能发现它并不是BUG，可能是由于某处逻辑不清晰产生的，也可能是由于字段填写不对称造成使用误解。

只用五秒种是看不到问题的本质的。

但有时我也会对某种情况产生疑惑，有人会觉得这样的匆忙是正在工作的表现，如果将问题梳理的仅仅有条，提高效率缩短了处理所需要的时间，反而因为没被看到所以被质疑；也有开发人员不介意更改或过多的处理临时的需求。

目前正在考虑这个问题。

四、为什么更改？

我们必须要承认更改需求的需求客观存在的事实，也必须要承认我们每天都在面对着这些问题。

“ 唯一不变的，就是变化本身。”——斯宾塞·约翰逊

1. 需求的认知

人们认识世间事物的过程总是由浅入深，最开始展现出来的总是冰山一角，无论是甲或乙对某一需求的理解与规划也是随着时间及了解的深入程度才逐渐变得清晰明了；而初始提出的方案渐渐不能满足后续的发展。

2. 沟通的层面

项目中，每个步骤都环环相扣，随着团队规模的扩大，参与的人员越来越复杂，对同一事物沟通的次数也越来越多，哪些重要的、必须要注意的细节则更容易在言语间流失。

3. 技术的壁垒

同一个功能，不同的产品阶段、不同的参与人员，都会产生不同的结果，而技术日新月异的更迭为我们提供了更多样的处理方式；方案并不是一成不变的，我们需要做的只是在合适的时间选择合适的方案。

五、结语

马斯洛的方法论最上级的需求是“自我实现”，产品工作的有趣之处大部分也源自于此，自己的理想与目标经过无数的日夜后实现落地，提供创意的人在其中会获得极大的成就与满足；而需求，是一切的开始与结束，是一切发展的基石，产品从业者始终在学习如何更好的理解它。

当你真正理解你的需求的时候，需求自然也会理解你。

需求池的要素：

要素梗概

本文由 @kolulu 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议