人人都是产品经理——iamsujie

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

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

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

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

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

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

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

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

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

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

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

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

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

这次只说3阶（3×3）的魔方，目标是还原成6面同色。几个礼拜前我还做不到，以为很难，不过这段时间简单研究了一下，发现还是挺简单的，现在可以做到100秒左右还原，和高手比起来很菜（世界上最快的人曾经在7.08秒成功还原了一个魔方，创造于Czech Open 2008，记录保持者是来自荷兰的Erik Akkersdijk）。

认知科学

“模式、元素与记忆”。

魔方有6面，6种颜色，每种颜色有3×3个小面。

一个打乱的魔方，在玩家与外行眼中是不同的，玩家眼中是各种模式，然后迅速找出模式对应的解法，而外行眼中就是各种颜色杂乱的块，只能想如何把相同颜色的面移到一起。

举个例子：“Hello World”：

在学过计算机的同学看来是尝试各种编程语言第一个程序的经典句子；

在没接触过计算机，但是懂英文的人看来是有点意义的两个单词；

在不懂英文的人眼中，是“H e l l o W o r l d”十个字母，还分大小写；

在连字母也不认识的人眼中，这是系列的图案，有横有竖有斜线有曲线；

而这之间的记忆量区别，不同的人为了重复写出“Hello World”所付出的努力，显然是不同的。

所以，知识与练习的作用就是习得“模式”，把你心中的“元素”给复杂化，形成更高级的“元素”，这是一个从“字母–单词–句子”的艰苦过程、然后再固化，之后再碰到类似问题，就可以手到擒来。

回到一个打乱的魔方，玩家眼中是什么呢？应该是某种颜色（乃至多种颜色）在某个面（乃至多个面）上的位置关系，具体能抽象到什么高度，就看水平了。

阅读全文…