人人都是产品经理——iamsujie

为什么要说严肃版呢？因为之前发过一批不严肃的，猛击此处围观。

放3张，下面开始：

需求状态流转图

Bug状态流转图

日常需求发布流程

那个，虽然图里已经有广告了，是不是还给个链接呢？太纠结了，算了，还是再给那本“励志的专业书”加加人气吧~~~

一个同事，视力不好，要学开车，我们都说他一定要配眼镜，但他多年习惯了不带，有点不愿意。我的说法是会看不清人，撞到，比如晚上会很危险，他说肯定不会；同事说，你到了路口会看不清路牌上的字，得减速，结果他认可了。

• 结论一：我不开车，所以体会不到痛处，也就说不出用户关心的关键，所以，熟悉用户很重要，否则你真的猜不出他是怎么想的。

• 结论二：站在用户的角度考虑问题，而不要站在一些莫名其妙的角度（比如本例我站在路人的角度，也是我的日常角色，虽说也很重要，但毕竟痛感不强烈）。

做产品必须找到用户的刚性需求。何谓刚性需求？我们常说的一个例子，成（防绿坝插入此句）人网站就是满足了刚性需求，在这个前提下，就算注册流程做得再烂，下载一个文件需要点10次鼠标，用户的粘性照样嗷嗷的高。所以，找到了刚性需求，方向正确，后面的事情做起来都简单很多。

前两天听了卫哲同学的一个分享，其中对我们用户——中小企业——需求的理解让我印象深刻，记录一些点滴，并融入了自己的理解，供讨论。

• 作为产品经理，乃至每一个人，都要不停的想，不断的问自己：用户痛在哪里？痛有多深？止痛药多少钱？

• 中小企业的需求，开源>节流，效率<效果：大企业的时间值钱，所以愿意花钱买时间；中小企业的时间不值钱，纯粹靠帮助他们省时间是赚不到钱的：对大企业，提升“效率”的服务可以赚钱，他要雇很多“农民”做的事情（指劳动力密集型的工作，没有贬低的意思），我们都可以关注，当“农民”做到手酸的时候，就是我们可以收钱的时候；而中小企业，一共就一个“农民”，还很便宜，你帮他省了点时间，他聊QQ、偷菜去了……所以需要提升“效果”的服务，帮他搞到更多的订单、客户，让他先发展壮大起来。

• 满足需求的节奏感：从Meet@Alibaba到Work@Alibaba，第一，Complete Trade，完成贸易，比如订单、收款；第二，Beyond Trade，超越贸易，比如资金、人才。对中小企业，首先要生存，必须拿到订单、抓住客户，这是刚性需求；然后要成长，需要资金、人才，是刚性需求；在满足了这些需求之后，才可能从“让天下没有难做的生意”到“让天下没有难管的生意”，生意做大了，会自然而然产生发展的需求，才到管理软件的需求。对头疼得想撞墙的用户，就先给他杜冷丁打下去，不要说“你体质不好，我给你开一副中药调理，半年后肯定壮汉一条……”

• 止痛药的售卖思路：从远古时期的买断，到会员制，一年一卖，为了卖出价（比如几千块一年），所以必须把很多功能打包堆砌在一起。回顾上面两条，这样卖的东西就很有“管理软件”的感觉，不是说不能这样做，而是这条路会很辛苦，并且不是唯一的路。而现在可以看到的另一条路就是打散了卖，把管理软件化整为零为无形的服务，功能模块化，做到“一拆二插三深入”，先把自己拆了，然后插入现有服务，最后“随风潜入夜，润如细无声”。除了按时间卖，我们还可以多多思考按“效果”卖，真正的P4P（pay for performance），时间对每个人都是公平的，所以对大企业也只能收中小企业那么多钱，这对中小企业反而是不公平的。“效果”的变形，可以是Leads数、交易额、转账额……

• 中小企业付钱买药的人：收钱的时候，要分清中小企业中，老板和业务员能动的钱，我们的中小企业中，业务员通常是有一定资金的自主决定权的，要利用好。越是数额小、紧紧绑定业务过程的钱，业务员越能自行决定。卖软件的思路是“业务员预先请款（如果有的话），老板做购买决策，付钱，业务员使用”，我们的痛苦在于“客户”与“用户”的分离，买的人和用的人不同。“一拆二插三深入”以后，改造服务的收费模式为“业务员先用，再去找老板报销”，比如业务员跑业务的过程中，自己做一些宣传资料是可以报销的，会比原有的的方式顺畅很多。对于老板，把握住他们“就算不上网、不用电脑，但是用手机”的特点，无论如何，看来移动的趋势大家都逃不掉。

找到用户的刚性需求，最痛的地方以后，有节奏的用合适的方式把止痛药卖给合适的人，之后的产品设计过程中，各种技术、工具才能发挥最大的作用。

【小广告】今天在我的强烈要求下，出院了，进入在家休息阶段，本周六去医院拆线，发一篇庆祝~~~

敏捷（Agile）的一个特点，先确定项目时间，专业点叫“迭代周期”，然后有一个人员相对固定的团队，意味着项目资源，要保证项目品质，根据项目的“多快好省”原则，最后能变得只能是量——项目范围，前段写过一篇如何做好“老板项目”里也有相关描述。

那么，某个项目里，做多少需求到底怎么定？这个过程不妨用下图来表示，这张图也是PD的需求过程图中的一小部分，即“PD @ alisoft做什么”这张图里最左边一个箭头里的“需求分析”那个小框，以后有机会再把全图展开来说。

同学们可以先回顾一下之前说过的excel功能列表和需求管理表格，产品团队的一项日常工作就是采集产品干系人，即“广义用户”，提过来的各种需求，并整理转化为产品需求，即图中的“需求转化”，通常转化之前我们用mindmap较自由的表达，转化之后就成了excel里的功能列表。采集到这个需求的PD，自己可以先“确定属性”，即这个需求是属于产品的哪个模块？是基本、扩展、增值功能？是功能、性能、用户体验方面的？等等，属性的维度大家可以按照产品的不同自由定义，原则是为了便于需求的管理。

这样我们得到的feature list，就有必要每隔一段时间、或是新需求积累到一定数量、或是由特别事件触发，拿出来大家一起过一遍，这是最关键的，即图中用红色突出的“确定商业价值（产品内PK）”。我们的经验，商业价值由单个PD确定风险很大，所以这个步骤是PD团队集体讨论，再叫上有必要的干系人，比如销售、服务。对于商业价值可以从多个维度描述，并加权平均得到综合的商业价值，详细描述可参见单向需求卡片，但绝大多数情况下，我们发现只用一个值的高中低，或者5、4、3、2、1分来衡量就足够了。具体讨论的时候，大家充分表达意见，最终往往是会场上级别最高的人综合以后说一个数字，这是现实，也是一种高效的办法，我想过投票、群体打分的方式，可是实施起来成本太高。

注意一点，讨论商业价值的会议上，会把所有状态为“待讨论”的功能点都过一遍，散会的时候，它们的状态一定要变化，或是进入“需求中”、或是被“拒绝”、或是“暂缓”。拒绝的需求是被认为对产品的商业目的没有价值的，而暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，比如“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等等。

对于状态变为“需求中”的功能点，下一步就是初定工作量了，因为需求不明确，所以只是简单的评估，和真实情况的匹配程度很取决于经验,要靠不断的实践来反复修正。我们通常经历的项目，三大类人力资源是“产品、开发、测试”，用团队里的瓶颈资源做评估基准，所以我们一般评估每个功能点的开发工程师工作量，因为在我们的团队里通常产品、测试资源相对可以调配，这个大家视自己团队的情况灵活应用。具体的评估，通常是类似技术经理的角色来做，评估者按照自己做需要多少时间，乘以一个系数确定，这个系数一般大于1。

继续，既然对于每个迭代周期，我们有多少时间、多少人是早就知道的，那么可用工作量是多少“人日”，也就知道了。有了每个功能点的商业价值和工作量，很自然的就能算出性价比，简单的说即“商业价值/开发工作量”，我们把feature list按照性价比从大到小排序，再对应考察每行评估出来的开发工作量，从上到下依次纳入项目，我们的可用工作量能做多少个功能点，一目了然。

上面谈到的这些，也就是一步步确定某个项目能做多少需求的过程。

最后，我们把这些要做的功能点合在一起，把“需求打包”，再往下就要做这个项目的BRD了。BRD通过，立项之后，再全程跟踪某个需求的进度，上述整个过程就是一步步确定某个需求的各种属性的过程，而对某个需求的描述，可以用下面的表格来表示（不妨起个名字叫做“一个需求的DNA”），表中红色星号表示的项目，是我心目中的必填项。

这个过程完全是定量的，也就回答了“做多少”的问题。但，真实情况哪会这么简单明了，下面再说几个需要注意的地方。

第一，需求打包最好打类似的功能点，是否类似取决于需求的属性，“确定属性”这步做的事情起作用了，一般来说业务上有逻辑关系的需求才会包含一个项目里，否则就是一个纯粹修修补补的“小需求项目”了。

第二，需求依赖，功能点互相之间有依赖关系，那没办法，只能先做某些功能，应该在feature list里注明；功能点与人力资源之间的依赖关系也会经常存在，在这里评估工作量的时候不会考虑“谁来做”的问题，但是在后续立项，组建团队的时候需要注意，当然长期来说，为了避免这类风险，提升与平衡团队成员的能力是王道。

第三，功能点的粒度大小问题，商业价值很高的功能，如果细分的话，我们也会发现其中有价值相对低的部分，所以功能点的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内。具体细到多少，也只能具体情况具体分析，我想工作量的最小单位总不能超过“5人日”吧。

先说说理念：产品需求不止是需求分析人员的事，而是产品涉及的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯。

“单项需求卡片”就是一种很实用的需求采集工具，一张卡片相当于需求列表中的一行，讲一个用户需求到底包含哪些内容。明确一下，需求列表一般是指未经加工的用户需求，重点是需求的各种属性；功能列表（Feature List）通常是分析过的产品需求，重点是实现它的性价比。下面用一张“单项需求卡片”的实例来介绍一下（表格有点变形，凑合看哦），蓝色内容为重点，我自己也在团队里推行过这玩意。

说明：需求特征的描述，通常有如下几个维度：重要性（细分为“满足后、未实现”，或者说“基本、扩展、增值”，参见KANO模型）、紧急度、持续时间（生命周期）。实用主义的考虑，可以综合抽象为一个指标：商业价值（或者叫商业优先级）。然后除以开发量就得到了“性价比”，我们先做性价比高的需求。