编辑导语：作者作为一个典型的从一线产品经理成长起来的「小组长」，在这个成长的过程中专业能力不断提高，也经历了不少辛酸血泪。本文作者将与你一同分享团队管理的实操经验，希望这些总结和感悟，能够帮助到很多跟作者一样的成长中的初级管理者！
我是一个典型的从一线产品经理成长起来的「小组长」，网上有很多讲解团队管理的文章，大都是偏理论的，我的这个分享是比较偏实操的，是一些拿来即可用的方法工具，希望我的这些总结和感悟，能够帮助到很多跟我一样的成长中的初级管理者。
先说一下团队的情况。
首先是组织架构层面，这个团队原来就是一个纯粹的研发团队，由研发组长和三个研发小组组成。在我进组之前，这个团队大概运营这个小工具，这些工具的用户量或大或小，成熟度也不一。
我是年月份进的组，是这个团队的第一个产品经理，直接挂在研发组长下面。
年组织架构调整，独立出来了一个产品组，年下半年产品组长和研发组长双双异动了，产品组长空缺了一段时间。
从年月份我开始暂代组长，也来了一个新的研发组长。
年月份研发组长异动，新来了一个产品组长，兼任研发组长。
其次是在人员配比方面，这个组研发人数一直都是人左右。但之前是没有产品经理的，产品经理的人数也不是从忽然一下子增到的，而是从个→个→个，经历了年多时间慢慢增加到个的。另外这个组之前也是没有前端的，从年下半年开始有了自己的前端，经过年的时间发展到个前端。
总结来说，这个组花了三年多的时间才达到了各种角色人员配比平衡的一个状态。
从年年底我进组一直到年年底的这段时间，我基本上就是一个大头兵。这段时间的专业能力成长很快，也充满了辛酸泪，回头单开一篇分享，以下的分享和总结就从我暂代组长开始说起。
不管是空降过来还是从内部成长起来的管理者，新接手一个团队之后基本上都需要解决以下三个问题：
定义团队价值和目标
招聘合适的人、定义这些人的分工、建立各种协作机制
做好年度、季度、月度工作规划、借助管理手段确保绩效落地
如果是空降过来的管理者，还会有一个额外的过程，就是「知人→识人→用人→建立信任和权威」。
对于产品组内而言，我倒是没有这个过程，因为我是第一个产品经理，是最熟悉产品的，也熟悉所有一线工作的同事，之前就已经建立了一些专业权威。但是跟我合作的这个研发组长以及他底下的小组长是都换过的，所以跟他们之间有一个磨合和建立信任的过程。
年上半年合作的这个研发组长是其他组的研发老人，之前就认识，所以整个建立信任的过程还是挺快的，我们从一起工作到产出一些成果不过就是一个月的时间。年空降的这个领导就不一样，对于他来说（我现在领导），当时他就有建立信任和权威的这么一个过程，我跟他磨合了有大概三个月的时间，才开始有一些真正的产品/团队管理上的动作。
下面展开讲一讲我解决三座大山的过程和感悟。
整个年团队是比较混乱的，直接领导和间接领导都变了两回，大家对于年在做的事情又有一些不认可，再加上这个团队原来人均运维着一个小工具，小组之间几乎没有联系，所以这个团队的成员，不管是产品还是研发，普遍是比较迷茫的，对这个部门的目标和价值普遍没有认知，也不太认可自己在做的事，基本上可以用“一盘散沙”来形容这个团队。
我跟研发组长接手之后，恰逢组内制定年工作计划。对于手上拿的这个工具，我跟研发组长一致认为需要聚焦，我们按照工具的建设成熟度、使用范围大小、工具本身的差异化价值的大小，给所有工具的后续发展做了一个分类。
把那些有一定成熟度的、在整个集团范围内都有差异化价值的工具拿出来作为后续重点建设的工具；那些没有差异化价值的工具，不论使用面大小，通通都做下线处理，让用户迁移到集团的其他同类工具上；那些有差异化价值但是建设尚不成熟的工具，我们尽量不扩大使用面，按需建设。这样一波操作下来，其实就只剩下了个工具是我们要重点建设的，在这个事之后我们也建立了一个价值准则「我们只做整个集团范围内有差异化价值的工具，并且要做精做好，绝不重复造轮子」。
后来这个价值准则和我们对于这些工具的处理方式也得到了大家的普遍认可，所以大家有了第一个共同认同的目标——推进下线这些不太可能产生大价值的工具。
但是我们选出来了接下来要重点的建设的工具，并不等于就定义清楚了团队的目标和价值，那个工具之间还是几乎没有关联，大家仍然不知道我们为什么而存在。老实说我当时不具备定义目标和价值的能力，没有那个sense。之前当大头兵的时候，我就只管建工具、推广使用、降本增效就完事儿了，根本没有从公司的角度想过我们解决了公司的什么问题，后来才知道价值的一些基本维度——营业成本、运营效率、销售收入、客户体验。
当时就到混沌学园里听课，去学习定义问题思考问题的一些最基本的逻辑，去看案例，再对照自己的工作。当时针对保留的这个工具，具体做了几件事：
站在公司的视角、用户的视角上看这些工具解决的到底是怎样的一个问题，产生的价值属于什么维度。
去市场里找同类产品，搞清楚自己做的这个工具到底是不是市场化的一个产品，市场上是怎么量化这个工具的价值的。
把这些工具当B端产品看，定义清楚这些工具的客户、用户、合作伙伴。
理想情况下这个工具的产品架构、能力清单。
最后总结出几个视角下我们工具的价值：
公司视角下，提高特定类型需求的研发效率、同时控制系统安全风险。
业务视角下，提升客户导入效率、提升一线运营效率。
产品视角下，为公司贡献基础技术组件，未来有商业化的可能。
接下来全年目标的定义也自然是根据这几个价值点来的，类似于「降低客户导入周期」「系统安全防护能力建设」「商业化项目应用和收入」。
总的来说这个阶段倒用不上多少管理技巧，主要是考验管理者的「认知能力」，具体又表现为几个方面：
多角度看待问题的能力：从部门、公司、行业、市场等不同层次不同视角来看待问题。
定义关键问题的能力：我们到底要解决的是谁的什么问题，如果你定义的问题对于任何一个角色来说都不是问题，那这个问题或许确实是个问题，但没有价值。
把价值转化为目标的能力：当定义了一个有价值的问题后，那么用什么手段来解决这个问题呢，我们要建一个怎样的产品能力或运营体系，达到怎样的一个目标，怎么衡量目标是否达到了。
招聘一个人的时候，并不是说有了编制就随便招一个人，人也不是越多越好。我是从以下几个维度来评估是不是要新招人手的：
公司是不是有编制和预算？有的话才能考虑加人，否则只能替换现有人。
目前的总工作量是不是让团队严重超载了，除去那些可做可不做的工作外，团队是否需要高强度加班才能完成全年目标？加人是不是能提升团队产能？如果工作量严重超载，并不是一定要加人进来，可以考虑降低目标；如果不能降低目标，也要看加人是不是能提升产能，如果可以提升则可以考虑加人；如果不能提升产能，就要考虑去提升现有人的能力；
是不是找到了新的价值点，有一个很大的问题需要专门的人来解决？这个人来了之后跟其他人的分工是不是能划的清楚？如果是有新问题要解决，一般考虑新招人，但如果不能把相关的活都拆出来给到这个人，则要考虑调整现有人的职能分工，否则新人来了会施展不开拳脚，还会降低其他人的生产力。
团队中是不是有人出问题了，明显不能胜任工作？这个时候是招一个新的人替换现有人，不需要新的编制。同时也还是要从不同的维度考察这个人，即便真的要淘汰，也要做到管理留痕。
如果决定要招新人了，首先得定义清楚你想要一个什么样的人，给这个人打上标签，这样才好招。常见的通用标签有：
要一个经验丰富的还是一个初级选手？取决于你需要怎样的人才梯队。
要一个男同学还是女同学？不同性别会给团队带来不一样的力量补充。
要一个基础能力扎实（学习能力等）还是要一个领域经验丰富的？通常在市场上很难找到基础能力又扎实，又刚好做过这个工作的同学。
当时我的情况是团队非常年轻，我居然是当产品经理时间最长的人，需要一些有经验的人；团队女性比较多，需要男性力量平衡下；我个人更看重基础能力扎实的，过来之后再学习相关领域知识，关键是我在市场上也找不到做过类似产品的人。
时间线上，先是淘汰了几个在意愿和价值观上不达预期的人，换进来踏实肯干的应届生，再同时换掉了能力不及预期的人，然后补充了两个经验丰富的人。在淘汰人的过程中，都是给他们找了下家的，这些人的能力并不是非常差，只是不适合这个团队。折腾下来，花了一年多时间才组建出一个相对健康的团队。
良好的分工是提升团队生产力和个人成就感最基本的条件，如果职能重合，不仅是浪费资源，同时会打击个人积极性，因为这个活干出来的业绩有争议，还得分人一半，搁谁谁都不愿意。另外一个，团队分工并不是一成不变的，需要根据当时的目标和人手动态调整，像我自己的团队，分工职能是一个季度一调。我自己做职能分工的时候遵循以下几个原则：
每个人必须有一整块的活，这块活略微超出这个人的现有能力，可以独立考核，可以支撑这个人成长、出业绩、晋升。
每个人的分工对他的能力要求跟这个人的特点尽量匹配，具体说来这个活是要求抽象能力、架构能力，还是要求执行能力、需求分析能力，还是要求沟通协调能力 等等。
人人都能互相备份，包括大家能备份我，不存在一个活说只有一个人能干，所以至少一年会有一次大的职能调整，我每个季度侧重跟进的产品也不一样。
说实话做分工也不是一个简单的活，要求你自己对产品架构径熟烂于心，对目标的实现路很清楚，团队成员才能不被你的分工相互拖累，才能在你的分工设计下相互配合，做到+= 而不是 +<，但其实+<也是很多团队常见的现象。
由于所有产品基本上都是我都干过，对于产品非常熟悉，所以分工对于我来说不是太费劲，但也中间也出过问题，
说完招聘、分工，再说说协作。依据整个产品从需求调研到上线运营的流程，协作分为好几大块，产品内部协作、产研协作、产研测协作、产品运营协作。正常来说就按研发流程来即可，但总有一些不在正常研发流程内的场景，例如「客户反馈线上问题时，我们如何能快速解决线上问题，并及时修复缺陷」，例如「迭代日历中给的测试时间太紧张怎么办」。
这些问题都没有标准的工作流程，每个团队有他自己的行事风格，所以只能是拉上关键人讨论行得通的协作流程和职能分工，监督执行，并反复优化这个流程。
但在协作过程中有一个要注意的就是，不能偏袒产品团队，不要有屁股，要客观地看问题判责任，否则自己就会失去公信力，一单研发不认可你这个人了，之后所有的协作、协调都会变得困难。
这部分要求一丢丢专业能力和一些基本的管理方法。在工作规划方面，自己要能定清楚年度目标，拆解到季度。落地执行方面，就是通用的项目管理能力和戴明循环。这部分更多是体力活，一开始是我做好所有的规划，包括目标和落地计划，大家来执行，但是这种就调动不起大家的积极性，好像是这是我的目标，而不是组员自己的目标。后来逐渐形成一个产品规划制度，分为两大部分：
年度产品规划：
每年春节前领导和几个组长定好年度OKR，并与各级领导对齐。这些Object成为本年度我自身的考核指标，也是部门的KPI。
这里面的一部分KeyResult变为组员的Object，组员要将自身的Object拆解为下一级的KeyResult，形成组员的考核指标。
这些拆解会形成一篇总的年度OKR的文档，在做季度总结和规划时我会翻出来看一看，年度总结的时候也要对照这个文档来。
季度产品规划：
每季度的倒数第二周，我会根据年度规划+当时的情况，定好下一个的OKR，并与领导对齐，在周会上与组员同步。
每季度的倒数第一周，组员要拆自己的OKR，要写上达成KR所需的Action，并跟我来对齐。最终形成产品组的季度OKR文档，注意这个文档里只放OKR，不是工作清单，现实中每个人除了OKR（主要任务）外还会有很多杂活要干。这个周我还要做本季度的工作总结
每季度的第一周，我们单独开规划同步会，跟研发同步上季度产品建设和运营的情况，并讲解下季度的规划和工作思路，同时这一周组员还需要将工作拆解开来形成工作排期表，排期表上不仅包括OKR中的任务，还包括其他细碎的任务，需要写清楚每项工作的起止时间。
每季度的第二周，微调OKR和工作排期表。当周给隔级领导汇报上季度工作总结和本季度公祖规划。
做季度规划的前后一个月是挺累的，接下来每周就是按照工作排期表检查工作进度，辅导组员达成目标。最难的地方在于制定的OKR，在制定OKR的时候，往往会犯几种问题：
OKR写得高大上，既不定性也不定量，不可衡量
O和KR之间不是因果关系，达成KR并不会达成O
KR个数太多，外加一堆Action，根本做不完，实质是没找到关键KR
在制定OKR的时候，我常问组员几个灵魂问题：
现在的KR描述地太泛了，你这个词指的是什么？你要做的是A还是B还是C？
你觉得拿到这些KR，O就能达成了吗？
这个指标的统计口径是什么，现在已经有数了吗？怎么才能统计出来？
怎么考核你这个KR达成没有，拿到什么结果我该给你打A？
另外说一点我对OKR的理解，整个部门的O可以是一个方向性的O，是一个比较虚的O，然后用KR来衡量O实现没有，而且不同的阶段可以从不同的维度用不同的指标来衡量O，所以KR必须是非常具体的一些阶段性成果。
然后还有一些日常管理工作，像组员积极性建设、组员能力培养、协调资源、解决协作问题 等等，这个我是看了本工具书《人以下小团队管理手册》来速成的，只要认知上知道自己该干些啥，思想和身体上不偷懒，运气不要太差遇上奇葩选手，日常管理可能累，但并不难。
解决了上面的三座大山之后，一个团队差不多就可以跑起来了，可以持续地去为组织创造价值，但是并不代表这个团队就是一个积极的、正能量的、欣欣向荣的团队。
事实上整个年我都过的挺累的，一个是所有东西都要从到，另一个是我既要做一些管理的事情又要当一线的大头兵，所以每天都把自己折腾的很累，好像这个组好像离了我可能业绩就达不成了似的（其实地球离了谁都照样转），总是不放心。
现在反过头来看，虽然当时我把组员之间的职能分工定义的很清晰，但是我个人跟组员之间的职能边界却不清晰。对于该干什么不该干什么，该干到什么程度都把握不好。
年年底我们产品内部开了一个复盘会，思考过去一年内为什么会有这么多的协作问题、有这么多矛盾隐藏了很久才爆发出来，最后得出来的结论是我们产品组开的会太少了，以至于没法及时让上下级和平级都认识到一些问题的存在。想必大家看到这里也会笑了，一般都是觉得各种会太多了，但我们组的人一致认为会开的太少了。
其实这是我个人风格导致的直接结果。我个人是非常不喜欢开会的，总归是绝大部分会的效率都非常低，漫无目的的讨论简直浪费生命，所以我基本上从来都不开会，有什么事情就直接找我，我能解决的话绝不墨迹推脱。最直接的一个结果就是我们产品组一整年基本上都没开过组会，我都是通过周报或者私底下的沟通来了解大家的工作进度，组员就没有一个合适的渠道来去给我反馈日常问题。
但是我又不想开一个干巴巴的组会，传统的组会就是每个人汇报自己这周的工作进度，然后领导讲一讲问题。我在网上也看了很多开组会的方法，我把自己当一个普通员工去感受这个整个组会，就感觉满满的都是上级的压力、非常不开心，久而久之这样的组会就会变成“一言堂”——只有领导在那发言，组员都不乐意发言。组会气氛沉闷、成员普遍觉得与自己没大关系，这也是事实上绝大部分组会的现状。
当时我面临的问题一个核心问题——组员的专业能力不足导致业绩、产品效果总不达预期。之前设立了季度学习制度，每一季度一个学习主题，月底轮流分享学习成果，这个制度最后执行地很差，大家普遍没花额外的时间去学习总结。所以我把「专业能力提升」和「横向信息拉通」作为组会的两个核心目标，逐渐形成了一下组会模式：
组会之前，每个人不用花时间去准备长篇大论的汇报材料的，轻松参会就行，每个人轮流做会议纪要。
组会上大家不用汇报工作进度，工作进度在组会之后以简报的形式发在群里。
组会的第一趴是我来分享一些横向的信息，比如说「最近公司的营收很大，咱们要多多支持创收的需求」，比如说「到了，研发要备战，大家可用的研发资源实际上是比上个季度要少的，可以侧重做一些运营工作」。这个期间大家其实会简单的讨论一下这些大的环境的变化对于自身工作的影响、如何调整工作节奏和优先级，整体持续大概分钟。
组会的第二趴是大家提问，主要是需要我知道的重要的外部信息、需要我支持的地方、需要我帮忙解决的问题，比如说「跟业务的目标对不齐，需要我去找业务负责人对齐目标」，比如说「有个内部客户期望购买我们的产品，有什么要注意的」。一部分问题我会当场解答，另一部分问题会留给我的待办，期间也会有简单的讨论，整个过程持续约分钟。
组会的第三趴是个人工作分享，事先我会指定一两个同学分享近期的工作成果，比如说「产品的市场调研报告」，比如说「产品商业化计划」，一般是讲分钟，然后大家点评、讨论，这个过程中，我会顺势指定一下下一次的分享人。整体持续分钟左右。
组会之后，会议纪要发给所有的产品和研发，要求研发侧按照会纪要中的内容配合我们工作。
这种组会形式，对于我个人而言，有个好处：
通过工作分享大家共同点评的方式减轻了我作为监督者的工作量
自然而然地给到分享者适度的工作压力，并且是定期给到压力
自然而然让每个人都能相互了解彼此的工作，一个目标的实现不再只是某个人的事，大家群策群力
对于组员而言，也是有个好处：
不用光听我一个人说，自在~
每周顺便学点别的领域知识，省事~
同时可以过一把点评者的瘾，开心~
整个组会的气氛是比较好的，经常会有人笑出声。目前存在的问题还是我说的太多了，后来设了一个规矩，只要我说话连续超过三分钟，任何人都可以打断我。之后还要继续改良组会的模式，尽量让大家说的多一些，相互促进，我就做一个服务大家的角色就好了。
这种组会模式对于管理者的要求其实是比较高的，要求管理者了解每一件事情的推进的方式、进度，这样才能做到组会上不汇报工作细节而是直接讲问题。因此这种模式应该也只适用于~个人的小团队，管理者直线管理所有人。人再多一些的话，管理者几乎不可能做到了解每一件事情的进度，肯定是要依靠再下一级的小组长来管理好整个团队的。
一年之际在于春，一周之际在于周一，周一是我一周中最累的一天。由于组会上大家没有汇报工作进度，所以我肯定还是要另找机会跟大家对齐工作的思路的，确保一周过后我们能拿到一些确定性的结果。所以每个周一我会对照整个季度大家的工作排期表，逐项检查工作的进度，然后找到对应的人，去让他给我讲拿这个结果的思路、风险、需要沟通的人，需要协调的部门，再给他纠偏。找所有人逐个对过思路和进度之后，我会规划一下自己这周的要做的事情，形成一个待办清单。再遇上老板找我、紧急需求、临时会议，这一天基本上就从早忙到晚、精疲力尽。
周二周三周四就相对轻松，%的时间用来支持组员工作，%可以用来干自己的事，去思考未来要解决的关键问题和问题的解法、做产品规划、做横向的项目、了解行业咨询等等。周五一天就是各种会（PRD评审会、组会）+ 写周报。
周六日是学习+放松。一般周六上午会看混沌学园的直播课，周日花两个小时针对性地补一些知识，例如新做的项目有知识盲区、老板推荐的好书、文案OR心理学等产品经理的基本技能。剩下的时间都是放松——打球、唱歌、聚餐、看剧、尝试新菜谱。
比起之前的状态来说，还是要好很多的。之前自己很焦虑，工作没有规划和节奏，每天都事无巨细折腾自己，一发现问题就会找组员聊，搞得组员不清楚问题的轻重缓急、作没有节奏感，并且周六日还难以避免地要加班来完结大大小小的事。现在就是周一忙一天，后面就比较轻松，也能腾出时间来做一些有挑战性的事，你好我好大家好。大家都知道我有一个”九阴神功“工作本，每周占一页纸，这页纸上有三个部分：
第一部分是我这一周的待办事项清单，一般会有七八条，再多我也干不完。这个待办清单由两部分组成，一部分是上周组会留给我的待办，一部分是我自己规划这周要做的事情。
第二部分是产品组会上我要同步的信息，这些信息是在我这一周工作过程中记下来的，一般会有三四条。
第三部分是我要在产研组会上同步的信息，也是一周工作过程中总结出来的，一般涉及到协作问题、工作方向和策略。
这一周其实就是一个小的戴明循环PDCA。周一是做计划Plan，周二到周四是执行Do，周五的组会就是check，周会上的待办项其实就是改进措施Act。这个戴明循环逐渐转起来之后，自己的状态就会逐渐由筋疲力尽变为忙而不累，同时团队成员反而比之前更投入工作。但这种工作方法也要求自己要做到周事周清，不拖延，保持一贯适中的工作强度。我也有emo状态不好的时候，一般当周就少干点自己的事，绝不会拖延团队需要我干的事，不拖累团队。
周一到周日有时候会失眠，这种情况下我一般跑到客厅看书催眠，随机地读一些书。总的下来看书的进度是一个月一本，强度并不大，但贵在坚持。自我感觉读书的一个特点是转化率特别高，虽然书看得不多，但大多数能记下来，能用起来，有时还会给其他人讲。
日常避免不了需要指导组员工作，一开始别人问我他的产出物有什么问题没有，我一般都会把很多具体的问题指出来，并告诉他们更好的做法是什么，但久而久之就会发现组员越来越依赖于你，什么事都等着你做决定，甚至当方案最终出了问题时，组员会说「这是你说的要这么干的呀」，那个时刻就感觉很无奈。
后来就觉得肯定是自己出问题了，就去看书，去想到底是哪里出了问题。有一天是看短视频就突然开窍了，别问我为什么，有时候就是两件看似毫不相干的问题之间能相互启发。所谓授人以鱼不如授人以渔，我之前就是直接告诉别人正确的做法，是「鱼」，那什么是「渔」呢。思索良久后，恍然大悟，「渔」就是做事好坏的衡量标准，我的做法在这个衡量标准下是一个好的做法，但在这个衡量标准下可能也有其他好的做法。所以如果我能把衡量的标准总结出来，那么只要组员的产出物在这个标准之上，就是好的产出物。
再后来就开始持续地总结不同产出物的衡量标准：例如PRD，什么样的PRD是一个好的PRD，我就把PRD的组成部分，注意事项，优秀PRD案例总结出来，之后再让我看PRD，我会先问符不符合这个标准，复合之后我再给你看具体的业务问题。具体一点的，例如说做宣传海报，有宣传目的、明确目标人群、明确想传达的信息点、找个人看海报能GET到这些点、海报上有转化用户的外链，那么这个海报就是个好海报。
总结这些标准的过程是痛苦的，有时候会发现自己的专业水平也是有短板的，并不能一下子说出什么样的才算好的。所以这一整套下来，也倒逼自己进一步提升了专业能力。
实行了一段时间「授人以渔」后，明显感觉大家的投入程度上来了，对自己的要求高了，会做出一些你意想不到的惊喜。其实再想一想，也确实是这个道理。之前大家其实很懵的，不知道为什么按我那样做就是好的，相当于被束缚者了。当他们知道标准后，我不再限制达成目的方式，创造活力被激发了，他们自然而然会找到最适合他们自己的前进之路，整个组也走向一个良性循环。
最后，谈谈自己对管理这门学问总的一个感受。我在这方面应该还是刚刚入门，但按网传「没开过个人根本不算会做管理」，我也依然是个弟弟。
在初级管理者被赋予的这些职能里，「定义团队价值和目标」是最不容易胜任的，这要求的是管理者有”不一样“的「认知能力」，而这个能力又是无法速成的，确实需要经验、视野、思考，只能靠自己日积月累，且有玄学；目标落地和团队建设等其他职能，个人感觉只要真心实意带团队、不偷懒去实践最基本的管理方法，是可以在半年内速成的。
当然，如果是带一个上千人的团队，管理者还会有稳定团队、传承文化等更抽象的职能，又会有一些玄学，但这已经是中高级管理者考虑的事了，是另外一说。
以下推荐一些好书和课程，希望能帮到跟我一样的”小组长“，如果其他好书，也欢迎大家推荐给我。
人以下小团队管理手册： 这本书的内容篇幅并不多，天就可读完，里面都是最基本的管理理论，日常管理过程中几乎全会用上，个人认为这个就是初级管理者的工具书，必读且需常常温习，市面上很多初级管理者培训营的培训内容也不会超越这本书，非常实用。
场域领导力-关系视角下的高绩效团队打造： 这本书的篇幅也是天就可读完，但就有点玄学，是从 性格和心理上来讲解不同类型的组员对于团队的影响，但也算是管理者的基本知识了，组建团队的时候一定是需要知道自己团队缺什么样的人。
极简工作法：对常用的工作方法做了个介绍，例如「清单工作法」「番茄工作法」，所有职场人都应该掌握这些方法，
混沌学园 – 人力资源工程是CEO的第一工程：这个课可以帮助建立最基本的人力资源的概念，我个人非常受用，反复听了几遍。混沌学园里面的课程都是讲认知、哲学、创新的，专为企业用户打造，每周都更新课程，学费多一年，并不便宜，内容偏玄学，建议高级产品经理和管理者看。个人最喜欢的是其中认知思维和理论与商业案例结合的课程，可以很直观的感受到认知理论是如何应用于实际工作的。
