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

关于在制品 WIP 的应用

恰好最近因为????的原因，被迫卧床在家休息。空下来的时间在思考：为什么今年感觉这么累，体检报告很多异常，身体状态下降这么多？

这让我洞察到个人事务管理的 WIP 控制其实做得很差，今年大半时间都并行非常多的项目，有工作上的、生活上的、还有学习上的。在各个项目之中切换时，其实很多时间都是低效的，看起来自己很勤奋，但实际效果并没有那么好。当然，最后的效果就是身体撑不住了，体检下来异常很多...

这也给我一些启发，每个人的WIP也是有上限的。同一时段我们能够兼顾的项目就那么多，再多可能就超过负荷了，这时候通过堆积时间只会带来低效率的勤奋。对我当前阶段而言，可能抛开工作中，同时能够并行的项目也就2个，超过这个数量感觉就很难妥善处理了。

回到实际工作中，当我们通过迭代来管理团队工作时，其实已经默认设置好了 WIP，因为当团队成员固定时，两周能够排期的工作就那么多，我们不需要再单独考虑团队的 WIP 应该如何设置。

参加技术TL的述职会有啥好处？

今年作为某业务线的PMO负责人，走完了一个完整的闭环。在年中和年末都参加了对应技术 TL的述职会。有机会参加技术TL的述职会并有所输入，对 PMO 来说有莫大好处的事情。

1、扩大PMO的影响力，今后的合作话语权更重。

2、抛出关键的项目管理问题，为明年的工作做好铺垫。

开发与产品之间如何建立信任感？

如果开发与产品之间没有建立信任感会带来很多问题。最典型的是产品会经常挑战开发的工作量和估时，然后会尽可能的去压工作。开发人员会去挑战需求，希望他的需求准备得更加的完善，很容易演变成吹毛求疵。

如何解决开发与产品之间的信任感，之前提到很多团队融合的想法。这里提供另一个思路：让技术和产品背同样的OKR，技术的同学到业务侧去驱动业务。 

如何避免数据游戏在效能指标中的影响？

在定义效能指标的时候，希望牵引整个组织的行为必然会带来一些影响，很容易演变成为了数据好看，而实际行为变形。在这个时候我们有几个策略可以考虑：

第一就是不要把这些指标与大家的直接绩效关联在一起。虽然没有办法避免会影响大家的部分绩效，但是不要直接将绩效与某些指标绑定。除非某些客观的指标，没办法作假，例如 SLA 相关的数据。

第二就是构建指标的群组，不要以单一指标作为参考，北极星指标、群星指标以及围栏指标在这部分可以发挥作用的地方。

第三就是让子弹飞一会儿，持续观察。如果要一直保持数据好看，对团队本身就有管理成本，而且会带来诚信的问题。