接上篇
三、会议中
经过了会议前三步的准备，团队成员对需求范围、设计方案以及初步开发方案都有了较深入的理解，接下来就进入到了正式开会环节。
前文说了开发评估会议是开发团队对本期需求制定实现方案，并根据方案的难易程度评估每个开发活动的具体时间。后续开发过程是否顺利，是否能够按时按量完成，都会受会议中产出的结果影响，因此重要性不言而喻。
在开发评估会议中，主要包括三个环节：①确定开发方案；②分解开发活动；③评估活动时间。当需求较简单或开发方案没有争议时，可以跳过①环节，所以下文基于开发方案已确定的情况，主要对②③两个环节进行展开。
1、引导开发正确分解开发活动
“分解”是产品经理必备的一种思维，上到业务目标，下到产品功能都需要分解成可执行的最小单位，开发评估工作亦是如此。
倘若你的团队没有这种“分解”意识，直接根据功能或页面进行评估，比如“下发试卷”功能：“需求是时间到后把试卷发给每一个考生，看起来比较简单，就估1人/天吧”，但实际在开发的时候才会发现，之前没有考虑下发随机组卷这种类型的试卷，也没有考虑上万人同时发卷的并发问题，导致按照之前评估的时间完不成，进而导致延期。
要想解决这一问题，要从思想上转换：功能是设计方案可分解的最小单位，而开发方案的最小单位是一个个的接口。因此在评估前要做一件事：建立设计方案和开发方案之间的联系，这就需要在前面的步骤中我们已经做好的WBS。
还是拿“在线答题”功能举例：
虽然WBS已经把功能分解并按层级罗列了出来，但从开发的角度看还比较笼统，不能直接用于评估。此时要引导开发继续分解到接口层面：
对设计方案做整体介绍带领开发对WBS中的每个功能/功能组梳理逻辑引导开发利用MECE原则列出所用后端接口讨论接口细节确定前后端开发活动（任务）如果前期的准备工作做的充分，这个过程会进行得很顺利，因为大家有共同的认知，容易达成一致意见。允许对细节方案短暂讨论，比如对于倒计时提醒，可以采用后端提供服务器时间，前端定时校准并计算倒计时，也可以直接由后端计算。但是涉及到模型建立、表结构设计、技术选型这类方案的讨论，还是需要在会前决定好。
2、引导开发准确评估活动时间
分解好开发活动后，接下来就要对每个开发活动估算时间。大家可以回顾一下在自己的项目中开发人员是怎么做评估的，我见过很多团队，基本上都是采用开发负责人拍脑袋的方式进行估算。这样做会出现两个问题：
仅靠个别人员评估，可能造成评估不全面。例如试卷已生成，此时再改题库中的题目是不会影响试卷的，因此往试卷中添加题目时，需要存入题目的副本，对于这种细节单靠个别人员评估很容易遗忘评估人员和实际开发人员不一致，可能造成实际工时的偏差。开发负责人是基于自己的经验去评估的，没有考虑实际开发人员的情况。因此要想准确评估开发活动的时间，全体参与是必须的。但全体参与又会带来另外两个问题：
因为每个人的经验不同、理解不同，如何就活动时间达成一致？如何避免“从众效应”，导致估时不准？这里我提供一个高效率进行群体决策的工具——估算扑克，产品经理可以用其引导开发准确评估时间。
（1）什么是估算扑克
估算扑克是一种迅速而精准地进行评估和规划的工具。
和普通扑克牌一样，也是由54张牌组成，两张大小王分别用中英文描述了使用规则，剩下52张牌分为4组，可供4人使用，每人13张，由11张数列牌、1张“？”牌和1张“咖啡”牌组成。“？”代表无法准确评估，“咖啡”牌代表要休息了。数列牌可以是自然数排列（0-10），也可以是修正后的斐波纳契数列（如上图），其中0代表非常简单，不需要精力就能完成。
（2）数列的含义
扑克上的数字可以代表“工时”，也可以代表“故事点”（敏捷开发）。
代表工时很好理解，即估计每个开发活动需要花费的小时数（允许组合，如1+1/2=1.5h），是目前使用范围最广的方式。
但这样做会有一个问题：每个人做一项任务所花费的时间都是根据自身情况决定的，比如挖一个10m³的坑，你需要用1小时，而一个小学生需要用8小时，所以要如何评估挖10m³的坑所用的时间才合理呢？如果估1小时，显然对小学生来说不可能完成，如果估8小时，对你来说就是浪费时间。
我们无法让能力不同的人，就同一份工作的耗时达成一致，但可以做到对工作量大小的估算保持一致。什么意思呢，不管谁来做这个工作，它的工作量、复杂度、风险都在那里，不增不减，因此可以转而评估工作总量。评估前需要定义一个单位工作量——故事点，比如我们事先定义挖1m³的坑为1个故事点，那么对于10m³的坑就是10个故事点，
实际中，可根据团队情况选取数列表示的含义，也可并行估算。
（3）估算工时步骤
分牌：为每名参与估算的成员分一组牌（13张）讲解：产品经理为大家讲解需求并答疑（若在上一步骤中已经详细讲解，本步骤可以省去）估算：仅与该活动有关的开发成员估算工时，如针对“交卷”接口，由全部后端评估工时。待每个成员选好牌后同时展示出来，估算过程不可互相商讨若大家的估算结果相近（相差的数值牌不超过2张），取平均值若差异较大，需要让估算最大和最小的成员分别阐述自己的理由，大家沟通后重新进行估算记录估算结果注：一个完整的开发过程还涉及前后端联调，可以拆成单独的活动再由前后端成员共同评估。同时由于工时评估关注细节——各活动已是分解的最小结果，工时不会太久，建议使用0-10的数列进行评估。
（4）估算故事点步骤
由于故事点指的是工作总量，单独对任意一个前后端任务评估都不完整，且不好统一定义单位故事点，因此基于故事点估算的步骤会与工时估算稍有不同，主要体现在评估对象不同和确定单位故事点。
关于评估对象故事点代表了一个最小的、完整的功能所需的所有工作量，一个交卷接口不算完整，一个涉及到前后端的交卷功能才算完整（这不代表前面的分解活动没有用，恰恰是因为分解，才使得估算更准确），所以故事点的评估对象是一个完整的功能（用户故事），同时在评估时还要考虑影响该工作量的所有因素，包括开发、联调、风险点等。
关于确定单位故事点如果是刚刚建立的新团队，在进行估算前，还需要寻找一个标的，建议团队选取一个简单的功能闭环代表1个单位故事点，并要达成共识。例如把交卷功能作为1个故事点，在估算“保存”功能时，若开发认为“保存”功能的开发任务量、复杂度、风险和不确定性预计是“交卷”功能的3倍，那么“保存”功能就应该为3个故事点。另外在以后的每次估算中，最好使用同样的单位故事点，这样有助于评估和提升整个团队的生产能力。
按故事点估算步骤可分为：
确定单位故事点分牌讲解多次估算：仅与该功能有关的开发成员进行估算，如针对“交卷”功能，由前后端成员共同评估，并对故事的点数达成一致记录估算结果将所有功能评估完后，就可以得出总的故事点数，新团队在第一个开发周期可以先不用考虑完成率，尽量做，在周期结束后统计做完了多少个故事点即可，再通过两三个周期的调整和适应，我们就可以较准确地评估出团队整体的生产力和个人的生产力，为后续改进提供依据。
（5）并行估算
根据前面的介绍，不难看出故事点估算侧重于对整体的评估，关注结果，而工时估算侧重于对细节的评估，关注过程，两种估算方式互为补充，可以同时进行：
确定单位故事点分牌讲解针对功能（故事）估算故事点数针对具体开发活动估算工时记录估算结果3、开发活动分配和筛选
到了这一步，我们已经拿到了每个开发活动/功能较准确的评估，接下来就是由开发负责人将这些任务合理地分配给各成员，成员也可以主动认领，产品经理无需干涉这一过程。
如果按工时估算，一般会给每个成员分配的活动时间占总工时的80%（每人每周安排32小时），剩下的时间留作应急。
如果采用的是故事点估算，会参考前几次已完成的总故事点数。
不管是采用哪种估算方式，都可能会遇到所排需求超出团队周期内的最大工作量，此时就需要产品经理根据需求的优先级和关联性判断哪些需求可以移入下一个周期。
4、会议通用
（1）把控会议进度
控制会议整体时间：一次会议最好不要超过90分钟，若需求过多，可拆分为多次会议控制会议各环节时间：拆解开发活动时可能会遇到无法达成一致的情况，要及时引导大家转入下一个议题，会后相关人员再对未决议问题展开讨论，避免浪费所有人时间控制讨论内容：开会时很容易讨论着讨论着就跑偏了，需要及时制止这种情况并把话题带回来（2）做好会议记录
安排人员记录会议过程中的确认事项、待办事项，并整理产出文档。
四、会议后
1、跟踪遗留问题
如果记录了一些待办事项，会后要组织相关人员进行落实，做到事事有结果。
2、跟进开发过程
如果团队中没有项目经理，那么项目跟进的工作就需要由产品经理负责。
通过前面的评估会，我们可以得到已经确认的开发活动、开发时间和开发人员，接下来就需要把这些内容做成可视化的图表，便于跟踪和查看，目前常用的有甘特图和项目看板。
甘特图适用于：
基于工时的估算方式瀑布式开发模式无固定开发周期需求较多且不容易变更看板适用于：
基于故事点的估算方式敏捷型开发模式有固定开发周期需求多变在项目进行过程中，产品经理需要每天检查并更新活动进度，这样可以及时发现偏离情况：
尽管经过细致的分解和科学的评估，仍然不能保证活动评估时间与实际完全一致，这里面包含内部原因（遇到技术难题、评估时忽略了细节等）和外部原因（疫情隔离等），如果会导致进度延期，产品经理需要根据实际情况做出应对并及时上报若需要临时增加需求，则按照前面的步骤再走一遍，评估出新需求的时间。如果新需求不复杂，那么可以跟开发负责人沟通，加在剩余时间内；如果新需求比较复杂且优先级较高，则需要考虑替换掉原来的某些任务（当然现实情况是都得要，那么就只能加班了）3、过程复盘
在整个过程中需要和团队及时总结经验和教训，并形成切实可行的改进计划。这里请注意，还记得上文提到的“基本归因错误”吗？复盘是针对出现问题的流程/制度，而不是针对某人。
