人人都是产品经理——iamsujie

有100个需求，资源只够做10个，是的，当时就是这样。

标题是马云的一句话。

2007年国庆长假回来，基本在全力做网店版“批量定时上架”的需求，n多的pk、评审、确认会搞得头昏脑胀，不过终于算是把需求确认掉了。其中有些关于功能做多做少的争论，这里再写点。

一个功能的多次需求会议中，必然有这样一个过程。开始对一个功能想的不完整，说着说着大家都想把这个功能做的再强一点，这里加一点那里加一点，但后来有通常因为技术实现，资源等原因，又把这些加上去的功能点一个又一个的砍掉，甚至会发现砍到最后和一个月前的第一次方案是一样的。看似白搭的这个过程其实是有用的，这是一个“见山是山，见山不是山，见山还是山”的三段过程，对于那些加上又砍掉的功能点，第一个阶段我们根本没有想到，第二个阶段想到了，很兴奋，那就做吧，而第三个阶段的砍掉是权衡了利弊之后的决定，和“没想到”是完全不同的，千万别停在中间那个功能点“大而全”的时候，必死无疑！

有很多文章谈到这样的思想，用100%的质量去实现75%的数量，而不是反过来！吸引用户的往往只是功能模块中的1、2个点，我们一开始只要把这个做到100%的质量其实就够了，这样留给用户的是升级的期待，而如果反过来，功能铺的很开，但每个点都不爽，那反而喧宾夺主，把闪光的地方给掩埋了。

越来越认为当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！

要做的东西少了，出现几个问题。

问：有资源空出来了怎么办？

答：要做的数量是少了，但要达到100%的质量，一般很难空出资源。

问：真的空出来了怎么办？

答：去找其他意义更大的功能。

问：找不到怎么办？

答：把team空闲下来的人拉去做另外一个意义重大的产品，这不可能再找不到了。

潘长江说过：浓缩的都是精品。

我们已经做了需求采集，需求分析，现在似乎应该甩开膀子干活了，但经验告诉我们不是这样的，一个实际的例子：

网店版二期上线后两个月，各方各面提出过的需求也许有四五百个，经过PD们的初步判断，记下来供团队讨论的有200多个，决定暂缓的有60多个，七月一个月发布掉了70多个。其中每个需求的去留，去的怎么去，留的怎么跟进，是一定需要管理的，这时候我们要考虑的，是在评估出“性价比”的情况下，到底什么时候来做，谁来做。

其实在功能列表上做一些简单的扩充，就可以得到一个简单的需求管理工具了。

首先，功能列表是静态的，现在要变成动态的，对每个功能（视为一个需求）加上跟踪状态的属性，让我们能实时看到“何时做，谁来做，状态如何”。

负责人：细分为需求提出者（很可能是用户，有必要备注一下最原始的需求）、需求负责人、开发负责人、测试负责人，属于哪个项目……

需求状态：通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可以按照实际情况有所增减。

时间信息：提出时间、录入时间、发布时间……

有了如上信息，然后我们就可以制定每个需求的状态变迁的流程，举个例子， “待讨论”状态的需求应该多久讨论一次；讨论完了就应该转为三个状态：“拒绝”、“暂缓”、“需求中”；而“暂缓”的又应该再多久以后激活，等等。

此外，各种状态的需求个数，也可以通过excel的基本统计功能的实时监控。

做完这些，基本就可以得到文中的图了。

至于更专业的需求管理方法和工具，也看了一些书和软件（比如IBM的Rational RequisitePro），确实是相当的有学问，不过还是觉得暂时不合适游击队，而对于正规军是绝对必要的。

最后说一下我对管理的理解，管理并不是部门经理们才需要掌握的技能，而是每个人都必备的，只是每个人可以使用的资源不同，所以需要管理的资源也不同。当资源充分的时候，我们会觉得“正确的做事很重要”，事实也确实如此，比如被分派了某个重要任务的时候，我们的目标就是做好这件事。而一旦资源出现了瓶颈，“做正确的事”就立刻变得更重要了。比如同时有3个人要请你吃饭（当然这种好事比较难得），资源（你的时间）不够了，你就需要迅速判断吃谁的请更有价值，谁的请可以搁置住但不会丢掉……

每个人需要管理的，必定有自己的时间，也许还有自己的抽屉、硬盘空间、钱等等。经理们需要管理的通常有人员、经费等等。一个共同的特点，这些资源总是处于不足的状态！管理做的事情就是合理分配不足的资源让结果最优。

只要需求采集的功夫做足了，你就会发现需求超多，必须每隔一段时间整理一次，通常我们叫它功能列表：Feature List,说一下自己感觉这个玩意应该怎么做，其中吸取了叶老大原来的表格还有网上一些相关文章的内容。这个表是用Excel做的，一些简单的技巧，比如条件格式、筛选、单元格有效性、单元格锁定、隐藏是必须的基本功，另外我比较喜欢把表格弄好看点，这样整天对着就不会闷死嘞，如图。

看不清吧？那就对了，不好意思有些信息不能公开。

表格中每一行是一个功能，而每列都是这个功能的某个属性：

模块：一般来说，每个模块下分3~10个子模块是合理的，否则要考虑重新划分（由于这个癖好，自己电脑里的文件目录结构也是遵循这个原则的）。

子模块：稍大一点的产品至少要给功能模块做二级分类了（更大的产品视需要可能有更多级的模块分类），这部分其实又涉及另外一个很大的领域IA（信息构架，会影响将来产品的站点树形结构，页面组织，菜单层级等），后面也会整理一些相关内容。

功能：具体的说一点，要给用户提供什么功能，给这个功能起个名字。

功能描述：这里可以说具体一点。

商业价值描述：通俗点，卖点是什么，可以给用户提供什么价值。

商业属性：简单分为基本，扩展，增值。举个手机的例子，打电话短信是基本功能，给电话录音是扩展功能（和基本功能相关），而如果这个电话特别结实，可以当锤子钉钉子，那就是增值功能了。这里的区分其实没那么绝对，取决于很多因素，比如商业目的。

商业优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影响着将来产品的方向，我们的做法是先基于自己对商业目标的理解，主观定一个级别，所以之前的功课很重要，然后再PD团队pk，如有必要，再去客户处确认。

（iamsujie补：有时候细分为功能的紧急程度、重要程度、生命周期等细分因素。）

开发量：一般由技术部门的项目经理或者系统分析师/架构师来确定。

性价比：简单一点就是综合商业属性、优先级与开发量来确定，可以找出一个合适自己产品的计算方法。

备注：这个不说了吧。

最后，对于这个表格，依照产品的大小、资源多少，可以灵活变通。

有了前面需求分析的结果后，我们就要做决定了：到底做哪些需求。其实并没有一个功能是没有价值的，也并没有一个功能是做不了的，某个功能到底做不做？至少要从两个方面来考虑。

第一，商业价值。在我们公司的团队构架里，“商业——产品——技术”是明显的三条线，和用户、商业层面直接发生关系的是运营，我把这看作是前端的内容。那么这里的商业价值也就是对用户意义的大小、以及对公司目标意义的大小。这里需要PD和运营积极配合，充分分析功能给用户/公司带来的利益，但不是说利益大的就做，先把这个分析结果存着备用。

第二，实现难度。换句话说是开发量，需求+开发+测试+硬件等等一共需要的资源。这是技术层面我把它看作是后端，绝对不能因为一个功能很容易实现就马上去做，也不能因为另一个功能很麻烦就不做。

现在可以做决定了，我们做性价比（商业价值/实现难度）高的。无论任何事情都是一个性价比的问题，2007年下半年的工作中，由于一直和工程师直接接触，所以综合考虑时有点倾向于做实现难度小的，这是需要改进的。

再说开一点，谈一下对商业价值的一个判断因素，功能的商业属性：雪中送炭 or 锦上添花。雪中送炭是基本功能，对用户很有用的，产品缺了这个功能根本不可能运行，比如网店版的“我要付费”模块；“锦上添花”的功能是指用户用得到的，但没有时用户也不会跳起来的，也许现在的“客户关怀记录”可以算这类。我们在论坛上会很明显的感受到这两种需求的不同，有一点像“bug”和“需求”的区别。我是一个不那么激进的人，觉得要把“雪中送炭”的商业价值调高，稳定和谐压倒一切。情愿把一半的功能做到尽可能完美也不要把全部功能都做到半吊子。

（iamsujie补：延伸阅读，KANO模型）

另外可能还有些无法控制的因素影响这“做不做”的决定，比如国家、公司的政策指向，这里说了也白说就不说了。