与“Deadline”和平相处,你需要做到这些

全文共3439字,预计学习时长7分钟



Deadline……


对于开发人员人员来讲,Deadline可能是最大的噩梦和敌人。承认吧,这让你很害怕。但其实你知道吗,接受“Deadline”,与之言归于好——这是打败它们的唯一方法。


那么,具体该怎么做呢?


Deadline到来之时,我们往往忽视一些事情。本文的目的就是展示这些事实,最终你会发现消除恐惧并不难,开发人员可以毫无畏惧地享受生活与工作,而不必再担心项目日期。


在安静的环境中工作




不要慌,不要赶。


首先要明白一点,一旦设定不切实际的截至日期并强迫团队匆忙完工,团队将不会安心地工作。有些公司放大话,说一些不切实际的话,激励团队向前进。但是对于团队成员们来讲,有些事实是显而易见的:在实际与你所说的相差甚远时,如何让他们相信你说的是真的呢?


没有一个固定且令人信服的“Deadline”,便不能平静地工作。没错,保持平静是关键所在。如果你不相信日期,如果公司加重工作量却不给你多一些时间,可能你会开始疯狂地工作。这时,工作不再是工作,而是地狱。


人在高压下,是无法高效工作的。只有心情平静,才能有清醒的意识,做出更佳的决定。


糟糕的预期时间



Windows用户应该都会记得对话框窗口。对话框中的预计时间就像我们所说的预计时间,对吗?


承认吧,预计时间真是太糟糕了。我们认为可以预估所需时间的长短,往往认为预估时间与现实情况差不多。


然而,一般来说,我们在预测时往往忽略了一些影响假设结果的重要因素。为何?因为我们所想的太理想化了。


与Deadline和平相处以及更好地设定Deadline的第一步就是承认我们很难预测未来。接受了这个事实后,下次工作中不会轻易低估工作要求。下面的方法可以更好地预测时间:


将一个大任务分解成一个个小任务。目标越小,越容易预估时间。如此一来,便可以得出更加精准的预估时间。


刚刚好才是真的好

 

 完美是优秀的敌人。伏尔泰(Voltaire)


人类喜欢难度大的挑战,最喜欢用复杂的方法解决简单的问题。但是事实却是:每个问题都有其简单的解决方法,只是被忽略了。


不要追求完美的解决方法。第一反应不应该是力求完美,而是可以奏效的半成品。等的时间太长,既会浪费有限的资源,又会浪费珍贵的时间。随后错过Deadline,甚至更糟的是什么都没做成,就是因为追求完美。解决方法是:

 

找到事半功倍的方法。不要忘了,“好”是可以变得“更好”的。


不要太乐观化了,实际点


许多管理者都太乐观了,设定极其乐观的Deadline来激励团队工作。这是不对的,这也不是说要大家消极面对未来。相反,要考虑到所有造成瓶颈的可能性。一旦预见这些,就可以将其纳入考虑范围,得出更加精准的预估。


公司里有许多不同的团队,工程设计、业务拓展、市场营销等。业务拓展团队希望尽快完成工作,于是要求给出最近的Deadline,此时切不可受其影响。记得每个部门都只站在自己的角度思考问题。


区分“必须做到”、“可以做到”、“想要做到”


理解这三者的关系是关键所在。发布产品的核心要求是什么?通常,产品团队很难区分这三句话。


参加会议时,其中一个团队成员会说“我们可以完成这个,这会为我们带来巨大的价值”,另外一个人会说“我们应该将此落实到位”。他们都是站在自己的角度说话。没错,我们可以实现这个并获得一些价值,但是最重要的问题是“如果按照第一个说法,那我们现在需要做这个吗?”


大多数情况下,答案是“不”。

 

应该将重心放在需要做的事情上,消除你可以这样做和你想要这样做的这类事情上,大多数情况下,这一点是毋庸置疑的。


养成说“No”的习惯


我们通常不会记得说“Yes”的事情,而说“No”的事情往往是需要完成的事情。

对新事物说“Yes”时,大家都不会思考此事对所做的事情有什么影响。


 “我们确定好Deadline后,此项目还需再加一点任务。(项目应该随着时间更加精简,而不是复杂)”No。


 “我们关注重要的事情,但是,可以能说得再详细一点吗?想想怎么样的细节可能在将来造成困扰。”No,首先应该忽视每个细节,不要尝试预测未来。


为事情争取更多的时间不是问题,太多的工作量才是问题所在。区分“必须做”和“愿意做”。


争取完成更多任务唯一的方法是更少的工作量。


不要更改Deadline

 

开发团队常常有个可能严重影响产品开发的不良习惯:重新安排Deadline。他们一旦错过了截止日期,就会设定一个新的截止日期。如果不能按此完成,便设定另一个。以此反复,就成了一个习惯。随后,这个习惯转变为一种文化。公司其它团队就会对这个开发团队失去信心并质疑他们的工作。更遭的是,开发团队自身也会彼此猜疑,甚至对自己产生怀疑。

 

更改Deadline本质上就是一种失败。就像是在说“我们没有做好计划要求,我们不会说No,我们不知道什么更重要,我们促使团队以不合理的时间完成不切实际的任务。”


保持危机意识


太乐观会导致人们忽视事情总会有些问题这个事实。请注意这一点。可能某些环节会出问题。不仅如此,这还会导致你浪费一些时间来弥补过失。因此最好做好坏的打算。这不是说应该消极地预测未来或是让自己和团队为未知的事情做准备。只是说要把握好乐观和悲观之间的平衡。现实一点!


根据以往经验,软件开发总会有些错误。我们给出的建议是:

 

为设定的Deadline留出更多的时间,以供错误弥补。


一个项目不要加太多人参加


许多人认为项目中人加得越多速度越快,但是,他们忽视了十分重要的一点。记住布鲁克斯定律(Brooks’s law):

 

增加人力资源于软件项目后期会导致任务时间更长。

弗里德·布鲁克斯(Freed Brooks)


依据维基百科中对于布鲁克斯(Brooks)的说法,越多人加入项目,事情反而越多,而不会缩短工作完成时间。所以,为什么要这样做呢?


· 刚加入项目的新成员要经过一段时间熟悉才能提高效率。首先,要对他们进行培训,此时,人力资源已经有限,还要抽调出一部分人力去培训新成员。不仅如此,由于是新成员,他们可能会制造更多的bug,离任务完成的日期更遥远。


· 人越多,沟通就越困难。


· 让更多的人参加如打扫宾馆房间这样的高度可分任务,确实会缩短整体任务时间。但是,有些其他的项目,如许多专业技术人员参加的软件项目,则是不易分割的。布鲁克斯所描述的另外一个例子也是这样:让一个女性九个月生一个孩子可以,但是“九个女性却很难在一个月生一个孩子”。


 “让更多人加入一个项目是错误的”这个说法可以通过理查德·道尔顿(Richard Dalton)的解释来理解:


团队是不变的。一旦有人离开或加入,就会形成新的团队,而不是改变原有团队。理查德·道尔顿.(Richard Dalton)


不要拖延


通过下面的例子解释这句话的意思。比如,我们通过开会来确定产品新性能完成的截止日期。会上我们讨论了哪些任务需要优先完成以及如何高效实施这些任务。


有一个任务已经耗费了很长时间。明明有三种方法可以完成这个任务,但是却卡在这了。由于开发人员尝试预测未来,反倒不知道如何选择。总是在思考“假如……会怎么样”。


你不能预测将来会带给你什么。不要对未知的事情做过多的准备。


这句话的适用范围不包含重大技术决策。当然,如果是核心解释决策,可以仔细考虑一晚上找出正确的解决方法。但是在小事上,不必太多时间。不确定的事情越多,会议就越多,同时,由于一直花时间来确定这些事情从而阻碍工作进程。


不要拖延,决定了就赶紧推进。


将思想从“让我再想想”转变为“现在下决定”。决定会加快工作进程,一旦事情决定好了,团队成员就可以目标明确清晰,知道自己要做什么。


沟通:找出瓶颈之处


计划好所有的事情,决定好应该把重心放在何处以及应该做什么。你也许就可以知道任务完成的时间(这样想可能就错了)。因此,确定好截止日期,如此就足够了吗?


当然不是!


如上述,总要出错的可能性。团队成员工作时,总会有阻碍工作进展的事情发生,使他们不能按时完成任务。此时,必须找到瓶颈在哪以及瓶颈是什么。


此时,沟通是关键环节。必须让整个团队保持一致性。有时,团队里各成员可能会被某个盒子套住,很难知道盒子外到底发生了什么。这就是你应该探究的地方。一旦知道了瓶颈是什么并消除瓶颈,你的团队将会跨过困境,继续向前。

留言 点赞 关注

我们一起分享AI学习与发展的干货

欢迎关注全平台AI垂类自媒体 “读芯术”


打开APP阅读更多精彩内容