程序员要勇于说不

程序员要勇于说不: 又一次情绪激动、气氛高度紧张的会议,这一次是商议如何让目前这个重要项目“重回正轨”——计划的完工日期早已超了几个星期。所有的这些场景听起来都很耳熟吗?我想说的是,项目超期在任何行业里都是常见的事情。然而,软件行业里看起来更容易出现这种情况。 我们怎么会走到这种地步的?这还要从我们梦开始的地方说起。所有的开始都是精神抖擞、干劲十足。一个漂亮的创意,这次我们发誓绝不会重蹈上次的覆辙,不会犯上次的错误。这次我们告诉自己,这次的计划将会“正确”的执行,不会图省事,也不会中途变更。经常有时候我们会感觉梦想正朝正确的方向前进,设计很成功,每个人都很乐观,外界评论也很好。然后,噩梦开始降临,因为各种打击开始出现。 系统中最容易的部分却耗用了大家全部的时间。一个微小的疏忽就可能意味着当初一系列简单的假设都不再成立。错误的假设产生连锁效应,导致系统设计陷入死局。需要对设计进行修改来纠正这些问题。希望仍然存在,只要付出足够不眠之夜和周末加班,我们仍然能让项目“重回正轨”。 具有里程碑意义的原型终于诞生了,所有人都充满信心,因为原型表现的非常好。外人不知道这是多少个通宵达旦的努力换来的。很快,“小需求”开始出现。通常的说辞都是从“这有什么难的?”“这真的很简单!”开始,更经典的话是“如果我们能够…那将会太神奇了”。通过交换意见发现,这些新增的小的功能特征不仅看起来“简单”,而且实际可做。当然,你是不会说不的,然而,历史的悲剧即将重演。 现在,你和你的团队终于回到了现实世界,再次查看这些新增需求。在经过了近距离的观察这些看起来“非常简单的功能特征”后,突然意识到它们并不像起初听起来的那样简单。但为时已晚,你已经答应了这些新修改。 “呯!”你的邮箱通知你有了一封新邮件,真是火上浇油,销售已经向客户许诺。销售向客户谈到了这些“简单”的新功能,而客户提出来更多他们想要的“更简单”的新功能。销售照单全收,因为这些新需求听起来比起初那些更简单。 Developers, Just Say
No 程序员们,请勇于说不 停,不能这么干 在80年代和90年代期间有一个非常流行的运动口号:“Just Say No”,是用来宣传让孩子们远离毒品。不管你是否还记得这场运动,它表达的信息是非常有力的。相似的,我们应该使用同样的语气来面对我们遇到的问题。 当然,我并不是在怂恿抵制任何的需求变更。从我的角度,任何需要编码开发的新增内容我都会用红线划分开。但诸如界面或前端内容的修改不包括在内。 任何新增需求在接受前一定要确定相应的充裕的追加时间。内心里对新需求的缺省反应应该是“just say no”。当然,并不需要从表面上暴露这种反应,可以用适当的外交手段达到这种效果。在项目开始之日,任何一个最初没有规划的“需求变更”都要谨慎斟酌。任何后来新增的功能特征都要坚持这个原则。有了这个原则你很容易说出“不”。因为这是一个标尺,所有人都明白,后加的新功能会耗费额外的时间。把这种压力放在客户和老板的身上,要么延缓完工日期,要么放弃另外一个功能做替换。 结论 有各种各样的原因会导致一个软件项目不能按时完工。项目进展缓慢,程序员持续在高强度压力下工作,这使项目开发时间的预估变得更加困难。程序员应该有心理准备,新增需求的情况肯定会出现。把“just say no”记在心里,多少能预防你张嘴就说“行”的习惯。玩枪很危险,给枪加上保险装置,至少能防止伤了自己的脚。 [英文原文: Just Say No ]

Written on April 22, 2013