最近半年都在做团队过程改进相关的事，刚好前阵子在深圳的MeetUp上和王宇老师也交流了相关的内容，本文总结一下在做团队过程改进前的一些思考心得。
01 有效识别干系人
团队过程改进，说起来简单，做起来其实很复杂，涉及的人员和流程很多。在千头万绪中，你需要首先识别出具体的干系人，并得到他们的支持，解决他们的痛点，让改进事项顺利实施下去。
需要思考以下几个问题：
- 过程改进这件事，是谁发起的？
如果是研发团队基于自身的痛点，自己发起的（或者说是团队负责人有想法去做团队改进），这是最理想的状态，大家的目标是一致的，能够快速识别出团队问题。
如果是业务团队对研发团队基于当前现状的不满（交付效率低、交付质量差等问题），进而要求做过程改进。这种情况就需要找到具体为这件事负责的人，做好沟通。然后带着目标进入研发团队，去做针对性的过程改进，完成目标即可。
如果只是纯粹的职能部门要求（现在很多公司都有专门的效能改进部门，但不对具体业务交付团队负责），这种是最难做的，需要有上级领导的背书和大力支持，对推动者的个人能力和团队认可度要非常高，才有可能落到实处。
- 谁更在意或者着急这件事的最终结果？
也就是谁是这件事的实际受益者。针对上面三种场景，受益人实际上是不一样的。
场景一的最大受益者，是团队自身，所以他们最有动力去做这件事。
场景二的最大受益者，是业务团队，通过过程改进，让交付更好地服务业务，研发团队有一定的收益，但不是核心受益者。
场景三的最大受益者，是主持过程改进的那个人。被改进的团队感受并不会那么深刻，因为不是他们自身发起的，是被动的选择。这时候就需要推动者，把这种场景转化成场景一和二，形成利益共同体。
所以，需要想清楚这件事，才能用不同的方案去取得最终的成果。理清了以上两点，明确责任主体、扩大责任主体，才有可能让过程改进可持续、可落地。
- 用哪些数据支持你的过程改进？
不论是哪种场景，都需要有具体的数据支持，才能让人信服，也能更好地体现过程改进的价值。数据指标的选取需要结合目标，而不是能简单获取的。同时需要在适当的时候调整数据指标，以便于聚焦当前的过程改进项。
由于研发过程的影响因素过多，如果最终你发现数据指标并没有变好，也不要沮丧。唯结果论并不总是有效的。
02 改进问题的两个方向
向左：从整体的流程上做优化，系统性地解决问题，标准化。
向右：以人为出发点，让团队更健康和活力
多数情况下，在做过程改进的时候，都会选择向左的方向。因为这个方向是有章可循的。具体到研发流程，其实现在业内有非常多的现成规范可参考（TMMI、成熟度模型、研发流程价值流等）。只要结合团队具体的情况，做适当的裁剪和改进，就能梳理出一套标准化的流程规范，让团队按这个规范去落就可以（难点在于如何强管控，结合DevOps工具而非几份宽泛的文档）。
但是，这种路径在个人看来，只能用于保障团队的交付下限，大家都按这个流程走，少出错。而且需要定期去审视这个规范，做针对性的调整，是件持续性的工作。
向右改进，对团队的人员素质要求很高，曾经有幸在那样的团队中工作过，也见识过以人为本的研发过程改进，那是一份珍贵的体验。
03 发现有主动改变意愿的人
在实施过程改进的过程中，推动者需要去发现有主动改变意愿的人，并让这些人逐步成为过程改进的闪光点和推动者。如果你在团队中没有发现这类人，那基本上可以预见，这次的改进是失败的。推动者需要寻找新的突破点。
对于这类有意愿做出改变的人，可以让他们去思考以下三个问题（作为推动者，同样需要思考）：
- 本迭代的交付重点风险是什么？
- 本迭代有哪些⾼优先级的决策需要推进？我需要进⾏哪些关键沟通？
- 研发交付的运⾏过程，哪些⼈更多关注？关注点是什么？
有思考才会有行动，才可能推动过程改进。对团队中的其他人，严格执行既定规范即可，多数人还是需要被推着走。
04 小结
识别干系人、明确解决问题方向、发现有主动改变意愿的人。这是做团队过程改进中，前期就需要想清楚的事，这三个问题将决定最终的改进结果。对于过程改进，后续还有会案例和改进结果相关的文章，敬请期待。
共勉。
往期推荐：
学习，从接受自己的笨拙开始
如何开展大规模集成测试
越迷信技巧越容易失败
自动化测试落地为什么那么难
接口测试这么玩才明白
如何高质量的做BUG分析
接口自动化不是救命稻草
声明：文中观点不代表本站立场。本文传送门：https://eyangzhen.com/419537.html
