始于需求，而终于需求的最终落地

项目一般是由一系列的需求组成的，需求来源于业务，业务需要通过一系列的流程串联起来，按照某种规则和规范循环执行；而在电商企业中的这些协作是通过对外或对内提供的一些软件产品和服务体现的。

产品技术部的工作就是不断打磨这些产品和服务，让其与竞品形成差异化，在效率提升和成本控制上产生优势，所有的这些都源于我们对需求的把握与控制。

无论企业愿景多大，业务战略与IT战略方向如何，都应该始于需求（用户、行业、市场、业务等），而终于需求的最终落地。

一、需求的发现与获取

有些需求是通过业务或产品提出来的，有些需求是自行创新整理出来的，需求的发现与获取通常采用以下几种方式：

1. 访谈

访谈顾名思义，就是通过交谈的方式获取需求；在电商企业中，产品经理需要不定期的与相关人员接触，深入了解业务状况以及即将开展的工作内容，并结合当前的产品及服务收集一些迫切解决的问题和痛点。

访谈分为内部和外部，对于外部访谈主要是针对一些重要客户或有代表性的关键用户（2B型产品采用的比较多）。

我们在访谈前要准备好提纲，在访谈过程中应该带有一定的目的性，集中一些流程或工作节点进行，不要过分的扩散，访谈后要进行梳理总结。

2. 需求调研会

需求调研会主要是针对谈过程中涉及的某些重大问题或企业确定的一个项目所进行的前期准备工作；在这个过程中，我们要确定重要的干系人（熟悉业务流程且可以确定一些流程及细节的人员），可以分别调研，必要时也可以将这些人组织在一起集中讨论。

如果以会议的形式，需要我们要有较强的会议组织和掌控能力，而且要提前准备好会议议题、确定会议时间与地点，在会上要能够按照既定的议程进行。

调研会的沟通效率及结果非常关键，充分、详实的会前准备工作是调研会成功的必要条件，正确的与会干系人选择是影响沟通成果的重要因素。

3. 竞品分析

我们都知道市场相似产品多如牛毛，很多产品都是抄来抄去的，但大部分都是形似而神不似；我们在做竞品分析时应该注重差异化，如何结合企业内部的资源做出区别于竞品的产品，为用户提供更优质的服务才是一个正确的选择。

今天偶然想到在之前公司商城上有近百元的礼品卡未使用，于是乎想用掉，发现原商城地址、小程序、APP都已经下线了（与某生鲜合并了），有点莫名的感觉。

回顾之前做的一些项目，似乎一直在跟着某些竞品屁股后面跑（到店到家、社区团购、鲜花、礼赠、牛奶周期配、旗舰店的堂食等），做的很早但没有优势，又缺乏运营与坚持，这也是企业最终不断的失去竞争力的原因之一。

竞品分析要运用SWOT进行优势、劣势、机会与威胁的分析，找出差异化，做自己的特色产品，拼DD的成功值得我们借鉴。

竞品分析需要了解行业，这里推荐一个小程序「报告查一查」，可以获取一些行业报告。

4. 用户反馈

对于APP和小程序等前端用户产品，企业要实时关注用户的行为与评论反馈；前端需求相较于后端生产的需求更多的是来自于用户，大的公司都会有用研部门，专门负责研究用户。

通过调查问卷或用户评价来收集一些需求时，一定要注意问题的质量，可以通过招募体验官的方式进行（要给予优惠酬金等），注重UGC的内容与影响。

此外，在用户反馈后，我们要根据结果进行分析（问题多数是选择性的），但前提是参与的用户数要达到一定的量才有代表性，否则很容易以偏概全。

5. 数据驱动型需求

数据的获取一方面是对于面向用户的前端产品通过埋点数据，形成分析报表，可以找出问题产生的原因。后端同样也可以通过操作频率、系统日志来分析系统使用状况和服务性能，从而形成整改的需求。

另一方面，对于有些项目或产品，还要针对生产过程中的各种数据进行分析，如缺货分析、履单效率分析、商品报损率、GMV等。

通过数据去驱动一些流程的优化，从而使业务运营得到改善。

以上都是正常的需求获取方法，在互联网公司呆的久了，我们都体验过“快”和“变”的酸爽；很多老板的需求一般都是最急迫的，如果老板对于电商行业与玩法判断不准，通常都是一个失败的项目。

如果为了职场发展，那么首先就要伺候好老板，老板爽了，你就会有莫大的好处，这在有些公司还是比较常见的，所以需求的获取莫要遗漏”时刻琢磨老板想法”这个途径。

二、需求筛选与分类

需求有了，多且杂。

首先，我们可以按照重要性和紧急程度先进行区分，这就是四象限法。

其次，对需求进行打标（分类）。分类的方式有很多种，比如按照前端产品与后端产品，按照问题BUG、现有业务流程优化、新项目等，也可以按照业务影响范围分为大、中、小等。

在需求分类时，我们也可以利用KANO模型进行划分；KANO模型把需求分为基本需求、期望需求、魅力需求、无差异需求、反向需求。

通过分类，我们可以将一些相似的需求进行合并，也可以去除一些不紧急不重要的需求，以便于更好的调整资源，也是为后续的需求优先级确定做准备。

三、需求识别与梳理

需求是来源于业务的，在些阶段应该站在业务架构的角度来识别与梳理这些已经筛选过且分类的需求；此时，我们要遵循如下图所示的几个原则：

需求是要满足业务的，业务则要满足企业的战略规划（业务战略与IT战略），每个需求的实现时流程可能会受到影响；我们不能固步自封，要敢于打破旧的流程，通过优化重构来寻求最好的解决方法；但前提是要保证业务连续性，不能出现“孤岛”现象，最终适得其反。

最后，要从企业规范、财务原则、信息安全等角度保证需求方案的合规性。

当然这些对于原则2、4，我们在后续需求设计时会重点考虑，在此阶段，如果需求没有脱离业务战略，主要是工作通过识别这些需求，将一些需求串起来，尽可能的使其连续（通过分类或归属）。

经过此过程，需求会更加清晰，相关的需求或相互有影响的需求都会识别出来，有些需求可以作为一些需求的子需求而存在，使其形成一个构建块；这些构建块可以形成一个或多个项目，便于后期的需求实现。

四、需求优先级

面对上述已经识别和梳理的需求先做哪个是非常棘手的问题；此时，我们通常会排优先级来确定，但根据工作经验，这种优先级很多时候都是拍脑袋决定的，冲突矛盾依然会存在。

作为产品负责人应该寻找一种合适的方法去规划协调需求与资源，通过合理的需求优先级定义，可以保证协调项目与IT资源的正常协作，解决公司内部的冲突，能够创造最大的业务价值，更快的响应业务变化，同时也可以对需求进行取舍或分期实现。

但这些需要企业内部相关人员能够从全局的角度去看待需求，以企业战略为愿景，业务战略为主，IT战略为辅去规划、设计、实现。

五、VCR方法

下面介绍的VCR方法，是本人应用实践过的，可以参考。

VCR估算法是基于价值（Value)、成本费用（Cost)、风险（Risk)的优先级评定的过程与方法。这里的价值是由提出需求的业务方进行评价，产品技术部进行费用与风险的评价。

在VCR方法中，采用9标度的评分标准，具体过程简单介绍如下：

1. 列出所有的需求（项目）

我们可以利用EXCEL列出要设定优先级的所有需求、项目或使用实例（这里以项目为例）。

这里要注意，所有的项目都必须在同一抽象级别上，不要把个人项目与公司级的产品项目混合在一起；如果某些项目有逻辑上的联系（例如，只有包括项目A的情况下才能实现项目B）那么在分析表中只要列出驱动项目就可以了。

在这个模型中根据其有效的范围或时间可以容纳很多不同类型的项目，但前提是要把相关的项目归成一类，便于分析与优先级的排序（参看前面介绍）。

2. 估计相对利润

以1~9划分等级（1代表可忽略的利益，9代表最大的价值)

这些利益等级表明了与产品的业务项目的一致性。业务人员（提出需求者）是判断这些利益的最佳人选。

在缺省情况下，利润和损失的权值是相等的，作为一种精化，我们可以更改这两个因素的相对权值。

3. 估计相对损失

估计出如果没有把应该实现的项目包括到产品中，将会给客户和业务上带来的损失。

同样使用1~9划分等级，这里1代表基本没有损失，9代表严重损失。

4. 计算总价值及价值占比

总价值=相对利润+相对损失

价值%= 总价值/总计价值 * 100%

5. 估计相对费用

根据项目的复杂度，根据需求的用户界面实际情况、重用当前代码的潜在能力以及所需要的测试量和文档等；产品技术可以估算出费用，使用1（低级）~9（高级）划分等级，同时计算每一个项目的费用占比。

6. 风险估计

产品技术要估计出每个项目相关的技术或风险相对程度，并利用1~9划分等级。

1级表示你可以轻而易举地实现编码，而9级表示需要极大地关注其可行性、缺乏具有专门知识的人员，或者使用不成熟或不熟悉的工具和技术。

相对风险估算完成后，计算风险百分比；在缺省情况下，利润损失、费用和风险的权值是相等的，可以自行设置；例如无需考虑风险，就可以把风险的权值设置为0。

7. 优先级计算

优先级=价值% / （（费用% * 费用权值） + （风险% * 风险权值））

六、成本金额估算法

如果我们是对外提供技术服务的企业，需求优先级的判定，在保证业务连续性的和相互最小影响的前提下，也可以采用成本金额估算法。

在评估项目费用成本时，一般情况下都是以IT资源进行的，其中人工成本占据很大的部分。通常我们是将一个项目评估为“人天”，然后分配不同级别的技术人员，按外包项目的方式进行估算。

这样确定优先级主要是考虑企业的最大利润，这在一些集团型公司（某一子公司为其他子公司提供技术服务，财务上是独立核算的）比较常见。

当然这些需求优先级的确认是需要甲乙双方沟通谈判的，不适用于企业自研团队。

对于需求优先级的确定，将需求进行分类非常重要，有些需求可以整合在一个项目中完成，有的需求则需要依赖于其它需求建设完成后才能开始，这些都可以通过整合采用循序渐进的建设方式。

同时，我们还要考虑业务的期望程度、建设时间以及经费资源，对于期望度高、时间要求短、资源少时，必须尽早确定出所待建设项目中最重要的项目组合，这个有点类似于关键路径法。

需求优先级的判定可以结合企业自身的特点来制定，以上也仅是参考，鞋合不合适，只有脚知道。

七、需求文档

一个项目（需求）可能会涉及到不同的产品及系统服务,需求文档的重要性不言而喻，它的详细程度与完整度会影响到很多方面。

PRD文档，是各种沟通的媒介，所以我们要做到以下几个部分。

• 规范及完整性是对需求文档的基本要求。
• 变更要及时通知相关干系人，包括视觉设计师、交互设计师、测试和研发以及相关人。
• 必要的流程图不可少，相对于纷繁的文字，清晰的流程图可以加快沟通的速度和内容的理解。
• 要注意非功能性需求的影响和体现。功能性的需求很多时候只是冰山一角，产品和系统的复杂度多数来源于非功能及后端隐藏的实现过程。
• 需求涉及多个产品协作时，要保证统一性原则，即流程统一，名字定义统一，业务目标统一，时间统一等。

在此阶段要谨防前期配合紧密，后期疏于沟通协调的场景发生，要充分利用实时在线工具，如原型等可以利用墨刀、需求可以利用共享文档，避免各种变化产生的影响。

八、需求执行

对于一个需求有了明确的目标，了解其明确的约束以及明确的责任后，接下来我们就是制定计划，跟踪执行。

目前对于需求的管理都是通过WEB管理平台实行的条目化管理，通过配置最小化权限来保证需求的执行。常见的工具有禅道、Readmine、Jira等。

以JIRA为例，通常产品经理会先创建用户需求（业务需求或项目），然后分别由研发负责人创建系统需求，再根据系统需求创建开发任务，具体的需求及任务关系如下图。

详细的执行过程参考下图，此流程是原公司结合产品技术内部实际需求设计的，个人觉得比较繁琐，还可以再简化一下：

在需求执行管理过程中，要保证每个需求都要进入到JIRA中并分配好相关人员的角色权限，相关人员要及时的更新状态。

后续我们可以根据JIRA中的数据进行需求管理的数据分析，知晓需求达成率、挂起率、延期时间等指标，以助于优化管理。

九、写在最后

本篇对需求的管理进行了简单的整理，源头管理好了后续的工作会轻松一些，但这都依赖于规范与制度；这些需求从领导到员工，从上到下严格执行才能达到效果。

在实际的工作中，很多制度似乎都是要求干活的人遵守的，这是需求管理过程中的大忌，只有上下、内外都保持一致，才能更好的满足企业业务。

最后感谢您的阅读！

#作者#

倔强的大萝卜，公众号：倔强的大萝卜。较早的互联网电商行业从业者，有过多家电商公司的工作经验；撸过代码，10年以上的团队管理经验，目前的学习方向是供应链及业务构架等。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！