? ? ? ? 我们团队一直执行敏捷项目管理方式，模式运转还算顺畅。不过过程改进，持续优化之路任重道远…
? ? ? ? 今天这篇，是借我们团队的一次例行过程改进活动的开展，向大家分享过程改进在团队的执行方式。
? ? ? ? 如下是我们改进现?。?/p>
【背景】：针对“迭代开始前产品向团队讲解需求的过程”。前期收集大家在执行过程遇到的痛点、问题和建议。
第一，过程改进建议搜集及改进草案如下：
一、我们现在产品经理（及交互总监）推开发需求过程存在如下问题：
1、推需求时间点模棱两可，没有形成节奏感。
2、推送的需求没有提前将技术可行性等问题解决好，以致在会上还要讨论技术可行性。
3、产品推开发讲解需求时候，存在部分需求描述过于简单，没有按照规范描述细至需要考虑的点。配套的PRD等未及时录入项目管理工具。
4、推动需求的量上面三个产品经理+交互总监没有提前沟通好。包括优先级。
5、开发总监没有腾出时间及时在约定的下个迭代前将需求过完一遍且将任务分配到具体开发人员，或指定的开发人员与实际真正执行人员有不一致（会造成新加的开发人员第一次没注意听到该需求应该注意的点）。
6、开发人员没有提前看或者当堂讲解时候没有认真听，提不出问题，听了如同没听，真正开发还要再讲解，耽误时间。
7、产品经理讲解时没有充分准备到细致的点，讲的比较肤浅，甚至敷衍、走过场。
8、开发人员理解的与产品人员陈述的一致性，无法考证，如果开发人员不提问，很难消除歧义。
9、【非】推入的需求，讲解完毕，中途变更（新增内容、删减内容、修改内容、取消不做），存在相关人员不能及时获知信息的情况。
二、准备&准入标准：
1、需求准入标准。产品经理需求录入项目管理工具前已经完成必要PRD、原型，与王洋沟通技术实现可行性，需要UIUE地方已与交互总监沟通完毕。简言之：要达到推过来的需求开发人员听明白了就可以拿去做才可以（反面案例：讲需求时才发现技术不可实现，开发要开始做了才发现UIUE还没配套做好）。
2、产品经理录入需求。产品经理在迭代开始前将需求按照要素录入项目管理工具，配套必要PRD，原型等，标注优先级。原则：推送的需求量满足开发总工作量120%。超过的20%作为开发选做，产品录入时候标记优先级为低。
3、开发总监评估工作量?？⒆芗嗾攵圆仿既氲墓ぷ髁拷谐醪狡拦馈Ｆ拦赖悖盒枨蟮奶辶吭谑奔湎淠诔浞只故遣蛔?，人员分配上是否有搭配不合理的，线下对接产品沟通协调。
4、任务分配。开发总监逐条需求分配至具体的开发人员。
三、需求讲解步骤（新迭代开始前完成）：
1、所有开发人员提前熟悉需求。
2、产品经理（及交互总监）给开发、测试讲解。
（1）、拉会，产品经理（及交互总监）给自己需求对应的开发人员逐条讲解需求。有问题当场澄清。
（2）、开发总监，测试经理及测试人员参加，其他人员视情况参加。有歧义当面协商一致。
3、开发人员反讲。
（1）、开发人员逐条讲解自己对该条需求的理解和实现思路。
（2）、产品经理（及产品总监）、开发总监、测试经理把关。
（3）有歧义当面协商一致。
三、注意：
1、讲解点要细到开发实现。反向案例：产品澄清需求只是将需求读一遍，开发反讲也读一遍?；岷缶咛遄龅礁眯枨笫?，又要耽搁很久去在需求内容理解上进行重新互相确认。
2、时间建议。最好拉一个澄清会全体参加。
3、发生变更，及时在群里@all 并作说明，必要时产经理品拉会组织对应开发、测试人员进行讲解和反讲。
第二，如上改进草案发送各口相关人后，收获反馈如下：
第三，整理汇总，方案如下，组会评审。
最终形成改进方案如下。
第四，全员通知落实。信息同步，深度解释。确保全员理解一致。
第五，跟踪监督落实，收集效果反馈。解决新流程发布给大家带来的问题。确保顺畅贯彻下去。
