别让你的 SM 变成流程执行者。

我们在引入团队内部的 SM 的机制后，普遍出现的问题是：SM 变成了执行者、监督者、工具人。我们想要 SM 能够领导团队持续改进，可是经常发现 SM 在推动各类过程改进实践时总是非常吃力，最后总是不了了之。怎么做好一个服务型领导者，有效对团队施加影响力对他们来说是一个很大的挑战。

01 好的想法不会自己传播，有一个好的想法只是第一步。

你可能发现团队的质量不佳，想引入 Code Review 的机制帮助大家相互学习，提高代码质量。这似乎是一个有百利而无一害的好主意，可是具体落实的时候总会因为各种因素落不了地。所以好的想法只是第一步，具体的落地还需要从以下三个方面来系统考虑：

1. 解决意愿问题：怎么让团队有意愿去做这件事情，做这件事情的动力是什么？

2. 解决能力问题：团队是否有能力做这件事情，是否有足够的知识、技能来支持？

3. 解决持续性问题：怎么样让团队持续的做下去，是否有机制保证形成有效闭环？

02 如何解决意愿问题？- Push + Pull！

Push - 我不得不做。通常的做法是制造外部的压力，让团队成员不得不开始行动。

Pull - 我想要做。设定愿景，激发大家的内在驱动力，激发大家的内在渴望，让大家清晰的看到做了这件事情带来的好处和收益。

03 如何解决能力问题？

降低难度、不要一口吃成一个大胖子，缩小每一次的改变幅度，逐步提升能力。

04 如何解决持续性的问题？

正向反馈 + 机制保证。如果坚持一件事情没有任何的正向反馈是很难持久的，我们需要在机制上进行设计，保证持续性。

举个例子：我是如何在团队落地技术 PM 机制的？

1、解决技术 PM 的意愿问题

PUSH - 和团队重要干系人宣导重要性：技术 PM 这个 role 的建立是非常重要的事情，从上而下都非常认可。

PULL - 对齐技术 PM 对个人的意义：技术 PM 是技术leader的后备队，能够有效的锻炼技术管理的能力。

2、解决技术 PM 的能力的问题

为技术 PM 设定清晰的成长路径，利用 PMO 导师制确保技术 PM 的所需的技能点各个击破。具体说来：

• 第一个迭代：关注基本的会议组织和沟通技能的提升

• 第二个迭代：关注风险处理能力、Owner 意识的提升

• 第三个迭代：关注团队纪律性的提升：工具使用规范

• 第四个迭代：关注团队整体效能的提升

让技术 PM 在实战中提升技能，辅以导师制 + 培训的方法让团队顺利的完成从知识到能力的过渡，背后的设计思路是：人才发展的 721 法则。

3、解决技术 PM 的持续性问题

如何让技术 PM 不被日常的琐碎事务磨灭了热情，我们尝试做了以下事情：

• 引入荣誉体系：定期 review 技术PM 的工作情况，并给予优秀的技术 PM 相关荣誉

• 晋升和绩效关联：将技术 PM 的工作质量纳入绩效考核范围

• 1on1：定期和技术 PM 1on1 对话，支持他们成长。

reference：人才发展 721 法则

• 任务——70%的学习应来自挑战性在职任务

• 他人——20%的学习内容应来自与他人的合作与洞察

• 课堂——10%的适度学习应来自正式或虚拟课堂