别觉得只有你一个人会遇到这种情况，软件项目里最常见的就是领导突然宣布要把时间线往前赶。比如离产品上线只剩两个月，需求却越来越多；或者是客户非要赶在圣诞节前看到完整版，结果你们连架构都还没定下来。这种进度被挤压的状况在软件开发圈里简直就是家常便饭。 为什么大家总是对时间估算那么乐观？说白了就是赶节点的冲动太重了。交易展示会、税法改了、节日来了……每个截止日期就像火车马上要开走，谁都想挤上去。其实这种压缩往往是多重压力下的产物：管理者喜欢往好处想，有人喜欢挑战带来的刺激，有人为了拿钱或者中标故意把时间缩得更短，甚至还有人觉得紧计划能让效率变高。 但现实是，一旦计划脱离了实际，它非但不能帮项目提速，反而会变成最大的绊脚石。拼命赶工带来的频繁加班和持续紧张状态会让代码质量变差，调试时间变长，最后反而拖慢了整体节奏。研究早就说过了，超过一半的项目延误都是因为一开始估得太短造成的。 当计划成了一张废纸，团队的信任和士气也就散了。真正能让开发变得快的，得是基于现实的进度计划。想要阻止领导瞎指挥，咱们得学会跟领导谈判。 技术人员通常都是谈判新手。我们懂怎么估算时间，却不擅长让别人接受这个数字。《谈判力》里讲的“原则谈判法”是个好方法。核心意思是别想着打败对方，而是要找个共赢的办法。 跟领导谈的时候记住把人和问题分开。面对那个非要你快点的人，先搞清楚：他不是你的敌人，大家的目标都是让项目成功。试着这样说：“我明白咱们得赶在展会前把东西展示出来，我也希望展示的是个稳定的版本。咱们怎么在这中间找个平衡点？” 别老盯着自己的立场不放，多聊聊共同的利益。如果对方说必须在X月X日前完成，你就把话题引到实际好处上去： 比如提高真正的开发速度。解释一下为什么现实一点的计划反而能让大家走得更快。 比如增加成功的概率。拿出数据说话，比如现在估算只有50%的按时完成率，如果再压缩下去就只剩20%了。 再比如讲讲历史教训。指出来以前有个类似的项目就是因为时间太紧最后不仅耽误了工期质量还不行。 作为技术人员你有别人没有的专业知识，可以用创意方案打破僵局。比如把功能分开来做或者先把核心部分搞出来。也可以考虑增加点资源或者减少点不必要的流程。 进度上也可以灵活点。在需求还没定的时候先别定死日期，随着项目推进慢慢细化估算，要是需求变了也得允许重新算一遍。 关键技巧是只说你能做到的事。别说“我们做不到”，而是说“要把所有功能都加上得再给四周时间；如果不要X、Y、Z这几个功能，咱们能在原定时间内把核心功能搞定。” 软件开发里有个挺奇怪的现象：科学的估算结果如果不合领导的意，大家往往就当没看见。这时候你得坚持客观标准：不直接跟估算结果较劲；请专业人士或者第三方来帮忙算；按照科学的步骤来估算。 前期哪怕有点争吵也比后来项目搞砸了强多了。想从根本上解决这个问题，得推动一种文化变革——从“越快越好”变成“稳中求快”。作为开发团队我们可以这么做： 通过以前的项目积累估算信誉；定期跟大家说说进展和遇到的难处；教一教那些非技术人员软件开发到底是咋回事；弄一套客观的估算流程或者引入点工具和第三方评估。