万字干货手把手教你做需求管理

　　通过这篇文章，总结自己在工作实践中需求管理的方法论——普拉姆方法。总结这个方法论的特点是，用最轻量化的投入，与他人协作，并管理需求，推动需求上线。这套方法论组合了项目管理、敏捷开发的知识，希望能对大家有所帮助。本文适合0-2岁产品经理阅读，产品大牛、敏捷管理大师请绕过。
　　本文大纲如下：
　　1. 为什么要做需求管理？
　　1.1 我们的工作是否像救火
　　1.2 需求管理是什么？
　　1.3 宗旨是什么？
　　1.4 结尾
　　2. 需求管理中的干系人和角色
　　2.1 什么是干系人
　　2.2 需求管理中的角色
　　2.3 如何识别干系人和角色
　　3. 需求管理的三个模式与公交模型
　　3.1 破解＂越快越好＂的局面
　　3.2 急诊室的场景
　　3.3 让需求管理运转——公交模型
　　3.4 总结
　　4. 急诊模式在需求收集中的应用
　　4.1 再谈需求人和负责人
　　4.2 急诊模式的应用流程
　　4.3 关于时间的把控
　　4.4 结语
　　5. 收集需求的模板
　　5.1 应用场景
　　5.2 模板样式
　　5.3 结语
　　6. 需求池的核心：优先级和重要性
　　6.1 什么是需求池？
　　6.2 优先级——需求的分类和排序
　　6.3 重要性——优先级的辅助
　　6.4 统一的看优先级和重要性
　　6.5 结语
　　7. 排期站会——需求收集的最后一站
　　7.1 为什么要站着开会
　　7.2 排期站会的一般流程
　　7.3 排期站会的道具
　　7.4 结语
　　8. 登机模式与需求设计
　　8.1 何为登机模式
　　8.2 产品文档要用共享文档
　　8.3 结语
　　9. Trello的使用技巧——看板模式与需求研发
　　9.1 鸡肋的邮件
　　9.2 看板与需求卡片
　　9.3 Trello的使用技巧
　　9.4 结语
　　10. 需求管理的证伪
　　10.1 遭遇危机
　　10.2 优化需求管理流程
　　10.3 优化需求池
　　10.4 普拉姆理论的缺陷
　　1. 为什么要做需求管理？
　　1.1 我们的工作是否像救火
　　总是做迫在眉睫的事情，会令人丧失目标。——《普拉姆原则》
　　我在工作中体会到每天忙东忙西的处理需求，虽然每天都很充实，但确实极为耗费精力，时间长久就会缺乏动力。
　　上面讲的是个人的角度，如果一个组织或者团队面对大量的需求，在处理需求的时候，没有节奏和规划，会产生消极的影响。从小的方面看会影响团队士气，往大的方面看，会影响组织实现既定的目标。
　　我的工作环境是，作为后台产品经理，处在业务运营团队和技术团队之间，要作为一个桥梁，保障业务运营团队从我这里输出高质量的需求，也要保障具有不同知识背景团队，能过通过需求，高效沟通，快速推进需求上线。
　　于是，我就通过工作实践，形成了自己的管理需求方法论——普拉姆方法。
　　存在即有标识。——《普拉姆原则》
　　为了便于总结和归纳，我给这个方法论起了个名字。在需求管理中，需求的名称也是很重要的因素，之后会提到。
　　1.2 需求管理是什么？
　　我的定义是，通过协作，管理需求内容和进程，实现成功发布。
　　便于理解这个概念，在这里讲一个海湾战争的故事。
　　在海湾战争中，美军在前期并没有派出大规模的地面部队进行战术打击。而是，派出一批批的特种部队渗透到敌人境内，侦查清楚敌人重要的军事目标，并将精准坐标和信息，传递给后方。顷刻之间，海洋上的战舰派出飞机和战斧导弹对其进行精准轰炸，并取得战术和战略上的胜利。
　　在这个例子中，特种部队是业务运营团队，飞机和战斧导弹是技术团队。产品经理通过需求管理的方法论，用高效和轻量化的方式，去精准的做出需求，实现预期的效果。
　　1.3 宗旨是什么？
　　普拉姆方法的宗旨是积极主动，知识共享，相互尊重。
　　什么是宗旨？可以理解为这套方法论的价值观。这套方法论的每一个细节，都应该遵循这个宗旨来实践，并遵循这个宗旨发展和进化。
　　＂积极主动，知识共享，相互尊重＂的宗旨，是我借鉴了美国西南航空的价值观。美国西南航空是美国航空业受到911事件巨大打击的背景下，依然能够盈利的廉价航空。在航空业极为复杂的管理模式下，使用廉价航空的经营方式实现盈利，还是令人十分震撼的。所以，阅读了相关书籍之后，将美国西南航空的价值观的精华，吸纳为普拉姆方法的宗旨。
　　（1）积极主动
　　积极主动是核心，具体指团体之间的成员积极主动的承担责任去做事情。
　　在《高效能人士的七个习惯》中，积极主动也被列为很重要的素质。在管理每个需求的过程中，每个人都要有担当或者忽略角色的做事情。这也是敏捷开发中推崇的。一个产品经理在不同的需求中，可能既是梳理需求、输出原型的角色，又可能是测试的角色。但是，团队中每个工作的角色在变，通过管理需求达成的目标不会变。
　　请明确讲清需求的目标！我会像战士，即使身陷重围，也会向胜利的方向战斗！——《普拉姆原则》
　　（2）知识共享
　　知识共享，是指分享不同团队的领域知识，减少沟通的未知区域，减少沟通中的误解。
　　有一个Johari窗格的沟通理论，专门提到沟通分为四个区域，即开放区、盲目区、隐秘区、未知区。通过扩大开放区，来提升沟通的效率和效果。
　　同时，＂公则生明＂，即将信息公开透明，可以增加协作团队之间的信任。比如，公开展示各需求的进度。
　　讲个题外的故事，俞永福对产品经理说过，产品经理要有树靶子的意识。自己的需求就是靶子。公司内部的任何人都可以打靶子。每个产品经理有责任，维护好自己的靶子，不被打漏。所以，产品经理自己要让自己的需求健壮，不被打漏。
　　从另外的角度看，尽早的把问题暴露，可以最大的降低解决问题的成本，防止问题积累成一个＂惊喜＂。
　　（3）相互尊重
　　相互尊重，是指尊重每一个人的人格、劳动及输出成果。
　　在管理需求的过程中，要与不同岗位的人打交道。每个人站在不同的立场，必然会有看待问题的不同角度。所以，大家在合作的过程中，要相互尊重。内在的思想是人格上的尊重，外在的表现是尊重别人的劳动成果。不要站在自己的立场和知识背景，去简单评判别人的劳动。
　　对他人劳动的尊重，就是对他人的尊重。
　　1.4 结尾
　　这是文章的的开篇，湿货很多。可能都是大家知道的常识。不过，常识并不常用。把常识内化为行动之中，可以让事半功倍，至少不会犯错。
　　2. 需求管理中的干系人和角色
　　识别出需求的干系人，是需求管理中非常重要的起点。之后的需求管理活动要与干系人及角色，进行紧密的合作。
　　2.1 什么是干系人
　　干系人，是来自于项目管理中的概念。
　　项目干系人是能影响项目决策、活动或结果的个人、群体或组织，以及会受或自认为会受项目决策、活动或结果影响的个人、群体或组织。他们也可能对项目及其可交付成果施加影响。干系人可能来自组织内部的不同层级，具有不同级别的职权；也可能来自项目执行组织的外部。——《项目管理知识体系指南(PMBOK指南)(第5版)》
　　总结的简单点，干系人是与需求相关的人或者组织。
　　而且干系人在需求管理中起到很重要的作用。特别是在做跟业务流程密切结合的需求时，找到并找对干系人极为重要。在需求中的每个人，都会从自己的立场出发提需求，可能会不经意间破坏别的业务线的流程，所以这个时候就需要产品经理从全局的角度去思考需求，或者找到那个能从全局思考的干系人去帮助找到需求中的障碍。
　　有人就会有角色，每个角色必然有不同的关注点，被忽略的关注点都变成了坑。——《普拉姆原则》
　　这里再扩展一点，就是需求可能存在二律背反的情况。也就是说，提一个优化改善的需求，可能会损害其他流程或角色的利益。有时，产品经理要找到需求的受害者，从而更全面的了解需求。
　　不害人的需求，不是完整的需求。——《普拉姆原则》
　　所以，找到和找对需求的干系人，对于需求管理非常重要。
　　2.2 需求管理中的角色
　　在《西游记》中，六小龄童扮演的角色多达16个，最知名的就是孙悟空，还有道士、和尚之类的角色。而唐僧的角色，就有三位演员扮演过。同理，在需求管理中，干系人是一个个的演员，而演员可以担任多个角色。
　　以下是我在从事后端系统的工作中遇到的角色：
　　（1）需求人
　　顾名思义，真正提出需求并描述需求细节的角色。这个角色可以是任何干系人，毕竟产品经理是一个负责从四面八方收集需求的人。需求人一般要与其所在的部门联系在一起，有助于判断所提需求的立场。
　　（2）负责人
　　负责人也来自于业务部门。收集需求人的需求，从业务角度对需求进行梳理和判断，并转发给产品经理和研发同事。当业务团队远大于技术和产品团队时，负责人的角色就非常重要。如果业务团队的人数小于等于技术团队时，可以省去这个角色。
　　负责人，就像一个漏斗和筛子一样，初步筛选一遍需求。毕竟，评估需求也是要花费时间，特别是占用研发同事的时间。
　　（3）产品经理
　　需求管理的组织者、推动者。以＂积极主动＂的态度，与需求管理的角色进行沟通。
　　（4）研发经理
　　研发资源的管理者。在这里的研发经理，一般是带四、五个人小团队的级别。因为，他们能够了解每个研发工程师的工作和能力，协助评估业务需求。
　　（5）研发工程师
　　实际参与研发需求的程序员。
　　（6）测试工程师
　　参与需求测试的测试人员。可以根据公司的组织架构，增加测试经理的角色。测试经理的级别也是带四、五个人小团队。
　　在需求管理中，产品经理要当成一个桥梁，与不同的角色，进行沟通和协作。在后面，需求管理的流程和需求看板的管理方法，都会与这些角色紧密相关。
　　2.3 如何识别干系人和角色
　　了解所在公司的组织架构，以及团队组织架构，是识别干系人和对应角色的关键。
　　产品经理可以根据组织架构，明确了解到研发和测试的相关角色。
　　同时，产品经理可以跟业务团队进行沟通，了解业务团队的业务背景和知识，以及团队文化。
　　识别出潜在的需求人，才是真正的考验。
　　以上，就是需求管理中干系人的相关内容。
　　3. 需求管理的三个模式与公交模型
　　普拉姆方法的运行流程包含三个模式：急诊模式、登机模式、看板模式。本章将介绍这三个模式与公交模型的关系，提供一套应对＂越快越好＂类需求的方法。
　　3.1 破解＂越快越好＂的局面
　　在接到来自各部门的需求时，每个需求都会打上＂越快越好＂的标签。站在提需求者（需求人和负责人）的角度，研发资源是稀缺的，老板的要求是急迫的，如果不表达需求的急切性，需求就排不上。
　　这就像飞机迫降之后，每个人都会带着＂越快越好＂目的奔向出口，如果没有空乘人员的指挥，最后大家慌不择路的堵在出口，最终导致延误了逃生时间。
　　处理工作的模式：划散乱为规律，划应急委预测。——《普拉姆原则》
　　所以，可以借鉴急诊室的场景 ，来规划＂越快越好＂的需求，让需求管理有序的运行起来。
　　3.2 急诊室的场景
　　产品经理面对的需求，就是来看急诊的病人。病人都会觉得自己应该马上得到最快的医疗救治。但是，医疗资源有限，只能让医生先救治最危重的病人，病情较轻的病人要先等待一下。这个时候，需要有一个预检分诊的流程，预先对病人进行判定和分诊，从而让急诊室高效的运转起来。
　　因此，借鉴急诊室的做法，我们对需求增加一个＂预检分诊＂的预处理模式。从而对＂越快越好＂的需求，进行区分，在研发资源稀缺的情况下，让真正紧急的需求获得资源。
　　3.3 让需求管理运转——公交模型
　　设想一下，病人去急诊楼就医的时候，我们安排了＂预检分诊＂（预处理）的流程。那么就需要安排一个房间，让病人们在那里等候，并安排医生进行诊断。然后，病人根据预检医生的诊断，再从这里出来，去对应的诊室去看病。
　　所以，要让这个流程在需求管理中正常的运行，就需要采用公交模型。
　　公交模型，是我结合火车模型发布模式，起得一个通俗易懂的名字。
　　（火车模型发布模式是）以固定的周期持续发布产品，如果某项既定功能未完成，就挪到下个周期发布的开发方法——《启示录——打造用户喜爱的产品》
　　公交模型，就像我要从到家到公司要换乘3趟公交车去上班，到公交站等车。每趟公交车之间都有发车间隔和到站时刻，并且周而复始的经过公交站。所以，我就按照规划好的路线，从公交站坐车，再到下一个换乘站乘车。
　　从公交模型中，可以提炼出几个概念：出行路线、发车间隔、到站时刻。
　　在公交模型中，出行路线称为＂需求管理流程＂，发车间隔称为＂需求管理周期＂。到站时刻，称为＂需求时间＂。
　　（1）需求管理流程
　　需求管理流程，是指在需求管理中，按照顺序依次进行需求管理活动。
　　需求管理活动按先后顺序分为三个阶段：
　　需求收集
　　需求设计
　　需求研发
　　再强调一遍，这三个阶段是依次进行的。先进行需求收集、在进行需求设计、最后进行需求研发。
　　每一阶段的需求管理活动对应一个指导原则。指导原则就是急诊模式、登机模式、看板模式。急诊模式指导需求收集，登机模式指导需求设计，看板模式指导需求研发。
　　在文章的开头，我用急诊室的场景，介绍了急诊模式。后续的章节中，我会介绍剩下的两种模式：登机模式和看板模式。
　　（2）需求管理周期
　　需求管理周期，简称＂周期＂，是需求管理活动按顺序重复出现，并完成需求管理活动的时间叫做需求周期。
　　普拉姆方法的需求周期，是80小时，即2个星期。80小时原则，来自于项目管理中的工作分解结构。根据项目管理的一般经验，将一个项目中的工作，按照80小时的工作量进行拆分比较合理。所以，每一类需求管理活动按照2周的工作量进行。
　　换句话说，需求收集、需求设计、需求研发是三辆同时发车但路线不同的公交车，三辆公交车运行一趟的时间是2周。每个需求相当于是乘客，要根据路线（需求管理流程）在公交站等车。当然，每个需求的终点就是发布上线。
　　（3）需求时间
　　在需求管理活动中，进行某一项具体活动的时间点，就是需求时间。
　　一般，需求时间意味着规则。比如，需求设计阶段的周二的下午2：00，需要开排期站会，这是一个约定好的时间，需求的相关方都必须要来。排期站会后面再介绍。
　　（4）运转模式
　　如果一个需求从开始到发布上线的生命周期来看，公交模型是下面这个样子。
　　从需求管理周期的角度，无数需求按照公交模型去运转着。从参与到需求管理的角色来看，每一个周期中的需求收集、需求设计、需求研发阶段，参与者的工作是连续可预测的。每个角色各司其职，让需求管理顺畅的进行下去。
　　3.4 总结
　　这章通过介绍急诊室的故事，也就是急诊模式，来引出破局＂越快越好＂类需求的方法，以及后面要介绍的登机模式和看板模式。这三个模式用来分别指导需求收集、需求设计、需求研发三个阶段的需求管理活动。
　　同时介绍了推动需求运作的公交模型，让需求管理活动具有预测性和规划性。
　　本章之后，将依次介绍三个模式和三个阶段对应的方法和工具。
　　4. 急诊模式在需求收集中的应用
　　4.1 再谈需求人和负责人
　　在《需求管理的三个模式与公交模型》中谈到，需求就像来急诊室的病人，只有经过＂预检分诊＂的过程，判断出需求的轻重缓急，从而匹配出对应的资源。
　　那么，在实际的场景下应该如何应用急诊模式呢？
　　首先回忆一下《需求管理中的干系人和角色》中，提到了角色有需求人和负责人。
　　需求人，这个角色来自于公司或者组织的任何方面，他们是提出需求的人。
　　负责人，这个角色负责收集需求，特别是业务需求。当业务团队的人数，远远大于研发团队时，这个角色非常的重要。
　　需求人和负责人在应用急诊模式时，处在比较重要的位置。
　　4.2 急诊模式的应用流程
　　急诊模式的应用流程如下图：
　　其中，圆角方形代表操作步骤，直角方形代表输出物。
　　在这里复述一下整体的步骤。
　　需求人提交需求。提交需求的模板，之后的章节会介绍。
　　负责人收集需求文件，初步评审需求。在这里，如果需求存在不合理的状况，特别是业务流程不合理，负责人可以将需求打回需求人重新整理。
　　产品经理、研发经理初步评审，并放入待排期列表。产品经理拿到负责人评审通过的需求，与开发经理进行初步评估，判断需求是否可行。可行的需求放入待排期列表。待排期列表的模板，之后的文章也会介绍。不合理的需求，也会打回。
　　根据待排期列表，需求人、负责人、产品经理、研发经理评定待排期列表中的需求，生成待开发列表。在这个过程，会应用一个工具——排期站会。这个工具，之后也会介绍。经过排期站会后，形成待开发列表。
　　在需求收集阶段，以上所有步骤是应用急诊模式的过程。
　　4.3 关于时间的把控
　　在《需求管理的三个模式与公交模型》中，公交模型下，会有三辆＂公交车＂，即需求收集、需求设计、需求研发。因为需求管理的时间周期可以是2周，所以每辆＂公交车＂的发车周期是2周。
　　换句话说，在需求收集阶段，执行急诊模式的操作步骤的时间是2周。
　　其中，需要关注几个需求时间。
　　在需求管理活动中，进行某一项具体活动的时间点，就是需求时间。
　　（1）需求收集的开始时间和结束时间
　　关注需求收集的开始时间和结束时间，因为二者相减，约等于2周，或者说约等于2周的工作时间。因为每个公司的工作习惯不一样，可能会涉及到固定时间点的例会等，所以，需求开始时间和结束时间设置要灵活。
　　同时，需求收集的开始时间和结束时间，要有一定原则性。产品经理要尽量影响需求人，不要赶在紧邻结束时间提交需求。就好比，在现实生活中赶火车，总要提前一会儿到达车站，毕竟还要有检票进站等环节。同样，需求人在临近结束时间提交需求，负责人评审需求和产品经理评审需求的时间，都不能保证，会影响需求的质量，以及之后的排期站会的质量。
　　所以，为了规避这种情况，可以在需求收集结束前5天，发送排期站会的会议邀请，以此提醒大家马上就要排期需求了，赶紧提交需求。
　　（2）排期站会的时间
　　排期站会的具体内容和形式，后面的文章会提到。这里先提一下排期站会的时间。
　　排期站会的时间紧邻需求收集的结束时间。换句话说，需求收集一结束，立刻开始排期站会。
　　因为排期站会，需要需求人、负责人、产品经理、研发经理及研发工程师参加，所以要多方协调一个大家都有空的时间进行。
　　排期站会的时长控制在一个小时内。
　　4.4 结语
　　本章介绍了在需求收集阶段，应用急诊模式的流程步骤。
　　之后将介绍，在需求收集阶段的3个工具：
　　需求提交模板
　　需求排期列表
　　排期站会
　　5. 收集需求的模板
　　本章介绍一套收集需求的模板。通过模板规范需求的内容，以及提升沟通的效率。
　　5.1 应用场景
　　模板应用在需求收集阶段，方便需求人提供和描述相应需求，便于负责人、产品经理、研发经理等角色评审需求。
　　利用此需求模板，可以快速提取需求信息，便于存档和查阅。
　　5.2 模板样式
　　此需求模板在填写上有如下说明：
　　（1）需求提交部门
　　填写需求人的所在部门。
　　（2）功能使用角色
　　比如可以填写业务主管、业务经理等。可以是使用者的职位描述。
　　（3）使用频次
　　单位时间内预计使用功能的次数。比如，10次/月。方便判断此需求的优先级。
　　（4）提交时间
　　记录需求提交的时间，便于使用＂先入先出＂原则。
　　＂先入先出＂原则，来自于仓储的概念，指的是先进入仓库的商品先出库。比如，食品行业有保质期的要求，需要生产越早的食品，越早出库。
　　再形象一点，把处理需求的过程理解为一根管子，新进入管子的需求，就先从另一头流出。
　　因为需求对应的场景和业务可能会变化很快，如果积压时间太久的需求，就变贬值，跟不上现有业务的发展，所以要应用＂先进先出＂的原则。
　　（4）优先级和重要性
　　这两个概念下一章重点介绍。
　　简单地说，优先级是对需求按不同的类型进行划分。通常见到的优先级划分是高、中、低，或者用简单的数据代替。
　　优先级：是部门与部门之间的需求比较。
　　重要性：是对需求打分，对优先级的补充，是部门内部需求的比较。
　　（5）需求涉及部门
　　一个系统需求，会牵一发而动全身。通过填写此需求可能涉及到的其他部门，来评估需求带来的可能影响。
　　也能驱动需求人在提需求时，增加跨部门思考的维度，提升需求的可行性。
　　不害人的需求，不是完整的需求。——《普拉姆原则》
　　（6）系统功能位置
　　对于系统功能优化类的需求，可以注明原有需求的位置，或者想要添加的功能页面。
　　（7）业务背景
　　或者叫需求背景。可以想象一下，如果需求是一部电影的话，是不是要介绍这个故事发生的时间、地点、人物等。以此类比，填写相关的需求背景。
　　（8）预期完成效果
　　描述需求实现后，预期实现的效果。
　　（9）需求说明
　　以任何形式来描述需求内容。
　　（10）需求文档
　　任何形式的需求文档，都不如流程图简单明了，便于沟通。
　　5.3 结语
　　此文档偏向于应用在后端产品或者系统需求。
　　如果是前端需求，可以根据业务需要选择填写。
　　6. 需求池的核心：优先级和重要性
　　本章重点介绍需求池中的核心：优先级和重要性。
　　6.1 什么是需求池？
　　需求池，顾名思义就是放需求的地方。需求像下饺子一样，储藏在需求池中。
　　在我看来，需求池是更像是一个游泳池，需求有不同的泳道。而泳道代表着需求的不同状态。
　　需求的状态一般包括：筹备中、待排期、待开发、开发中、待测试、测试中、待上线、已完成等。
　　每一种状态的需求，可以汇集成一起。比如，待排期状态的需求，可以汇总成列表样式，叫做待排期列表。
　　所以，需求池是多种状态的需求，以合适的形式展现的需求汇总。
　　结合，之前文章提到的内容，需求池列表可以是长成如下样子。
　　当然，需求池中不同状态的需求，可以用多种形式进行展现。比如，待排期的需求可以用列表的样式进行展示。待开发状态以后的需求，可以用看板的样式进行展现。
　　6.2 优先级——需求的分类和排序
　　需求的优先级是再熟悉不过的名称了。
　　优先级表现形式，一般是数字123、汉字高中低，或者字母ABC等。优先级可以用来给需求进行排序，优先级高的需求，优先开发。
　　同时，优先级也可以对需求进行分类。或者说，对不同的优先级给予一个不同的释义。
　　举一个例子：
　　需求优先级的定义，可以根据所在公司和组织、所经营的业务进行综合评估和划定。
　　但是，有一个问题，需求的数量一般会比需求优先级要多。所以，多个需求可能会同一个优先级，那么同一优先级的需求又该如何区分呢。
　　6.3 重要性——优先级的辅助
　　刚才说了优先级，具有对需求分类的作用。重要性是对优先级的辅助。
　　重要性是对需求进行打分，分数的范围是1-100分。每个需求会被赋予1个分数，每个需求的分数是唯一的。
　　例如，需求A、需求B、需求C，分别赋予了97分、85分、90分。那么，根据分数从大到小进行排序，那么优先做分数大的需求。
　　如下列表：
　　需要注意的是，重要性的分数只是用来做排序，不代表其他信息。比如，重要性是100分的需求不是50分需求的2倍。
　　另外，在做重要性评分的时候，建议每个需求之间不要打连续的分数。比如，需求A的重要性打95分，需求B的重要性最好打92分。分数中间的间隔，用来插入需求。毕竟在工作中，有很多突发的需求会插入进来，以调整研发计划。
　　6.4 统一的看优先级和重要性
　　从整体的角度看，优先级和重要性两者的关系。
　　优先级和重要性是需求池的核心！什么是核心？优先级和重要性一旦确定，将贯穿需求的整个生命周期，所有的资源将根据优先级和重要性来被安排。
　　换句话说，如果是高优先级和高重要性的需求时，不管在需求的哪一个状态，都会被优先分配资源。
　　优先级和重要性在处理跨部门需求的时候，尤为重要。原因在于，优先级可以用来比较不同部门之间的需求。因为优先级已经对需求进行了分类。
　　同时，重要性只用作一个部门内需求的比较，重要性的分数不能跨部门比较。比如，采购部门重要性100分的需求，与销售部门重要性是90分的需求，在分数上是没有可比性的。
　　（是不是有点晕了？先跳出来。）
　　优先级和重要性，只是处理需求的工具。更重要的是，如何给需求划分优先级和重要性。
　　我觉得这些方法有很多，但是可以借用项目管理的一个概念——项目组合管理。
　　项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化。
　　这个概念有点绕，只要关注一个词——＂符合企业战略＂。所以，划分需求的优先级和重要性，是紧密围绕着企业和组织的战略。
　　而如何划分优先级和重要性，可以看做是项目组合管理方法论的范畴。可以使用SWOT分析、KANO模型等等，这些都是得到优先级和重要性的工具。
　　所以，在符合企业或组织战略的核心目标下，通过项目组合管理的方法，先对收集到的所有需求标注好优先级，再对这些需求进行分组，形成需求组。分组的依据可以是部门，可以是项目。对这一组内的需求，赋予不同的重要性分数。因为需求组之间划分的标准不同，所以不同需求组的需求，重要性分数不具有可比性。
　　因此，从实现企业战略的角度，高优先级的需求在划分给不同需求组后，可能并不会赋予很高的重要性。
　　6.5 结语
　　优先级和重要性，只是处理需求的手段。它们背后的核心要义是企业和组织的战略目标。
　　7. 排期站会——需求收集的最后一站
　　上一章介绍了制定需求优先级和重要性。在此基础上，可以组织需求方和研发方在一起开排期站会。一是评定进入到需求设计阶段的需求，同时也是增进各方沟通信息的好时机。
　　7.1 为什么要站着开会
　　在敏捷开发中，站会是一个很有用的工具。在5-10分钟的时间中，快速交流信息，推进项目。
　　之初，排期会议也是安排在会议室之中，大家坐着沟通信息。实际上，人一旦没有紧迫感，就容易天马行空的沟通起需求的细节。值得注意的是，排期会不是需求评审会。
　　一般，排期会上要评定20-30个以上的需求，每个需求讨论3-4分钟，将是个极为漫长的过程。
　　所以，让大家站着开会，以一种不太舒服的方式，压缩自己的思路，快速沟通问题。
　　7.2 排期站会的一般流程
　　举行排期站会的一般流程如下：
　　（1）发送会议邀请
　　排期站会的举办时间是以固定时间举办。按照之前文章提到需求管理周期，一般是2周举办一次。具体的开会时间，要与各方协调，特别是避开例会时间。
　　与会人一般包含：需求人、负责人、产品经理、研发经理、测试经理等。
　　（2）在规定时间开会，提前公布讨论需求组的顺序
　　站会中讨论的需求，会来自不同需求组（关于需求组的概念，请上一章:需求池的核心：优先级和重要性）。每个需求组对应着不同的人，为了避免浪费大家的时间，按照讨论组的顺序，让对应的人按顺序参加会议。
　　制定讨论顺序时，尽量要考虑每个需求组的数量，和需求组的重要性。因为，先行讨论的需求，就会有优先获得需求的优势。
　　（3）按顺序召集大家开会，首先介绍当前需求的开发情况
　　由会议主持人（一般是产品经理）介绍当前的开发状况，特别是沟通时间点。
　　（4）评审进入下一阶段的需求
　　主持人可以针对需求池的内容，沟通可以进入到下一阶段的需求。
　　但是，主持人要控制住节奏，防止大家陷入需求细节的讨论。对于一时没有定论的需求，要标注出来，邀请需求相关方在会后讨论。
　　7.3 排期站会的道具
　　（1）站会的场地
　　站会的场地可以选在工位旁，较大的过道或者走廊上。这样便于参会人快速到达和撤离开会现场。也可以让一些让其他同事，快速参加会议。
　　（2）展示会议内容：电视/白板/看板
　　一般大家要围绕着需求池来开会。而展示需求池的道具，可以一块儿屏幕或者投影。这样可以集中大家的焦点，和快速展示信息。
　　（3）倒计时器
　　在每一个讨论模块设置倒计时器，到时铃响。提醒大家关注时间。
　　7.4 结语
　　站会的首要目的是公布信息，增进沟通和了解。
　　大家在开会的过程中，了解微信和邮件中以外的信息，增加对需求的了解。需求相关方的信任和了解。
　　8. 登机模式与需求设计
　　之前的章节已经将需求收集和急诊模式讲完了。本章介绍需求设计和登机模式。
　　8.1 何为登机模式
　　做需求，犹如坐飞机，通过各种渠道买好了机票，但并不是意味着马上坐上飞机，而是进行check-in。
　　面对从各个部门提出来的大量需求，有时在需求收集阶段，不能简单快速的评估出全部细节。这个时候需要增加一个需求设计阶段，对已经定好排期的需求，进行check-in，将机票转化为登机牌，然后凭借登机牌，登上飞机。
　　这里的登机牌就是产品文档，登上飞机就是进入到需求开发阶段。
　　之前，在需求收集阶段，收集到的资料大部分是可以归为需求文档，也就是描述：我想要什么，实现什么样的效果。或者说，需求文档不涉及到具体界面功能流程、交互设计、UI设计。
　　实际上，需求文档也不应该涉及这些。原因是，提供需求文档的人（需求人和负责人）并不擅长用非业务语言描述，同时也会增加他们提交需求的工作量，从而影响需求质量。
　　专业的人做专业的事。
　　什么是产品化？将需求转化为可以投入资源的行动项。——《普拉姆原则》
　　这样的话，需求设计阶段，就需要讲需求文档转化为产品文档，真正将需求描述转化为产品解决方案，转化为让研发同学可执行的方案。
　　当然也有特例，如果需求是业务逻辑的修改，不涉及界面操作，这时的需求文档其实等价于产品文档。
　　8.2 产品文档要用共享文档
　　这里并不讨论在需求设计阶段怎么书写产品文档，因为书写产品文档是用于沟通的工具，格式并不是特别重要。
　　这里要提的是产品文档要采用共享文档的格式。在之前，本人将写好的产品文档是以邮件的形式发送给相关人。但是，随之而来的问题就是，更新和保存文档，就变成了问题。
　　以邮件的形式，总会是存在漏看文档，和不易查找文档的方式。
　　所以，产品文档要使用现在共享文档的方式。国内已经有很多类似的产品，比如墨刀之类。我使用的是Google文档。使用的原因是体验好，功能完备。
　　使用在线共享文档的最大优势是，可以随时保存，使用链接分享，随时保持文档的最新状态。同时，可以多人共同编辑文档，更新信息，减少沟通的成本。
　　同时，还能对文档进行积累和保存。
　　8.3 结语
　　在需求管理的需求设计阶段，对需求重新进行评估和设计，从而转化为产品文档，并使用在线共享文档的形式，进行协作，减少沟通成本。
　　9. Trello的使用技巧——看板模式与需求研发
　　经过多个章节，终于到了需求研发的阶段。这个时候，使用看板模式进行需求管理。普拉姆需求管理方法的介绍，也快接近尾声。
　　9.1 鸡肋的邮件
　　邮件已经成为公司最基本的沟通工具。但也是最鸡肋的工具——食之无味，弃之可惜。
　　所以，在需求管理的方法中，尽量让需求的形式或者载体，不仅仅依附于邮件，而应该采用多种形式。比如，在需求池中，需求就是以一行数据的形式存在。
　　在需求研发阶段，采用看板模式，以卡片的形式存在。
　　9.2 看板与需求卡片
　　（1）看板
　　看板的管理方法，是一个来自于制造业的专门知识。
　　看板管理，是指为了达到JIT准时生产方式而控制现场生产流程的工具。——百度百科
　　这里只是才用如下图进行示意，感兴趣的读者可以查阅相关资料，学习看板知识。
　　看板由不同的＂泳道＂组成，需求以卡片的形式，从最左端开始，运行至最右端结束。
　　一般＂泳道＂的划分，可以按照需求的状态划分。也就是说，需求卡片从左向右的流转，就是需求状态的流转。
　　（2）需求卡片
　　需求卡片是需求在看板中的载体。这里可以记载需求的所有信息。
　　但是包含如下信息：
　　需求名称
　　需求的相关人：需求人、负责人、产品经理、研发工程师
　　部门
　　需求完成时间
　　需求描述
　　在开发需求的过程中，各需求的相关人不用再去寻找邮件，或者翻看电脑保存的文档。
　　每个人都可以通过看板，看到每个需求的实时状态。每个人都可以去拖动卡片。提前预知自己的工作量。比如，测试工程师就可以通过看板，大概预知有多少卡片在待测试状态，从而预估自己的工作量。
　　当然，看板和卡片可以用采用多种形式展现。比如，用真实的板子和纸片进行管理。也可以采用电子虚拟的形式进行管理，比如使用Trello。
　　9.3 Trello的使用技巧
　　现在，有很多管理工具，在使用看板的方式。但是，综合感受还是做得太复杂。而Trello的最大邮件就是简单，而且兼容很多插件，可以灵活应对多种场景。
　　当然，Trello最大的优势是免费。
　　Trello做为工具，本身极为容易上手，这里只是简单介绍一些使用技巧。
　　（1）卡片
　　Trello的卡片功能非常强大。
　　这里要特别强调的是善于使用标签功能。
　　标签功能，像是办公文具中的条状彩色便利贴。对不同卡片进行分类。
　　因为Trello有搜索和筛选功能，在实际的应用中，可以将不同的＂部门＂作为标签打在卡片上，这样就可以对卡片进行筛选。
　　这里提示的小技巧是，将同一类的信息的标签，赋予同一种颜色，以便于管理。比如，不同部门（如销售部门、运营部门等）的标签是红色，不同系统的标签是绿色。
　　另外，＂附件＂功能，可以添加在线共享的需求文档的链接，便于查看更详细的需求细节。
　　同时，可以利用＂清单＂功能，创建此需求的研发工作项目（WBS），使用@可以指定到具体的人。
　　（2）插件
　　使用Trello建议使用Chrome浏览器，因为在Chrome的应用市场中，提供了很多Trello的免费插件，增强Trello的功能。
　　Card Color Titles for Trello：使用让卡片的标签，显示出文字。Trello的自带功能，标签只能显示一个色块。
　　Trello Card Numbers：展示Trello的每个列表一共有多少张卡片。在看板管理中，每个＂泳道＂是有限额和容量的概念，也就是说每个列表应该是有最多装多少卡片的限制。如果一个＂泳道＂塞满了卡片，就是会出现堵车。
　　TrelloExport：可以将Trello的看板看片导出成Excel。
　　True age for Trello card：展示一个卡片在一个列表中呆了多长时间。卡片就像库存，如果卡片长期在一个区域长期搁置，就会变成呆滞库存，成为需求管理的负担，应该尽快去掉。
　　9.4 结语
　　本章介绍了需求研发的看板模式，从而引申出了Trello的使用技巧。
　　Trello只是工具，关键还是背后的需求管理方法。
　　10. 需求管理的证伪
　　这是普拉姆需求管理的最后一章。最后，再聊一些关于需求管理的感悟。
　　10.1 遭遇危机
　　之前文章提到的需求管理方法，包括三个阶段：
　　需求收集
　　需求设计
　　需求研发
　　其中，每个阶段分别对应了三个模式：
　　急诊模式
　　登机模式
　　看板模式
　　其中，让整个需求管理流程顺畅进行的是公交模型。也就是说，需求收集阶段、需求设计阶段、需求研发阶段，变换成2周为一个管理周期的公交车，让需求按照固定线路上车，完成需求的生命周期。
　　这样的流程设计，可以让需求得到充分的评估和讨论。但是，缺点是一个需求给人的感知是经历一个月以上的时间，才能完成。
　　同时，需求池区分了不同的状态进行展示，其实存在重要性和优先级信息在需求研发阶段逐渐模糊的情况，特别是在测试工程师面对需求时，对于需求的重要性和优先级就无法正确判断。在有临时需求插队时，情况会更加严重。
　　在收集需求人意见的情况，对普拉姆需求管理方法进行优化。
　　10.2 优化需求管理流程
　　根据公交模型，将之前的三辆公交车（即三个阶段：需求收集、需求设计、需求研发），去掉需求设计阶段，缩减为两量公交车（即需求收集、需求研发）。
　　这样修改之后，需求的生命周期就会从结构上，最快缩短到4周以内，即在2个需求管理周期内完成。
　　同时对需求站会的开会时间，进行修改。将时间改在需求收集阶段接近尾声的位置，即每2周的周四开站会。这样给人感觉就是开完会之后，排好的需求在下两周就可以进行开发。
　　10.3 优化需求池
　　需求的优先级和重要性在任何阶段都应该是不变的。比如，即使需求进入到了测试阶段，高优的需求应该优先获得资源。
　　所以，根据以上的思想，对需求池的信息进行精简，主要是去掉状态信息，让处在研发、测试或者设计状态的需求，全部放在一个列表中，根据优先级和重要性进行排序。
　　需求的状态展示，就依托看板模式。
　　其中，Title是填写需求名称，Link是此需求的Trello卡片链接，可以快速将需求查看需求相关信息。Members是涉及此需求的需求人、负责人等。Label是指哪一个类别的需求，比如可以填写部门。
　　这样，只要没有完成的需求，就可以处在这个需求池中，根据重要性和优先级进行排序，所有资源根据这个需求池的顺序进行安排。
　　10.4 普拉姆理论的缺陷
　　用了将近10章的篇幅，将普拉姆需求管理方法的最佳实践阐述完。但是，还有几个问题，虽然有解决的理论，但是没有经过实践检验得出可行的方法。
　　问题一：如何评估工作量？
　　这是一个难题。在敏捷开发中，采用估点的方式，得到比较之后的相对工作量。但是，在实践中却是比较难实现。或者说，如何让需求人和负责人清晰明确的了解所提需求的工作量。
　　问题二：如何确定需求完成的deadline？
　　由问题一引发出如何评估需求完成的deadline。在实践中，需求人和负责人最想知道的是最终完成时间。但是，时间上进行会存在估不准的情况。毕竟，大家都不是先知。如何才能比较正确评估出完成时间呢？是不是要采用置信区间呢？
　　问题三：如何处理长期堆积在需求池中的需求？
　　资源永远是有限的。所以需求池中的需求，可能会积压很长时间。达到三个月的需求，应该是如何处理呢？如何说服需求人，去处理长期挤压的需求。也许出现需求积压的问题是需求缺少规划。
　　最后
　　我所写的都是屎，唯有一点要坚持。
　　我将实践之后的需求管理理论写出来，里面有肯定有很多纰漏和漏洞。
　　虽然胡扯的地方很多，但是有一个观点，我一定会坚持。那就是普拉姆方法的宗旨：积极主动，知识共享，相互尊重。
　　不管任何需求管理的技巧，都应该围绕这个宗旨展开，这是超越任何方法论的方法。
　　水平有限，希望对你有所帮助。