![](https://images2015.cnblogs.com/blog/284255/201601/284255-20160113112638835-2041681100.jpg)
关键词
将长项发挥到极致
“一个人只要懂得利用自己的长处,根本不必用武功也一样能够将人击倒。”
她的长处是笑——无论多么锋利的剑,也比不上那动人的一笑。
古龙最后说:“所以我说的第一种武器,并不是剑,而是笑,只有笑才能真的征服人心。所以当你懂得这道理,就应该收起你的剑来多笑一笑!”
演绎
项目经理最重要的基本功就是制定计划,执行计划。为此,我们就从计划类型的风险管理开始,解读如何将这一工作做到极致。
项目中遇到计划风险,主要涉及下面几个场景:
-
角色职责:项目组织结构涉及部门较多,项目开发过程中,可能出现问题无人负责或职责不清晰的局面;
-
项目范围:在项目启动之初项目范围不清晰,导致项目无法正常运作,无法输出项目排期等较大风险;
-
需求:需求前期未进行充分的调研,业务价值不确定,找不到恰当的目标用户的情况;
-
技术难度:技术团队尝试使用新技术方案进行迭代,预期比原有方式更好。但因为之前未尝试过,只是从理论上评估了可能性,所以提供的计划具有相当大的风险。
-
人力资源:按业务特点划分三个不同子方向,分别由三个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)非常必要。
-
要管理老大预期,计划基准要合理。
-
持续加班透支不可持续,应尽量避免。
经过这两个风险的处理,项目逐渐进入稳定的发布节奏。而我们的长生剑,也需要继续修炼,以便于能够将这些经验快速复制到类似的项目中。
看到这里,小帅陷入了沉思,自己的项目计划确实需要重新梳理一番。欲知后事如何,请听下回分解。
博客转自:《项目风险管理七种武器之长生剑 | 百度敏捷教练》