注： 哲理故事与管理之道-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     [http://jlins.iteye.com/](http://jlins.iteye.com/category/202600) **故事一、海马的焦虑**           小海马有一天做了一个梦，梦见自己拥有了七座金山。           从美梦中醒来，小海马觉得这个梦是一个神秘的启示：它现在全部的财富是七个金币，但总有一天，这七个金币会变成七座金山。 于是它毅然决然地离开了自己的家，带着仅有的七个金币，去寻找梦中的七座金山，虽然它并不知道七座金山到底在哪里。           海马是竖着身子游动的，游的很缓慢。它在大海里艰难地游动，心里一直在想：也许那七座金山会突然出现在眼前。           然而金山并没有出现。出现在眼前的是一条鳗鱼。鳗鱼问：“海马兄弟，看你匆匆忙忙的，你干什么去？”海马骄傲地说：“我去寻找属于自己的七座金山。只是……我游得太慢了。”“那你真是太幸运了。对于如何提高你的速度，我恰好有一个完整的解决方案。：”鳗鱼说“只要你给我四个金币，我就给你一个鳍，有了这个鳍，你游起来就会快得多。”海马戴上了用四个金币换来的鳍，发现自己游动的速度果然提高了一倍。海马欢快地游着，心里想，也许金山马上就出现在眼前了。           然而金山并没有出现，出现在海马眼前的，是一个水母。水母问：“小海马，看你急匆匆的样子，想要到哪里去？”海马骄傲地说：“我去寻找属于我自己的七座金山。只是……我游得太慢了”“那你真是太  幸运了。对于如何提高你的速度，我有一个完善的解决方案。”水母说，“你看，这是一个喷汽式快速滑行艇，你只要给我三个金币，我就把它给你。它可以在大海上飞快地行驶，你想到哪里就能到哪里。”海马用剩下的三个金币买下这个小艇。它发现，这个神奇的小艇使它的速度一下子提高了五倍。它想，用不了多久，金山酒会马上出现在眼前了。           然而金山还是没有出现，出现在海马眼前的，是一条大鲨鱼。大鲨鱼对它说：“你太幸运了。对于如何提高你的速度，我恰好有一套彻底的解决方案。我本身就是一条在大海里飞快行驶的大船，你要搭乘我这艘大船，你就会节省大量的时间。”大鲨鱼说完，就张开了大嘴:“那太好了，谢谢你，鲨鱼先生！”小海马一边说一边钻进了鲨鱼的口里，向鲨鱼的肚子深处欢快地游去…… **这是一个崇拜速度的时代**           在一个盛行崇拜速度的时代，有不少管理者把诸多的管理问题归结为速度的问题，又把速度问题简化为提速问题。他们像那条海马一样，对“慢”的焦虑成为他们的基本焦虑：“我去寻找属于我自己的七座金山。只是……我游的太慢了！”于是，他们把企业的发展战略简化为“买入”战略……用金钱来购买速度。然而，只有强烈的发财愿望而毫无目标管理可言，企业的经营尚处“漫游状态”时，快或慢是没有分别的。因为此时我们找不到一个参照系数来判断多快才算快，多慢才算慢。正像我们在海马故事中看到的，为快而快的发展模式最终可能使企业被“速度之魔”耗尽资源并且欢快地走向灭亡。混乱的战略，模糊的目标，极可能使企业陷入一种可怕的“商业浪漫主义”之中。作为商业浪漫主义的典型形态，漫游式经营暗中注定“通向毁灭之路”。一个人如果没有明确的目标，没有“正业”，他就会滋生出很多零碎的爱好和荒诞无稽的“浪漫情怀”。对于一个企业来说，同样如此。在一个市场化程度不高，客户成熟度低的商业环境中，可能有以浪漫的管理手法获得成功的企业，可能会有诗人，哲学家式的企业家。然而随着市场逐渐成熟，客户的鉴别力和权力意识的增强，此类企业和企业家会逐渐绝迹。80年代在中国翻云覆雨的商界名流后来纷纷落马，就是一个旁证 。 **开发团队也崇拜速度**           对于开发团队来说，崇拜速度依然是目前存在的主流行问题，大家或多或少的听说过这样的话：“软件的交付时间决定的软件的价值，交付时间每拖延一周，软件价值就较少x% ”。 领导层同样会对速度比较看重，然后就会直接或者间接的给下属压力 。        **例如下面的场景：**              客户代表山姆和项目负责人露西讨论项目的完成时间。              山姆说：“路西：我们这个项目我希望你们能在10.1号之前交付，10.1后交付我们就会失去抢占市场先机的机会了。”              于是路西赶紧找到项目经理杰克，说“杰克,这个项目必须在9.20号完成，否则客户会生气,我们将会很难过，项目奖金就不能正常发了！”              然后杰克匆匆忙忙的召开了团队项目会议，在会议上严肃的对大家说“这个项目必须在9.12号之前给我完成，不然的话客户就不会给我们打项目款，我们团队就完蛋了！从今天开始，团队必须要强制加班,未来的3个月内，每个月只能休息一天......”                  上面的场景在目前的项目开发中应该不少见吧，每一层的领导都会采用提前工期的压迫方式让下属提前完成任务，然后给自己一点风险处理的时间，然后呢，本来是要求10.1要完成的工作，最后被通知完成的时间提前了接近20天，那结果呢？           要求高速度的同时还要保证高质量？团队认为项目日期十分的紧张，故而舍弃了很多框架设计、功能设计、的质量的校验和测试，而把所有的时间投入到功能完成上来.最后虽然完成了功能，但是bug频出，又因为前期设计的不够导致改不完的bug,最终导致光bug修改的时间都比开发的时间长...           项目急：这是加班中最大的原因，频繁的加班已然成为了软件行业的标志,给开发人员的身心造成了很大的伤害..   **做为一个项目经理改如何识别和避免日程安排的游戏呢？**            **故事 "给我一块石头"**           克里夫与团队一起，用一周时间制订出了项目日程。他们完成了“哈德逊湾式启动”，并且确定已经识别出了主要的技术风险。他将风险和日程安排告诉了他的上司诺姆。“你就不能再早点完成项目了吗？”诺姆的一句话将克里夫送回了团队，步履蹒跚。            克里夫与团队又花了一周时间修改时间表，得到另外一个日期。他走进诺姆的办公室， 说道：“如果你能在这里和这里为我提供更多的人手”，他 指着几个里程碑，“我就能用一个月时间完成项目。 ”诺姆皱着眉头说道：“还不够好。我需要这个项目早点儿结束。”克里夫叹了口气，又回到项目团队中去了。            又过了一周，克里夫拿着另一个日程来找诺姆，“好吧，这就是我们力所能及的结果了。 ”克里夫说。 诺姆几乎连看都没看，就说道：“但是还是不够好。” 克里夫暴怒道：“你到底想要什么？”             “给我一块石头” ，这就是诺姆玩的游戏。不管你制订出什么样的日程，你的出资人总是希望项目能更早完成。你只会发现：出资人不会认同你提出来的每一个截止日期——你的日期总是离他们的期望值很遥远。              当“他们”希望项目能更快交付，但是不告诉你何时需要或为什么的时候，就会玩“给我一块石头”游戏。如果他们告诉你期望截止日期，你就能告诉他们能完成哪些工作。如果他们告诉你原因，你和团队也许就能想出一些创造性的解决方案来满足他们的要求。 讲求实效的项目经理自有应对之策，其中就有克里夫采取的谈判策略。一旦谈判失败，或者看起来永远难以成功，  在一个组织中， “给我一块石头”的游戏会反复发生。很多时候，每个项目都会发生这种状况。如果你总是碰到“给我一块石头”的问题，考虑采用下面的实践。                    **1、在试图取更多石头之前，先提几个问题**：你喜欢短的日程，还是长的日程？是要更多的人，还是更少的人？要是少实现几个功能会如何？先知道什么是最重要的，这会帮项目经理产生更加合理的解决方案，多少也能为你的谈判做些准备。           **2、要让出资人明白你做出的选择以及背后的原因** 。也许出资人会有更容易操作、更快实现的好主意。           **3、为你提供的日期说明信心范围** 。很可能管理层不明白你的估算意味着什么，而且你也有可能不理解他们所要的东西。           4、**在提供日期时要说明发布条件** ，这样你就可以提一些问题，了解他们对于发布版本的质量和功能的要求。我们可以让这个功能的性能极其出色，但是就得先放下那个功能，这  样做可以吗？用户们可以接受带有更多缺陷的产品吗？           **5、制订排好优先级的产品代办事项**           **6、逐个实现功能。如果能够让出资人了解更多的项目进程，他们就不会那么纠缠截止日期了。**           **7、使用短小的时间盒（持续时间少于四周），** 这样出资人就可以看清项目进程。如果你每隔几周就能展示出项目的有价值的进展，截止日期就没那么重要了。你可以开始讨论何时实现哪个功能，他们对质量的要求又是什么。   **最后**           项目经理在算工期的时候不要把员工的加班时间也考虑进去 .请考虑开发人员的身心健康 [](http://blog.csdn.net/dyllove98/article/details/7275320)[哲理故事与管理之道(9)-善用员工的缺陷](http://blog.csdn.net/dyllove98/article/details/7278880) [哲理故事与管理之道(8)-挖一口属于自己的井 ](http://blog.csdn.net/dyllove98/article/details/7275320)[哲理故事与管理之道(7)-不可奖励员工错误的行为 ](http://blog.csdn.net/dyllove98/article/details/7266950)[哲理故事与管理之道(6)-看学历更要看能力 ](http://blog.csdn.net/dyllove98/article/details/7266936)[哲理故事与管理之道(5)-授权与控制的管理技巧 ](http://blog.csdn.net/dyllove98/article/details/7261882)[哲理故事与管理之道(4)-善用员工的优点 ](http://blog.csdn.net/dyllove98/article/details/7261871)[](http://blog.csdn.net/dyllove98/article/details/7261853)[哲理故事与管理之道(3)-不要吝惜赞美 ](http://blog.csdn.net/dyllove98/article/details/7261853)[哲理故事与管理之道(2)-留个缺口给下属 ](http://blog.csdn.net/dyllove98/article/details/7261814)[哲理故事与管理之道(1)-沟通从倾听开始](http://blog.csdn.net/dyllove98/article/details/7261748) <哲理故事与管理之道> by dyllove98 @[http://jlins.iteye.com/](http://jlins.iteye.com/category/202600)                @[http://blog.csdn.net/dyllove98/article/category/1078476](http://blog.csdn.net/dyllove98/article/category/1078476) 关注@[我的新浪微博](http://weibo.com/dyllove98) 关注@[我的腾讯微博](http://t.qq.com/dyllove98)