项目管理沙龙第三次聚会纪要--模式“玩就是心跳”
聚会开始之前先强调了参与沙龙的要点：与会者都是有经验的项目管理者，既然大家都想通过聚会来获得一些知识和经验，那么每个人都要积极地想办法去引导其他人与自己交流，在这个沙龙里，等待和被动是没有意义的。
《项目百态: 深入理解软件项目行为模式》是一本得到jolt大奖的书。它归纳出来项目管理中经常出现的86个模式，这些模式有些是正模式（就是好的做法），但是大部分都是反模式，就是不好的模式。这些模式普遍存在于各个项目组中，我们公司也当然不例外。
"玩的就是心跳"（adrenaline junkie）是这本书的第一个模式，从http://book.51cto.com/art/201101/244194.htm可以阅读，它是一个反模式，说的是一种项目组的类型。该型组织的特点就是：“优先级总是变化不休，所有事项都是"昨天"就要，总是没有足够的时间交付项目，所有项目都是紧迫项目，紧迫的项目源源不断。每个人都忙得焦头烂额……永远如此。” 沙龙的每个成员都对这种类型的“忙碌”深有感触。
“这些组织里面的人不会从战略层次上思考问题，只是按照紧迫程度来完成工作”，这句话引发了我们的讨论。
很明显，这种类型的项目组存在的原因之一是没有优先级，经过其他人的补充，确切地说项目组无法得到优先级，因为客户通常也搞不清楚哪一个优先级较高。所以很多时候，客户就会要求项目组尽快给出一个东西给他看看。在前几次沙龙我们已经谈到了“客户经常是不知道自己要什么，但是知道自己不要什么”，正是因为这个原因，“原型法”在这里应用的效果就会很好。
客户通过原型就可以直观地看到自己未来所要接触的软件是什么样子和拥有什么功能，而且原型还可以刺激客户进一步思考，发掘出一些未曾想到的需求，甚至出现“需求爆炸”。有与会者提出要防止用户这样的联想，担心这样的需求过多可能对项目不利，但是经过讨论，我们一直认为“需求爆炸”是一件好事。
通常的项目接单流程是这样的：客户接触、订立合同、需求调研、系统设计、编码、测试、交付。事实上，大部分中国的公司忽视了需求调研的阶段，而是在项目边开发边设计边调研需求，这就意味着“需求爆炸”通常是在项目进行过程中出现的，毫无疑问，“返工”就出现了，问题也就来了。
如果我们保留了需求调研阶段，同时使用“原型法”来引导客户需求，结合客户需求的优先级评估，在调研结束之后，我们基本可以掌握60%甚至更多的客户需求。然后对每一个需求评估出来优先级，形成一个列表放在客户的面前。不要担心客户会让你实现所有的列表中的需求，除非这是个本来就想着只花10万元让你做一个淘宝的家伙，否则他一定会捏着钱包来选择他想要实现的功能需求的。
我们使用scrumworks中的优先级评估方法：对一个需求（backlog）评估两个值，一个是做了这个需求之后的收益值，另一个是不做这个需求之后的损失值，两个值的相加结果就是该需求的优先级值（显然做了收益最大且不做损失最大的事情优先级最高）。
如果客户是比较强势的话，项目组也可以让步，但是千万不要将demo当作正式版去交付，一定要抽时间重构甚至重做也在所不惜，否则，因为架构问题会引起的非常大的麻烦，到时候“长期性的加班”恐怕也是轻的。
我们认为“过度忙碌”的项目存在的第二个原因是管理者的素质问题。很多老板都希望自己的员工能够忙一些，加班多一些。其实很少有老板能够想到“产出=效率×时间”这个公式，认为一味地增加时间就可以完成任务，而从未想到效率也是可以为0的。他们总是以为可以不断地去挖掘员工的潜能，寄希望于某一天有人会来个能力大爆发。
但是这个假设可能并不那么简单，就拿任正非来说，我们大家都觉得他应该是一个聪明人，不会想不到这个效率公式。但是他依然号召华为拼命加班的原因是什么？有人觉得要么他想在华为形成一种时刻有紧迫感的企业文化氛围（他做到了）；要么就是他认为即使加班，效率为0的时间也比较少，所以加班还是会有收益的，更何况加班还是免费的呢（也做到了）；要么就还有其他我们没有想到的原因。
所以有人说，要做老板，一定要想一下自己到底要员工是一个什么样的工作状态。但是无论如何，只有保持员工有充足的休息时间，才能保证有持久的工作效率。否则难保出现华为的例子：一个员工长期加班实在撑不住了，去医院一检查，立刻被下了一张“病危通知书”，糖尿病晚期！
管理者的素质问题不仅仅是这些，现在中国公司的普遍问题是PM太技术化，回顾历史，当年那些编程厉害的人，现在还有几个在编程序？公司都是把这样的人提拔成PM，结果在新的位置上他们需要重新学习和积累经验。就等同于少了一个编程高手，多了一个蹩脚的项目经理。你说这样的人来做管理，怎么会不乱？
引申出来，其实这个可能也是当前中国的IT公司“脉冲式增长”的原因之一。所谓“脉冲式增长”，就是公司借着一个机会迅速扩张，然后在一段时间之内又迅速缩小，如此循环不已。一个可能的合理解释就是创业团队成功之后，公司迅速扩张，创业团队的成员被迫离开技术去做管理，这样导致产品的技术水平下降，进而引起质量问题，最后失去市场。与此同时，蹩脚的管理导致公司的文化和气氛发生变化，进而导致人员离职潮...最终公司又回到原来的起点，而且创业团队也分崩离析。如果运气好，这个公司还会苟延残喘，等待下一次脉冲的时机。
那么我们是不是可以避免这种编程高手到管理初学者的情况呢？职场心理方面的研究告诉我们，“每个人都有不断追逐不称职岗位的欲望”，2010年搞笑诺贝尔奖的管理奖就是关于这个问题的http://www.cnbeta.com/articles/123444.htm，他们从数学上证明，如果随机选择一个人升迁，可以让公司运作更有效率。由此，现行的升迁制度的效果可见一斑了。
第三个可能原因，不外乎钱的问题。有人说“所有钱能解决的问题，都不是问题”，可是另外一个事实则严酷的多：“所有因为省钱而省出来的问题，最后都变成了钱解决不了的问题”。
我们总结出来了一个典型的场景：某公司研发了一个新产品，大卖。于是该项目的架构师A也觉得当年自己的收入会很好，结果公司没给他加薪或升职，于是失望。接连几次失望之后，于是架构师A离职了。架构师B接手项目，发现架构上有些需要改进的地方，但是因为时间紧，打了一个补丁上去，心想有时间的时候在重构。同样公司最后也带给他一连串失望，架构师B没来得及重构就走了。接下来架构师CDEF 基本都是同样命运...。 最终架构师Z登场，等到他看到一个补丁摞补丁的系统的时候，他想改也无能为力了。最终，项目成了一块硬骨头，丢不得，又吃不消。金蝶的 EAS 多半就是这个状态，不过好消息是，基于中国的现状推断，用友也肯定不会好到哪里去！
有人提出，这样的产品路线，其实不是没有人看到，只不过怕当时花钱多，觉得能拖就拖罢了，谁想最后就拖不起了。
最后，按照本次沙龙的规矩，我们需要给所讨论的模式给出一个“药方”。我们对“玩的就是心跳”模式的解决方案是：
1. 如果到一个公司就发现是这种类型的话，直接离开是上上策。其次如果努力之后无法改变，离开也来得及。
2. 充分沟通，减少焦虑感。对客户，要引导他，让他在对需求和项目有充分的了解之后再做决定；对于员工，则要尽可能透明，比如一些战略规划，收益情况和收益的分配方法等，通过这些信息公开，逐渐形成一个“价值反馈循环”，即项目组和商业的互动反馈模式。
3. 让管理层了解公司自身的实际能力，尤其是工作效率。避免出现“让出租车一天内从深圳机场开到北京”的情况出现。一个人开汽车的时候能够知道自己的最大速度是多少，同样的人开公司，我想也应该让他知道这个公司的速度。