POLYV敏捷项目管理
本文主要介绍POLYV半年来的敏捷项目管理实践经验，融合了以往十多年研发过程管理经验，采取了双班车制度，有效推进客户高商业价值的需求落地；同时也介绍了PM工具箱，确保研发过程的风险控制，让客户价值得到落地。
POLYV产品线
从官网帮助中心入手，简单把产品线分为：点播、直播两大类，还提供API、SDK技术支持，并拥有国家专利级别的Playsafe®视频版权保护技术及三套CDN加速，致力为用户提供稳定、安全、快速的企业级云视频服务。
cdn.xitu.io/2018/11/12/16705418ba0e24a7?w=600&h=317&f=jpeg&s=56859">
为了确保客户商业价值的收益转化，在项目管理中，既没有采用繁重的CMMI成熟度，也没有生搬硬套的敏捷宣言，而是根据团队特性制定规则，围绕客户商业价值高的需求，进行快速迭代、过程风险控制、交付反馈，把资源合理化利用，做恰到好处的质量标准。
PM敏捷体系介绍
为了确保客户商业价值的收益转化，在项目管理中，既没有采用繁重的CMMI成熟度，也没有生搬硬套的敏捷宣言，而是根据团队特性制定规则，围绕客户商业价值高的需求，进行快速迭代、过程风险控制、交付反馈，把资源合理化利用，做恰到好处的质量标准。
项目管理中经典的戴明环PDCA实践：
P（Plan） --计划，确定方针和目标，确定活动计划；
D（Do） --执行，实地去做，实现计划中的内容；
C（Check）--检查，总结执行计划的结果，注意效果，找出问题；
A（Action）--行动，对总结检查的结果进行处理，成功的经验加以肯定并适当推广、标准化；失败的教训加以总结，以免重现，未解决的问题放到下一个PDCA循环。
业界通用的敏捷方案
Scrum
Scrum是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum在英语是橄榄球运动中列阵争球的意思。
极限编程（XP）
极限编程（eXtreme Programming），是一种全新的、轻量级的、灵巧的软件开发方法，是一种软件工程方法学。它强调程序设计团队与业务专家之间的紧密协作、面对面的沟通（比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好的适应需求变化的代码编写和团队组织方法，更注重软件开发中人的作用。
看板
看板管理，是丰田生产模式中的重要概念，指为了达到JIT(Just in Time, 及时生产)方式控制现场生产流程的一种工具。几乎每个学习丰田TPS（Toyota Production System）的企业都会不自觉的把看板当作第一个引入的模式，因为它直观有效。
PM敏捷管理架构
POLYV的PM管理所采用的框架，是精益和敏捷软件开发三种不同风格的轻度重叠，在此基础上根据团队业务特性优化形成。
PM管理职责
产品经理和项目经理有本质区别的，绝不是等同。
简单来说，产品经理把客户的商业价值需求，转化为研发可理解的任务，这也是艰难的过程，如何表述可研发，可测试性；
而项目经理尽一切整合研发资源，把高商业价值的任务推进落地，关注过程管理，风险控制，虽然在敏捷开发中没有定义项目经理，但确是很重要角色，敏捷开发要因地制宜，不能照搬来水土不服，适合团队特性定制的才是硬道理。
项目经理会更加专业业务和教练两个方向，不断探索。无论敏捷Scurm，XP，还是看板，都只是形式、流程，客户的关键商业价值目标要把握，从需求到运营阶段落到实处，简洁用六个字概括职责：管什么，怎么管，PM管理职责的要点有：
根据产品的质量等级定义和相应测试策略，在过程中跟踪、反馈商业价值高优先级需求的研发过程落地情况
项目计划跟踪执行，打通产品、市场、研发、测试、运维生产线的沟通，识别风险和解决团队所遇到的问题，区分轻重缓急，组织和协调项目中各项活动，基于要事第一的原则推动解决问题
服务于产品、研发、测试、运营团队，使项目顺利地、有品质的交付， 并提供研发过程质量数据分析
那么不同段次的PM，将围绕管理职责展开不同层次的工作，这就是PM的相关成熟度定义。
PM成熟度
基于PM管理职责，把PM成熟度分为六段：
从第一段至第六段，都是围绕：管什么，怎么管的职责，那么为了更好地尽职尽责，做PM还得有技术活三板斧：懂项目、懂业务、懂人。
PM三板斧绝活
懂项目
项目管理中，最经典的铁三角：
时间、成本、范围：三者之间要形成一个闭环管理，相互关联、制约、提升、促进，做到三者缺一不可的高效平衡：就像一个等边三角形，为了保持平衡性，其中任何一边有变动，另外两条边也会随之发生适应性变化。而质量是三角形中心的核心元素，也是项目三角形的"眼睛"，项目三角形的任何一个边发生变化都会影响项目质量，项目质量与三个边也相互约束。
所谓质量，是指产品上市后给社会带来的损失。-田口玄一
任何一方的尺寸不合适，都会影响最终交付商业价值的质量，当目标的偏离值小于公差范围，那就是离目标值越近，这个损失就越小。
懂业务
有开发经验的人员，不论做PM，还是测试，都有优势
从高商业价值的业务角度出发，引导产品、研发团队和参与规划、定义项目，提炼出项目，化被动为主动
推动全员清楚地知道为什么立项这个项目，明白帮助客户实现的商业价值
掌握业务领域相关知识，还包括对实现其业务需求的产品方案的了解，知道使用哪些技术栈来实现，以及对技术实现过程中的难点和重点需要有清晰的把握
使用风险工具集，分析业务进度卡顿的地方，给相关负责人做决策分析带来依据
懂人
懂人并不是说具备读心术的技能，而是掌握团队成员的技能优缺点，以及对事情把握的判断深浅程度，基于历史数据筛选分析，识别研发过程风险，能够根据成员特性，找出解决风险的策略，推进实施。
除了懂项目、懂业务、懂人，PM绝活还有不少，比如这些软技能：
Scrum敏捷过程管理
项目管理并不能直接提升产品质量，同样投入再多测试也不能提升产品质量，产品在转化为研发任务的制造过程中已经决定了质量。
项目管理有一个很重要的观点：事前预防、事中控制、事后分析。
制定Scurm敏捷过程管理框架，也是为了贯彻这个观点，打通从需求阶段出发、研发阶段、发布阶段、运营阶段环节，把控过程反馈、识别风险，调整计划，做好拥抱变化，把质量偏差控制到最小可接受范围，实现客户的商业价值需求落地。
概览：双班车制
在整个敏捷迭代周期中，分为：快速班车和版本班车。
例如：三周迭代中，每周都可以发布来自市场、客户迫切需求，剩下的按照版本班车的迭代步伐进行。这样子的好处，在确保客户高商业价值需求得到实现的同时，也快速把版本需求迭代前行，更好为客户服务，体现价值。
需求阶段
关注点：以交付价值为导向，推进高商业价值需求进入研发池。
Sprint会议前
PM参与产品需求评估，识别客户高商业价值的需求，转化为研发迭代任务
组织参与当前迭代的研发成员提供有效可用工时，并且录入系统以供评估分析
组织上一次迭代总结会议，提供QA数据（工作效率统计、质量维度数据）分析过程问题
Sprint会议中
组织评估研发、测试任务工时，消除需求、工时含混性
推动产品、研发、测试相关人员将商业价值高的需求放入研发池
根据定版的迭代任务，定义质量等级，协助测试指定验收准则
研发阶段
关注点：透明化、可视化、尽早暴露问题
日常站立会
组织团队成员自发参与每日晨会，分享信息，提出路障
燃尽图问题反馈、风险识别、各端进度反馈；
会后重大问题跟踪、反馈
日常风险控制
日常问题反馈：
重大问题、任务调整，拉上产品人员一起讨论决定
日常运营客户问题识别风险，推动研发、测试解决
任务调整：
保持原有饱和度，工时紧张的情况下，插入新任务，则移出优先级低的
超过原计划，必须插队的任务，也没有考虑移出的，则项目周期会发生延长变化的可能性
风险评估：
根据产品的质量等级定义和相应测试策略，跟踪反馈商业价值高优先级需求的研发过程落地情况
提供风险识别，打通产品、市场、研发、测试、运维生产线的沟通，解决要事第一的优先级
燃尽图风险反馈
曲线居高不下：看看哪里出问题，谁可以帮忙解决？
曲线下降太快：是否路障消除、任务评估不准确，实际更加乐观，能否加快测试，
警惕：前松后紧，前面图形乐观，后面爆发风险
信心指数反馈
根据已知风险点评估当前团队信心，是否能够顺利消除路障，达成目标
倒计时
项目距离交付的紧迫感，全员聚焦时间可用，关注当前整体进展
发布阶段
关注点：现地现物
验收机制
组织全员参与BugBash大扫除
组织产品相关人员参与客户价值验收
发布过程
协助研发、测试人员制定checklist，用于线上检查
组织测试参与需求覆盖线上确认，明确发布阶段关注重点
运营阶段
关注点：持续改善
收集技术支持反馈当前发布版本的状况，客户商业价值实现的反馈程度,快速响应推动解决
团队全员参与，总结当前版本迭代遇到的问题，形成有效措施落地执行，避免重现
PM工具箱
迭代看板
在敏捷迭代过程中，不同角色的关注重点不同，分为需求看板和敏捷看板。
需求看板
产品人员无需关心研发任务细节，仅关注大的方面，需求总体进度如何，缺点是对细节不了解，需要进一步查看敏捷看板，以及跟PM沟通。
PM看板
作为实施敏捷PM框架的核心人员，PM关注全局：需求、研发任务进度详情，包括各类开发类型任务进度、bug进度等等。
研发看板
实际就是PM看板，隐藏了需求部分，将关注点落到具体研发任务上。
风险检查表
PM工具箱常备检查表，从业务风险、技术风险、过程风险提供基础检查点，可以根据每次Sprint总结的问题反馈，转化为新的风险关注点，补充到检查表中，以下从工具箱提取部分列举
业务风险检查表
产品商业价值定义不清晰
需求不清晰，完成产品定义含混的部分比期望需要更多的时间
与竞争对手抢时间，牺牲了质量定义
技术风险检查表
开发自测不充分
功能点可测试性差
代码设计复杂
使用不熟悉的技术，没有额外的调研时间
CodeReview不充分
过程风险检查表
士气低下，沟通不到位
客户商业价值需求，信息传递不一致
任务估算乐观过度，未留够缓冲时间，例如日常会议、学习分享
进度更新不及时，导致项目总体进度看似没进展
新增任务没有通知PM、测试，需求覆盖不完整
人员负责多个项目，上下文切换成本高，导致项目进展有拖延
设备不到位，开发环境出问题
数据分析
通过收集过程数据，从四个维度来评估项目质量，包括：项目完成率、Bug生产率、燃尽图健康率、团队生产效率：
下面列举一下简化的指标
项目完成率
总体完成率=迭代总完成工作量/迭代总工作量
计划完成率=完成计划工作量/计划工作量
Bug生产率
bug生产率=迭代新增bug工作量/迭代总完成工作量
bug分布阶段：需求、开发、测试
bug分布模块
燃尽图健康率
卡顿出现持续时长，占比总体时间
开发过程中，任务变更的统计
团队工作效率
个人工作效率完成百分比
团队工作效率完成百分比
统计个人开发速率
总结
水因地而制流，兵因敌而制胜。 故兵无常势，水无常形；能因敌而制胜者，谓之神。-《孙子兵法》
项目管理无章法，就谈不上围绕客户商业价值高的需求，进行快速迭代、过程风险控制、交付反馈，把资源合理化利用，做恰到好处的质量标准，而整个研发过程中，除了客户商业价值，人也是活动中的重要因素之一。我们的核心成员曾分别服务于网易、腾讯、搜狐、优酷等互联网巨头企业，踩过许多坑，有相当丰富的解决问题的经验，犯错不害怕，关键是自省机制很重要，不再犯同样的错误，确保过程质量风险透明反馈、资源分配合理，质量恰到好处，客户价值得到实现。
微信公众号：乐少黑板报
