这些哭笑不得的情景,每个程序员都可能面对

这里写图片描述

每个程序员都经历过项目的洗礼,你是项目成员还是项目经理?许多年过去了,那些让你哭笑不得的场景是否依然没有改变?几位大牛将大量场景抽象为模式,以其幽默、深刻的洞察力讲述了项目失败的原因,这些原因跟每一位程序员息息相关。

1、工作忙乱是生产率高的表现

优先级总是变化不休,所有事项都是“昨天”就要,总是没有足够的时间交付项目,每个项目都是加急项目,而且加急项目还在不断出现。每个人都忙得焦头烂额……永远如此。

2、所有失败的会议…

你经常开会吗?你们会议得出的大多数决定都是正确的,且可以很干净利落地决策和行动吗?还是会议组织杂乱,新想法层出不穷,主题不断变化,新问题源源不断,但却没有一个有答案。最终,大家在会议结束时安排了额外的会议。——所有失败的会议最终都走上这一步,概莫能外。

3、死鱼就在那儿

从开工起,项目就完全不可能完成目标,项目团队中的大多数人都很清楚这一点,却缄口不言。

很多组织过于看重成功,所以任何表达疑虑的人都不会因为说真话得到任何奖赏。事实上,如果谁在项目的前期阶段就声称死鱼的存在,管理层的第一反应多半如下:

“证明给我们看。给我们证明成功的可能性是零。不要拿以前项目的死鱼经验来唬人。现在的项目不一样。请用严密的数学证明来告诉我们失败无法避免。”

一旦你提出任何缺乏精确证据的东西,就会被指责为软蛋或者是试图逃避辛苦扎实的工作。

4、项目经理是保姆

快偷偷笑吧,这个好难得!

你所在的组织或许已经有一些“保姆型”经理,如果你留意,会发现:不必预约就能见到你的头儿,或者不必在琐碎和令人生厌的管理工作上花费太多时间。周围是开放的氛围,人们畅所欲言,互相学习。这种经理认为培训或进修非常必要,而不是视之为烧钱。他们还会专门安排时间(比如早晨咖啡闲谈或者周五下午阅读探讨),让大家在一起讨论新想法。

5、把灵魂卖给开发语言

合格的专业人士能够根据待解决问题的实际情况来裁剪解决方案,而不是把个人或者团队久经检验的技能强加在问题上。这不是说团队成员不懂应用已知的工具或方法。他们没有把灵魂卖给任何技术,换而言之,一旦出现了好的新思路,他们能够比较优劣,明智地决策。

不把灵魂卖给开发语言的好处是,当技术潮流退去时,你不会在沙滩上裸泳。你可能知道,有些人自诩为开发人员,却很久都没有尝试学习新的编程语言。这些人眼巴巴地搜寻提到自己所用语言——当年也曾风行一时,但现在基本不再使用的编程语言——的工作职位。悲哀就在于,他们把灵魂卖给了那种开发语言。

6、你们为什么不是米开朗基罗

“我给了你凿子,可你为什么不是米开朗基罗?”这样的疑问充斥在迫不及待希望立即提升生产率的组织,以及招聘时重视应聘者的薪水要求而非所掌握技能的组织。热切人人都是米开朗基罗的组织内,架子上总是堆满了各种工具。

没错,工具是有用的,在合适的人手中它们能大幅提升生产率,还可以完成那些本来无法完成的任务。但是,工具的构造者会告诉你,最关键的是,拥有对应的技能来使用工具。所谓凿子,在米开朗基罗拿起它之前,只是拥有锋利边缘的铁器而已。

7、影评人

影评人是团队成员或者公司内部的旁观者,他们认为自己对项目的贡献在于,指出问题所在或者将会出现问题的地方,至于解决问题,那不是自己的职责。

并不是所有评论项目的人都是“影评人”,重要的区别在于选择的时机不同。如果对项目的成败负有责任感,人们一旦发现事情做得不对,或者可以做得更好,就会毫无顾忌地讲出来。他们会走到他们认为可以发挥作用的人面前,讲出自己的想法。他们尽可能及时地行动,因为他们知道时间总是有限的,纠正措施应该越早采取越好。这些人不是“影评人”,他们是跟你携手并肩的“电影制片人”。他们知道自己和项目是一损俱损的,因此他们每天都会把问题揽在自己身上,以增加成功把握。

而“影评人”往往到“电影”结束,或者快要结束的时候才参与进来,此时已经没有足够的时间来采取纠正措施。

8、沉默即同意

利益相关方无法区分真正的赞同和屈从的沉默。承诺被误解的情形通常是:一方表达了需求,然后另一方点头示意明白。前者把这种情形理解为承诺:“我告诉他必须在12 月31 号以前完成,这非常重要。”后者则视为痴人说梦:“当然,他希望我在年底完成,但那不可能。”通常,提要求的人更有权力,而且他会依据法律上的格言“沉默即同意”来设定自己的期望。如果没有对这样的人物说“不”,就相当于在说“是”。

9、稻草人

“客户只有看到了系统,才知道自己真正想要什么……肯定不是那个系统。”

稻草人模型是一种需求钓饵。你给客户一个激发想法的东西,试探出他们的好恶。这些模型都是快速完成的,而且因为它们不保证正确,所以不必花太多精力。由客户来评审解决方案——比如说,“选定区域销售主页”界面——的实物模型、原型或者故事画板。用这些东西模拟未来要交付的软件,作为回报,客户带你走向真正的需求。

最好的分析师不会问:“你们想要什么?”他们意识到这种问题通常会令人不快。人们讨厌对着一张白纸设想答案,但乐意批评已经写在纸上的答案。

10、贪多求全

组织想要贪多求全,就会影响速度,最终导致净收益降低。但是那种诱惑可能是无法抵抗的……

承担超出最大能力范围的工作是降低速度的罪魁祸首。你大概从未见过有人如此坦率地指出数量和速度之间的关系,因为说出来绝对是令人不快的。正因为大家无视这个问题,所以如此多的组织会为了完成大量的工作而让自己慢到几乎动不了。如果他们暂停下来,从麦麸中挑出麦粒,就能明白停滞的原因是没价值的麦麸太多了。

11、坏消息

在组织里,坏消息不能准确向上传达。

这里写图片描述

12、把坏消息埋在心底

许多企业文化都会传达一种信号:谁发现了杂乱不堪的现象,谁就得负责清理。另外,指出问题,却没有立刻提出改进措施——这会被认为是在抱怨。而在很多组织里面,抱怨者的职业前景相当有限。

13、记者

记者是指这样的项目经理,他们认为,准确报告项目的情况与保证项目成功是两个目标。

想一想记者报道飞机失事的情景。记者觉得自己有责任准确地报道哪架飞机失事了,发生的时间地点,飞机上有多少人,是否有人生还,但他不会因为没有阻止飞机的失事而觉得内疚。那不是他的责任。

记者型项目经理也同样如此。他们的报告清晰、准确、细致,可以列为范本。他们清楚地知道“订单管理”子系统延迟多长时间,偏离关键路径多少天,这项延迟对依赖它的后继任务有什么影响。但是他们忽略了非常重要的事情:这个职位存在的意义,是要保证项目有个圆满结局。

14、数据质量

数据质量往往异常低劣。很遗憾,常见解法竟然是寻找更好的软件来处理它。

数据库软件的质量高出它所处理的数据的质量,这并不罕见,尽管对最终用户来说,系统的质量受制于两者之中更差的那个。各家公司的数据库里面都堆满了不准确的,以及过期或不完整的信息。问题就像鼻子长在脸上一样明显,但人很难看到自己的鼻子。即便每个人都能看出其他人的数据有问题,公司也很难去直面自己的数据质量问题。相反,公司看到的总是软件与数据混在一起的问题。因为软件总是比数据(数据量大得可怕)容易修复,所以公司乐意修复或者更新软件。

这两种做法都没有意义,因为我们要讨论的关键问题不是“为什么我们不应该从软件动手”,而是“为什么明知不是软件的问题,我们仍然从软件动手”。

15、好想法不会很快被接受

更新、更好并不足以保证想法能立刻被接受,接受新想法需要时间。组织会抗拒变化,或者延长决策期,以推迟变化。但是发明和支持更好想法的人可能备受打击,因为看到自己的建议被人忽略,或者被翻来覆去地考量。在军事上,反反复复的思考被称为“慢摇”。在做项目的这些年里,我们看到几乎每一个新出现的好想法都经历过“慢摇”(至少在短时间内是这样的)。举个例子,即使在像软件这种应该是高速发展的行业里面,一些今天已经被广为接受的最佳实践也花了差不多20 年时间才被接受。

经典推荐

这里写图片描述

作者:Tom Demarco等
译者:余晟 金明
书号:978-7-115-39130-8
定价:49
页数:207

第19届Jolt大奖获奖作品
《人件》作者又一力作
入木三分刻画软件项目众生图

“只要经历过一两个软件项目的磨练,就能从书中找出许多熟悉的模式,也会从大多数模式中获益。”
——Joel Spolsky,《软件随想录》作者

“作者兼具十足的幽默感和深刻的洞察力。本书清楚地讲述了项目因何而失败,有何补救措施,并以极为友善且易于接受的方式提出了切实可行的建议。”
——Warren McFarland,哈佛商学院教授

“对于任何一位曾经在组织里面从事过项目工作的人来说,86个项目模式熟悉得令人心惊。幸运的是,其中有一些模式是良性的,应该给予鼓励。然而悲哀的是,剩下的绝大多数模式不仅仅令人心灰意冷,而且它们对生产率、质量和项目团队士气的破坏程度令人瞠目结舌。”
——Ed Yourdon,《死亡之旅》作者

“这本《项目百态》就是关于项目管理的实话集……读这样一本书,你会笑,更多的时候你会摇头苦笑,甚至如芒在背。”
——熊节,ThoughtWorks中国公司首席咨询师

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值