人人都是产品经理-第12部分

按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！


Business　Requirement　Document，简称　BRD，它也是我们参加资源争夺战的武器。　


先看一下几个长得很像的词：BRD、MRD21、PRD22。按顺序来讲，这几个词是从　
商业的描述渐渐过渡到对技术的描述。我经历的团队在实际操作中通常只写两种文档，　
一个是给大老板们看的BRD，包含了BRD，以及MRD的部分内容；另一个是在项目中　
写的PRD。　
下面来聊聊我们的武器——BRD　怎么写，都包含哪些内容。　
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数　
据说明项目的必要性。　
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以　
后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这　
个项目的商业目标。　
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述　
一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会　
搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚　
不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，　
但不要在这上面太花心思了。　
非功能需求描述：提一下重要的非功能需求，如果有的话。　
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多　
大的花费以后，才能做出决策。　
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并　
且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而　
且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候　
提出来也是让老板们把一下关。　
从　BRD　中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本　
质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的　
商业价值。　
下面通过一个　BRD　的实例，再给大家讲一点直观的认识。　

21　MRD：Market　Requirement　Document，市场需求文档。　
22　PRD：Product　Requirements　Document，产品需求文档，在本书第　3。3。1　节的“产品需求文档，PRD”里有详细讲述。　


首页，我们会给　BRD，也意味着将来的项目，起一个有意义的名字，再配上一幅　
图，这样有助于团队的归属感，比如下面这个　BRD　叫“魔方计划”（如图　2…18　所示），　
是因为这个项目打算将两个老产品整合为一个新产品，有点像魔方一样，通过打散、　
组合，得到一个全新的结果。　
图　2…18　魔方计划　PPT　的首页　
商业价值（如图　2…19　所示），给老板们看他们最关心的指标，比如魔方计划就聚　
焦在“活跃用户数”上。　
图　2…19　魔方计划的商业价值　
功能需求描述，这里给出了业务逻辑图（如图　2…20　所示），若能给出一些简单的　
Demo　更好，让老板们提前看到产品完成后的样子，很可能成为争取资源的加分因素。　
资源评估（如图　2…21　所示），我们会根据团队的实际情况，重点评估主要功能对　
产品设计师、用户体验师、开发工程师的人力需求。　
魔方计划　BRD　
——老产品1　＋　老产品2　
****事业部　苏杰　
商业价值　
。　“产品1”不差人，坐拥100万用户，10万活跃　
用户，外加高速自然增长。　
。　“产品2”不差钱，是公司今年的重头戏，投入　
XX亿。　
。　产品级的强强整合，利用“老产品1”的庞大用　
户基数给“老产品2”快速带来更多的活跃用户　
。　截至2009年底活跃用户数　
–　铜牌10万、银牌15万、金牌20万　


　图　2…20　魔方计划的业务逻辑图　
图　2…21　魔方计划的资源评估　
BRD　转化为项目也并非一一对应，很可能老板会把多个　BRD　合并为一个项目，　
或者把一个　BRD　拆成多个项目，或者直接砍碎了再重新组合，这都无所谓，不管怎么　
说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，准备启动　
项目，迎接新的开始。　
等等，我们还需要先安抚一下“被砍得遍体鳞伤”的兄弟们。　
资源评估　
PD　UE　开发　测试　
功能1　10　2　22　
功能2　6　18　20　
功能3　5　2　10　
功能4　3　10　5　
功能5　2　0　6　
注：测试资源有保证，暂不评估　
资源单位是“人天”　


2。4。2　别灰心，少做就是多做　

有　100　个需求，资源只够做　10　个，是的，当时就是这样。　
一直都是这样。　
2007　年国庆长假回来，我在全力做网店版“自动上架”的功能，简单解释一下：　
淘宝为了防止一些没人打理的商品始终在搜索结果中，稀释了有效信息，所以所有商　
品会隔一段时间后自动下架，不再被搜索到，这时就需要用户重新将商品上架。而网　
店版的用户都是淘宝的优质卖家，所以我们给他们提供了一个“自动上架”的功能。　
这是一个确定“怎么做”的过程，当时的体会能很好地表达我的想法，借用一下。　
两个礼拜，整天的　PK、评审、确认，搞得头昏脑胀，不过终于算是把需求定下来了。　
一个功能的多次需求会议中，必然有这样一个过程：开始对一个功能想得不完整，　
说着说着大家都想把这个功能做得再强一点，这里加一点那里加一点，但后来通常因　
为技术实现、资源等原因，又把这些加上去的功能点一个又一个地砍掉，甚至会发现　
砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这　
是一个“见山是山，见山不是山，见山还是山”的三段过程，对于那些加上又砍掉的　
功能点，在第一个阶段我们根本没有想到，第二个阶段想到了，很兴奋，那就做吧，　
而第三个阶段的砍掉是权衡了利弊之后的决定，和“没想到”是完全不同的。我们无　
法绕过第一阶段的无知，也千万别停在中间那个功能点“大而全”的时候，必死无疑！　
而第三阶段的“少做”则是超越第二阶段“多做”的“少做”，这才是真正的“多做”。　
有很多文章谈到这样的思想，用　100％的质量去实现　75％的数量，而不是反过来！　
吸引用户的往往只是功能模块中的一两个点，我们一开始只要让其拥有　100％的质量其　
实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺得很开，但每个点　
都不爽，那反而喧宾夺主，把闪光的地方给掩埋了。　
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得　
当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的　
选择：不做！现在我们可以自我安慰了——少做就是多做！　

最爽就是“四两拨千斤”　

做得少不如做得巧。　

第　2。3。1　节中我们提到满足需求有三种方式，其实就算“改变现状”这样一种最常　
用的办法，也有很多“四两拨千斤”的方案。如果机会闪现，就千万不要放过，因为　


做这样的事情实在太爽了，让我对下面这个故事过目不忘。　
话说某跨国日化公司，肥皂生产线上面存在包装时可能漏包肥皂的问题。　
于是该公司总裁命令组成了以博士牵头的专家组对这个问题进行攻关。该研发团　
队使用了世界上最高精尖的技术（如红外探测、激光照射等），在花费了大量美金和半　
年的时间后终于完成了肥皂盒检测系统，探测到空的肥皂盒以后，机械手会将空盒推　
出去。这一办法将肥皂盒空填率有效降低至　5％以内。　
问题基本解决。　
再说某乡镇肥皂企业也遇到类似问题，老板命令初中毕业的流水线工头想办法解　
决之；经过半天的思考，该工头拿了一台电扇到生产线的末端对着传送带猛吹，那些没　
有装填肥皂的肥皂盒由于重量轻就都被风吹下去了。　
这样做得更少，但是效果更好，至少性价比更高。当然，具体情况要具体分析，任何　
事情总有它的两面，上例中乡镇企业的解决方案换到跨国公司的环境中，也许并不适用，　
比如会造成肥皂盒无规律地四处翻滚，引起更大的问题，但我想表达的意思是：　
我们用不着觉得只有“吃苦耐劳”，做了很多事情才是贡献，而应该直接从目的出　
发。有一句话说得好：内部（指偏技术）的大改动往往是外部（指偏商业）的小改动，　
反之亦然，所以我们应该在动手前先找找有没有成本低，收效大的解决方案！　

尽可能多地放弃　

第　2。2。5　节里，我说“尽可能多地采集”，这里，我又说“尽可能多地放弃”，看似　
矛盾，其实正反映了我们对事物的认识过程，只有在收集阶段没有遗漏，才可能完整　
地看到事物的全貌，有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。　

多年以前我看到白鸦　23写过的一段例子，发现如果不放弃，最终会被自己折腾死，　
他是这么说的：　
比如，一个最简单的“评论”功能：既然可以发评论，那么……　
是不是需要改评论？　
删评论？　
发的权限是否要管理员设置？　

23　白鸦，支付宝产品设计师，UCDChina　发起人，5G　咨询合伙人，专注于以用户为中心的互联网产品设计的　Blogger。　
个人博客　ui。　


那么改的权限呢？　
删的权限呢？　
是否可以引用别人的评论？　
评论被人引用了是否可以再改？　
如果可以改那么是不是要保留修改记录？　
如果管理员改了一个评论那么作者是不是不能再改？　
评论是否要有数量和时间限制？　
评论要不要翻页？　
如果要翻页是在本页翻还是打开新页？　
评论能不能带图片？　
带了图片那么是不是能上传？　
能上传之后是不是要删除？　
是不是要提供自定义评论排序？　
是不是要　xx？　
是不是　xx？　
xx？　
……　
“需求越来越多，让人崩溃，但是要做的事情太少，似乎也会有问题。”小明忍不　
住跳出来问。　
小明：“有资源空出来了怎么办？”　
大毛：“要做的数量是少了，但要达到　100％的质量，一般很难空出资源。”　
小明：“真的空出来了怎么办？”　
大毛：“去找其他意义更大的功能。”　
小明：“找不到怎么办？”　
大毛：“把空闲下来的人拉去做另外一个意义重大的产品，这不可能再找不到了。”　
“少做就是多做”，阿里巴巴的马云也说过。　

…
　　　　*小说来自　艾博网　更多免费电子书下载　请点击：iboke/

　　　　*艾博网，iboke/，汇总当前最新热门软件资源、小说下载、电影观看、游戏攻略、八卦娱乐等信息；是一个专注于中国青少年热点话题的网站。内容丰富；更新快；是大中学生们喜爱的综合互动交流平台。


　　　　*声明：本书仅供读者预览；请在下载24小时内删除，不得用作商业用途；如果喜欢请购买正版图书！

　　　　*如艾博网打不开了；请访问　53418　下载小说电子书。
…