“你连起码的按时上线都做不到,我凭什么信任你?”

今天我们聊一聊，项目按时交付，一些开发同学不是很重视项目的按时交付，觉得早一天或晚一天交付，差别并不大，所以经常听到开发同学发牢骚：

业务的需求真的有这么着急吗？非要在25号上线？28号再上吧，联调问题会比较多，25号上线有风险！

这时候，项目经理是崩溃的：

早干嘛去了？明天就要上线了，你现在才跟我说上不了？业务有自已的运营推广计划，26号预热，30号广告投放，没有幸运大转盘功能，拿什么去做活动。。。

开发同学这才意识到延误上线后果很严重，老板很生气，于是跟测试同学熬通宵，赶在原定的时间上线，毕竟不能让广告费都打水漂吧，至少这个水漂不是被开发打的。

许多企业里，业务方对技术同学是不信任的，其中很大一部分原因就是经常被放鸽子，说好明天上线的，今天被通知要延误到下周，中间过程也缺乏沟通。

按时交付是技术与业务之间建立信任的纽带，你连起码的按时上线都做不到，我凭什么信任你？这恐怕是业务方最真实的内心写照了。

管理大师德鲁克说过，管理的本质就是建立信任。对业务方而言，信任，靠一次次按时交付累积起来，又因为一次次延期交付，消耗殆尽。

▲长按图片保存可分享至朋友圈

那么，究竟项目不能按时上线的原因是什么？又应该如何避免延误？

01 对需求理解不透彻

产品和开发对需求理解不透彻，是导致项目延期的主要原因之一，业务方和产品是从用户视角思考问题，而开发是从技术视角，经常会出现鸡同鸭讲的情况，到测试环节才发现大家对需求理解上的不一致，造成了项目延期。

解决需求理解不透彻的问题并不难，关键人物是产品，产品理解好业务需求，并将业务需求翻译成开发听懂的人话。对于经验不是那么丰富的产品同学，可以尝试下面的需求沟5步法：

1、倾听业务方的需求，不厌其烦的问，不放过每一个细节；

2、根据业务方的描述，将需求以原型文档的形式整理出来，在整理过程中及时跟业务方确认疑问点；

3、将原型讲解给开发人员，确保业务方的需求是在技术上可实现的，同时听取开发的意见和反馈，调整原型；

4、将调整后的原型跟业务方讲解，以便业务方理解原型和所做的更改；

5、让开发人员对原型进行讲解，确保研发人员对需求的理解和业务方的需求保持一致。

产品经理在沟通需求时，需要做到：让鸡讲得清楚，鸭听得明白，消除沟通障碍。

02 对实现难度预估不足，工作量预估有偏差

这个问题主要出现在开发环节，尤其是缺乏经验的开发同学，往往无法正确识别出技术实现的难度，工作量预估的时候就会出现比较大的偏差。

规避的办法很简单，每一个开发小组，安排一名相对比较资深的开发同学把关，帮助经验不足的同学识别出技术难点，多花一些时间做技术预研，提醒开发同学把联调时间，修BUG的时间都估进去。

许多敏捷开发团队，常常会先让开发同学预估一个乐观工时，在这个基础上乘以1.5~2的系数，得出最终的计划工时，大家不妨借鉴一下。

03 需求变更频繁，甚至迭代内仍有需求变更

产品的职责之一，就是管理好需求，并非业务方说什么就照做什么，如果只是充当传声筒，没有自已的思考，迟早是要被机器淘汰。

同时，业务方是需要被教化的，频繁变更需求导致的后果是，产品、开发、测试之前所有的工作都白做，轻则浪费公司资源，重则导致公司机会成本增加，错失了业务拓展的最佳时机，相信这样的结果是大家不想看到的。

所以，宁可在需求沟通阶段多花时间，帮助业务方想深想透，避免在开发过程中反复修改。

关于项目的按时交付，你有什么想说的？留言告诉我。

高效领导者都关注[技术领导力]，你也来吧！

---

精彩文章推荐：