产品与研发选择合适的开发模式

v2-cc7d12ef9feb36dd074fbe6bb7486547_1200x500

产品与研发永远是合作关系。当项目初创时,产品与研发常亲密无间。这时大家的工作目标是高度一致的,人员配比经常是产品1:设计1:研发2这种水平左右。在项目不断发展中研发队伍的扩张总是最先出现(做不下去的除外),研发也会开始更规范的管理。独立成部门的研发部在管理规范后最先出现的问题是人员配比变大后的规范问题,早期的类似XP开发模式(极限开发)下,因为各种理由所缺乏的

文档成为最明显的产品与研发矛盾点,其次就是过度设计的矛盾。

`产品与更规范的研发部为什么出现更多矛盾?常见的原因有

1.工作目标不再高度一致。部门KPI的差异使研发部门专注技术实现,产品则偏向业务需求、运营设计。同时人员配比的变化(1:2到1:5)对产品的个人能力要求不断提高,需要在更短的时间,更多的业务需求,更难的决策共识完成版本的推进。因此在评审过程中,会经常变为产品设计的批斗会。

2.套用的规范不适合自身。传统的软件开发模式发展的时间长,模式规范。项目初期的不规范行为比如需求细节频繁变更、需求临时新增等在规范管理后变成积怨。所以选择合适自已,大家认同的开发模式并不只是研发部门的事情。否则会经常出现,没有按照研发部门的规范执行变成统一的借口。

3.过度设计。产品面对敏捷开发的平衡点很难把握,特别是在害怕别人评价“这么简单”时。通过满足更强大的功能,更复杂的流程过程中,比正常流程多出成倍数量的异常情况成为需求变更和文档不完善的雷。面对这些坑时,研发部门只会在评审时果断的拒绝。

4.产品能力的瓶颈。人是对环境变化很抗拒的,同时产品的综合能力提升并不容易,大部分产品经理会一直停留在业务需求的搬运工状态下。打破常规的设计只能出现在自已身上,绝大部分不被人轻易接受。

目前的产品与研发合作方式

1.产品需求确认(产品、需求代表)

2.产品PRD文档评审(产品、研发、需求代表),100%机率延期、过度设计

3.版本开发(产品、研发)(需求变更,返回第一步)

4.测试(研发测试组)

5.发布版本(研发)

基于敏捷开发可改进由6个步骤组成

1.版本启动会(周期4-5周),参会人(产品与研发全员、需求代表)

2.功能或验收测试标准确认(测试、产品:流程图、需求代表)

3.产品PRD文档评审(研发、产品)

4.版本开发(需求变更分为验收标准变更、产品PRD变更)

5.测试(测试、产品、需求代表)

6. 发布版本(研发、产品)

一些要避免的常见问题:

1.避免需求变成要求,需求有环境特征、目的、角色、结点、优先级。

2.开发及设计要求可以在验收测试标准内体现,减少由PRD文档过于深入的沟通次数,避免产品与研发将设计风险转移至其它部门。

3.满足最小需求,避免过度设计。

4.模板化UI设计,非核心页面轻量化设计。

5.测试优先编码,与产品同步进行。控制产品PRD文档质量。

6.PRD文档轻量化(流程、信息架构、功能摘要、原型、描述说明),迭代完善。

7.版本迭代中,需求是甲方,产品与研发都是乙方,

Leave a Comment

您的邮箱地址不会被公开。 必填项已用 * 标注