企业不只在组织级可以通过管理体系和流程来驱动组织的学习和成长,还可以尝试以敏捷团队为单位来发展团队的能力。最好的敏捷团队是T型团队,即每个人都有自己的专长,但也是个通才,在别人需要帮助的时候,可以提供帮助。
陈硕是通信企业W中一个Scrum团队的ScrumMaster。在敏捷转型之初,该团队强烈地感受到了技能壁垒的痛苦。由于每个工程师对其他模块都不熟悉,只能做自己熟悉的一个模块,因此在Sprint计划中,每个工程师都只能领取自己熟悉的模块工作。结果,在每个Sprint执行中,团队无法以价值优先的原则为Backlog排序,因为高价值的工作只有一个人有能力做,而他的工作量已经饱和。此外,每个人都孤立工作,互相没有讨论与协作,大家对彼此的模块不熟悉,互相帮不上忙。于是,当有同事遇到困难时,其他人只能唉声叹气。更糟糕的是,每个Sprint会有不止一名同事遇到这样的困难,因此陈硕的团队连续五个Sprint都失败了。在连续失败的情况下,团队终于决定不能再这样继续下去了,需要打破技能壁垒。但是光说打破容易,具体该怎么操作呢?
在这种情况下,我们可以用技能地图作为工具来解决此类问题,如表9-8所示。
表9-8团队技能地图示例
构建技能地图有以下四个步骤。
- 第一步:团队将产品需要的技能逐一列出。
- 第二步:自评。每个人对自己的每一项技能水平打分。0~9分,即从完全不懂到极其精通。
- 第三步:集体评估。每个人自己评估打分后,ScrumMaster召集团队成员一起复评,团队就每个人的自评进行讨论校正。之所以需要校正这一步,是因为每个人对自己能力评估的标准不同。比如,一个很谦虚的同事往往会给自己一个偏低的分数,而一个自信满满的同事可能会给自己一个偏高的分数。
- 第四步:能力基线化。大家将评估结果作为团队的能力基线,团队基于现实能力水平和产品的业务需要制订能力提升计划,即每个人需要花多长时间将某项能力提升到某个层级,尤其需要关注的是那些从0到1的能力提升。计划定好后,团队结对工作。例如,一个用户故事需要PON协议开发技能,而同事Jenny没有这方面的技能,她正计划学习这块知识,而Tony在这方面的能力很强,评估分数为7分,于是这两个人结对开发这个用户故事。
这样的结对开发在短期内会使团队的用户故事效率有所下降,但是在长期范围内团队是非常受益的。拿案例中陈硕的这个团队来说,过了3个月后,团队的技能壁垒打破了很多,交付效率迅速上升,Sprint的成功率极大提高。
当然,团队制订能力计划不能只从自己的兴趣着手,还要参考业务需求。团队可将产品负责人提供的Backlog里优先级最高的那些需求以及产品路线图作为技能地图的重要输入,然后依据接下来的几个月内要做的业务内容,分析其所需的业务能力,再结合每个人的兴趣来制订能力提升计划。
技能地图制作完成后,团队需要对其定期更新。比如,每隔2~3个月团队就要更新自己的技能评估,并制订下一步能力提升计划。
|