软件开发中的deadline的一些问题及解决方案

 
　　日常谈话中有多少次你在谈到deadline（期限）时，曾至少有一个人对这个概念嗤之以鼻？我已经听过太多次了，甚至连我自己也这么干过，不过现在我想改正这一习惯。
　　软件领域较之于传统的印刷媒体（print media）有很大的不同，而deadline的概念就是从传统的印刷媒体中得来。然而，不能仅因为目前在软件领域尚无通用的deadline概念，就以为该摒弃这个概念，或以为它没有价值。
　　就工作的规划和并行处理来说，deadline是极其重要的。如果没有预计的完工期限，所有团队都必须连轴工作，同时也会大大减少交付次数。而且如果不明白deadline的真正含义，那么deadline可能会让人感到沮丧，甚至产生相反的效果。
　　问题及解决方案
　　以下是根据我的经验总结出来的，在工程公司中与deadline最为相关的问题，以及最有可能解决问题的办法。
　　1）对deadline的理解因人而异
　　A：“下周才是deadline，我还有大把的闲余时间！”
　　B：“为什么要担心这个？没关系的，deadline什么的当不得真。”
　　A：“但我不想被炒鱿鱼啊！”
　　这组对话就很形象地展示了对同一个deadline，A和B两人在理解上有着巨大的差异，这也会导致整个团队在努力实现deadline时出现困惑与挫败感。
　　事实上，deadline必须要有号召力，每个人都得知道deadline重要的原因，他们必须明白错过deadline会对整个圈子有什么样的影响，包括对其他团队的、对客户的或者对公司整体的影响。
　　更重要的是，那些达成的deadline需要热烈的庆祝，而这一点常被忽视掉。比起责备那些错过deadline的员工，建立起为达成deadline庆祝的企业文化才是上上之策。
　　2）在项目的生命周期中过早设定deadline
　　A：“嘿，我们得完成这项工作【插入一个真的非常难的未知项目】，什么时候能干完？”
　　B：【快速搜了一下到底是什么工作】“额，我不确定。”
　　A：“我需要一个确切的deadline。”
　　B：“三，呃四个……月嗯周……月吧，四个月！”
　　A：“好极了，到时候见。”
　　向一个各方面都属于未知状态的项目要求一个deadline简直后患无穷，也让项目涉及到的员工压力很大，为项目立起了失败flag。所以，先深呼吸，耐心等两天，让大家完成探索工作。虽然搜集信息花费了时间，但之后我们却能给出有意义的评估，这些信息会帮助我们设定更加准确的deadline。
　　3）deadline更新频度不够
　　A：“这个项目要在5天内完成，目前进度ok吗？”
　　B：“有一点落后，不过不要紧，我们会按期完工的。”
　　A：“好极了！”
　　【4天23小时后】
　　A：“再检查一下项目，准备好发布了吗？”
　　B：“额，还没，出了点问题，目测还得一个礼拜。”
　　A：“$%@！*”
　　在这个案例中，在新问题出现时，开发人员并未调整或重新评估deadline，B没能立即提出问题，而是等到deadline才告知他人，于是A也受此牵连，而整个团队也会因为要赶工另一个deadline而倍感压力。
　　设定deadline不应当是为了强迫员工超额负荷，把人当牲口用，而应用以设定外部对项目的预期，让计划呈现可预期性。Deadline必须尽可能准确地反映现实情况，否则一旦出现信任危机，这个概念也就失去了传递可预期性的功能。当然，我不提倡每小时或每天更新deadline的行为，但也许每周更新，或至少按标准计划的节奏来更新是个不错的主意。
　　更新deadline并不拘于延长时间，也可以缩短周期。至于具体怎么做，又或者兼而有之，都得工程师和产品团队商榷后确定。
　　4）未将所有“已知工作”都纳入考虑范围，仅考虑到了有趣的那些
　　A：“这个功能多久能交付？”
　　B：“两周。”
　　【两周后】
　　A：“怎么没完工？”
　　B：“额，技术上来说已经完工，我们现在在测试，要给它新建一个部署机制，会先发布一个beta版。另外上周我休假了。”
　　在设定这个deadline时，相关人员对要完成的工作以及要投入的时间缺乏完整的理解，更别提该案例中B也出现了上面第三条的问题。
　　在设定deadline时，我们应当确保将所有已知的挑战都涵盖在内，是否会因某个已知原因而浪费一些时间，比如说度假、公司断网、因为生日派对宿醉而迟到？
　　另外我们是否可能遗忘了某些不起眼的任务？这个项目打算写多少测试？如何将这玩意儿发布到生产环境中？跟着这些问题放慢脚步，仔细思考下整个过程以及可用的资源。这样做会让设定deadline简单得多，同时这样设定出的deadline也更经得起考验。
　　关于评估：令人不适，但却是必要的
　　工程师所设定的deadline很大程度上是通过评估形成的，也就是说团队中的每个人都要习惯犯错，犯很多错——将自己知道不对或是没信息的地方说出来，可能会很困难。
　　我们必须达成共识，尽可能准确地作出评估，并随着时间评估地越来越准确。评估是一项技能，反复使用会熟能生巧。初期可能会让人不适，但这是我们需要做到的。
　　评估任务
　　在定下大型项目的交付时间前，我们应当将整个项目拆分成小的任务，每个任务应当能在约五个工作日内完成。
　　以下问题对评估任务十分有用：
　　这个项目是新建的，还是之前就有的？这部分代码质量如何？我对这部分代码的熟悉程度如何？对涉及的编程语言熟悉程度如何？与其他代码段在哪里有接触或集成点？现有的测试覆盖率如何？这项工作是否涉及关键业务（写入路径、计费、负载均衡器、注册）？之前是否有人参与过这项工作？他们有何想法？有哪些问题需要做出权衡？这项任务的目标是什么？这项任务究竟是否需要完成？
　　评估工程项目
　　工程项目通常被视为一个较大的任务，可以让多人并行完成。
　　下面这些问题有助于评估项目：
　　我们实际要在这个项目上花费多久时间？这个工程项目的目标是什么？是否有已知会安排的休息时间？所有要完成的任务有哪些？是否对其他团队有依赖，还是障碍性的？项目中是否有任务对其它任务产生障碍？该项目是否需要新的基础设施或硬件？该项目的完工标准是什么？
　　完工标准
　　即便要知道某项工作是否完工都是很困难的，团队中不同角色可能会有不同的“完工”标准，因此我们需要指定某个项目的具体完工标准。
　　下面是典型完工标准的一些样例：
　　部署到生产环境；全自动化测试；与公司内部或第三方人员沟通；在公司内部或外部进行了一定量的测试；为生产环境编制文档；完成对销售或推广团队的讲解；发布登录页面；分析并追踪；操作运行手册与系统可观测性。
　　总结
　　随着公司的壮大与管理能力日趋成熟，交付能力成为必须，而deadline是其中主要的工具之一，合理善用将有无与伦比的功效。不过，想要利用deadline，还需时日在实践中慢慢磨合。因此我建议：工程类公司应当将其视为一个活生生、有生命力的东西，不间断地去学习了解，并通过文档在全公司内部，乃至与整个行业分享经验