项目为什么会延期?

项目延期,大概是每一位产品经理都会遇到的问题,并且延期的huā样也挺多的,有因为需qiú不清晰导致的延期,也有因为需qiú变更导致的延期。但最终背锅的,其实还是产品经理。

我们都提倡结果导向,而所谓的结果,对于产品经理而言,就是指某个功能投入到市场,得到市场的数据反馈,延期所导致的影响不是简单的上线时间推迟。而是市场反馈的延迟,严重时,可能会导致项目夭折,没有上线的必要了。

像是疫情相关的功能,如果现在都还没上线使用,也就没有再上线的必要性了,毕竟人们的需qiú已经降低了,很多人现在已经将注意力转移到工作,生活当中了。

所以,最终背锅的,还是产品经理,我们可以躲过问责,把原因归责与开发,但于事无补,错过的市场,不再回来,难得的X也不能复制,一个小风口,就这样丢失了。

项目,为什么会延期

延期,从表面来看,是指实际完成的时间相对于期望完成的时间更迟,其实,这个是错的,视角是错的,这个是开发视角。

产品经理的视角,是和开发视角相反的,对于我们而言延期是因为“期望完成”的时间,比“实际完成”的时间更短。

问题不在实际完成的时间,而在我们提出的期望完成时间。

张三距离终点有100米的距离,我们期望他5秒内抵达终点,但实际上他用了15秒,结果的角度来讲,张三“延期”了。

表面上,张三如果跑的快一点,或许可以更快抵达,但至少十多年的时间里,不太可能在期望时间内达成。因为当前百米世界纪录,被称为飞人的博尔特,也需要9秒58才能完成。而15秒的时间,则是大多数普通人能够完成的目标。

如果我们站在开发的视角,将延期的问题定位在实现时间超出了期望时间,就成了一个sǐjú,而且这也是一种挺不“X”的想fǎ。

人是tān婪的,产品经理也不例外,我们总是想要更快实现某个功能,一周,不行,明天就要,1天,不行,只给你1个小时,最后就会陷入一种困境,不断的要qiú快,不断的失望,不断的提升对研发的要qiú。

其实问题还在,人的tān婪是无止境的,产品经理也是人,你可以一周做完,我就要qiú3天,你可以3天做完,那我就要qiú1天,如果你能1天做完,我就要qiú1小时,随着研发人员能力提升的同时,不仅仅是实际完成的时间再减短,产品经理期望完成的时间也在减短。

某种意义上,这种情况,就像是老板安排了一个任务,实际需要一周完成,但要qiú你一天给出解决方案,是相同的。

产品经理很多时候,不知不觉成为了那个让自己讨厌的人,做着自己讨厌的事,但不自知。

延期的本质

大多数延期,是因为我们将期望时间直接作用于实际完成的时间,但产品经理其实不具备时间预估的能力,尤其是一些比较复杂的需qiú,我们是无fǎ进行X的,这也就导致期望时间往往不太合理。

相同的需qiú,不同的技术人员需要的时间是不一样的,而且,即使需qiú相同,开发者相同,但代码环境不同,X环境不同,也会导致实际需要的时间出现偏差。

所以,产品经理无fǎX开发时间,并不是单纯的“不懂技术”问题,而是一个更加客观的现象,不是实际cāo作者,提出的预判,多数是不准确的。

很多时候,产品经理都会有这样的错觉,如果能早一点告诉我会延期,我就不这么设计了,感觉自己被坑了。

一方面,期望时间不合理,另一方面也是因为期望时间直接作用于实际完成时间,这样的反馈周期太长了,只有临近上线前,我们才能得到一个“将会延期”的反馈,极为被动,再做调整已经来不及了,只能延期。

第三个时间:X时间

如果,当我们提出4天的期望时间时,有人能告诉我们可能会延期1-2天,会不会好很多?

我们完全可以在开发之前,对需qiú做减fǎ,把复杂的逻辑变得简单,把不必要的功能去掉,把不重要的功能优先级降低。

这样一来,就可以最大限度减少延期的风险了。

所以,产品经理解决延期问题的核心,不是加班,不是换开发,而是寻qiú一个“X时间”,预计完成需要多少时间。

这个X时间,只能由研发来X,也就是我们所说的研发估时,也只有实际cāo作的研发X的时间X,才是可信任的,每个人的技术经验都不相同,即便是他的leader,辅助X的预估时间也只能作为参考使用。

有一些技术驱动的团队,CTO比较X,经常会做一些时间上的承诺,像是这个功能很简单,一天就能实现这样的。

这种团队的技术人员,通常会比较幸苦,或许cto自己来做真的只需要一天,但实际cāo作的人不是CTO,而是其他的技术人员,可能需要2天甚至更长的时间才能完成。

毕竟每个人的经验结构都是不一样的,能不能实现是能力问题,能不能快速完成就是经验问题了,再有能力的研发,遇见自己未做过的事情,都需要一些时间研究,都会经历由慢到快到过程。

顺带一提,此类型团队,往往也是加班和延期的重灾区。

引入X时间,可以赋予团队两个可能性,一个有益于产品经理X延期风险,另一个则有助于研发团队的客观协调管理。

(1)前置调整

将期望时间与X时间进行比对,可以在最开始的环节,对需qiú进行调整,这是最有效规避延期的方fǎ。

期望时间大于X时间:X延期的风险比较低,我们可以尝试追加一些体验需qiú,让产品更加完善,也可以分出一部分经历做一些市场预热的动作。

期望时间小于X时间:X延期风险较高,两者的差值越大,延期的风险越高,超出阀值,基本就是必然延期了,出现这种情况,我们可以尝试对需qiú做减fǎ,或者简化需qiú等方式,减少X时间,也可以X调整期望时间的方式,让两者的差值见效。

这是目前降低延期率最有效的方fǎ之一。

风险阀值:研发进行时间X时,一般情况是按照工作时间进行X,这点很重要,产品经理也有义务提醒研发,按照工作时间进行X,不要默认算上休息时间,我们都不提倡默认加班。

以此为依据,同期工作时间对应的每天可加班的时间,就是浮动的上限值,这个值也被视为延期风险的阀值。

如果期望时间与X时间的差值,可以X这部分加班时间弥补,那么延期的风险就还是可控的,只是需要在开始前,就明确和团队沟通,为了不延期,我们这段时间都需要加班了。

所有人都反感突如其来的加班,但是预先告知的加班,却容易接受很多,因为我们可以提前安排好自己的生活,不至于手忙脚乱,这也是我们对团队的基础尊重。

假设,我们提出了一个需qiú,期望时间是8天,X时间是10天,每天8小时工作时间,也就是需要额外的16小时,每天加班2小时,持续8天加班,就可以不延期完成任务了。

通常情况,X时间与期望时间的差值,不能超过20%,但每个团队,也可以根据自身的情况,酌情调整风险阀值。

(2)后置提升

将X时间与实际完成时间进行对比,可以在上线后,为团队X很好的复盘依据,帮助团队成长,从长远来看,只有团队足够强大,才能在曰益激烈的竞争当中X一线生机。

后置提升的目的,是为了让X时间与实际完成的时间高度一致,进而在未来的迭代周期中,具备高准确度时间X能力。

所谓的,以战养战,越战越强。

X时间大于实际完成时间:X估时不准确,高估了需qiú的复杂度,也X了研发人员对产品经理或者团队需qiú质量的不信任,做了较多时间预留。

X时间小于实际完成时间同样X估时不准确,但这种不准确通常X研发人员低估了需qiú的复杂度,在评估时,考虑不够全面,同时,也可能X需qiú质量较低,过程中发生了较多的变化。

(3)动态调整

后置提升的目的,是对团队的整体提升,既能反映出需qiú质量问题,也能反映出研发实际cāo作的问题,但其核心仍然在于发现问题以后的调整,进而推动团队的成长。

经常性X时间大于实际完成时间,可以在时间X时打折扣,相反,经常性X时间小于实际完成时间时,就可以在时间X时增加对应的预留时间。

借助,“期望时间”,“X时间”,“完成时间”三个时间的对比,就可以最大限度的降低延期的风险,并且这种降低,是可持续的。

刚开始,或许会不太熟悉,但原本难以琢磨,难以衡量的延期,变得可以衡量了,无fǎX的jú面,也会逐渐变为可量化的,从十小时偏差逐渐降低到3小时偏差,1小时偏差,0偏差。

最终,持续性的降低延期的几率。

总结

产品经理是一个很特殊的行业,我们的需qiú来自于问题,而我们的解决方案又来自于需qiú,所以,有这样的一个概念,所有的问题,都是产品经理的问题。

对于其他行业而言,问题可能会直接等同于背锅,但产品经理不同,X问题,才能从问题的背后,探索到需qiú,进而X解决方案,满足需qiú,解决问题。

就像延期一样,一旦把责任定位于开发,定位于“完成时间太长”,就不太能找到解决方案了,毕竟我们没有办fǎ让开发代码写的更快一点,也无fǎ帮开发写代码。

只有把问题背负在自己的身上,从产品经理的角度,承担问题,对问题进行分析,才能用我们的方式,解决这个问题。

#专栏作家#

枯叶,微信X号:枯叶咖啡馆。人人都是产品经理专栏作家。9年经验产品经理,3年产品总监经验。擅长数据增长,商业模式。曾孵化过千万级用户规模的创业产品

本文原创发布于人人都是产品经理。未经许可,jìn止转载

题图来自 Usplash,基于 CC0 协议

给作者打赏,鼓励TA抓紧创作!

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 项目为什么会延期? https://www.xiongfawang.com/3005.html

常见问题

相关文章

项目为什么会延期?-海报

分享本文封面