你还在崇拜速度吗?

The Depth of Sensibility.
Post Reply
星际浪子
Posts: 3585
Joined: 01 May 2009 23:45

你还在崇拜速度吗?

Post by 星际浪子 » 23 Feb 2012 15:35

故事一、海马的焦虑

小海马有一天做了一个梦,梦见自己拥有了七座金山。
从美梦中醒来,小海马觉得这个梦是一个神秘的启示:它现在全部的财富是七个金币,但总有一天,这七个金币会变成七座金山。
于是它毅然决然地离开了自己的家,带着仅有的七个金币,去寻找梦中的七座金山,虽然它并不知道七座金山到底在哪里。
海马是竖着身子游动的,游的很缓慢。它在大海里艰难地游动,心里一直在想:也许那七座金山会突然出现在眼前。
然而金山并没有出现。出现在眼前的是一条鳗鱼。鳗鱼问:“海马兄弟,看你匆匆忙忙的,你干什么去?”海马骄傲地说:“我去寻找属于自己的七座金山。只是……我游得太慢了。”“那你真是太幸运了。对于如何提高你的速度,我恰好有一个完整的解决方案。:”鳗鱼说“只要你给我四个金币,我就给你一个鳍,有了这个鳍,你游起来就会快得多。”海马戴上了用四个金币换来的鳍,发现自己游动的速度果然提高了一倍。海马欢快地游着,心里想,也许金山马上就出现在眼前了。
然而金山并没有出现,出现在海马眼前的,是一个水母。水母问:“小海马,看你急匆匆的样子,想要到哪里去?”海马骄傲地说:“我去寻找属于我自己的七座金山。只是……我游得太慢了”“那你真是太 幸运了。对于如何提高你的速度,我有一个完善的解决方案。”水母说,“你看,这是一个喷汽式快速滑行艇,你只要给我三个金币,我就把它给你。它可以在大海上飞快地行驶,你想到哪里就能到哪里。”海马用剩下的三个金币买下这个小艇。它发现,这个神奇的小艇使它的速度一下子提高了五倍。它想,用不了多久,金山酒会马上出现在眼前了。
然而金山还是没有出现,出现在海马眼前的,是一条大鲨鱼。大鲨鱼对它说:“你太幸运了。对于如何提高你的速度,我恰好有一套彻底的解决方案。我本身就是一条在大海里飞快行驶的大船,你要搭乘我这艘大船,你就会节省大量的时间。”大鲨鱼说完,就张开了大嘴:“那太好了,谢谢你,鲨鱼先生!”小海马一边说一边钻进了鲨鱼的口里,向鲨鱼的肚子深处欢快地游去……

这是一个崇拜速度的时代

在一个盛行崇拜速度的时代,有不少管理者把诸多的管理问题归结为速度的问题,又把速度问题简化为提速问题。他们像那条海马一样,对“慢”的焦虑成为他们的基本焦虑:“我去寻找属于我自己的七座金山。只是……我游的太慢了!”于是,他们把企业的发展战略简化为“买入”战略……用金钱来购买速度。然而,只有强烈的发财愿望而毫无目标管理可言,企业的经营尚处“漫游状态”时,快或慢是没有分别的。因为此时我们找不到一个参照系数来判断多快才算快,多慢才算慢。正像我们在海马故事中看到的,为快而快的发展模式最终可能使企业被“速度之魔”耗尽资源并且欢快地走向灭亡。混乱的战略,模糊的目标,极可能使企业陷入一种可怕的“商业浪漫主义”之中。作为商业浪漫主义的典型形态,漫游式经营暗中注定“通向毁灭之路”。一个人如果没有明确的目标,没有“正业”,他就会滋生出很多零碎的爱好和荒诞无稽的“浪漫情怀”。对于一个企业来说,同样如此。在一个市场化程度不高,客户成熟度低的商业环境中,可能有以浪漫的管理手法获得成功的企业,可能会有诗人,哲学家式的企业家。然而随着市场逐渐成熟,客户的鉴别力和权力意识的增强,此类企业和企业家会逐渐绝迹。80年代在中国翻云覆雨的商界名流后来纷纷落马,就是一个旁证 。

开发团队也崇拜速度
对于开发团队来说,崇拜速度依然是目前存在的主流行问题,大家或多或少的听说过这样的话:“软件的交付时间决定的软件的价值,交付时间每拖延一周,软件价值就较少x% ”。 领导层同样会对速度比较看重,然后就会直接或者间接的给下属压力 。

例如下面的场景:
客户代表山姆和项目负责人露西讨论项目的完成时间。
山姆说:“路西:我们这个项目我希望你们能在10.1号之前交付,10.1后交付我们就会失去抢占市场先机的机会了。”
于是路西赶紧找到项目经理杰克,说“杰克,这个项目必须在9.20号完成,否则客户会生气,我们将会很难过,项目奖金就不能正常发了!”
然后杰克匆匆忙忙的召开了团队项目会议,在会议上严肃的对大家说“这个项目必须在9.12号之前给我完成,不然的话客户就不会给我们打项目款,我们团队就完蛋了!从今天开始,团队必须要强制加班,未来的3个月内,每个月只能休息一天......”

上面的场景在目前的项目开发中应该不少见吧,每一层的领导都会采用提前工期的压迫方式让下属提前完成任务,然后给自己一点风险处理的时间,然后呢,本来是要求10.1要完成的工作,最后被通知完成的时间提前了接近20天,那结果呢?
要求高速度的同时还要保证高质量?团队认为项目日期十分的紧张,故而舍弃了很多框架设计、功能设计、的质量的校验和测试,而把所有的时间投入到功能完成上来.最后虽然完成了功能,但是bug频出,又因为前期设计的不够导致改不完的bug,最终导致光bug修改的时间都比开发的时间长...
项目急:这是加班中最大的原因,频繁的加班已然成为了软件行业的标志,给开发人员的身心造成了很大的伤害..

做为一个项目经理改如何识别和避免日程安排的游戏呢?

故事 "给我一块石头"

克里夫与团队一起,用一周时间制订出了项目日程。他们完成了“哈德逊湾式启动”,并且确定已经识别出了主要的技术风险。他将风险和日程安排告诉了他的上司诺姆。“你就不能再早点完成项目了吗?”诺姆的一句话将克里夫送回了团队,步履蹒跚。
克里夫与团队又花了一周时间修改时间表,得到另外一个日期。他走进诺姆的办公室, 说道:“如果你能在这里和这里为我提供更多的人手”,他 指着几个里程碑,“我就能用一个月时间完成项目。 ”诺姆皱着眉头说道:“还不够好。我需要这个项目早点儿结束。”克里夫叹了口气,又回到项目团队中去了。
又过了一周,克里夫拿着另一个日程来找诺姆,“好吧,这就是我们力所能及的结果了。 ”克里夫说。 诺姆几乎连看都没看,就说道:“但是还是不够好。” 克里夫暴怒道:“你到底想要什么?”
“给我一块石头” ,这就是诺姆玩的游戏。不管你制订出什么样的日程,你的出资人总是希望项目能更早完成。你只会发现:出资人不会认同你提出来的每一个截止日期——你的日期总是离他们的期望值很遥远。
当“他们”希望项目能更快交付,但是不告诉你何时需要或为什么的时候,就会玩“给我一块石头”游戏。如果他们告诉你期望截止日期,你就能告诉他们能完成哪些工作。如果他们告诉你原因,你和团队也许就能想出一些创造性的解决方案来满足他们的要求。 讲求实效的项目经理自有应对之策,其中就有克里夫采取的谈判策略。一旦谈判失败,或者看起来永远难以成功, 在一个组织中, “给我一块石头”的游戏会反复发生。很多时候,每个项目都会发生这种状况。如果你总是碰到“给我一块石头”的问题,考虑采用下面的实践。

1、在试图取更多石头之前,先提几个问题 :你喜欢短的日程,还是长的日程?是要更多的人,还是更少的人?要是少实现几个功能会如何?先知道什么是最重要的,这会帮项目经理产生更加合理的解决方案,多少也能为你的谈判做些准备。
2、要让出资人明白你做出的选择以及背后的原因 。也许出资人会有更容易操作、更快实现的好主意。
3、为你提供的日期说明信心范围 。很可能管理层不明白你的估算意味着什么,而且你也有可能不理解他们所要的东西。
4、在提供日期时要说明发布条件 ,这样你就可以提一些问题,了解他们对于发布版本的质量和功能的要求。我们可以让这个功能的性能极其出色,但是就得先放下那个功能,这 样做可以吗?用户们可以接受带有更多缺陷的产品吗?
5、制订排好优先级的产品代办事项
6、逐个实现功能。如果能够让出资人了解更多的项目进程,他们就不会那么纠缠截止日期了。
7、使用短小的时间盒(持续时间少于四周), 这样出资人就可以看清项目进程。如果你每隔几周就能展示出项目的有价值的进展,截止日期就没那么重要了。你可以开始讨论何时实现哪个功能,他们对质量的要求又是什么。

最后
项目经理在算工期的时候不要把员工的加班时间也考虑进去 .请考虑开发人员的身心健康

Post Reply