提交需求
赛事与广告咨询合作,请填写需求表单,我们会在第一时间与您联系!
推荐理由:适合人群:资深产品经理。
阅读耗时:字数2628,约7.5分钟。产品经理在敏捷开发中,占据着重要位置,其中参与引导和开发评估非常重要。本文提供部分方法论,很值得借鉴。欢迎想引入此套方法论的你,和我沟通,我们共同策划更好的方案。
一、产品经理在开发评估会议中的定位
在评估会议上,开发团队会对本期需求制定实现方案,并会根据方案的难易程度评估具体每个开发活动的开发时间。
因为评估会议代表整个开发工作的起点,只要评估得准确,那么后续按照计划执行即可,能够减少很多风险。
二、会议前
1. 对本期需求拆解详细的WBS
需要通过一种结构化的方式全局呈现需求,这种方式就是WBS,也可以理解为详细的功能列表。
给产品经理自己看的功能列表会相对简单一些,只需写出大致的功能架构,为后续的原型设计提供指引。
而给开发看的WBS则需要遵循MECE原则,将各功能分解地很详细,并且需要把重要的规则补充完整,这样有助于开发进行评估。
这是由于两者的形式决定的,WBS相比PRD直接和结构化。PRD文档包含了很多内容,产品经理自己写都需要花很久,开发同样需要花很长时间阅读。其次文档形式不便于直观地看出各功能的层级结构,难以形成前后联系。
2. 提前安排开发负责人制定初步开发方案
会议是决策,而不是讨论。
开发评估会也是同样的道理,当面对较复杂的设计方案时,作为引导者,要避免开发在会上就某个需求的实现方案进行讨论。
一个切实可行的做法是在会前,同相关负责人直接沟通,请他们提供一个或多个初步方案,再拿到会上由全体开发进行决策。
3. 促使信息对齐
主要目标是解决成员间信息不对称的问题。这里我提供一个经过实践验证的、确保大家信息对齐的方案,可以用到各种会议中去,也可以根据实际情况进行调整:
将所有资料和解释说明通过小D打包发给相关团队成员,并督促未查看的成员查看;
在会议前1天,要求各成员针对会议资料必须给出反馈意见,并收集留档;
提前解答大家共同反馈的疑问;
在会议开始前,准备纸质版资料,最少要能保证3人共用一份;
若会议前临时有人员变动,或前期准备时间不充足,可在会前加入静默阅读的方式。
三、会议中
在开发评估会议中,主要包括三个环节:①确定开发方案;②分解开发活动;③评估活动时间。
1. 引导开发正确分解开发活动
分解是产品经理必备的一种思维,上到业务目标,下到产品功能都需要分解成可执行的最小单位,开发评估工作亦是如此。
要想解决这一问题,要从思想上转换:功能是设计方案可分解的最小单位,而开发方案的最小单位是一个个的接口。
此时要引导开发继续分解到接口层面:
对设计方案做整体介绍;
带领开发对WBS中的每个功能/功能组梳理逻辑;
引导开发利用MECE原则列出所用后端接口;
讨论接口细节;
确定前后端开发活动(任务)。
2. 引导开发准确评估活动时间
这样做会出现两个问题:
评估人员和实际开发人员不一致,可能造成实际工时的偏差。开发负责人是基于自己的经验去评估的,没有考虑实际开发人员的情况。
这里我提供一个高效率进行群体决策的工具——估算扑克,产品经理可以用其引导开发准确评估时间。
1)什么是估算扑克
估算扑克是一种迅速而精准地进行评估和规划的工具。
和普通扑克牌一样,也是由54张牌组成,两张大小王分别用中英文描述了使用规则,剩下52张牌分为4组,可供4人使用,每人13张,由11张数列牌、1张“?”牌和1张“咖啡”牌组成。
“?”代表无法准确评估,“咖啡”牌代表要休息了。
数列牌可以是自然数排列(0-10),也可以是修正后的斐波纳契数列,其中0代表非常简单,不需要精力就能完成。
2)数列的含义
扑克上的数字可以代表“工时”,也可以代表“故事点”。
代表工时很好理解,即估计每个开发活动需要花费的小时数,是目前使用范围最广的方式。
评估前需要定义一个单位工作量——故事点,实际中,可根据团队情况选取数列表示的含义,也可并行估算。
3)估算工时步骤
分牌:为每名参与估算的成员分一组牌;
讲解:产品经理为大家讲解需求并答疑;
估算:仅与该活动有关的开发成员估算工时,如针对“交卷”接口,由全部后端评估工时。
待每个成员选好牌后同时展示出来,估算过程不可互相商讨;
若大家的估算结果相近,取平均值;
4)估算故事点步骤
由于故事点指的是工作总量,单独对任意一个前后端任务评估都不完整,且不好统一定义单位故事点。
因此基于故事点估算的步骤会与工时估算稍有不同,主要提现在评估对象不同和确定单位故事点。
(1)关于评估对象
故事点代表了一个最小的、完整的功能所需的所有工作量,一个交卷接口不算完整。
一个涉及到前后端的交卷功能才算完整。
所以故事点的评估对象是一个完整的功能,同时在评估时还要考虑影响该工作量的所有因素,包括开发、联调、风险点等。
(2)关于确定单位故事点
如果是刚刚建立的新团队,在进行估算前,还需要寻找一个标的,建议团队选取一个简单的功能闭环代表1个单位故事点,并要达成共识。
按故事点估算步骤可分为:
确定单位故事点;
分牌;
讲解;
多次估算:仅与该功能有关的开发成员进行估算;
记录估算结果。
5)并行估算
根据前面的介绍,不难看出故事点估算侧重于对整体的评估,关注结果,而工时估算侧重于对细节的评估,关注过程,两种估算方式互为补充。
3. 开发活动分配和筛选
接下来就是由开发负责人将这些任务合理地分配给各成员,成员也可以主动认领,产品经理无需干涉这一过程。
如果按工时估算,一般会给每个成员分配的活动时间占总工时的80%,剩下的时间留作应急。
4. 会议通用
1)把控会议进度
控制会议整体时间:一次会议最好不要超过90分钟,若需求过多,可拆分为多次会议;
控制会议各环节时间:拆解开发活动时可能会遇到无法达成一致的情况,要及时引导大家转入下一个议题;
控制讨论内容:开会时很容易讨论着讨论着就跑偏了,需要及时制止这种情况并把话题带回来。
2)做好会议记录
安排人员记录会议过程中的确认事项、待办事项,并整理产出文档。
四、会议后
1. 跟踪遗留问题
如果记录了一些待办事项,会后要组织相关人员进行落实,做到事事有结果。
2. 跟进开发过程
如果团队中没有项目经理,那么项目跟进的工作就需要由产品经理负责。
通过前面的评估会,我们可以得到已经确认的开发活动、开发时间和开发人员,接下来就需要把这些内容做成可视化的图表,便于跟踪和查看,目前常用的有甘特图和项目看板。
读后感
往往评估时间的确定非常重要,通常都是由客户的需求决定的,遇到最多的情况是不懂的人来评估时间,懂的人往往给自己的余量特别多。本文中提到的平均法值得借鉴。如果你试的好,记得告诉我。
Powered by Froala Editor
大牛,别默默的看了,快登录帮我点评一下吧!:)
登录 立即注册