博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
[转载]项目风险管理七种武器-长生剑
阅读量:6878 次
发布时间:2019-06-26

本文共 1906 字,大约阅读时间需要 6 分钟。

关键词

将长项发挥到极致

“一个人只要懂得利用自己的长处,根本不必用武功也一样能够将人击倒。”

她的长处是笑——无论多么锋利的剑,也比不上那动人的一笑。

古龙最后说:“所以我说的第一种武器,并不是剑,而是笑,只有笑才能真的征服人心。所以当你懂得这道理,就应该收起你的剑来多笑一笑!”

 

演绎

项目经理最重要的基本功就是制定计划,执行计划。为此,我们就从计划类型的风险管理开始,解读如何将这一工作做到极致。

 

项目中遇到计划风险,主要涉及下面几个场景:

  • 角色职责:项目组织结构涉及部门较多,项目开发过程中,可能出现问题无人负责或职责不清晰的局面;

  • 项目范围:在项目启动之初项目范围不清晰,导致项目无法正常运作,无法输出项目排期等较大风险;

  • 需求:需求前期未进行充分的调研,业务价值不确定,找不到恰当的目标用户的情况;

  • 技术难度:技术团队尝试使用新技术方案进行迭代,预期比原有方式更好。但因为之前未尝试过,只是从理论上评估了可能性,所以提供的计划具有相当大的风险。

  • 人力资源:按业务特点划分三个不同子方向,分别由三个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端等)依赖。

应对措施:

  1. 整个产品C端、B端的按月召开产品需求规划,跨端对齐需求;

  2. 各端PM与RD充分对齐需求;

  3. 实行后端先行;

  4. NA端试行AB版本,对于无后端依赖或后端依赖已ready的需求,纳入快速迭代的小版本。

总结提炼:

  • 多端依赖组成的大产品团队,从前端看,后端依赖是个高优风险,通过需求规划、需求对齐等手段,推动后端先行。

  • 同时自己强化版本概念,建立长短线版本机制,在可控范围内消化短线版本,可起一定缓解作用。

 

项目中的另一个相关风险:

风险描述:NA端经常在排期把周末两天都算在内,导致排期完全没有buffer,造成delay成常态。

应对措施:

  1. 团队内自上而下,从观念上逐步认识到这是一种不可持续的方式,不鼓励,应尽量避免。

  2. 从delay的原因找起,认识到留有buffer的必要性,尤其是作为大产品,常常会有不可控的高优需求插入。

  3. 配合项目管理透明化,当高优需求插入时,进行计划调整或需求取舍。

总结提炼:

  • 正常排期(加入合理Buffer)非常必要。

  • 要管理老大预期,计划基准要合理。

  • 持续加班透支不可持续,应尽量避免。

 

经过这两个风险的处理,项目逐渐进入稳定的发布节奏。而我们的长生剑,也需要继续修炼,以便于能够将这些经验快速复制到类似的项目中。

 

看到这里,小帅陷入了沉思,自己的项目计划确实需要重新梳理一番。欲知后事如何,请听下回分解。

博客转自:《》

转载于:https://www.cnblogs.com/SanMaoSpace/p/5126704.html

你可能感兴趣的文章
RH124-13 软件包安装与升级
查看>>
我的友情链接
查看>>
1.python入门到精通
查看>>
通过vue-cli来学习修改Webpack多环境配置和发布问题
查看>>
Exchange Server 2013 高可用部署系列(四)邮箱服务器高可用——数据库可用性组(DAG)...
查看>>
和尚挑水的故事给我们带来的思想
查看>>
Zookeeper工作原理
查看>>
c++ 函数指针
查看>>
三种vsftp安装方式
查看>>
angular validation 使用总结
查看>>
uwsgi ini 设置
查看>>
node.js中通过stream模块实现自定义流
查看>>
WPF中Image控件的Source属性的设置
查看>>
体绘制(Volume Rendering)概述之4:光线投射算法(Ray Casting)实现流程和代码(基于CPU的实现)...
查看>>
Python实践之(七)逻辑回归(Logistic Regression)
查看>>
PAT (Advanced Level) 1107. Social Clusters (30)
查看>>
POJ 3494 Largest Submatrix of All 1’s
查看>>
Ubuntu系统分配存储空间的建议以及给Ubuntu系统根目录扩容方法(从20GB追加100GB)...
查看>>
centos 查询mysql配置文件位置
查看>>
Eclipse IDE 使用技巧(一)
查看>>