程序员要勇于说不

又一次情绪激动、气氛高度紧张的会议,这一次是商议如何让目前这个重要项目“重回正轨”——计划的完工日期早已超了几个星期。所有的这些场景听起来都很耳熟吗?我想说的是,项目超期在任何行业里都是常见的事情。然而,软件行业里看起来更容易出现这种情况。

我们怎么会走到这种地步的?这还要从我们梦开始的地方说起。所有的开始都是精神抖擞、干劲十足。一个漂亮的创意,这次我们发誓绝不会重蹈上次的覆辙,不会犯上次的错误。这次我们告诉自己,这次的计划将会“正确”的执行,不会图省事,也不会中途变更。经常有时候我们会感觉梦想正朝正确的方向前进,设计很成功,每个人都很乐观,外界评论也很好。然后,噩梦开始降临,因为各种打击开始出现。

系统中最容易的部分却耗用了大家全部的时间。一个微小的疏忽就可能意味着当初一系列简单的假设都不再成立。错误的假设产生连锁效应,导致系统设计陷入死局。需要对设计进行修改来纠正这些问题。希望仍然存在,只要付出足够不眠之夜和周末加班,我们仍然能让项目“重回正轨”

具有里程碑意义的原型终于诞生了,所有人都充满信心,因为原型表现的非常好。外人不知道这是多少个通宵达旦的努力换来的。很快,“小需求”开始出现。通常的说辞都是从“这有什么难的?”“这真的很简单!”开始,更经典的话是“如果我们能够…那将会太神奇了”。通过交换意见发现,这些新增的小的功能特征不仅看起来“简单”,而且实际可做。当然,你是不会说不的,然而,历史的悲剧即将重演。

现在,你和你的团队终于回到了现实世界,再次查看这些新增需求。在经过了近距离的观察这些看起来“非常简单的功能特征”后,突然意识到它们并不像起初听起来的那样简单。但为时已晚,你已经答应了这些新修改。

“呯!”你的邮箱通知你有了一封新邮件,真是火上浇油,销售已经向客户许诺。销售向客户谈到了这些“简单”的新功能,而客户提出来更多他们想要的“更简单”的新功能。销售照单全收,因为这些新需求听起来比起初那些更简单。

Developers, Just Say No

程序员们,请勇于说不

停,不能这么干

在80年代和90年代期间有一个非常流行的运动口号: “Just Say No”,是用来宣传让孩子们远离毒品。不管你是否还记得这场运动,它表达的信息是非常有力的。相似的,我们应该使用同样的语气来面对我们遇到的问题。

当然,我并不是在怂恿抵制任何的需求变更。从我的角度,任何需要编码开发的新增内容我都会用红线划分开。但诸如界面或前端内容的修改不包括在内。

任何新增需求在接受前一定要确定相应的充裕的追加时间。内心里对新需求的缺省反应应该是“just say no”。当然,并不需要从表面上暴露这种反应,可以用适当的外交手段达到这种效果。在项目开始之日,任何一个最初没有规划的“需求变更”都要谨慎斟酌。任何后来新增的功能特征都要坚持这个原则。有了这个原则你很容易说出“不”。因为这是一个标尺,所有人都明白,后加的新功能会耗费额外的时间。把这种压力放在客户和老板的身上,要么延缓完工日期,要么放弃另外一个功能做替换。

结论

有各种各样的原因会导致一个软件项目不能按时完工。项目进展缓慢,程序员持续在高强度压力下工作,这使项目开发时间的预估变得更加困难。程序员应该有心理准备,新增需求的情况肯定会出现。把“just say no”记在心里,多少能预防你张嘴就说“行”的习惯。玩枪很危险,给枪加上保险装置,至少能防止伤了自己的脚。

[英文原文:Just Say No ]
分享这篇文章:

11 Responses to 程序员要勇于说不

  1. 程序小兵 says:

    不~~~~~~~~~~~~~~~~~~~~~~~~不

  2. David says:

    不!先生

  3. Adam says:

    要加新功能,可以,不过,需要重新评估时间。

  4. ppretender says:

    如何能说服老大你的工作量比他说的大呢?

  5. Anti says:

    “No, sir !”. “You r fired !!”.

    • 寻觅 says:

      我宁愿被fire也不要在这种高强度的公司里工作。就算拿了再高的工资也不一定能弥补身体健康的损伤,而且还不一定加班就有高工资拿。我们也要勇敢的fire掉老板啊

  6. just says:

    “no” “but why”

  7. just says:

    “no”
    “but why”
    “…”

  8. 罗志雄 对这篇文章的反应是赞一个俺的神呀

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据