精益化的团队高效协作_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 精益化的团队高效协作

精益化的团队高效协作

 2022/9/15 14:42:35    程序员俱乐部  我要评论(0)
  • 摘要:时间都去哪了?“不是在开会就是在去开会的路上”这是很多职业经理人工作的真实缩写。然而事实往往是忙碌了一天,拖着疲惫的身躯回到家,回头想想这一天虽然处理了不少事,但没有一样是真正完成的,所有的工作都是在进展中,而且越来越趋于复杂,依赖因素也越来越多。对于实现安排的完成日期也越来越没有信心。为什么会这样?我们的团队是不是哪里出了问题,导致效能这么低?在项目初期就给团队树立了明确的目标,但团队都把时间用到哪里去了?带着这个问题,我们将一起探索团队效能的问题症结在哪
  • 标签:

  时间都去哪了?  

  “不是在开会就是在去开会的路上”这是很多职业经理人工作的真实缩写。然而事实往往是忙碌了一天,拖着疲惫的身躯回到家,回头想想这一天虽然处理了不少事,但没有一样是真正完成的,所有的工作都是在进展中,而且越来越趋于复杂,依赖因素也越来越多。对于实现安排的完成日期也越来越没有信心。

  为什么会这样?我们的团队是不是哪里出了问题,导致效能这么低?在项目初期就给团队树立了明确的目标,但团队都把时间用到哪里去了?

  带着这个问题,我们将一起探索团队效能的问题症结在哪,该如何提高团队效能。

  很多人会把效率和绩效作为一个概念来评价团队,其实它们是两个完全不同的概念。

  首先高效不是绩效,也不应该是绩效的考核指标。效率是用来评价一个人或团队的工作效率,即完成每个任务的时间成本是多少。这是不会因为加班加点而提高的。

  绩效如果排除其他考核因素,仅从工作任务完成情况来看,绩效是通过统计员工完成任务的总量和预期目标比较所得到的结果。管理者往往会忽略团队成员到底花了多少时间完成那些任务,甚至鼓励员工付出额外劳动来按期按质地实现任务,因为绩效完全是结果导向的(这样的管理者也往往是效能提高的最大障碍)。因此我们可以得出如下两个效率和绩效的公式:

  效率 = 计划完成的工作总量 / 实际时间成本

  绩效 = 周期内实际完成的工作总量 / 周期内计划完成的工作总量

  如果仔细比较,我们可以发现如果是在一个周期内,效率×绩效=周期内实际完成的工作总量/实际时间成本,而这个值我们称之为工作预估偏差。

  到这里,估计大家能想到我们其中一部分时间去哪了。那就是工作预估偏差值(计划工作总量-实际时间成本),如果这个值为负值,说明我们在加班;如果为正值,说明我们团队效率不错,还有多余时间。

  看上去是这样的道理,但上面这个公式不一定总是正确的。原因是当团队面临很多技术难题或者其他因素时,会增加任务缓冲值,从而让估算偏差看上去总是正值。所以很多人会质疑这个值的可依据性。在敏捷开发模式里提出了一个很好的概念:故事点。

  高效实践一:故事点

  故事点估算是敏捷项目任务的估算方法的一种,它是一种相对值,而且不是连续数也不和实际工作时间有直接关联(具体可查看故事点介绍)。在敏捷开发模式中,特别是多团队协作的情况下,项目经理可以把某个简单任务设置为参照物,估算点为1。每个迭代周期之初,安排各团队对所要开发的任务和参照物对比进行故事点估算。

  通常情况下各个团队的故事点分配总数是接近的,因为它是相对值,对于任务估算中的缓冲时间被同步放大或者缩小。因此项目经理通过故事点的管理比工时管理更为可靠,而且宏观。

  有了故事点,我们可以把团队的绩效用故事点来衡量。抛开这个不确定因素,我们的效率值或者估算偏差值就变得十分可靠。而让估算偏差变为正值是我们建立高效团队的目标。  

  如何改进估算偏差?

  看过《一分钟经理人》这本书的人,一定记得管理大师布兰佳关于“一分钟目标”这个说法:只花一分钟的时间,就往往决定了这一天80%的工作内容,这是一个多么神奇的计划。于是很多人也去尝试做一分钟的目标,然而并没有描述的那么奏效,随之就放弃了。事实上,很多人忽略了这是一个持续性的计划,其实80%也是个人计划中需要去达成的一个目标。这种计划方法对于一个团队,即使是大型团队,花很少的时间来做一个当天目标设置其实同样十分有效。而关键在于计划的持续性和长期、中期、短期计划的关联。

  这本书给我们另一个很好的概念:多短计划。

  高效实践二:多短计划(站会)

  在我带过的团队里,都会采用多短计划,每天早上或晚上进行15分钟的短会。目的是让每个团队成员了解我们一天要进行的任务有哪些,有什么样的问题需要相互协作解决,并确认是否存在计划偏差。

  事实上,团队管理者更多关注的是任务的依赖性和计划偏差;团队成员关注的是当天任务计划和存在问题。当团队较多或每个团队中人数较多时,对于团队的每日状态管理就是难点了。如果每个团队有7个人,每个人平均有5个任务在进行(包括需求分析中、开发中、测试中、交付待确认等),任务之间存在相互依赖关系。那么对于管理者来说要掌握35个任务的进展状态和他们的问题在哪里,同时还要关注任务之间的优先级关系。如果每个任务需要10分钟,那么管理者可能花费将近350分钟(将近6小时)的时间来查看或处理所有的任务项。这是多么恐怖的现状!

  对于每个团队成员来说,除了自己关心的任务之外,还要关心对于别人的依赖任务和依赖别人的任务。如果每个人各有一项依赖和被依赖项,每天也至少花费20分钟来处理。那对于团队来说也存在至少140分钟的沟通讨论。

  是否管理者和团队的这些时间是必不可少的呢?答案当然是否定的。在团队中,我们可以用看板很好地管理这些任务,几乎可以在站会中一起解决这些事情。

  高效实践三:看板

  看板来源于日本,是丰田精益生产中的一个工具。其原理是只有当下游的任务发出原材料请求时,上游工序才开始生产该原材料。如此形成了拉动式的制造工序,并努力实现零库存。引入软件开发工程后,生产过程中的材料就被转化为工作任务项。每个任务要经历准备→开发中→开发完成→测试→测试完成→部署这几个阶段。每个人员或者每个任务会形成一条自己的“泳道”(任务需要通过的路径)。通过看板我们可以解决以下一些问题

  所有团队成员的任务状态清晰明了。

  哪个阶段积攒任务过多,说明是瓶颈所在。

  集体更新的机制减少团队1对1沟通次数。

  可以收集过程数据,进行团队效率改善。

  看板所带来的好处远不止这些。但在看板使用过程中也要十分注意一个关键词——WIP(Working inProgress)。它代表的是团队在某个活动下同时进行的工作项的数量。从科学的角度,每个任务的完成周期(Cycle Time)越短,其从事这项工作的工作效率越高。而对于管理者注重的人员使用率(Utilization)来说,当一个任务较大时(Cycle较高),其Utilization也会降低。而无限细化任务会大大提高分析时间和沟通成本,因此作为统计值,每个人同时有2个任务时,其工作效率是最高的,如图1所示。  

  影响效率的因素

  有了一些实践方法,并不一定能马上提高团队的效率,因为影响因素是多方面的,需要综合长期的情况来看待效率问题。研发团队中,效率的主要障碍来自以下几个方面:

  为快速交付积累的技术债;

  团队人员T形技术能力;

  不稳定的开发节奏;

  管理者的微观管理;

  低效的沟通成本,包括手工流程执行;

  代码质量。

  此外还可能来自组织自身的因素,如部门壁垒、区域分布和文化差异等。对于任何影响效率的因素都值得重视。很多团队就因为被其中一两个因素羁绊住,而导致整体效率的下降。这种时候不能期待依赖于其他问题的改善来提升整体效率,这和木桶原理一样。如果能够正确快速地识别原因,那么剩下的就是如何解决问题了。

  建立高效团队的目标是发现消极因素,针对性地提出改进措施。管理者需要不断地思考这些因素给团队带来的影响,以及和交付目标之间的平衡。对于发现的问题,刺激我们的是发现问题的原因。这需要借助系统思考(System Thinking)的一些技巧,即把事务的逻辑关系和来龙去脉进行分析,打破影响因素的环路。例如图2的技术债问题,可以在任何环节中引出分支,即可消除滚雪球效应。

图2 借助系统思考分析逻辑关系

  通常,我们可以为此可以重点监控一些下面的过程数据,以便于对阻碍因素的改进:

  UAT缺陷率;

  缺陷周期长度;

  版本开发和维护投入比;

  各类会议所占开发时间比;

  周期内知识共享和代码走查次数;

  自动化测试比例。

  收集数据的目的不是为了根据现状去设定目标,否则就是本末倒置了。其真正目的是可以用来做改善方向的依据。例如发现缺陷周期超过一周,说明一个缺陷从代码签入开始一周以后才能被检测到,这是多么糟糕的事情。管理者应该思考如何加强对新签入代码的功能的检测,如何在还没有被集成到系统代码之前,让这样的缺陷可以被修复。这样才能减少不必要的沟通和二次发布的浪费。

  管理者应该善于发现团队浪费,但同时也要允许浪费。宁可让团队完成任务后打游戏来培养团队协作能力,也不允许对于一个已经发现过的错误,再出现第二次。对此,一定要有个精神洁癖和偏执狂般的执着,才能给团队带来持续不断的效率改进。

  郑立

  • 相关文章
发表评论
用户名: 匿名