“拥抱变化”这个词已经被滥用太多年了.
到底什么样的变化需要拥抱,什么样的变化需要舍弃?
让我们来简单的思考一下…
软件项目管理往往区别于我们常说的项目管理.往往由于软件项目内容的特殊,流程的复杂,领域的专属
回想一下传统开发中我们怎么做的 - 项目计划的足够完整 - 单线程工作流 - 多部门交叉沟通
- 冗长的计划,从头至尾.维护长周期的任务以及相关的 wbs 工作,让项目人员不堪重负.经常性的意外任务使得整个计划不断更新维护,资源不断调配直至不再意外
- 多个工作步骤间交叉的信息传递,带来很大的沟通复杂度,及时大量使用文档,维护强度也往往不可估量
- 传统瀑布流让效率足够低,完美主义盛行,当大多数的结果是无法按预期完成
- 技术估算仍然差强人意,最终成为不靠谱的代表
“变化”
伴随着需求变化的频率逐渐提升,传统开发思路基本无法胜任
前期市场调研 -> 竞品调研/产品定位 -> 产品输出 ->研发 -> 上线 ->反馈 -> 循环
前提: 只要是人参与的环节都无法完美整个流程使得最终结果呈漏斗状变异
上面所说的传统开发思路就是一种超大粒度的闭环,而今天所说的”拥抱变化”就是微小力度的闭环
往往有很多人,以拥抱变化为借口,以不断的变化来掩盖自己低质量的输出.
先从 wbs 看起吧
- 从整个系统的设计缩小到某个模块的某个场景
- 目标明确,小规模易维护,易估算,周期短, 更早的闭环,典型的少吃多餐
从需求变化看
- 短周期意味着,更小概率的计划中意外情况的发生
- 不同迭代往往有更快的相应速度.更及时的优先级和资源的调整
- 更早得到真实用户的反馈,调整
从研发角度看
- 重点明确,不易被变化打断.
- 效率高
- 低压工作下质量往往更好,细节可以更多注意
- 计划产生,case 即生成
注意事项
迭代 内容的制定:
严格的入口标准是必须的,低质量的产品输出不能进入研发计划,不能构成闭环的迭代不是迭代
迭代中变化需要合理评估,权衡当前迭代任务的粒度,调整优先级,严格祛除各种意外
迭代出口标准的流程把控: 当即研发,当即测试,当即修复
人, 人, 人!! 重要的事情说三遍!
流程固然有用,模式固然要更新,但重要的是每个人自己对自己的把控,时间管理,知识管理,以及专注,积极反馈等因素
看看你身边到底有多少人扯着项目管理的虎皮在吹牛逼,到底有多少人在用”拥抱变化”的借口在让你加班
狠狠的扇他们耳光,踢回学校里学习吧