标签：
关键词
将长项发挥到极致
“一个人只要懂得利用自己的长处，根本不必用武功也一样能够将人击倒。”
她的长处是笑——无论多么锋利的剑，也比不上那动人的一笑。
古龙最后说：“所以我说的第一种武器，并不是剑，而是笑，只有笑才能真的征服人心。所以当你懂得这道理，就应该收起你的剑来多笑一笑！”
演绎
项目经理最重要的基本功就是制定计划，执行计划。为此，我们就从计划类型的风险管理开始，解读如何将这一工作做到极致。
项目中遇到计划风险，主要涉及下面几个场景：
角色职责：项目组织结构涉及部门较多，项目开发过程中，可能出现问题无人负责或职责不清晰的局面；
项目范围：在项目启动之初项目范围不清晰，导致项目无法正常运作，无法输出项目排期等较大风险；
需求：需求前期未进行充分的调研，业务价值不确定，找不到恰当的目标用户的情况；
技术难度：技术团队尝试使用新技术方案进行迭代，预期比原有方式更好。但因为之前未尝试过，只是从理论上评估了可能性，所以提供的计划具有相当大的风险。
人力资源：按业务特点划分三个不同子方向，分别由三个PM负责，但存在公共人力，任务分配会存在冲突（比如前端FE人力、UI/UE人力是公共人力）
关键依赖：项目存在大量的后端（如检索端、营销端、B端等）依赖，对版本的需求能否按期按量发版产生很大影响。
环境准备：在迭代过程RD联调测试时因缺少测试环境，部分功能未经过RD联调测试直接交由QA测试，导致QA测试周期压力较大，质量风险滞后，后期修复bug风险和成本都很高。
排期：技术人员的过于乐观，或在排期时未考虑到提测集成阶段需要占用RD的时间修复bug，以及非正常排期（周末时间都排入）等情况。
接下来我们就用这把长生剑来解决一个实际项目中的计划风险。
项目特点：
产品发展阶段: 方向探索+加速赶超。2015年重点产品，从市场占有率上排名第三，今年的重要目标是弯道超车。目前产品在探索新模式，以期通过新的产品定位抢占市场。
项目组织结构：内部和四个部门有合作；外部计划接入三个重量级的第三方合作商。
团队的组织结构：组合模式，大型项目上按特性团队组织，常规开发按模块团队组织。
产品包含的端：PC、SDK、APP(Andorid，IOS)、H5
产品类型：平台类；创新；优化；运营，销售，产品，研发多方配合；工程策略相结合。
研发模式：前端为scrum模式，检索端和运营等团队为流式研发模式。
项目背景：作为大产品，产品团队的组织架构较为复杂，从前端看，产品研发上线非常依赖于后端多个端。
识别阶段：加速前进（进攻时刻）
触发条件：一直如此
发生概率（高、中、低）：高
影响评估（高、中、低）：中
应对措施（避免、缓解、转移）：缓解
负责人：项目经理
状态（新建，已发生，已处理，已关闭）：已发生
优先级（高、中、低）：高
风险描述：作为一个多端依赖的大产品，NA端（Native APP）作为移动用户的入口，每一版本的发布都牵动整个产品线，但NA端版本的需求能否按期按质按量的最终发版，存在大量的后端（如检索端、营销端、B端等）依赖。
应对措施：
整个产品C端、B端的按月召开产品需求规划，跨端对齐需求；
各端PM与RD充分对齐需求；
实行后端先行；
NA端试行AB版本，对于无后端依赖或后端依赖已ready的需求，纳入快速迭代的小版本。
总结提炼：
多端依赖组成的大产品团队，从前端看，后端依赖是个高优风险，通过需求规划、需求对齐等手段，推动后端先行。
同时自己强化版本概念，建立长短线版本机制，在可控范围内消化短线版本，可起一定缓解作用。
项目中的另一个相关风险：
风险描述：NA端经常在排期把周末两天都算在内，导致排期完全没有buffer，造成delay成常态。
应对措施：
团队内自上而下，从观念上逐步认识到这是一种不可持续的方式，不鼓励，应尽量避免。
从delay的原因找起，认识到留有buffer的必要性，尤其是作为大产品，常常会有不可控的高优需求插入。
配合项目管理透明化，当高优需求插入时，进行计划调整或需求取舍。
总结提炼：
正常排期（加入合理Buffer）非常必要。
要管理老大预期，计划基准要合理。
持续加班透支不可持续，应尽量避免。
经过这两个风险的处理，项目逐渐进入稳定的发布节奏。而我们的长生剑，也需要继续修炼，以便于能够将这些经验快速复制到类似的项目中。
看到这里，小帅陷入了沉思，自己的项目计划确实需要重新梳理一番。欲知后事如何，请听下回分解。
博客转自：《项目风险管理七种武器之长生剑 | 百度敏捷教练》
标签：
原文地址：http://www.cnblogs.com/SanMaoSpace/p/5126704.html
