求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
需求管理:需求探索与团队沟通
 

作者:Warlial ,发布于2013-3-1,来源:leiphone.com

 

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

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

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

需求探索

确认价值

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

1.需求=问题

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

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

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

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

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

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

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

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

    确定范围

    项目层面

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

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

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

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

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

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

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

    部门分工

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

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

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

    解决方案

    主要包括:

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

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

    团队沟通

    邮件

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

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

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

    会议

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

    1、头脑风暴类

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

    2、议题类

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

    功能与商业

    确定需求(的价值、范围)后,便着手思考解决方案。很多方案是对产品功能的添删和改善,比如上传图片:

    1.「上传图片」按钮。但一次只能上传1张图片

    2.添加「批量上传」按钮,一次最多可以上传25张图片

    3.删除「上传图片」按钮,更新「批量上传」按钮为「上传」,一次可以上传30张图片

    4.优化视觉,突出「上传按钮」

    5.优化方式,允许用于拖动图片到网页即可上传。同时将上限提高到50张

    然而,功能通常滞后,而且容易被竞争对手模仿。功能上的改进对专业的竞争对手来说几近透明,还记得脸谱用更改颜色来验证校内网「反应速度」的例子吧(别在意是否真实)。反之亦然,自己的产品也可以跟风很酷的功能。问题在于,这些功能的初衷是什么呢?

    iPad 用户场景:商务应用

    功能一定对应某个的需求;而需求并非孤立存在,必然融合到使用场景中。用户作为社会人,进入场景时也必然带着情绪(与感情)。用户场景可以看成对用户情感的细化与细分。以评价为例,我作为消费者,当然是商品评价越客观、越有用越好;自己购物评价不评价则不太在意(至少不强烈)。做评价的产品,我会解决下面两个问题:

    一、将现有的客观且有用的评价提炼出来

    1.对商品的评价无非是偏好还是偏好,中评的价值不如好评和差评

    2.有用=丰富=形容词≠泛泛而谈(比如「很好」这种词)

    3.提炼,即一瞟页面就能看出,扫都不用扫

    二、鼓励用户产生客观且有用的评价

    1.人都是自利的,目的是利用产品将自利转化为同时利他。这句话比较绕,反过来说即将利他转化为自利。比如,小朋友帮助老奶奶过马路,得到老奶奶的表扬,可以有材料写作文,增强了自我肯定

    2.可以评价某一条评价,并结合网站会员体系,积分信誉神马的

    功能可以克隆,需求可以模仿,场景可以堆资源去覆盖,但情感只能亲自体会。一款没有情感灌注的产品,是没有灵魂的 3 ,也不可能做到极致。

    一旦关注用户的情感,产品功能便顺其自然;有时甚至微不足道。

    商业化的产品离不开商业意识。在《产品经理修炼之道》的座谈会上,印象最深的莫过于这样一句话,大致是:「产品经理能不仅仅通过功能和技术解决问题,而要跳出来,不能只做技术范围内技术不做的事。」

    至于张小龙说「微信是一种生活方式」我倒不以为然。

    首先,「生活方式」难以定义,至少比「噱头」难。其次,这句话用任何其它大型互联网产品代替「微信」都比微信更合适。

    个比方:QQ 是一种生活方式(有事儿您Q我),百度是一种生活方式(有问题,百度一下),淘宝是一种生活方式(淘不出手心),微博是一种生活方式(随时随地分享身边的新鲜事儿)……不过这也没什么好叨的,毕竟微信取得了市场占有率的成功,还不如讨论「同样是腾讯的产品,为什么微信成功了,腾讯微博却没有?」

     
    相关文章

    需求分析师的能力模型
    基于模型的需求管理方法与工具
    需求管理工具DOORS 的接口
    使用Web+EA实现基于模型的需求管理
    需求经过大脑的过程:需求分析评估方法
     
    相关文档

    需求分析与需求管理
    需求分析具体要求全解
    需求分析与验证
    需求分析的核心线索
    基于UML的需求分析方法
     
    相关课程

    需求分析与管理
    从需求过渡到设计
    业务建模与业务分析
    产品需求分析与管理
    需求分析最佳实践与沙盘演练
     
    分享到
     
     

    相关文章

    需求分析方法—把测试流程图表化
    敏捷需求分析五大关键因素
    写好市场需求文档的10种技巧
    需求分析中减少客户摩擦的法则
    软件项目需求管理复杂性分析
    EPC-事件驱动的流程链
    更多...   

    相关培训课程
    软件需求分析与管理实践
    业务建模与业务分析
    软件需求分析与管理
    软件需求分析师
    面向产品的需求分析与管理
    IT规划体系与实践

    成功案例
    北京 软件需求分析与管理
    某知名基金 软件需求分析
    联想 业务需求分析与建模
    财税领域某IT服务商 测试需求分析
    医疗行业 面向产品的需求管理
    某知名IT服务商 测试需求分析>
    某高新技术公司 测试架构、需求分析
    更多...