Tag Archive for 产品

互联网产品需求管理思考1-统一需求管理

对于互联网公司而言,产品需求管理是产品研发的核心环节,产品需求的正确与否直接影响产品开发周期、产品开发成本、产品运营成本,甚至直接决定了产品市场 竞争力。根据统计:产品开发中40%~60%的问题都是在需求阶段埋下的”祸根” ,在测试阶段及运营阶段发现需求阶段植入的问题,解决的代价是需求阶段发现问题的68~200倍。

关于需求管理的故事很多,列举一些常见问题:

  • 某天老板问起:我很久以前提过一个需求,提过以后就没下文了。产品经理无辜地说:有提过吗,是给我提的吗?
  • 某个销售谈起:我很久以前提过一个需求,当时被产品否掉了,觉得不重要,现在竞争对手就靠此功能赢得了众多客户。产品经理无辜地说:当时是被否掉 了,但你后面再没有提过,因此在后续产品开发中当然没考虑此需求
  • 某天老板提起:某个产品的某个功能很不错,于是乎大家加班加点地开发实现了类似功能。等到产品开发出来后才开始找客户、找卖点。
  • 销售们抱怨:产品人员、开发人员闭门造车,只关注技术,不关注客户需求。产品及技术无辜地说:销售人员根本描述不清楚需求,我们已经按照他们需求 开发出来了,他们还是不满意。
  • 销售人员只管销售目标的完成,客户反映的信息不能传递到产品及技术部门。研发部门主动到销售人员那里了解市场信息时,他们往往说:“我只管销售, 你先把产品拿出来再说”
  • 某个客户在社区里投诉:xx产品的xx功能做得太差了,已经投诉过几次都还没有改善;但产品及技术无辜地说:他这功能相对于其他产品功能优先级很 低,因此暂时不考虑
  • 竞争对手某个杀手级产品的功能其实以前公司很久以前就做了,但后来没有持续完善,导致“起了个大早,赶了个晚集”
  • 某个产品越做越大、越做越乱,直到有一天无法维护时候整理产品功能才发现,里面有一堆乱七八糟的需求,这些需求怎么来的、现在哪一个客户在使用此 功能,谁都不知道
  • 公司层面产品相关利益者都参加的需求收集会议也开了很多次,但大家对于产品需求的理解还是没有统一
  • 与竞争对手的产品比较,产品功能比竞争对手全面多了,但还是竞争不过竞争对手的产品
  • 某个产品离职了,大家才发现,对产品最熟悉的人只有这个产品经理,没有任何文档及功能说明,有的只是网站页面和代码

对于大部分互联网公司而言,都意识到了产品管理的重要性,因此都有相应的产品管理流程,但为何以上问题仍然屡见不鲜呢?

以上问题的根源在于:

1)、没有对各种需求有效地分层分级,对不同阶段需求的目标没有明确的定义

2)、没有建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求,并将其传递给产品研发团队

3)、缺少完备的需求收集、汇总、分析机制,“公司神经末梢与大脑失去联系”;

4)、没有建立一套跨部门的端到端的业务流程来指导市场需求收集与传递工作

5)、没有一个客户需求分析工具来指导系统性地收集客户需求

1、互联网产品需求来源

一提到需求管理,产品人员及技术人员都会异口同声地说:软件需求管理,我们有啊。我们的软件开发过程遵循CMMI3、RUP、XP、SCRUM等开发过 程,需求管理是我们进行开发的最重要阶段。

我们这里所指的“需求”不单纯只是技术术语的产品需求、软件需求,还包括:

  • 客户所想所需:Needs、Wants
  • 市场需求
  • 产品包需求:Offering Requirement
  • 产品需求
  • 开发需求

相对于传统软件开发过程,互联网企业的需求管理来源更加多样化,包括:

1)、外部来源

  • 客户需求:客户在使用产品过程中所提的建议和意见;以及通过客户访谈等手段得到的需求
  • 竞争对手产品分析:直接作为竞争对手产品的客户试用,获得竞争对手产品相关信息
  • 社会化媒体:搜索引擎、IM、BBS、Blog、SNS社区、Blog、Twitter、百度知道等社会化新媒体
  • 传统媒体/竞争对手软文等
  • 合作伙伴
  • 行业分析

一些竞争对手分析的手段可以参考 电 子商务企业竞争情报分析工具

2)、内部来源

  • 公司产品战略
  • 客服人员:包括呼叫中心(电话、短信、传真、邮件等)、在线客户(IM、BBS、留言板、WebCall等)
  • 运营人员:所谓互联网产品是运营出来的,任何成功产品不可能一蹴而就。公司内部运营人员在运营中产生的需求是重要的需求来源渠道。
  • 市场营销人员
  • 销售人员
  • 财务人员
  • 技术支持
  • 网站用户行为分析:包括网站用户购买行为、点击流等

2、统一需求管理的意义

由于需求来源的多样化,就要求在公司层面对需求进行统一的管理,以保证能够:

1)、建立端对端的需求管理流程,实现技术与市场的无缝结合。

2)、深入理解行业,成为行业专家:对于互联网企业而言,必须深刻理解所在行业的特征及行业用户的痛点才能够推出有竞争的产品,因此必须首先成为所在行业 专家。产品需求本质代表了行业用户的需求,通过产品需求的持续积累,可以加深对于行业理解,从而成为行业专家,能够推出更符合行业需求的产品

3)、知识的传承:通过对需求持续统一的管理可以保证知识的传承,避免产品需求知识积累在几个人脑袋里。

4)、主动收集需求,准确把握市场机会点

5)、产品创新:通过产品及产品间原有需求的优化、借鉴、组合等手段来达到产品创新的目的。

我们这里的所说的“统一需求管理”比RUP中的更为宽泛,包括:

  • 公司层面统一的需求管理组织支撑体系
  • 公司层面统一的需求管理流程制度
  • 公司层面统一的需求管理工具

4、怎样实现统一需求管理

在实现公司层面需求统一管理,华为及IBM所采用的IPD过程很有借鉴意义,核心思想在于:

1)、组织支撑

通过建立一个横跨市场和产品研发部门的组织机构来统一负责收集市场需求,并将其传递给产品研发团队

2)、端对端的流程

所谓“端到端流程”是区别于职能式的产品开发模式,建立的产品开发流程是跨部门的、关注业务实现的、客户到客户的业务流程。企业中与产品需求相关的主要有 三大流程体系:市场管理流程、产品开发流程、需求开发流程。在市场管理流程的第一阶段(了解市场阶段)、在产品开发流程的第一阶段(概念阶段)都会定义客 户需求的收集活动,用需求开发流程来支撑需求收集活动。

产品管理,需求管理,需求工程,端到端需求管理,统一需求管理

可以参考:华 为IPD流程管理

5、统一需求管理一些思考

1)、所谓“工欲善其事,必先利其器”,一个好的需求管理工具对于需求管理有很大帮助。但工具不是万能的,关键还是使用工具的人,因此不用整天寻找完美的 工具,而是要问一下自己:对于工具的使用热情我们能够坚持多久?

2)、工具本身并不能解决需求管理混乱的困局。核心问题还是需求管理的方法论、流程制度是否能够持续完善。成功需求管理的秘诀之一就是:持续积累、持续完 善。

3)、我们很多时候忙于开拓新的市场需求而忘记了总结的价值。与客户、市场、销售、产品、技术、运营等相关人员定期对积累的各种需求(不单纯只是产品需 求)进行“requirement review ”(类似于“cod review”),可以碰撞并挖掘出许多有价值的产品需求及卖点。

4)、对于运营型企业而言,各种行业需求的持续积累是企业最为宝贵的财富之一,也是产品创新之源。因此应当把持续的需求积累提升到公司战略层面。

从Buzz看产品的纯粹性

http://www.xiuyu.com/wp-content/uploads/2010/02/GoogleBuzz_thumb.jpg

我本来打算在2月13号,也就是Buzz发布之初写这篇日志,结果当天毒瘾犯了,玩PSP月下去了。拖到3月中成稿后,又因忙碌和烦躁,放了两周不去修订 它。此时是否已经没有人关注Buzz?

剽悍的Buzz不需要解释,基本上是Friendfeed的翻版。很多人没玩过 Friendfeed,所以老往Twitter上面套,并盛赞Buzz的创新,其实大都是Friendfeed玩残了的把戏。没办法,明星吃饭拉屎皆新闻 也。然则Friendfeed没能大红大紫,始终是笼罩在Buzz头顶上的一片阴云。这个模式的缺陷到底在哪里呢?

显而易见,Buzz认 为是推广不利,没能快速到达增长拐点,所以背靠Gmail/Google Reader/Picasa三颗大树。Buzz心想,坐拥近2亿的用户基础,自然胜券在握。吓!好乐观,我看未必。强大的推广渠道其实是把双刃剑,带来用 户也带来麻烦,甚至于麻烦超乎想象,预期的收益中却充满了泡沫。

近半年来,我一直在极力鼓吹产品的纯粹性,主要是用户社区的纯粹性。所谓 用户社区,即人与人之间相互影响较多的产品。在我看来,Friendfeed也好,Buzz也好,都是由于纯粹性不足而上升乏力的案例,Buzz的情况尤 其糟糕,具体有如下五点:

1、不纯粹的习惯
首先,我们可以明确Gmail是一款邮件产品,Buzz是一款社交产品。二者的使用习惯并不一 致。比如邮件应用的目的性较强,社交应用的随意性较强,如果沿袭邮件的使用习惯,有可能访问Buzz的时机不对(早上上班),停留时间下降(忙于处理正经 事务),访问频度也低于其他社交产品。但若期待用 Buzz去改变Gmail的使用习惯,它目前还没有如此大的魔力。

拿特别熟悉的QQ举 例。我们会因为挂QQ而顺带使用它面板上的其他服务,却不容易为了使用“其他服务”特地打开QQ。在子母产品之间,习惯上的主次分明,次要服务必然迁就主 要服务,除非它也慢慢进化为了主要服务的一部分——多么漫长的过程,但Gmail的用户习惯却不利于Buzz的快速渗透。

我 猜,Google的工程师一定也看到了个中隐忧。或许正是因为Gmail的用户习惯难以拉动Twitter类产品的使用,最终才采用了 Friendfeed模式,即便用户并不活跃地产出信息,他在Google Reader、Picasa以及其他feed源的活动依然能自动输出内容,使得Buzz用户“总有得看”,用阅读来带动Buzz起步,再用互动来加速 Buzz成长。

于是Gmail一方面加入了社交阅读器的特征(QQmail早就干了),另一方面也借力于Gmail的邮件往来数据,用算 法搭建好了用户关系网络。在一开始的新闻稿中Google正是得意洋洋地宣布,庞大的关系网络乃Buzz的核心优势之一。

当真如此?

我 看未必。留到第三个小节再去评价。

2、不纯粹的感受
所谓“用户感受”的概念,可以用更专业,更装逼一点的名 词来描述,即“用户情感体验”,他使用产品时,在情感上产生的细腻的触动。

如果从产品类型的角度出发,那么Gmail和Buzz同为信息 获取工具,用户操作均为收取-阅读-回复,看似雷同。但如果从用户感受的角度出发,阅读一封邮件和阅读一条社交信息的情感触动往往有明显的区别。邮件类型 因其多元化,其阅读感受是中性的;而社交资讯的阅读感受则是亲切而随性的。

正是由于这种差异化,作为邮件产品,Gmail强调信息的获取 与管理效率;作为社交产品,Buzz强调的是轻松阅读与便捷互动。产品设计风格出现了明显的区别。那么不同感受的内容,不同风格的服务,强行糅合在同一款 产品里,又怎么能算得上纯粹呢?

就像宣纸是纸,草纸也是纸,却绝不可以混为一谈。感受上的不纯粹使得用户适应性被削弱,接受新应用的时间 被延长,无法实现平滑而凶猛的扩张。

3、不纯粹的关系
之前提到过,Buzz得意于Gmail和Google Reader现成的用户关系网络。这是鲜花,也是炸药。这是营养牛奶,内含三聚氰胺。问题并不在于用户关系网络是否真实,是否有效,而是这张网络属于什么 样的交流性质?

很显然,我的工作网络,家庭网络,同学网络,兴趣组网络各自不同。我希望老板看到自己生活中的一面吗?我希望家人看到自己 工作中的一面吗?把关系网络简单理解为熟人关系,好比这世界上只有一个Internet,却不允许无数个局域网的存在。我在接受Buzz作为社交网络之 前,被强行夹到一份自以为是却错漏百出的速配列表之中,然后一个个删除清理。何必这么辛苦呢?不用它便是。

任何一张成功的社交网络必定由 用户亲手织成,由他根据不同的社交情景来选择每个交往对象。从情景和对象出发,自由定义社交类型,才会使得用户足够投入。这就是人的社会性,它必定是自由 恋爱而非相亲节目。然而Buzz与Gmail、Google Reader捆绑,使得用户关系的性质错综复杂,发言颇多顾忌,更有隐私泄露的大患。

后 来Google很快解除了Buzz与Google Reader好友的同步,可见用户之怒。这不是废话吗?Google Reader的follow只是普通的订阅关系,可视之为“社会化”,却与“社交”两个字天差地别,我接受一个陌生人的文章推荐并不代表也接受他输出的其 他信息。可解除同步无法根除Gmail关系的芜杂,速配必然失败。我们必须尊重用户本人的社交选择意愿,多么高明的算法也无法将之取代。

如 果没有被用户接受的关系网络,那么社交就是一朵假花。Buzz借力于Gmail,情况可能还要糟糕一点,就是用户被茫然导入,对此地的对话语境全无了解, 也很难认可这张轻浮的算法列表。好像被外星人抓到了一起,天空中有个高音喇叭喊:“快聊”。那么他连从头开始建立关系网络的兴致可能都被打消了,或者直接 过滤掉Buzz,眼不见为净;或者自居于公众场合而不是私人空间,有悖社交的初衷。

4、不纯粹的内容
上面谈到“不纯粹的关系”, 乃是Buzz的致命伤。当然也不排除有一部分用户,他们可以接受Gmail的算法推荐,或是手动清理出来一张满意的关系网络,然后踏上Google赞助的 社交之旅。你好,Friendfeed的衰败阴云正在前面等着你们。

在2009年,我曾经疯狂迷恋过半年的Friendfeed,但只使 用它的Room(以后还会专门写篇日志分析“社会化推荐”)。和大红大紫的Twitter相比,Friendfeed一贯叫好不叫座,红颜薄命吗?我倒认 为是孤芳自赏居多。

那半年里我在Friendfeed上follow了不少人,信息流那是刷刷的快。过瘾吗?一点也不。我压根感受不到在 信息背后的人的存在,只是一队僵尸,一个高音喇叭,一条死气沉沉的河。只见源源不断的碎片资讯被抓取而来,可作为阅读器,乱纷纷的碎片干扰了阅读的质量与 节奏;作为社交产品,它又缺乏最起码的人味儿。既然大多数人压根不来这里活动,哪里有什么人味儿呢?与邮递员送信又有何异。

缺少个人魅力 的吸引,把人抽象为内容订阅源,却忽略掉了微妙的“人的气息”,这就是Friendfeed模式的败笔。在社交场合我们关注的是某个鲜活的人,而不仅仅是 他发表的内容,如果他不在这里(或很少来这里),那么我也没有留下来的必要。当他发表的内容被从本人身上剥离出去,变成若干条广播消息,于是光芒尽折,我 却更愿意看到他亲口在某处讲述。这无关时间、地点与形式,转发如临摹,再怎么逼真也是幅赝品。

当然,Friendfeed里也不乏活跃的 发表型用户,但终归是少数,僵尸抓取信息与真人发布信息羼杂在一起难以辨识,尸臭沾染到活人身上。信息再怎么汹涌,也如同群尸过界。创始人太看重信息获取 效率,却无法理解人与人之间的情感诉求。

说回来Buzz,它自动关联feed的设计既丰富了内容,又制造了一大批生化僵尸来削弱社交的乐 趣,看似Google Reader的互动加强版——然则僵尸愈多,社交乐趣愈少。

5、不纯粹的阅读
即便是照搬Friendfeed模式,Buzz可能比它的前辈还要更糟糕一点。因为 Friendfeed的正文设置为新开窗口阅读,Buzz却继承了Google Reader的衣钵,在本页直接展开阅读。带来什么样的后果呢?你自己看嘛,正文接评论接正文接评论接正文,鸡包纸包鸡包纸包鸡……

冗长 的评论毫无疑问对正文阅读造成了干扰。有时候我好奇点开折叠评论,呼啦啦拖下去两屏,全是生面孔的无聊吵闹,下一条正文信息被挤到两屏开外。Buzz的交 互设计极力鼓励琐碎的评论发表,又时常因为陌生评论者的掺入而显得索然无味。再加上Friendfeed回复优先的显示设置,信息被反复顶上去,一长串无 趣评论频频跑到你眼皮子底下去抢风头。结果用户关系驳杂的创口越撕越大,不感兴趣的“好友”动态,莫名其妙的口水回复,充盈视野,使人焦躁不安。

更 加要命的是,轻快的微博和长篇大论的文章,通栏排开的图片绞在了一起,忽而长文忽而短语,绞成一团乱麻。内容界面全无简洁清爽的美感,只能用“杂乱无章” 四个字来形容,阅读节奏时轻时重,时快时慢,怎可能与Twitter行云流水的流畅相比。

Buzz把长长短短性质各异的内容放在同一个页 面上,必然带来阅读上的跳跃感,忽而漫步忽而短跑,全无连贯性可言。然而Twitter之所以是了不起的Twitter,不仅因为它够简单,还因为它够纯 粹,又从纯粹中派生出鲜明的感染力与稳定的节奏感来。像脉搏一样强有力的内容节奏能明显提高阅读舒适度,进一步促进阅读的连贯性和浸入感。如果把 Twitter的纯粹理解为简陋,把Buzz的花哨理解为强大,则徒增笑柄。

反观Buzz之旅,与其说是热闹,不如说是嘈杂,使阅读区变 成了闹哄哄的广场——是的,一群Google粉丝聚集闲聊的广场就是Buzz的现状。讨论比发表更热烈得多,讨论者之间常常互不相识。它更像是一个由五花 八门的follow关系构成的,开放性的资讯讨论组(或灌水群),却与社交的初衷南辕北辙。轻浮的用户关系再加上紊乱的阅读体验,如何能“社交”得起来?

Buzz 发布半个月后,伟大的谢尔盖·布林宣布说,Buzz公测的结果与Google内部2万名员工的内测结果大不相同,因此Google今后的产品都将进行小范 围公开测试,不再以内部员工测试为准。于是你立刻理解了为什么牛逼如Google也会在Buzz上犯这么多错误,因为所有的Buzz试验都是以 Google员工,这批少数派精英为参照标准,尤其在封闭式的环境下无法还原多样化的用户情景。而社交中的情绪化,个性化,远远超出了 Google工程师的感知范畴。社交的本质是特定关系网络中的特定社群文化,它的规律即便用尽全世界的大型电脑也无法计算。

最终,我猜测 Buzz不会垮掉,毕竟背靠着Gmail这棵大树,但它也很难大红大紫。遥想Yahoo!Buzz当年,难道不是另一颗大受追捧,冉冉升起的明星吗?今天 谁还记得它人老珠黄。

From:http://ucdchina.com/snap/6229