尔东陈的12月个人小结（下）

年底了，如何分析团队的健康度？

从成本角度上可以分析预算和实际投入的偏差情况？

从团队梯度来看可以看看人员构成是否合理，头部人才、腰部人才、腿部人才的构成比例是否健康分布？

从团队汰换来看团队是否保持活力，整体战斗力仍然足够？

从团队成长来看，团队成员的晋升情况如何，晋升之后是否仍然保持高绩效？

从团队的工作投入度来看，是否处理有着合理的投入？

引导中点赞达人的升级玩法。

传统的点赞达人玩法是：在复盘会中涉及一个环节，让团队成员在便利贴上写出最近一段时间你最想感谢的那个人，然后让大家挨个面对面表达感谢。

最近在《关键会议第二季》的工作坊中，受沫含老师的启发，升级了一下玩法。具体操作如下：

1、事先准备很多礼物的卡片

2、让每位同学选择要送出的礼物和想表达感谢的寄语，然后上墙

（注意，这里先不写送给谁）

3、让大家挨个分享自己为什么送这个礼物，以及给对方的寄语

这种方法设计的好处是将整个感谢的环节更有层次感，更丰富。 

敏捷转型并不会让团队变得更轻松。

我们在考虑为团队导入新的工作方法时，要有一个意识：新的工作方法并不会让团队的工作量减少，不会让团队变得更轻松，反而可能让每个人会更加忙碌。例如敏捷开发关注的并不是减少大家的工作量，而是怎么样让大家所做的事情更有价值，让大家的交付过程更有效率。

团队在转型的过程中，每个人都要改变自己原有的工作习惯。这会存在很大的鸿沟需要逾越，可能没那么轻松，会有更多的学习成本、探索成本，工作量也会比高很多。但是跨越这个阶段之后，团队的产出和价值交付的能力会越来越强，团队的整体价值感会更高，团队的满意度也会更高。但是满意度并不体现在我的工作量变小了，而是做的事情更有价值，每个人都能发挥自己的潜力。 

迭代小瀑布模式带来的损害。

团队采用小瀑布的工作模式，会让大家的工作一环套一环，很难带来灵活性。举个例子来说：小瀑布模式下通常会固定提测的时间，一般都是在迭代后半段，这样会带来另一个问题。团队的需求评审没办法更灵活，只能集中在一个时间段进行评审。

但是分批按需求评审明明可以带来更多的灵活性，也能节省很多人的时间，避免所有人参加所有会议。但是因为小瀑布模式的限制，这个实践的阻力就很大。所以你看因为小瀑布的工作模式给团队还是带来了很大的损害的。