关于最后期限和预估工时
首先，需要明确两个概念：
最后期限(deadline)：也称为截止日期，一般来源于业务诉求本身，如在xxx节日之前需要上线xxx功能，为xx活动提供支持；预估工时：由程序员内部评估得到，如xxx功能需要n周才能完成。
通常，程序员应该进行合理的工时预估，而销售/营销负责设定deadline。
那么问题来了：如何让两者之间达到平衡呢？
如何设定预估工时？
我们先来听听冤大头Sam的故事：
张总
Sam，我们这边有新需求，来参加评审？😎
Sam
我们这边暂时没有开发同事，暂时接不了这个需求。🤔
张总
没事，没事，你来听一下，一样的 😁
Sam
好的..
会后，张总突然想起来这个需求很急，于是开始催促Sam推进项目进度…
张总
Sam，我们这个需求什么时候可以上线？
Sam
蛤？我们这边都还没有人手做这个事情...
张总
你给个时间，我按照你的时间来定发版计划
Sam
这块看起来不复杂，不过里面有写细节我也不太了解，一周吧，大概
第二天，小王修完了一个现网临时代码导致的问题之后，Sam来到了小王身边…
Sam
小王，你这个现网问题修复的太及时了，刚好有个紧急需求，你来接一下这个需求，一周后上线
小王
好的经理
一个小时后，小王脸上表情略显复杂
小王
这个需求涉及到xxx，xxx，还需要和xxx合作，最少也要三周...😳
Sam
啊蛤？我都答应业务方下周完成了...
对于开发人员来说，预估工时的关键技巧：
- 让
实际做这些工作的人来预估工时，如果对方硬是要你给个时间，尽量往上报，别坑了队友； - 预估工时的时候，把需求拆解成
一个一个的任务，每个任务最多不超过两天，太大的任务一般意味着不准确的预估工时； - 基于实际耗时统计不断循环反馈给开发人员，以提高他们的预估技能，以得出更准确的工时；
一旦有了准确的预估工时，能够让您有更大的把握在deadline之前完成需求。那么deadline又如何设定呢？
如何设定deadline？
一个团队里面的营销人员一般都背负着业绩压力，所以都希望把deadline尽可能往前提，这有好处也会有副作用哦，后面听我解释。
一些公司则会对岗位做更细的划分，比如运营人员，销售，产品经理等，特别是互联网公司，要是没有把目标对齐，让整个团队统一战线，少不了各种扯皮。
对于营销人员来说，设置deadline的关键技巧：
- 不是迫不得已，不要把deadline设定在预估工时的前面，那样会遭开发人员，测试人员，项目经理唾弃；
- 如果deadline的确要在预估工时之前，唯一的选择：
- 整个团队加班修福报；
- 砍掉一些需求，以减少工作量，达到满足deadline的要求；
- 要是这也不愿意，那也不愿意，那就只能眼睁睁的看着deadline到达了，软件还不能交付；
- 要向团队
解释清楚该deadline的目的是什么，有什么重要的意图（如，上线后能够创造多少位数的营收等），这将是驱动团队前行的关键动力之一。我见过一些比较擅长调动团队积极性的产品经理就很会通过这个去给大家画饼； - 如果设置了一个苛刻的deadline，将会导致开发人员缺乏动力去完成此需求，进而打破团队合作氛围，不利于长期合作发展。
强行上线的副作用
面对紧迫的deadline，开发人员一般会忽略开发最佳实践，转而通过投机取巧去完成任务，从而节省一半以上的编码时间，但最后却增加了数倍的测试和自测联调时间。
我的朋友Tony接到过一个很大的需求，要求5天内提测，眼看着时间远远不够用，于是为了应对提测时间他跟开发同事想出了一些解决方案。
小王
以我多年的在校项目经验，必须要砍掉一些原本做的一些通用设计😮
大表哥
这还必须先写死一些业务规则，以加快编码速度
bug终结者
对于正常业务流程覆盖不到的分支，先直接写个TODO，生产遇到了问题，再完善TODO地方的代码
小李
我还有一招，本地程序调通即可，不做详细的单元测试🤔
码神
这上线后又要不断迭代需求怎么办？我觉得上线后尽量把这块功能交接给别人，避免自己踩到自己挖的坑同样很重要。
老张
要是真的赶不上提测时间，接口先写死直接返回200状态码，哦不，加个随机值，偶尔返回500异常，让测试同时看起来服务不太稳定，好让我们有时间继续优化...😉
arthinking
...
业务方看着版本发版时间，漏出了满意的笑容。软件UI原样交付，只不过别人的产品是人工智能，他的产品是手工智能…
