快生活 - 传播价值、传递关注!

项目为什么会延期


  项目延期,大概是每一位产品经理都会遇到的问题,并且延期的花样也挺多的,有因为需求不清晰导致的延期,也有因为需求变更导致的延期。但最终背锅的,其实还是产品经理。
  我们都提倡结果导向,而所谓的结果,对于产品经理而言,就是指某个功能投入到市场,得到市场的数据反馈,延期所导致的影响不是简单的上线时间推迟。而是市场反馈的延迟,严重时,可能会导致项目夭折,没有上线的必要了。
  像是疫情相关的功能,如果现在都还没上线使用,也就没有再上线的必要性了,毕竟人们的需求已经降低了,很多人现在已经将注意力转移到工作,生活当中了。
  所以,最终背锅的,还是产品经理,我们可以躲过问责,把原因归责与开发,但于事无补,错过的市场,不再回来,难得的事件也不能复制,一个小风口,就这样丢失了。
  项目,为什么会延期
  延期,从表面来看,是指实际完成的时间相对于期望完成的时间更迟,其实,这个是错的,视角是错的,这个是开发视角。
  产品经理的视角,是和开发视角相反的,对于我们而言延期是因为"期望完成"的时间,比"实际完成"的时间更短。
  问题不在实际完成的时间,而在我们提出的期望完成时间。
  张三距离终点有100米的距离,我们期望他5秒内抵达终点,但实际上他用了15秒,结果的角度来讲,张三"延期"了。
  表面上,张三如果跑的快一点,或许可以更快抵达,但至少十多年的时间里,不太可能在期望时间内达成。因为当前百米世界纪录,被称为飞人的博尔特,也需要9秒58才能完成。而15秒的时间,则是大多数普通人能够完成的目标。
  如果我们站在开发的视角,将延期的问题定位在实现时间超出了期望时间,就成了一个死局,而且这也是一种挺不"专业"的想法。
  人是贪婪的,产品经理也不例外,我们总是想要更快实现某个功能,一周,不行,明天就要,1天,不行,只给你1个小时,最后就会陷入一种困境,不断的要求快,不断的失望,不断的提升对研发的要求。
  其实问题还在,人的贪婪是无止境的,产品经理也是人,你可以一周做完,我就要求3天,你可以3天做完,那我就要求1天,如果你能1天做完,我就要求1小时,随着研发人员能力提升的同时,不仅仅是实际完成的时间再减短,产品经理期望完成的时间也在减短。
  某种意义上,这种情况,就像是老板安排了一个任务,实际需要一周完成,但要求你一天给出解决方案,是相同的。
  产品经理很多时候,不知不觉成为了那个让自己讨厌的人,做着自己讨厌的事,但不自知。
  延期的本质
  大多数延期,是因为我们将期望时间直接作用于实际完成的时间,但产品经理其实不具备时间预估的能力,尤其是一些比较复杂的需求,我们是无法进行预测的,这也就导致期望时间往往不太合理。
  相同的需求,不同的技术人员需要的时间是不一样的,而且,即使需求相同,开发者相同,但代码环境不同,业务环境不同,也会导致实际需要的时间出现偏差。
  所以,产品经理无法预测开发时间,并不是单纯的"不懂技术"问题,而是一个更加客观的现象,不是实际操作者,提出的预判,多数是不准确的。
  很多时候,产品经理都会有这样的错觉,如果能早一点告诉我会延期,我就不这么设计了,感觉自己被坑了。
  一方面,期望时间不合理,另一方面也是因为期望时间直接作用于实际完成时间,这样的反馈周期太长了,只有临近上线前,我们才能得到一个"将会延期"的反馈,极为被动,再做调整已经来不及了,只能延期。
  第三个时间:预测时间
  如果,当我们提出4天的期望时间时,有人能告诉我们可能会延期1-2天,会不会好很多?
  我们完全可以在开发之前,对需求做减法,把复杂的逻辑变得简单,把不必要的功能去掉,把不重要的功能优先级降低。
  这样一来,就可以最大限度减少延期的风险了。
  所以,产品经理解决延期问题的核心,不是加班,不是换开发,而是寻求一个"预测时间",预计完成需要多少时间。
  这个预测时间,只能由研发来提供,也就是我们所说的研发估时,也只有实际操作的研发提供的时间预测,才是可信任的,每个人的技术经验都不相同,即便是他的leader,辅助提供的预估时间也只能作为参考使用。
  有一些技术驱动的团队,CTO比较强势,经常会做一些时间上的承诺,像是这个功能很简单,一天就能实现这样的。
  这种团队的技术人员,通常会比较幸苦,或许cto自己来做真的只需要一天,但实际操作的人不是CTO,而是其他的技术人员,可能需要2天甚至更长的时间才能完成。
  毕竟每个人的经验结构都是不一样的,能不能实现是能力问题,能不能快速完成就是经验问题了,再有能力的研发,遇见自己未做过的事情,都需要一些时间研究,都会经历由慢到快到过程。
  顺带一提,此类型团队,往往也是加班和延期的重灾区。
  引入预测时间,可以赋予团队两个可能性,一个有益于产品经理控制延期风险,另一个则有助于研发团队的客观协调管理。
  (1)前置调整
  将期望时间与预测时间进行比对,可以在最开始的环节,对需求进行调整,这是最有效规避延期的方法。
  期望时间大于预测时间:代表延期的风险比较低,我们可以尝试追加一些体验需求,让产品更加完善,也可以分出一部分经历做一些市场预热的动作。
  期望时间小于预测时间:代表延期风险较高,两者的差值越大,延期的风险越高,超出阀值,基本就是必然延期了,出现这种情况,我们可以尝试对需求做减法,或者简化需求等方式,减少预测时间,也可以通过调整期望时间的方式,让两者的差值见效。
  这是目前降低延期率最有效的方法之一。
  风险阀值:研发进行时间预测时,一般情况是按照工作时间进行预测,这点很重要,产品经理也有义务提醒研发,按照工作时间进行预测,不要默认算上休息时间,我们都不提倡默认加班。
  以此为依据,同期工作时间对应的每天可加班的时间,就是浮动的上限值,这个值也被视为延期风险的阀值。
  如果期望时间与预测时间的差值,可以通过这部分加班时间弥补,那么延期的风险就还是可控的,只是需要在开始前,就明确和团队沟通,为了不延期,我们这段时间都需要加班了。
  所有人都反感突如其来的加班,但是预先告知的加班,却容易接受很多,因为我们可以提前安排好自己的生活,不至于手忙脚乱,这也是我们对团队的基础尊重。
  假设,我们提出了一个需求,期望时间是8天,预测时间是10天,每天8小时工作时间,也就是需要额外的16小时,每天加班2小时,持续8天加班,就可以不延期完成任务了。
  通常情况,预测时间与期望时间的差值,不能超过20%,但每个团队,也可以根据自身的情况,酌情调整风险阀值。
  (2)后置提升
  将预测时间与实际完成时间进行对比,可以在上线后,为团队提供很好的复盘依据,帮助团队成长,从长远来看,只有团队足够强大,才能在日益激烈的竞争当中抓住一线生机。
  后置提升的目的,是为了让预测时间与实际完成的时间高度一致,进而在未来的迭代周期中,具备高准确度时间预测能力。
  所谓的,以战养战,越战越强。
  预测时间大于实际完成时间:代表估时不准确,高估了需求的复杂度,也代表了研发人员对产品经理或者团队需求质量的不信任,做了较多时间预留。
  预测时间小于实际完成时间同样代表估时不准确,但这种不准确通常代表研发人员低估了需求的复杂度,在评估时,考虑不够全面,同时,也可能代表需求质量较低,过程中发生了较多的变化。
  (3)动态调整
  后置提升的目的,是对团队的整体提升,既能反映出需求质量问题,也能反映出研发实际操作的问题,但其核心仍然在于发现问题以后的调整,进而推动团队的成长。
  经常性预测时间大于实际完成时间,可以在时间预测时打折扣,相反,经常性预测时间小于实际完成时间时,就可以在时间预测时增加对应的预留时间。
  借助,"期望时间","预测时间","完成时间"三个时间的对比,就可以最大限度的降低延期的风险,并且这种降低,是可持续的。
  刚开始,或许会不太熟悉,但原本难以琢磨,难以衡量的延期,变得可以衡量了,无法控制的局面,也会逐渐变为可量化的,从十小时偏差逐渐降低到3小时偏差,1小时偏差,0偏差。
  最终,持续性的降低延期的几率。
  总结
  产品经理是一个很特殊的行业,我们的需求来自于问题,而我们的解决方案又来自于需求,所以,有这样的一个概念,所有的问题,都是产品经理的问题。
  对于其他行业而言,问题可能会直接等同于背锅,但产品经理不同,拥抱问题,才能从问题的背后,探索到需求,进而提供解决方案,满足需求,解决问题。
  就像延期一样,一旦把责任定位于开发,定位于"完成时间太长",就不太能找到解决方案了,毕竟我们没有办法让开发代码写的更快一点,也无法帮开发写代码。
  只有把问题背负在自己的身上,从产品经理的角度,承担问题,对问题进行分析,才能用我们的方式,解决这个问题。
 
建站大全赚钱大全网站目录投稿:又之