项目总结:需求变更和开发周期问题,如何协调?

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

xiangmuzognjiexietiao

上周我们团队的一款产品可以说是在历经困难之后发布了V1.0版本。版本上线之后,我们进行了一次review,希望发现问题,总结教训,避免下次再踩坑。

出现的问题

通过梳理,我们发现问题集中出现体现在:

  • 在上线之前还有需求变更。
  • 开发周期估计不足,出现前松后紧的情况。

问题分析

为什么上线之前需求还在变更?

1、异常流程考虑不足

这次负责项目的是一个年轻的产品经理,因为经验欠缺确实存在原型和文档的撰写不够细致和完整,颗粒度不够细。最重要的就是对异常流程考虑不充分,缺乏对异常流程场景的详细描述。开发同学不得不在开发进程中经常停下来询问产品经理,产品经理这时才去考虑异常流程,此前的需求便可能因此不得不进行调整和更改。虽然调整的幅度不大,但是对开发过程的流畅性和效率却造成了一定的影响。

2、需求收集没有找对人

这款产品是一款TO B的产品,为集团内部员工提供的效率提升工具。我们在需求收集中重点收集的对象是集团中上层管理者,一线实际使用者的真正需求被忽视了。虽然大方向没有偏差,但在一些使用细节上却和一线员工的实际场景不一致。这些情况在开发过程中被逐渐暴露出来,也导致了需求变更的频繁。

为什么开发周期估计不足,前松后紧?

1、需求评估是单一和断裂的

在需求评审中,部分开发人员只关心自己这一块业务,没有全面了解整体需求情况。不了解整个项目的完整逻辑和流程。这样的结果是我们对开发难度和工作量的评估出现了偏差,前期比较乐观,随着开发的深入才发现有的节点比较复杂,不得不加班加点开发。

2、对外包把控的失败

前期我们是准备让外包主要负责项目的开发,我们自有人员只投入1.5人力。实际过程中,外包方更多的是考虑尽快完成项目,而没有去考虑项目的整个流程和扩展性,采取的一些开发方法虽然可以完成整个项目的开发,但是会对我们后续开发和维护带来更大的问题。同时沟通的效率无法保证,因此我们最终只好自己投入开发,前期外包写的内容基本被重构,前期的开发周期相当于浪费了。

如何改进

1、产品经理文档要更细致,不能只考虑正常流程,也要考虑异常流程。每个功能不仅要考虑顺利的情况,还要考虑各种异常分支,并进行相应的提示说明或跳转等操作。

2、需求收集必须针对实际使用者。谁是真正的使用者,我们必须了解他们的工作、生活和学习的相关场景。不仅仅要了解管理层对于宏观业务的需求,也需要实地了解一线使用者的个体(或群体)要求。

3、需求评审所有开发人员都要参加。每个人不仅要了解自己所负责的开发模块,也要对整个项目的逻辑和模块都了解清楚。这样开发周期的评估才是全面和立体的,提高整体开发效率。

4、外包的正确打开方式,自主开发人员确定开发方法和规则,外包人员按照规定开发代码并提交我们验收。

反思还在继续:

这是我们团队第一次和传统实体行业合作,过程确实存在诸多困难甚至是痛苦。我们以往坚持的MVP原则似乎在传统行业面前碰了壁。我们计划先切入A功能,以后再逐步迭代到完善版本。可是线下工作人员这一块却更倾向直接用一个完整的全功能版本,对于不完善的版本他们兴趣很低。一个MVP的版本虽然可能部分解决了某些问题,但是短期内他们却可能因此在两个系统内工作,对于他们的效率可能短期内反而是降低的。

#专栏作家#

肥寒,微信公众号:chanpingdog,人人都是产品经理专栏作家。九年产品经理。做过数字阅读,电商,社区,目前致力于在线教育。

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

您的赞赏,是对我创作的最大鼓励。

评论( 0

登录后参与评论
加载中