阿当

算法，产品经理的必修课

你知道IMBD的电影排行算法么？你有兴趣研究一下么？

加权平均分(WR) = (v ÷ (v+m)) × R + (m ÷ (v+m)) × C
在这里：
R = 该电影的平均分
v = 该电影的总投票数
m = 列入前250所需要的最少票数(目前是1300票)
C = 数据库中所有电影的总平均分(目前是6.7)

哈哈，厉害吧，投票数多的话，那么R，也就是每个人的电影评分就起到主要作用；
如果投票数少呢，也不能说电影不好，小众的东西还往往是精品呢，文化的东西，毕竟有可能因为语言等因素，或者曲高和寡变得在IMDB上变得小众，这样如果投票数少，那么也不能一棒子打死，就趋于平均水平。
如果票数相同呢，那么就看R了，平均分越高，那么自然排名就越靠前啦。

好玩吧，再看一个。

很多网站在设计博客的排行时，在时间相关性上很困惑，为了满足访问网站频率不同的用户需求，他们只好按日、周、月来做排行，非常明显的缺陷是，让每周或每月的开始时，周榜和月榜上的精彩文章精彩程度不够，而上周末或月末的精彩文章可能被过早撤出用户视线。但是如果按七天排行或者三十天排行，算法又太复杂。
有没有兼顾的算法呢？答案是有的。


假定用户访问周期介于T1到TN，TN=N*T1，用户访问频率在T1到TN之间线性分布。
设文章在每个时间TX里获得的访问量为TXPV，设计系数A=(N-1)/N

使用计算式
T1PV*A^(N-1)+T2PV*A^(N-2)+T3PV*A^(N-3)+……+TNPV=∑TXPV*A^(N-X)
来计算随时间衰减的关注度。
太TMD牛了，佩服的五体投地。
如果算周排行榜，一篇文章在第一天的访问量跟第七天的访问量在权重上明显是不同的，到第七天还有人在访问，那就说明这篇文章更热。

通过这件事情我想，作为一个产品经理，其实应该有这样的基本功力。今天大家在研究热文的的出现和排序算法的时候，我为自己是个理科生感到非常惭愧，对于分析一种算法的改变对于效果的影响上，我表现得跟个文科生一样。倒也不是说文科生同学们就干不了这个事儿，只是说我这么多年的专业训练啊，都tmd练到哪儿去啦？？！！

作为一个将致力于成为一个有创意的、脚踏实地的、有执行力的、成熟的、经验丰富的、牛B哄哄的产品经理作为毕生奋斗目标的人，我今天的体会是一定要严于律己，有意识的培养自己对于算法的感觉，积极参与工程师同志们的算法讨论，不断修炼，逐渐成仙。

Tags: pm

以用户故事管理项目

什么是用户故事(user story)

假定这个项目的客户是个饮料自动售货机的制造商。他们要求我们为他们的售货机开发一款软件。我们可以找他们的市场经理了解这个软件的需求。

因此，我们的客户就是他们的市场经理。谈需求的时候，有一回他这样说：“用户往售货机每塞一个硬币，售货机都要显示当前该客户已经投了多少钱。当用户投的钱够买某一款饮料时，代表这款饮料的按钮的灯就会亮。如果那个用户按了这个按钮，售货机就放一罐饮料到出口，然后找零钱给他。”

上面的话描述的是一件事情，一件用户通过系统完成他一个有价值的目标（买一罐饮料）的事。这样的过程就叫“用户案例(user case)”或者“用户故事(user story)”。也就是说，上面我们的客户所说的话，就是在描述一个用户故事（user story）。
(我解释一下为什么用故事这个词，没兴趣也可以忽略。在一个系统面前，每个用户要完成同样的目标，都要做这个系统设定的例行的事，这件事情不是一个例子，所以不叫事例，这也不是故事，也不能算一段历程，而是一个例行的事。)

如果我们想要记下这段用户故事，我们可能会用这样的格式：

名称：卖饮料

事件：

1. 用户投入一些钱。

2. 售货机显示用户已经投了多少钱。

3. 如果投入的钱足够买某种饮料，这种饮料对应的按钮的灯就会亮。

4. 用户按了某个亮了的按钮。

5. 售货机卖出一罐饮料给他。

6. 售货机找零钱给他。

注意到，一个用户故事里面的事件可以这样描述：

1. 用户做XX。

2. 系统做YY。

3. 用户做ZZ。

4. 系统做TT。

5….

用户故事只是描述系统的外在行为

一个用户故事只是以客户能够明白的方式，描述了一个系统的外在行为，它完全忽略了系统的内部动作。比如，下面有下划线的那些文字，就属于不应该出现在用户故事中的系统内部动作：

1. 用户投入一些钱。

2. 售货机将塞进来的钱存在钱箱里，然后发送一条命令给屏幕，屏幕显示目前已经投入的金额。

3. 售货机查询数据库里面所有饮料的价格，判定钱足够买哪些饮料，对于钱足够买的那些饮料，对应的按钮的灯就会亮起来。

4. 用户按下一个亮起来的按钮。

5. 售货机卖出一罐饮料给用户，然后将数据库里面该饮料的存货数量减1。

6. 售货机找零钱给用户。

不管是口头描述的，还是书面形式，这样的内容是描述用户故事时一个很常见的错误。特别的，千万不要提及任何有关数据库，记录，字段之类的对客户一点意义都没有的东西。

评估发布时间

用户故事是用来干嘛的？假定客户希望在50天内递交这个系统。我们做得了吗？为了解答这个问题，我们就要在项目开始的阶段，试着找出所有的用户故事，然后评估一下，每一项历程需要多长的开发时间。可是，怎么评估呢？
比如，我们现在收集了下面这些用户故事：

卖饮料：如上面所说的。
取消购买：在投入了一些钱后，用户可以取消购买。
输入管理密码：授权的人可以输入管理密码，然后增加存货，设定价格，拿走里面的钱等等。
补充饮料：授权的人可以在输入管理密码后增加存货。
取出钱箱里的钱：授权的人在输入管理密码后，可以取出钱箱里的钱箱里面的钱。
安全警报：有些事情经常发生的话，系统会自动打开安全警报。
打印月销售报表：授权的人可以打印出月销售报表。

然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短）。我们不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。比如，我们觉得“输入管理密码”是最简单的用户故事。然后我们判断说，这个用户故事算1个“故事点（story point）”。

用户故事故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱
安全警报
打印月销售报表

不过一般我们不会列出清单，而是做出一堆卡片贴在墙上，每张卡片记录一个用户故事，然后将故事点写在卡片上面：

这样的一张卡片就叫“故事卡（story card）”。

然后开始考虑其他用户故事。比如，对于“取出钱箱里的钱”这个故事，我们认为它跟“输入管理密码”这个故事一样简单，所以它应该也是算1个故事点。我们在列表里面标上。当然，实际操作的时候，我们是在“取出钱箱里的钱”的故事卡上填上故事点。
用户故事故事点
卖饮料
取消购买
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表

对于“取消购买”，我们认为它应该是“取出钱箱里的钱”的两倍的工作量，所以它算2个故事点。
用户故事 故事点
卖饮料
取消购买 2
输入管理密码1
补充饮料
取出钱箱里的钱1
安全警报
打印月销售报表

对于“卖饮料”，我们认为它应该是“取消购买”两倍的复杂度，所以它应该算4个故事点。
用户故事 故事点
卖饮料4
取消购买2
输入管理密码 1
补充饮料
取出钱箱里的钱 1
安全警报
打印月销售报表

对于“补充饮料”，我们又认为它比“取出钱箱里的钱”复杂，但又比“卖饮料”简单，然后它又应该比“取消购买（２个故事点）”复杂，所以我们认为它应该是3个故事点：
用户故事故事点
卖饮料4
取消购买2
输入管理密码 1
补充饮料3
取出钱箱里的钱 1
安全警报
打印月销售报表

类似的，我们认为“安全警报”应该比“补充饮料”简单一些，所以应该是2个故事点：
用户故事故事点
卖饮料4
取消购买2
输入管理密码 1
补充饮料3
取出钱箱里的钱1
安全警报2
打印月销售报表

“打印月销售报表”应该跟“卖饮料”一样复杂，所以应该是算4个故事点，这样的话，我们总共有17个故事点：
用户故事故事点
卖饮料4
取消购买2
输入管理密码1
补充饮料3
取出钱箱里的钱1
安全警报2
打印月销售报表4
总计17

现在挑出任意一个用户故事，估计一下它要花（你一个人）多少时间来完成。假设我们之前做过跟“取出钱箱里的钱”类似的功能，所以我们就挑这个来计算，估计它要花5天的时间。也就是说，一个故事点要花5天的时间来完成。现在我们有17个故事点，也就是说，我们需要17×5＝85天来完成这个项目（如果只是一个开发人员来做的话）。假设现在我们的团队里面有两个开发人员，所以我们就需要85÷2＝43天来完成。

从目前的估计来看，我们可以在50天的期限里面做完这个项目。但现在说这个还太早了！这样的评估，更多的是猜测。通常开发人员在工作量上的估算都很差。事实上，人们经常会低估了工作量。那我们应该怎么估计得更准？

我们实际的开发速度是多少

为了做到更准的估计，我们就让客户先给我们两周的时间做一些实际的开发，来测量一下我们在这两周里面可以做多少的用户故事。我们叫这两周的时间为“迭代周期”。

哪些用户故事应该放在第一个迭代周期里面做？这可能完全是客户决定的，也可能是大家讨论以后决定的。不过挑出的这些用户故事的故事点不应该超过这两周的承受能力。因为一个迭代周期有10天（假设我们周末不工作），然后我们估计一个开发人员5天可以完成一个故事点。现在我们有两个开发人员，所以我们应该可以在这个迭代周期中完成（10÷5）×2＝4个故事点。

然后客户可以在总故事点不超过４的前提下，挑出一些用户故事在这个迭代周期里实现。他们可能会尽量挑选他们觉得最重要的故事。比如，对他们来说，销售报表跟找零钱最重要，所以他们就挑出这两个：
用户故事故事点
取出钱箱里的钱1
打印月销售报表2
总计3

假设两周的迭代周期过去了，我们完成了“取出钱箱里的钱”，不过“打印月销售报表”没有完成，还剩0.5个故事点没有完成。也就是说，我们在这个迭代周期内完成了3-0.5＝2.5个故事点（比原来的预计要差一些）。

2.5个故事点这样的数值，就是我们现在的参考值。也就是说，这个团队每个迭代周期可以完成2.5个故事点。这个参考值对我们很有用。它有两个用处：
首先，我们可以假定我们在下个迭代周期也可以完成2.5个故事点，然后客户选择的用户故事的故事点总和不能超过2.5。
其次，在从第一个迭代周期取得参考值以后，我们可以重新估算我们的发布时间了。本来我们估算我们每个开发人员完成1个故事点的时间是5天，现在我们有了实践后的数据了，我们的团队（两个开发人员）可以在一个迭代周期（10天）内完成2.5个故事点。现在总的故事点是17，计算一下，我们需要17÷2.5＝7个迭代周期来完成。14周，也就是70天。也就是说，我们满足不了客户提出的期限（50天内）！怎么办？

预计不能如期完成时怎么办？

很明显，现在我们完成不了全部的用户故事。在这50天里面，我们只能完成50÷10×2.5＝12.5个用户故事。因为现在有17个故事点，我们应该让客户挑出总计4.5个故事点的用户故事，推迟到下一个发布周期去。客户应该选择那些比较次要的用户故事。比如，客户可以推迟“打印月销售报表”这个用户故事。

（这只是开发不能如期完成时的解决方法之一，这种方法应该是在客户比较有诚意合作的前提下使用。）
用户故事故事点
卖饮料4
取消购买2
输入管理密码1
补充饮料3
取出钱箱里的钱1
安全警报2
总计13

然后他还要挑出总和至少为0.5个故事点的故事。

但是如果“月销售报表”这个用户故事对客户来说也是非常重要，而且其他的故事也不能推迟，这时怎么办？这时我们就要试着简化这些用户故事。比如，原来“月销售报表”是要用一个第三方报表库来实现的，而且还要画出饼状统计图，如果我们只是生成简单的文本格式的报表的话（这格式应该可以被Excel导入，以便日后的处理）。那么这个用户故事的故事点就会从4减少到2，节省了2个故事点。如果客户同意的话，我们就可以将“打印月销售报表”分成两个用户故事“生成月销售文本报表”和“生成图形报表”，然后将后者推迟到下一个发布。

现在新的故事卡片出来了：
用户故事故事点
卖饮料4
取消购买2
输入管理密码 1
补充饮料3
取出钱箱里的钱1
安全警报2
打印月销售文本报表2
总计15

还有其他的2.5个故事点要推迟，我们可以简化“卖饮料”。假设本来我们可以卖不同价格不同类别的饮料。如果现在我们只是简单支持一种价格一种类别的饮料的话，那这个用户故事的故事点可以从4减到2了。客户如果同意的话，我们就可以将“卖饮料”分割为“卖单一饮料”和“卖多种饮料”，然后将后者推迟到下个周期发布：
用户故事故事点
卖单一饮料2
取消购买2
输入管理密码1
补充饮料3
取出钱箱里的钱1
安全警报2
打印月销售文本报表2
总计13

现在还剩0.5个故事点，我们再考虑一下“安全警报”。假设本来这个故事是要同时触发本机上的警报，跟通知附近的一个警察局的。如果现在我们只是触发本机的警报，那所花的故事点就可以从2减到1了。于是在客户同意的情况下，我们将“安全警报”分割为“本机安全警报”和“通知警察”，然后将后者推迟到下个发布：
用户故事故事点
卖单一饮料2
取消购买2
输入管理密码 1
补充饮料3
取出钱箱里的钱1
本机安全警报1
打印月销售文本报表2
总计12

现在我们总计有12个故事点要做了（lt;=12.5）。上面这个筛选在本次发布的用户故事的过程，叫“发布计划编制”。

增加开发人员来满足发布期限

在上面的例子中，我们以推迟部分用户故事到下个发布周期的办法来解决问题。这种“控制开发范围”通常是最好的解决办法。不过，这种解决办法实施不了的情况下，那你就只好保留所有的用户故事，然后增加更多的开发人员了。在这个例子中，假定我们需要“n”个开发人员，才能在50天内完成17个故事点。50÷10×2.5×n÷2.算出来，n＝2.7，我们需要3个开发人员，也就是多加一个开发人员进来。不过注意：
团队人数加倍并不等于开发周期的减半。它可能只会缩短1/3。如果团队超过10个人的话，增加更多的人员可能反而会延缓项目的进度。
而且项目开发周期越长，团队内的成员对整个项目代码的熟悉度就越少，加上不确定的人员流动，新来人员的业务不熟等其他可能性，这项目会越来越复杂。
总的意思就是，项目人数不能太多，周期不能太长。

根据参考值来掌控项目

每个迭代周期2.5个故事点的这个参考值，只是第一个迭代周期的数据，第二个迭代周期可能会变成2或者3（一般是不会变动得太大）。假设是2的情况下，那对于第三个迭代周期，我们就要将参考值设为2，然后让客户以2为故事点总数来挑选用户故事。
对于大多数项目，参考值很快就会稳定下来（比如在几个迭代周期后）。当这个值稳定下来后，我们就要重新估计开发周期，重新进行“发布计划编制”了。如果这个参考值告诉我们，我们每个迭代周期可以做3个故事点的话，我们就要让客户挑选更多的用户故事放在这次的发布计划中。相反如果这个参考值是2的话，我们就要让客户减少用户故事（需要的话可以分割一些用户故事），如果团队人员还不多的话，可以增加更多的开发人员。

这是项目的初始阶段绝对要注意的。

发布计划编制，估算每个用户故事时要考虑哪些细节，忽略哪些细节？

在项目初始，我们要找出这个发布周期内所有主要的用户故事，评估每个故事的故事点。可是要怎么评估里面的细节呢？比如对于“卖饮料”， “卖饮料”这个简单的标题，省略了很多的细节：用户会投入什么样的钱？纸币可以吗？人民币可以吗？按钮的灯的亮度要多少？可不可以多个按钮对应一种饮料？按钮被按下以后，要不要变暗？找零钱是不是全部找10分的面额？
我们是不是要考虑上面所有的细节？对于按钮灯的亮度，我们就不用考虑了，它对我们的工作量没影响。不过，零钱的面额就对我们的工作量很有影响，我们要认真考虑一下（找一堆10分的零钱就很容易实现；如果要尽量减少零钱的个数就比较麻烦了）。处理不同币种也要考虑。
一般情况，我们不用太担心会漏过什么细节。对于每个用户故事，只要考虑一些“重要”问题就行了。当然，这里面的“重要”，就要根据经验以及客户的观点来决定了。

如果我们不好估算的话怎么做

如果我们觉得，这个用户故事不好估算，那可能的原因就是：

1.这个用户故事太大。这种情况我们就可以将这个用户故事分割出若干个新的用户故事，比如：
将“卖饮料”分割出：
1：显示总投入金额。
2：金额够买的饮料对应的按钮灯亮起来。
3：按下亮灯的按钮，可以买到对应的饮料。
2.我们之前从没开发过自动售货机的程序。因此，我们不知道开发这样的程序有多复杂。这样的话，我们就要做一些实验了，比如做一个让售货机找钱的小程序。这种试验就叫“spike”（翻译不出来）。

迭代周期内的计划编制

对于这个迭代周期内选择的所有用户故事，不像在发布计划编制那样，只是考虑一些重要的细节，现在我们要从客户那里调查到所有的细节。比如对于“卖饮料”，我们可能会在白板上画出用户交互的草图，然后跟客户一起讨论：
这是一台自动售货机……
用户投入硬币……
假设他投入的是50分，而价格是40分，那么按钮就会亮起（别忘了我们现在做的只卖单一饮料）
用户按一个亮起的按钮，一罐饮料会掉到售货机的出口
找零钱……

在跟客户详细讨论完，了解了足够的细节以后，我们才发现，事实上这个用户故事“卖饮料（只卖单一的）”的故事点远远比我们预计的要麻烦，这时候应该类似前面的发布计划编制那样，1、分割出小的用户故事，挑出一些放在下一个迭代周期内；或者2、挑出这个迭代周期内的一些用户故事放在下一个迭代周期。反之，如果发现这个用户故事比我们想像的还要简单，那我们就要增加更多的用户故事到这个迭代周期内。

用户故事只是跟用户交流的开始，而不是全部

假想现在已经从客户那边得到足够详细的需求了，我们可以开始实现了。注意，我们不用把所有用户提供的细节都记录下来。为什么呢？假设以后，你有点忘记用户故事，而客户又在你旁边，你是直接问客户，还是去找看需求文档找到你要的东西？当然是直接问客户了。客户可以提示更准确，更完整的需求给你。特别要注意的是，以后只要你一完成一个用户故事，你就要让客户看一下，或者实际的操作一下，因为客户对已经做的的东西了解得越多，那他就可以提供越准确越完整的需求。
用户挑选完用户故事以后，在之后的两个星期内，我们就要将这些用户故事逐个完成。每个用户故事我们都会设计结构，编码，测试等等。每做完一个用户故事，我们都要让客户验证一下系统是不是他所想的那样。

在这两个星期内，如果我们提早完成了用户故事，我们就要让客户挑更多的用户故事。相反的，如果我们不能及时完成，我们就要让客户知道当前的进度。

总结

小公司如何做项目管理

我所在的公司和大多数国内IT公司一样，十几到几十人的规模，每次在做完项目过程中我们都会感觉很累，老板其实也很累，在小公司老板更像是一个项目经理的角色，很多东西都没有流程化的东西可走，所以很多事情都要等老板拍板后才可以继续下去，员工在很多时候就会感到迷茫，随着公司规模的扩大，公司也意识到没有一套规范的项目管理方案是万万不行的，自己在这方面也摸索的一段时间。

我首先接触的是敏捷开发的方法，但很快我就感觉这个方法行不通，至少对于我们是这样，因为我们无法保证和客户以及业务人员及时沟通，一个月见几次面就很不错了，而且我们的开发人员也并不具有敏捷能力。后来接触了下CMMI，CMMI对于小公司就更不靠谱了，它庞大的身躯足以把一个小公司压垮，如果仅为一个证书的话，我建议完全可以向o6z订购，但不可否认的是CMMI也有很多优秀的地方可以借鉴。那么我对小公司项目管理的看法是一定要精简，做到不是傻瓜都能够理解并且能够执行，况且很多项目经理（老板）也并不是领域专家。在此我想简单谈谈我对适合小公司的项目管理方案的一些想法，所谓基本适合就是80%适合，我要是说100%适合那我是在扯淡，另外20%怎么办？那就像06z所说的那样，靠经验这个王道。

首先要谈的是需求这个东西，那么什么是需求？需求就是掏钱买你产品的人一些需要，只要是客户的需要，不管是合理不合理那都是需求。其实很多开发人员都意识需求的重要性，那么真正去做需求的人有多少呢？需求应该是包括需求开发和需求管理这两个过程，这里有个特别的情况是对于自主研发的项目，我接触的项目也是这种情况居多，于是我们认为自己就是客户，所以需求开发做的很简单甚至跳过去，结果后期的需求管理非常混乱，我觉得既然自己是客户，那就要当好客户这个角色，在做客户时应完全忘却自己是个开发人员，同样要把需求做全面。很多教科书上都说应该做需求，但关于怎么做的问题上却和实际情况差别比较大，以下是我关于需求该做什么以及怎么做到一些看法。

1 需求调研

我觉得需求调研非常的重要，1年前我还打算做一个在线教育服务平台，理念就是淘宝在网上卖商品，我在网上卖教育资源，我提供网上交易场所，签约的老师、学校以及培训机构提供可交易的服务，这种服务可以通过视频、音频、在线PPT、文本的形式展现。忙活了好一阵，发现这个市场早就有很多人做了，而且这个市场并不是很好做，首先在网上学习的人有几个？并且先不说前期推广需要海量资金就是所需要的那么些高性能服务器丫也买不起！这件事就此搁浅，结果信了马云的邪，2年后你还想创业你在创业！我觉得这就是典型的需求调研没做好，没有对用户需求做调查，没有考虑同行竞争，没有考虑可行性！另外还要考虑括行业标准和法律规定，比如前些时候国家就出台了关于办视频网站的政策，我觉得你丫没有足够的背景就不要往火坑里跳楼。总之根据所做行业情况尽可能的把需求调研做全面，这样才可以保证项目首先是可以赚钱的。那么文档要写吗？我觉得可以不要正式的文档，小公司的人手本来就不够用，要把主要文档化工作集中在重要的环节上，对于需求调研，本来就很杂乱，完全可以记在工作笔记上，放到需求分析的时候整理。

2 需求分析

为了得到用户的金钱，我们总是在说，用户是上帝，用户永远是对的，尽管背地里在说客户端坏话：“你丫钱给的倒不多，要求还真少，这需求根本不合理，是正常人的逻辑吗？”，如果你想活下去，最终我们还是要想方设法满足用户的要求。用户是个外界因素，我们是无法控制的，那么我们只有尽可能改进需求分析的方法来尽量减少不必要的麻烦。那么我觉得日本人做法倒是可以借鉴，在有条件的情况下派专人去现场，随时记录关键性的需求，即使不能去现场也尽可能的获取尽可能多大信息，不要指望开发后去获取什么有价值的东西。那么是否应该做个原型给客户看看？我是觉得这不大合适，因为如果项目周期短的话，等你做好原型，黄花菜都凉了。但我觉得等到需求做到差不多的时候可以做用户界面，所谓用户界面就是用户接口，是和用户打交道的地方，所谓一图解千言，有了界面用户会清楚自己所买的东西在未来会是个什么样的东西，再者开发几个有说明性都界面倒是不会暂用很多时间。等到需求确定下来后就要整理成文档了，这个是很重要的一步，是做设计时候的重要凭证和依据，这个文档就是用户规格说明书，所谓规格就是有规范的格式和内容。

3 需求评审

我们已经有了较正规的文档了，那么下一步就是召集所有开发人员开会，最好有客户代表参加，尽管我是很厌烦开会，但该开的会还是要开到，因为之前我遇到这种情况，开发人员根据设计文档写代码，可是他并不知道自己在开发什么，站在自己的角度想一下，如果自己都不确定自己做的东西，即使有再完备的设计，也会对开发毫无兴趣，只会让自己觉得自己是个代码机器。所以所有人员参加需求评审是让大家知道自己在做一件有意义的事情，自己正在满足社会的需要，自己在为和谐社会做贡献，即使你从没那么想过，那你敢保证的你的潜意识没那么想过吗？人是要有社会满足感的吧。另外开会前一定要准备关键有价值的议题，据我观察需求评审会最容易扯到不着边的话题，所以主持人要控制话题，会议控制在2-3个钟头，最好做成幸运52的形式，所有人员一定要互动起来，否则就变成了个人演讲。需求也做了，会也开了，那么要求客户签字吧。

4 需求管理

需求管理是在开发开始之后进行的，这也是另所有人头疼的一件事，之前做完一个项目后，客户经常打电话找我们，改过来改过去，后来我听到电话，血压都要升高50个百分点，后来索性就不接电话，客户就在网上找我，搞的我连QQ都不敢登，但躲是躲不掉滴，客户直接打我手机，丫的真烦人，见过难缠的，没见过这么难缠的。后来转念一想，难道这种情况真的不能避免吗？至少是可以大幅度的缓解的吧。这就是我们需求管理中的变更管理没做好，改了哪些地方自己都忘记了，最后是跟着感觉走，拆东墙补西墙。在这里我建议要建立需求跟踪矩阵表，有了这个表我们至少可以对要修改的地方有了依据，迫使我们去调查到底是改什么地方，怎么改，最后改成了什么样。可能你会说客户需要大幅度修改原有计划，很难跟踪到具体某一项需求，那么我觉得这是由于前期的需求开发没有做好，在后期客户进行实质性的修改的几率是很小的，比如客户要求我们做个OA系统，最后总不会要我们改成个门户网站吧，在举个例子，在比如你开发一个ERP系统，客户自己的业务流程不会轻易的改变吧，总不至于把盘点这个业务改成一个报表系统吧。如果真是这样，我们完全有理由告诉客户，你丫乖乖掏银子，我们再给你们开发2期工程，要改，没门！

在上篇文章里，我简要谈了项目管理中的需求开发和管理，那么在这篇文章里就和各位以闲话家常的方式讨论下项目规划和项目监控。项目规划、项目监控其实也是项目管理中比较核心的工作，也是很多开发人员最敏感的话题，因为这两个东西与公司的领导和员工关系都非常的密切。

先从我以前的学校说起，以前我们学校有片荒地，当时的领导觉得学校应该搞绿化，于是组织在荒地上植树，不到一年换了一个校长，这位校长觉得学校应该抓体育运动，决定再造一个足球场，于是把树移走，造了一个足球场，再后来北京奥运会来了，学习为了迎合绿色奥运的理念又开始植树，这就是没有规划和监控的典型例子，结果是劳民又伤财。当然对于学校来说，有国家财政的支持，有资本这么折腾，可是对于小公司做项目来说，这么折腾几下估计很快就要牺牲了。

事实求是的说大多数小公司在这两个方面做得很少有令人的满意的，小公司的老板其实也会意识到公司在项目规划和监控方面做得不咋地，但很少能做到有效的改进，其实这个也是有很多方面的原因的，以我自作多情的猜测主要有以下两个原因，对于小公司，尽管盈利不是很多，但基本还是可以撑下去的，老板会觉得管他乱不乱，公司总之每个月还是有盈利的，少就少点吧，多干几年自己的下半辈子基本有别墅有车了，所以比较保守，要是改革吧，万一鸡飞蛋打怎么办？还是本分点好，小心使得万年船。其实是对项目规划和监控其实需要大量的成本，老板觉得钱应该花在刀刃上，搞这些东西就是在务虚。再者更恶劣的老板有病就乱烧香，就有想想借助CMMI这个洋玩意治病的，其实很多老板都蛮喜欢CMMI的，CMMI就是假定人就是一个机器的部件，可以替换可以不停的运转，总之管机器总比管人省心吧，结果是万分的矛盾，银子撒了一大把，收效却甚微，甚至比以前更乱，大家做的都不开心。与其听咨询师们拿什么高深的方法论来瞎掰，不如我们谈点实际的，想就以下议题来和各位消遣。

1 工作量估算

对于工作量估算很多项目经理（老板）喜欢用数学公式来计算，可能数学公式更加的客观和科学，ok,，看看市面流行的计算方法吧，最常见的是基于代码行的数学模型，那么这里存在不少问题，工作量估算主要是为了在项目进行中进行有效的项目监控，那么软件开发尚未结束，谁知道最后的代码行有多大？代码经常会被修改，那么修改的代码算不算？如果算，那么代码修改越多难道能说明工作量越大？代码效率的区别也是很大的，假如一个10行代码可以实现的东西被写成50行，难道能客观的反映工作量？还有2种比较高级点的方法是基于功能点和COCOMO的方法，那么我想问的是它们的公式中的系数该怎么定？那么不少咨询师忽悠我说，根据自己的实际情况来定呗，那么我想问的是，算命是迷信，电脑意味着科学，那么用电脑算命算不算迷信?所以我是主张这里还是要靠人的经验来估算，大家可以在项目周会上对工作量进行充分的估算，在估算时要同时考虑到项目执行的难度，根据经验给出合理的评估。

2 任务分配

大多数的做法是将整个项目划分成一个个可以独立执行的原子任务，这些任务要划分优先级和难度，至少心理有个数，并且每项任务要制定负责人。那么问题就出在这个任务分配上了，软件开发是一项智力创造的活动，如果按CMMI假设的那样，在分配任务时忽略人的因素是万万不可取的，我就有血的教训，不久之前做一个 ruby的项目，然后开始在公司内部随便抓了几个有点ruby基础的人，也没太顾忌别人的想法。做着做着，觉得他们有点心在曹营心在汉，平时还是抱着本 thinking in java看，做ruby也是在敷衍了事，结果是代码质量不行，需要大规模的修改。当然按理说员工应该服从公司的安排，做一样就要做好一样，但员工也有员工的规划，你去叫他做他压根就不喜欢的事只能说明管理有问题。

另外还有一个普遍性的问题是能者多劳，有个朋友刚进公司动手能力很强，也非常的积极，每次做项目都分给他最难最累的任务，做着做着也就厌倦了，这时老板会忽悠你说，你能力强，要挑起公司的大梁，以后公司壮大了给你个什么职位，我觉得这就是在扯淡，这就是我经常见到的忽悠式的管理，很多管理手段完全靠人情，很多人都是在这种环境中被忽悠长大，到最后怎么样？被忽悠了几年还不是另谋高就了，所以指望人情化管理的公司很难长大。我觉得该讲原则的地方就要讲原则，在任务分配上给能力强的分配少而精的任务，而且要考虑到员工自己的想法，有些人想做java架构师，你叫他做oracle dba就不合适，有些对ui设计感兴趣，你叫他做系统分析员也不合适，有些人就喜欢搞技术，你硬要叫他做管理也是不合适。

3 进度管理

在做进度之前，一项最重要的任务是识别关键任务，很多进度表进行任务安排时将各项任务平均分的特点为觉得极不合适，有些任务比较难处理，而且许多后续任务依赖于该项任务，那么这项任务就应该配备更精良的人手和充裕的时间，依我的经验80%的时间都是在处理这些20%的关键任务上。这里还有个比较重要的问题是时间安排，我听很多项目经理说时间安排要尽可能的紧，也就是比预计要靠前，这样员工才有紧迫感。我觉得这是不可取的，首先即使你按原计划进行，八成也是要要延期的，那么这就会导致项目严重延期，长此以往，项目延期成了家常便饭，不延期反而不正常，于是大家都成了老油条，那么进度表不就是废纸一张，毫无约束力而言吗！我觉得根据实际情况指定个合理的进度表是比较重要的，或许你会说项目还是在延期，那我觉得是你项目估算没有做好，项目延期在10%左右比较正常，否则就可以调查是什么原因导致进度滞后，如果是客观原因，以后完全可以延长项目时间，总之一个合理的进度表比较重要。

4 项目奖金

这里牵扯到一个钱的问题，据我了解国内大多小公司很少有项目奖金这么一说，年底给点路费就不错了！国内的大多数项目经理更像是一个技术负责人，根本没有用钱的权利，我就曾像公司申请项目奖金，结果计划全盘泡汤，给的理由很荒唐，说项目奖金不好分配，给张三多一点吧，李四不爽，反之亦然。我心理暗自想：“你丫不想给就直说呗！”，这里会导致一个问题，就是“项目经理”凭什么约束成员，大锅饭的道理我也不想再解释了，总之结果就是3个月的项目就得做个5个月，其实老板的小算盘看似很精明，其实未见得，虽然项目奖金能省就省了，那么工作效率的下降所带来的成本的提高，孰轻孰重？长远一点说，产品质量的下滑导致的项目维护的成本你计算过吗？依我的经验，3个月的有效工作时间其实也就是1个月，这已经不错了。不过项目奖金的分配确实是个难问题，但有没有项目奖金和分配合理与否是2码子事吧？由于我也没有能耐申请到项目奖金所以也就没有深入研究这个问题，只得望梅止渴，看看人家华为了，员工根据能力分等级，加上年限、加班、表现得出个权值来计算。总之现有鸡才能有蛋，这个问题需要更深入的讨论。

原文