我们无需完全100%去套用一些管理方法,重要的是“实用”,舍弃一些无关的框架。例如关于敏捷开发:
- 团队跨语言、时差无法高效实时沟通就一定不能启用敏捷开发模式吗?
- “敏捷开发”就一定不能写PRD吗?
肯定不是这样的,重要的是我们要理解这些管理方法背后的底层逻辑,理解透彻后,我们在里面找到我们自己业务团队所在的一个平衡点。
个人认为,相比瀑布研发,敏捷开发的核心特点是:
- 小步快跑,迭代思维
- 灵活,调头成本低
- 让产品、研发、测试各个团队,形成交叉循环
- 流程链上能够闭环,行程一轮又一轮的冲刺(Sprint),就像摇起来发动机,甚至可以反向推动业务
- 研发透明度高,避免黑盒现象
而这里面有几个关键点:
- 需求的解构能力(Break Down),把一个大的需求分解成不同阶段,一方面可以降低研发负载,另一方面可以得到运营数据的反馈来优化。同理,Jira中的Epic-User Story-Task就是同样的底层逻辑。
- 需求的整体规划思维,敏捷开发另一个现象就是,产品经理被业务团队Push下,造成系统不断的碎片化,最后就像一个补丁做出来的衣服,缺少整体的规划。我们进行定期的需求路径规划探讨也是很有必要的
- 每个冲刺的时间的管理能力,一个高性能的发动机,需要各个单位的精密配合,火花塞、供油、活塞、齿轮都需要能协同好,那么这里的进度管理与纠偏就至关重要。每日的例会(Scrum Meeting),燃尽图(Burn Down Chart)的主要价值也在于此。
- 每个冲刺(Sprint)的复盘会是最重要的事情,往往也是最容易忽略的,或者敷衍的。能让大家跳出“担责任”的思想包袱,积极主动发现问题,提出优化方案更应该受到鼓励。
- 责任到人,比如,明确Scrum Master,日例会的组织、复盘会的组织、时间的纠偏等,有些时候,该作的决策,责任人就一定要果断
- 更多时候,我们会发现实操过程中不是流程的设计问题,更多的是团队对流程的底层理解不到位,动作变形了。
那么回到跨国团队这个大前提,敏捷开发,对于敏捷高效的沟通要求是非常高的,这也正是跨国的最大挑战。那么怎么办?我们一定要“敏捷开发”吗?不一定,重要的不是这个名头,而是这个模式背后优秀的价值,回到这个出发点再看,问题就会容易很多,挑战点就可以迁移了。
例如,我们可以把口头的高效沟通方式,通过文字和原型(简化版PRD)来表达即可,大家会觉得这失去了敏捷的高效,其实不然,事后我们依然会发现,高效、有序的敏捷冲刺模式所带来的效率提升,依旧远大于做PRD和原型所牺牲的时间,远大于无序的管理所浪费的时间。
以上也是这段时间的一些思考,希望大家一起探讨指导。
本文由 Zhang, Lucas 发布在 coolzmm,转载此文请保持文章完整性,并请附上文章来源(coolzmm)及本页链接。
原文链接:http://www.coolzmm.com/kjds/1511.html
原文链接:http://www.coolzmm.com/kjds/1511.html