本文以Scrum敏捷开发为框架，来分析项目管理中的要点。文章中的观点仅为学习参考，笔者在实践中，所以此文章将持续更新，感谢关注。
Scrum针对的是小团队的快速开发模式，一般会有Scrum Master、产品负责人、开发团队这三个角色，总人数7-11人左右。下图为Scrum的过程，以及不同角色在团队中的作用。
一、产品愿景
产品愿景可以统一团队的思想，提升团队士气，关键时刻更能发挥决策参考的作用。
一般团队愿景的思考原点有：产品是什么？产品将是什么？产品应该是什么？用户是谁？竞争对手是谁？如何满足用户需求并超越竞争对手？
回答好这几个问题后，可以填充以下愿景模版：
对于：（目标客户）；
目前存在：（问题&需求描述）；
我们提供：（产品名称）；
这是一个：（产品品类名）；
它能够：（满足需求&解决问题的方式描述）；
不同于以往的：（产品品类名）；
比如：（竞品名称）；
我们的产品：（核心卖点&差异化特性）；
而且符合：（公司愿景）
好的产品愿景可以在开发的过程中为团队起到树立目标的作用，愿景贯穿整个scrum阶段，用以检测产品是否偏离初衷。
二、产品路线
1.识别需求
产品愿景由许多产品特性所构成，产品的需求分为内部需求和外部需求，内部需求来自产品战略，外部需求来自市场调研。首先我们要将需求进行统计，可以画出产品结构图来帮助自己对需求进行分类，思路可以借鉴金字塔原理，以上统下，大的叫分类，小的叫特性，如的文章编辑是一个分类，图片插入、字号、链接插入等就是一个个特性。这里涉及到几个技能，市场调研、需求分析、竞品分析，甚至还有战略和商业模式的考量，之后慢慢一点点来梳理。
2.需求归类分组
按业务流程或功能逻辑把这些需求分成特定的主题。对需求分组时要考虑的问题包括：产品的使用方式和使用流程？哪些特性是客户要连续使用的？哪些特性是用户低频使用的？提供某一特性后，会对用户的使用造成什么影响？项目团队能否识别出需求的技术相似性或依赖性？用这些问题的答案来确认产品应有哪些主题（分类），然后根据这些主题把特性归类。
3.产品需求估算和排序
需求价值量化
需求的价值可以通过产品阶段、投产比、用户画像来确定，一般在产品初期中体验、中期重推广、后期重收入，而核心用户的需求一般要比大众用户高。这里可能用到有雷达图、时间管理-重要紧急四象限、Kano需求法则、数据思维（经济学思维）。
对需求的价值有了判断之后，要和项目干系人确认并获得支持，一定要把需求的价值进行量化，给需求的价值打分，这里的分值只是相对分值。
评估工作量
这里需要获得开发团队的支持，由他们来判断完成每项需求所需要的工作量。和需求的价值量化一样，需求的工作量也是相对的，选择一项团队认为工作量适中的需求来评出工作量，然后将这项需求作为参考系，再通过判断其他需求与这项参考系需求在实现上难易程度的差距，进而得到对其他需求的工作量分值。不同开发团队的经验和能力不同，所以不同团队可以进行多次打分。
这里经常用到的方法是斐波那契数列方法，斐波那契数列又称为黄金分割数列，指的是这样一个数列：1、1、2、3、5、8、13、21、…，这个数列从第三项开始，每一项都等于前两项之和，随着数列项数的增加，前一项与后一项之比越来越逼近黄金分割的数值。（在人的认知过程中，人处于一个信息过载的世界，能够让人觉察到的明显的差别必须达到60%以上，才能被人所觉察。这个数列是趋于0.618的比例排列，因此可以推荐使用）
比如开发团队就“放大”功能的工作量达成一致为5，那么“缩小”功能的工作量也会是5。当开发团队成员给出的分数存在很大差异时，最好让打最高分和打最低分的人说明原因，可能是对需求的理解出现了偏差，这时要进一步细化需求，让开发团队明确功能后再次重新打分，如果这次分歧不大，那么出现频率较高的分数即可作为最终分数。（人与人之间的偏好会存在偏差，所以需要不断促进团队的认知融合，进行多次打分，直到分数固定）
确定优先级
相对优先级是指一项需求相对于其他需求的优先程度。相对优先级=价值/工作量。这个公式可以让高价值低工作量的需求具备较高的优先级，使低价值高工作量需求具备较低的优先级。这样用价值的分数除以工作量的分数就得到优先级的分数。确定了优先级的需求列表就称为产品待办列表，有了产品待办列表之后就可以向产品路线图中添加发布目标了。
需求的优先级可以通过紧急重要四象限来确定。
4.填充路线图
第一次创建产品路线图时，产品需求发布的时间框架是比较粗略的，要思考一下路线图上各个分组的大致时间框架。然后为项目的发布选择一个合适的迭代周期（时间增量），比如一周、两周、一个月、一个季度或固定的天数。然后将产品代办列表中的需求分配到每个迭代周期中去。随着项目的进展，要及时更新产品路线图。
三、需求池
要做好迭代性的互联网产品，需求池是关键，因为在产品初期不可能预测到所有的用户需求，且一定有很多需求是被搁置的，因此我们需要整理需求池对需求进行管理。
需求来源自内部战略，也来源于外部收集。在收集需求的时候，我们通常可以通过自身的观察思考、数据分析、竞品分析、用户反馈得来。
这里我们从需求池和单项需求卡片两方面来做出阐述。
需求池
需求池是对需求分析之后的一个整理，通常是一个结果性的决策之后的结果。
单项需求卡片
单项需求卡片是对需求的详细描述，用以记录和分析需求。
四、迭代计划
根据产品路线图，列出阶段性的具体开发计划。这里的计划不是路线图那种大的计划，而是根据团队的特性，合理安排不同的人员在不同的时期的任务。举个例子：
一般产品经理给出产品原型后，可交由UI进行设计，之后再交付给前端和后端进行开发。这几个角色之间的关系有先后关系，也有并进关系，比如在产品完成原型之后，UI和开发和测试可以并发进行，在UI完成之后，前端再根据UI进行界面的优化调整，测试可以在这个过程中写测试用例。这里就可以将UI、测试和开发并发进行，在初始版本完成之后，测试再进行进一步测试，UI进行设计走查，最终测试好后，产品进行验收。那么产品经理的工作可以说是领先于UI、测试、开发一个周期的，因此一般产品会提前规划好一到两个版本的任务和需求文档。
这里的需求文档，可以用敏捷方法，即原型+标注的形式，更能节省时间，也利于团队理解。因为据我的经验，word版本的需求文档一般也就测试会详细得看，开发和UI都是直接看原型进行开发的。
五、每日例会
目的：保证大家的进度统一，知己知彼才能配合好，产品经理和项目经理合理评估项目进度。
方法：每个人回顾一下任务进度，昨天干了什么事，今天要干什么事，有什么阻碍点，有什么需要团队配合的。
时间：每天早上一次，每次不超过15分钟。
六、验收测试
1.开发工程师白盒测试
白盒测试就是开发直接看代码，是否符合规范，是否符合逻辑，是否符合安全性要求。
2.测试工程师进行测试
界面测试：所有页面浏览，连接的正确、所有功能按钮及界面显示正确；
功能测试：所有需求文档描述的功能实现正确；
性能测试：重点业务功能、性能能满足上线运营需求。
3.设计师进行UI走查
设计师根据自己的设计规范，来检查产品是否达到最初的要求。
4.产品经理进行用户可用性测试
产品经理模拟用户操作，测试产品是否达到自己的预期。
七、回顾总结
在每一期项目结束的时候，可由产品负责人对这次项目进行总结，并发至团队成员和领导的邮箱。主要可以是这次项目有什么好的地方，有什么不好的地方，好的地方要保持，不好的地方如何改进。
欢迎访问作者网站：https://pmhuiyilu.com