第292期：【团队管理】团队2023设计之旅15
推荐理由：适合人群：团队负责人。阅读耗时：字数2596，约7.5分钟。
第292期：【团队管理】团队管理感悟
推荐理由：适合人群：团队负责人。阅读耗时：字数2596，约7.5分钟。作为一个典型的从一线产品经理成长起来的小组长，在这个成长的过程中专业能力不断提高，也经历了不少辛酸血泪。这些心得值得作为读者的你借鉴。如果你的团队想搭建或培训设计团队，欢迎找我，我们一起合作。
团队的情况。
首先是组织架构层面，这个团队原来就是一个纯粹的研发团队，由研发组长和三个研发小组组成。其次是在人员配比方面，这个组研发人数一直都是40人左右。产品经理的人数经历了3年多时间慢慢增加到10个的。
一、团队的三座大山
1. 定义团队价值和目标
小组之间几乎没有联系，所以这个团队的成员，不管是产品还是研发，普遍是比较迷茫的，对这个部门的目标和价值普遍没有认知，也不太认可自己在做的事，基本上可以用“一盘散沙”来形容这个团队。
把那些有一定成熟度的、在整个集团范围内都有差异化价值的工具拿出来作为后续重点建设的工具。这样一波操作下来，其实就只剩下了5个工具是我们要重点建设的，在这个事之后我们也建立了一个价值准则。
最后总结出几个视角下我们工具的价值：
公司视角下，提高特定类型需求的研发效率、同时控制系统安全风险。
业务视角下，提升客户导入效率、提升一线运营效率。
产品视角下，为公司贡献基础技术组件，未来有商业化的可能。
接下来全年目标的定义也自然是根据这几个价值点来的。
总的来说这个阶段倒用不上多少管理技巧，主要是考验管理者的「认知能力」，具体又表现为几个方面：
多角度看待问题的能力：从部门、公司、行业、市场等不同层次不同视角来看待问题。
定义关键问题的能力：我们到底要解决的是谁的什么问题。
把价值转化为目标的能力：我们要建一个怎样的产品能力或运营体系，达到怎样的一个目标，怎么衡量目标是否达到了。
2. 招聘、分工、协作
做职能分工的时候遵循以下几个原则：
每个人必须有一整块的活，这块活略微超出这个人的现有能力，可以独立考核，可以支撑这个人成长、出业绩、晋升。
每个人的分工对他的能力要求跟这个人的特点尽量匹配，具体说来这个活是要求抽象能力、架构能力，还是要求执行能力、需求分析能力，还是要求沟通协调能力 等等。
人人都能互相备份，包括大家能备份我，不存在一个活说只有一个人能干，所以至少一年会有一次大的职能调整，我每个季度侧重跟进的产品也不一样。
3. 工作规划和落地执行
年度产品规划：
每年春节前领导和几个组长定好年度OKR，并与各级领导对齐。这些Object成为本年度我自身的考核指标，也是部门的KPI。
这里面的一部分KeyResult变为组员的Object，组员要将自身的Object拆解为下一级的KeyResult，形成组员的考核指标。
季度产品规划：
每季度的倒数第二周，我会根据年度规划+当时的情况，定好下一个的OKR，并与领导对齐，在周会上与组员同步。
每季度的倒数第一周，组员要拆自己的OKR，要写上达成KR所需的Action，并跟我来对齐。最终形成产品组的季度OKR文档，注意这个文档里只放OKR，不是工作清单，现实中每个人除了OKR外还会有很多杂活要干。这个周我还要做本季度的工作总结。
每季度的第一周，我们单独开规划同步会，跟研发同步上季度产品建设和运营的情况，并讲解下季度的规划和工作思路。
每季度的第二周，微调OKR和工作排期表。当周给隔级领导汇报上季度工作总结和本季度公祖规划。
团队的情况。
首先是组织架构层面，这个团队原来就是一个纯粹的研发团队，由研发组长和三个研发小组组成。其次是在人员配比方面，这个组研发人数一直都是40人左右。产品经理的人数经历了3年多时间慢慢增加到10个的。
一、团队的三座大山
1. 定义团队价值和目标
小组之间几乎没有联系，所以这个团队的成员，不管是产品还是研发，普遍是比较迷茫的，对这个部门的目标和价值普遍没有认知，也不太认可自己在做的事，基本上可以用“一盘散沙”来形容这个团队。
把那些有一定成熟度的、在整个集团范围内都有差异化价值的工具拿出来作为后续重点建设的工具。这样一波操作下来，其实就只剩下了5个工具是我们要重点建设的，在这个事之后我们也建立了一个价值准则。
最后总结出几个视角下我们工具的价值：
公司视角下，提高特定类型需求的研发效率、同时控制系统安全风险。
业务视角下，提升客户导入效率、提升一线运营效率。
产品视角下，为公司贡献基础技术组件，未来有商业化的可能。
接下来全年目标的定义也自然是根据这几个价值点来的。
总的来说这个阶段倒用不上多少管理技巧，主要是考验管理者的「认知能力」，具体又表现为几个方面：
多角度看待问题的能力：从部门、公司、行业、市场等不同层次不同视角来看待问题。
定义关键问题的能力：我们到底要解决的是谁的什么问题。
把价值转化为目标的能力：我们要建一个怎样的产品能力或运营体系，达到怎样的一个目标，怎么衡量目标是否达到了。
2. 招聘、分工、协作
做职能分工的时候遵循以下几个原则：
每个人必须有一整块的活，这块活略微超出这个人的现有能力，可以独立考核，可以支撑这个人成长、出业绩、晋升。
每个人的分工对他的能力要求跟这个人的特点尽量匹配，具体说来这个活是要求抽象能力、架构能力，还是要求执行能力、需求分析能力，还是要求沟通协调能力 等等。
人人都能互相备份，包括大家能备份我，不存在一个活说只有一个人能干，所以至少一年会有一次大的职能调整，我每个季度侧重跟进的产品也不一样。
3. 工作规划和落地执行
年度产品规划：
每年春节前领导和几个组长定好年度OKR，并与各级领导对齐。这些Object成为本年度我自身的考核指标，也是部门的KPI。
这里面的一部分KeyResult变为组员的Object，组员要将自身的Object拆解为下一级的KeyResult，形成组员的考核指标。
季度产品规划：
每季度的倒数第二周，我会根据年度规划+当时的情况，定好下一个的OKR，并与领导对齐，在周会上与组员同步。
每季度的倒数第一周，组员要拆自己的OKR，要写上达成KR所需的Action，并跟我来对齐。最终形成产品组的季度OKR文档，注意这个文档里只放OKR，不是工作清单，现实中每个人除了OKR外还会有很多杂活要干。这个周我还要做本季度的工作总结。
每季度的第一周，我们单独开规划同步会，跟研发同步上季度产品建设和运营的情况，并讲解下季度的规划和工作思路。
每季度的第二周，微调OKR和工作排期表。当周给隔级领导汇报上季度工作总结和本季度公祖规划。
二、通过机制让团队逐渐变好
1. 分享型组会，团队成员的凝聚场
当时我面临的问题一个核心问题——组员的专业能力不足导致业绩、产品效果总不达预期。把专业能力提升和横向信息拉通作为组会的两个核心目标，逐渐形成了一下组会模式：
组会之前，每个人不用花时间去准备长篇大论的汇报材料的，轻松参会就行，每个人轮流做会议纪要。
组会的第一趴是我来分享一些横向的信息。这个期间大家其实会简单的讨论一下这些大的环境的变化对于自身工作的影响、如何调整工作节奏和优先级，整体持续大概10分钟。
组会的第二趴是大家提问，主要是需要我知道的重要的外部信息、需要我支持的地方、需要我帮忙解决的问题。一部分问题我会当场解答，另一部分问题会留给我的待办，期间也会有简单的讨论，整个过程持续约15分钟。
组会的第三趴是个人工作分享，事先我会指定一两个同学分享近期的工作成果，一般是讲10分钟，然后大家点评、讨论，这个过程中，我会顺势指定一下下一次的分享人。整体持续30分钟左右。
组会之后，会议纪要发给所有的产品和研发，要求研发侧按照会纪要中的内容配合我们工作。
这种组会形式，有6个好处：
通过工作分享大家共同点评的方式减轻了我作为监督者的工作量
自然而然地给到分享者适度的工作压力，并且是定期给到压力
自然而然让每个人都能相互了解彼此的工作，一个目标的实现不再只是某个人的事，大家群策群力
不用光听我一个人说，自在~
每周顺便学点别的领域知识，省事~
同时可以过一把点评者的瘾，开心~
2. 一周一个循环，即循环团队也循环自己
一年之际在于春，一周之际在于周一，周一是我一周中最累的一天。每个周一我会对照整个季度大家的工作排期表，逐项检查工作的进度，然后找到对应的人，去让他给我讲拿这个结果的思路、风险、需要沟通的人，需要协调的部门，再给他纠偏。
周二周三周四就相对轻松，30%的时间用来支持组员工作，70%可以用来干自己的事，去思考未来要解决的关键问题和问题的解法、做产品规划、做横向的项目、了解行业咨询等等。
周五一天就是各种会+ 写周报。
周六日是学习+放松。一般周六上午会看直播课，周日花两个小时针对性地补一些知识，剩下的时间都是放松——打球、唱歌、聚餐、看剧、尝试新菜谱。
一个小的循环PDCA。周一是做计划Plan，周二到周四是执行Do，周五的组会就是check，周会上的待办项其实就是改进措施Act。
3. 多定标准少发表意见，最大化释放团队创造力
日常避免不了需要指导组员工作，一开始别人问我他的产出物有什么问题没有，我一般都会把很多具体的问题指出来，并告诉他们更好的做法是什么。
所谓授人以鱼不如授人以渔，我之前就是直接告诉别人正确的做法，是「鱼」，那什么是「渔」呢。思索良久后，恍然大悟，「渔」就是做事好坏的衡量标准，我的做法在这个衡量标准下是一个好的做法，但在这个衡量标准下可能也有其他好的做法。所以如果我能把衡量的标准总结出来，那么只要组员的产出物在这个标准之上，就是好的产出物。
读后感
组内开会非常有必要，如何让开会既有价值也不会让大家觉得厌烦是非常重要的，通常呢骆驼开会的时间会选择周一和周四。定义为一开一闭。开会的时间呢根据内容而定。首篇呢是协调工作内容，而后呢是答疑问。
