码迷,mamicode.com
首页 > 其他好文 > 详细

关于产品交付

时间:2018-12-20 00:06:20      阅读:201      评论:0      收藏:0      [点我收藏+]

标签:需求   问题   技术   原因   注意   架构设计   升级   架构   设计   

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

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

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

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

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

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

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

关于产品交付

标签:需求   问题   技术   原因   注意   架构设计   升级   架构   设计   

原文地址:https://www.cnblogs.com/music-heaven/p/10146896.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!