白癜风治疗要花多少钱 https://m.39.net/pf/a_4630319.html编辑导语：作为产品经理遇到的问题可谓是各式各样的，日常需要处理的问题也很繁多，本篇文章作者针对产品经理日常遇到的问题进行案例分析，讲述了产品经理应如何正确参与并引导开发评估的内容，一起来学习一下吧。作为产品经理，你是否遇到过以下问题：开发出来的功能和设计的规则不一致；看起来很简单的功能开发评估需要好几天；负责的项目经常延期；不知道开发进展。如果出现以上问题，80%是因为开发评估工作没有做好。这篇文章将会结合笔者的实际案例，详细讲解如何解决上述问题。注：本文讨论的内容基于特定的情况下，即团队中没有专职的项目经理/敏捷教练，需要产品经理兼任，即“保姆式产品经理”，同时产品经理的设计方案已通过评审。一、产品经理在开发评估会议中的定位在中小企业，特别是以敏捷开发为主的团队中，产品经理往往需要承担一部分项目管理的职责。其中最重要的要属需求评审后的开发评估工作了（若需求较简单，可与评审会共同进行）。在评估会议上，开发团队会对本期需求制定实现方案，并会根据方案的难易程度评估具体每个开发活动的开发时间。因为评估会议代表整个开发工作的起点，只要评估得准确，那么后续按照计划执行即可，能够减少很多风险。可是现实情况却不尽人意，常常会遇到：开发对功能规则理解有偏差；需求遗漏或需求蔓延；评估的工时和实际所用的工时差距过大。并且这类问题往往在开发后期才会暴露出来，轻则导致改动方案，费时费力；重则导致项目延期，影响整体目标。千万不要认为开发评估会是开发的主场，作为产品经理，需要对产品的结果负责，对于任何环节可能造成的风险都需要提前规避。因此，在评估会上，产品经理不仅要做一个“倾听者”（了解技术实现方案）和“支持者”（对于开发不明确的地方提供必要的说明），更要做一个“引导者”。虽不参与实际的开发决策，但需要在关键节点通过正确地引导保证评估过程的准确性。这种积极的做法有以下好处：降低项目开发风险；建立与开发的信任；从技术视角看待产品，了解开发知识；锻炼领导力。下文将会从会议前（准备）、会议中（引导）、会议后（监控）详细拆解每个步骤。二、会议前1.对本期需求拆解详细的WBS尽管经过需求评审会，团队成员已经对设计方案达成了共识，但仍不能保证每个人都记住和理解。因此在开发评估会前，还需要通过一种结构化的方式全局呈现需求，这种方式就是WBS（工作分解结构），也可以理解为详细的功能列表。对于产品经理，功能列表肯定不会陌生，在需求之后原型之前，我们就会通过功能列表梳理产品结构。但此处的功能列表则需要拆解的越详细越好，因为它是给开发看的，便于他们对要做之事有一个整体的了解。同时又可以避免需求遗漏、蔓延和理解不一致的情况出现。如同去菜市场买菜，相比于提前列出购买清单，如果是到了菜市场才决定买什么，那大概率会多买或少买。这里我用曾经做过的在线答题功能举例：可以看到，给产品经理自己看的功能列表会相对简单一些，只需写出大致的功能架构，为后续的原型设计提供指引。而给开发看的WBS则需要遵循MECE原则，将各功能分解地很详细，并且需要把重要的规则补充完整，这样有助于开发进行评估。比如对于“切换题目”功能，如果不写出“切换时需要自动保存答案”这一规则，前端人员仅看功能列表时就会忘记调用保存接口。这里可能你会有不解：PRD也有详细的功能规则，为什么不用，而是要重新做一个WBS？这是由于两者的形式决定的，WBS相比PRD最大的优势就是“直接”和“结构化”。从下图可以看到，PRD文档包含了很多内容，产品经理自己写都需要花很久，开发同样需要花很长时间阅读（现实中更多的情况是开发不看文档，遇到问题了再问）。其次文档形式不便于直观地看出各功能的层级结构，难以形成前后联系。而WBS是将PRD中最重要的“功能需求”拿出来，并细化到最小功能点，做到了需求不遗漏，方便开发做后续的活动拆分（下文会说明）。同时产品的架构、各功能之间的联系和关键规则都在一张表里展示出来，大大提高了阅读效率。2.提前安排开发负责人制定初步开发方案会议是决策，而不是讨论。我们回想一下开需求评审会的场景，经常有开发对我们的设计方案提出质疑。如果恰好是你没考虑清楚，那么你会选择跟他深入讨论，还是会说“这个问题问得好，我记下来了，会后我再好好想想然后答复你，我们先看下一项？”我相信大家都会选择后面的方式，因为在会上讨论，不仅浪费他人的时间，而且讨论出的结果往往都是没有经过深思熟虑的。开发评估会也是同样的道理，当面对较复杂的设计方案时，作为“引导者”，要避免开发在会上就某个需求的实现方案进行讨论。一个切实可行的做法是在会前，同相关负责人直接沟通，请他们提供一个或多个初步方案，再拿到会上由全体开发进行决策。例如我在设计阅卷规则时，不仅可按考生、试卷、题目分配，还可按试卷和考生、题目和考生综合分配。同时试卷类型还包括选题组卷、抽题组卷和随机组卷，题目中还包含复合题，这都增加了开发在设计阅卷模型时的难度，可能还会改动已有的题库——试卷模型。显然，这么复杂的方案不适合在会上讨论，于是我先后跟前后端负责人约了几次会议，形成了一个初步的方案。这样做不仅保证了实现方案的完备性（作为负责人，经验和眼界都会高一些），同时减少了沟通成本（沟通渠道=N（N-1）/2，N指参与沟通者的人数）。接下来再开评估会议，有了开发负责人的背书，就会顺利很多。3.促使信息对齐经过前面的两步，你已经为评估会做好了资源上的准备，接下来你可能会把WBS、PRD、设计图、开发负责人提供的初步方案打包发给团队成员。然后信心满满的准备开会。可是事与愿违，在会上你会发现，由于每个人所站的角度不同、高度不同，仍然有部分成员因为理解不一致而进行无效讨论。因此在这个步骤里，主要目标是解决成员间信息不对称的问题。这里我提供一个经过实践验证的、确保大家信息对齐的方案，可以用到各种会议中去，也可以根据实际情况进行调整：将所有资料和解释说明通过钉钉打包发给相关团队成员，并督促未查看的成员查看；在会议前1天，要求各成员针对会议资料必须给出反馈意见（无意见也要写明），并收集留档；提前解答大家共同反馈的疑问；在会议开始前，准备纸质版资料，最少要能保证3人共用一份；若会议前临时有人员变动，或前期准备时间不充足，可在会前加入静默阅读的方式。需要注意的是，心理学上有一个常见的现象——基本归因错误，即当我们对一个结果做因果分析时，往往会将原因归咎于倾向性因素（人格或态度等内在特质），而忽略外部环境的影响。但其实环境才是影响人们行为的最重要的因素。例如，如果你面对“仍然有部分开发成员因为不清楚需求而进行无效讨论”的情况，是不是第一反应是这个开发不认真、不主动。但不妨换个角度想想，其实是目前的一种工作流程造成了他还不清楚需求。人是制度的产物，改变人不如改变制度和流程，所以以上我提供的方法都是基于改变流程这一维度。想更深入的了解这一心理现象，可查看我的另一篇文章《指责他人是愚蠢之举》。三、会议中经过了会议前三步的准备，团队成员对需求范围、设计方案以及初步开发方案都有了较深入的理解，接下来就进入到了正式开会环节。前文说了开发评估会议是开发团队对本期需求制定实现方案，并根据方案的难易程度评估每个开发活动的具体时间。后续开发过程是否顺利，是否能够按时按量完成，都会受会议中产出的结果影响，因此重要性不言而喻。在开发评估会议中，主要包括三个环节：当需求较简单或开发方案没有争议时，可以跳过①环节，所以下文基于开发方案已确定的情况，主要对②③两个环节进行展开。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张），取平均值；若差异较大，需要让估算最大和最小的成员分别阐述自己的理由，大家沟通后重新进行估算。记录估算结果注：一个完整的开发过程还涉及前后端联调，可以拆成单独的活动再由前后端成员共同评估。同时由于工时评估
转载请注明：http://www.aierlanlan.com/rzgz/6769.html
