需求管理 (1)

2012-05-23 21:43

前言:本文为系列文章。

  1. 上篇 http://cuikai-wh.com/blog/2290
  2. 中篇 http://cuikai-wh.com/blog/2498
  3. 下篇 http://cuikai-wh.com/blog/2506

需求探索

确认价值

什么是「需求」?简单来说:

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

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

产品经理要做的,就是揪出用户的问题所在。用户想要一对翅膀?噢不,其实他只是想快点从上海赶回汉口。

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

  • 产品定义
    • 一句话描述用来解决谁的什么问题
  • 目标用户
    • 核心人群的属性(性别、年龄段等固定不变的)和偏好(小清新、喜欢旅行等阶段性的)
  • 用户场景
    • 人物角色。把目标用户拆开,进行细分,绘制典型用户
    • 用户场景。这些典型用户在什么情况下用该产品的哪个点
  • 产品特色
    • 最吸引人的3个特质
    • 竞品分析
  • 评价指标
    • 靠什么指标来判断上线的产品好还是不好
    • 指标预期值

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

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

确定范围

项目层面

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

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

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

  1. 产品定义。引用「基本产品」的概念,即这个最小化的产品必须满足,不满足就等于没做这个产品,不满足就会死
  2. 人物角色。优先满足哪个类型的用户
  3. 产品原则。定义产品的方向。资源(人力和时间)有限;在解决方案既定的情况下,优先满足运营计划、功能实现还是用户体验

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

部门分工

在哪个时间点交付什么

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

  • 甘特图。跟踪项目进度的利器
  • 跨系统流程图。理清部门关系最方便不过

解决方案

主要包括:

  • 产品经理。功能方案,即产品功能规格文档,或者称产品需求文档(PRD)
  • 项目经理。技术方案,不仅包括开发,还有测试方案
  • 交互设计师。体验方案,即交互稿

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

团队沟通

邮件

坚持按要点(1、2、3)撰写邮件,不仅方便对方阅览,更有助于自己整理思路。要点根据重要紧急程度依次展开。需要后续跟进的部分,确认部门分工四要素,缺一不可。邮件发送给项目成员(比如前端开发),抄送给项目相关成员(比如主管)。

邮件的行文:对事、语言精炼、有进展。

重要的事情务必口头沟通确认。

会议

会议总是不讨人喜欢。故此,不论是会议组织者还是参与者,为了自己宝贵的时间,都有必要维护会议的高效性。根据项目阶段,粗浅地分为两类。

头脑风暴类

  • 阶段:项目前期
  • 目的:发散思维
  • 要素:主题、思路、成果

议题类

  • 阶段:项目中期和后期
  • 目的:达成一致
  • 要素:目的、问题、结论

参考资料

  1. 莱恩 《给产品经理的建议》(英文) http://feltpresence.com/articles/14-advice-for-product-managers
  2. 知乎 《怎样判断用户需要(Need)和用户想要(Want)什么?》 http://www.zhihu.com/question/19574413
  3. 小轰 《关注问题,而不是解决方案》 http://cuikai-wh.com/blog/2105
  4. 小轰 《产品原则,还是用户习惯?》 http://cuikai-wh.com/blog/2276
  5. 知乎 《如何高效地管理邮件?》 http://www.zhihu.com/question/19600890
  6. 纯银 《谈开会》 http://firecacada.blog.163.com/blog/static/70743762012031102447600/

扩展阅读

  1. 打不死的小强 《真假需求》 http://xiaoqiang.me/?p=3416
  2. 随线放矢 《关于产品管理》(英文) http://www.randomwire.com/product-management-manifesto
  3. 优涩控 《解决方案,而不是功能》 http://www.userkon.com/tolyer/about_solution_no_features.html
  4. 设计团队博客 《以故事为中的设计:武装你的大脑,像用户一样思考》(英文) http://www.designstaff.org/articles/story-centered-design-2012-03-22.html
  5. 费杰 《由产品经理找人难想到的》 http://www.kuliqiang.com/?p=3791
  6. 产品启迪 《我是产品经理》(英文) http://mindtheproduct.com/2011/10/i-am-a-product-manager/
  7. 白鸦 《关于要不要做调研》 http://uicom.net/blog/?p=912
  8. 互联网的那点事 《为何产品升级后越来越烂》 http://www.alibuybuy.com/posts/67025.html

2 条评论 / 引用:

  1. 需求管理 (2):

    […] 上篇 http://cuikai-wh.com/blog/2290 […]

  2. 需求管理 (3):

    […] 上篇 http://cuikai-wh.com/blog/2290 […]

评论

《对话守则》第一条:对话的目的是寻求真理。

以下选填: