关于产品交付

Posted music-heaven

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于产品交付相关的知识,希望对你有一定的参考价值。

  在《构建之法》中,提到了一个案例,大意是程序员小飞在实现功能模块的过程中,发现原来的设计中的“弱点”,如果调整,将会影响交期;如果不调整,小飞可以按时交付,但会影响该模块被集成的效率,影响后续及整个工程效率。该怎么办?

  这是个非常典型的案例,仅今年下半年类似问题在我们团队里处理了至少2次,一次与硬件相关,一次与软件服务相关。这2次我们的处理方式均是一样:按时交付、随后立即优化。必须明确的是,我们这样做,不代表这样是对的、是普适性的,而是这2次我们所面临的客观原因,使得我们必须这样去做。

  我个人理解这个问题,是一个产品交付问题。产品交付,都有一个计划时间及一个deadline。若计划时间提前于deadline,例子里的小飞大概率是要作调整的;若计划时间大于deadline,不调整,增加的是产品成本,调整,市场里可能没有这个产品什么事儿(我们今年就是在某区域市场里,临时被通知必须在截止时间前完成交付,否则下次再来该区域就是一年后了)。以上,基本是职场人员的共识。

  更进一步,为什么在实际产品实现过程中,会遇到需要在中途作较大调整的情况。就我遇到的主要有2点:1、对同一需求,理解不到位+沟通不到位;2、对细节的忽视。

  理解不到位,包括PM对客户原始需求理解不到位,也包括技术负责人对需求规格理解的不到位。需要做较大调整的,很多时候是对整个业务逻辑的理解存在偏差。导致一开始从架构设计到流程设计都走偏了。所以,针对这种情况,后来我在做初期的市场调研时,至少会带技术负责人一起跑一次,让他对市场的原始需求有一定程度的了解,这样在后期对大量的需求进行讨论时,有一个基本的背景认知。事实证明,后来我在与其他程序员在沟通同样的业务需求时,往往需要花费更多的时间去让他们理解业务场景。

  对“细节”的忽视,这里我将细节打了一个引号。确实,对于一般的细节,会让我们多加加班,不至于说引起较大的调整。但就怕是一个你没注意到的大问题,被误以为是个细节问题。我们产品终端在一次升级过程中,除了功能的变动外,还将键鼠操作改为键鼠+触屏。当时大家都把精力放在功能的实现上了,忽视了触屏操作的优化,都误认为键鼠都用了这么多版本了,这次只是换了个带触屏的PC机。结果投入到市场,客户对触屏操作的兴趣远大于键鼠(这里面也有我们键鼠操作),但毫不例外的反馈触屏操作的优化是个必须解决问题。后来我们针对触屏操作的习惯,对整个界面及交互进行重新设计。最后证明,我们自己都回不到键鼠操作的版本了。

  先就我所见、所感写到这里,继续埋坑~

以上是关于关于产品交付的主要内容,如果未能解决你的问题,请参考以下文章

应用交付为什么会受到用户青睐

方便产品、开发、测试三方协同管理、测试、监控项目进度和质量,以持续交付。

实践手册:业务引领的DevOps持续交付研发体系

“5步”做好研发效能度量,打造DevOps研发管理闭环

持续交付优化之路产品剖析

持续集成 vs. 持续交付 vs. 持续部署