需求管理：需求探索与团队沟通

本文作者@小轰同学 ，在产品的调研的过程中，用户的需求往往被隐埋的很深。因为用户并不懂得表达出其需求，或者说，用户自己阐述的概念并不能表达出其所期待的解决方案。

由用户口中给出的解决方案与其真实需求相去甚远，因此在任何产品开发的过程中，都应该注重对用户的需求管理。

我们能从用户口中听到各种各样“奇妙的想法”，有的复杂有的简练。但是无一例外的，用户不会给你一个清晰、有条理的需求线索，因此在解决用户需求的前提下，你所需要的就是对用户的需求进行探索。

一、需求探索

确认价值

什么是「需求」？简单来说：

1.需求=问题

2.满足用户的需求=解决问题=产品

「问题」一般藏得深，用户难以表达出来，甚至他们自己也不知道想要什么。举个例子，用户说「饿了」，往深挖掘：如果问题是「活不下去」，塞给馒头即可；如果问题是「想吃好的」，馒头就不管用了。有意思的是，用户往往直接提出经过自己思考后、理想化的解决方案（比如，更快的马），这个时候已经离问题十万八千里了。

产品经理要做的，就是揪出用户的问题所在。

“用户想要一对翅膀？噢不，其实他只是想快点从上海赶回汉口。”

若问题大众化，或者惹毛了愿意付费的高端 / 小众用户，或者我们的产品方案能更完美地解决问题，这便是价值所在。为了确认价值，几件事情必须完成：

产品定义

一句话描述用来解决谁的什么问题

目标用户

核心人群的属性（性别、年龄段等固定不变的）和偏好（小清新、喜欢旅行等阶段性的）

用户场景

1.人物角色。把目标用户拆开，进行细分，绘制典型用户

2.用户场景。这些典型用户在什么情况下用该产品的哪个点

产品特色

1.最吸引人的3个特质

2.竞品分析

评价指标

1.靠什么指标来判断上线的产品好还是不好

2.指标预期值

收集、整理和掌握足够有用的信息，才适合做上述判断。多和团队成员聊聊，想必是极好的。

上面的话题网上俯拾皆是，不管是产品相关还是用户体验相关（的博客还是书）都在聊这些东西。强调之多，可见之重要。对于大公司来说，每个环节都必不可少；并非为了应付团队成员的质疑，这是大公司以「规避风险」为原则的生存守则。

二、确定范围

项目层面

首先是时间范围。确认期望上线时间，可能有时政因素、竞争对手因素的考虑。（还可能包括下线时间，比如某活动，某版本。）

其次是项目范围。从框架（比如跨系统流程图）开始评估，一步步细化到预期解决方案。确认一定要做什么，一定不做什么。

最后，最重要的是，确认优先级。为了在保证确认时不会跑题，以及尽量避免争执，可以从这三点出发：

1.产品定义。引用「基本产品」的概念，即这个最小化的产品必须满足，不满足就等于没做这个产品，不满足就会死；

2.人物角色。优先满足哪个类型的用户；

3.产品原则。定义产品的方向。资源（人力和时间）有限；在解决方案既定的情况下，优先满足运营计划、功能实现还是用户体验。

前两个在上一步已经讨论过，所以只用把产品原则讨论清晰即可。噗，冥冥中还有一个：关键绩效指标（KPI）。

部门分工

“谁”在哪个“时间点”向“谁”交付“什么”。

团队协作的效率就指望这4个要素了。对于大项目来说，有两个图很好使：

1.甘特图。跟踪项目进度的利器

2.跨系统流程图。理清部门关系最方便不过

解决方案

主要包括：

1.产品经理。功能方案，即产品功能规格文档，或者称产品需求文档（PRD）；

2.项目经理。技术方案，不仅包括开发，还有测试方案；

3.交互设计师。体验方案，即交互稿。

这些同学在产出方案之余，还有各自的职责。嗯，产品经理需要协调资源、控制需求和进度，项目经理需要和数据库管理员确认细节，测试经理需要在系统压力和安全上分析考虑，交互设计师需要协调整体视觉样式，等等。

标签： 产品设计 产品经理 用户需求分析 

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点！
本站所提供的图片等素材，版权归原作者所有，如需使用，请与原作者联系。