<commit_before>---

layout: post
title: 尝试带好一个小团队
category: 生活
tags: Life
keywords: technology manage

---

## 简介

## 认知上

[十年技术老兵总结的自我修炼之路](https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2651009003&idx=2&sn=9c48e19c584d7deacb4cdfa72ad31a05&chksm=bdbed7b88ac95eae78539cdf0201133c5dc51e49dba036f4787d9c624aeab32e84a492be415e&mpshare=1&scene=23&srcid=0904sCU1C4mt5FODn2JRNPL9%23rd)

![](/public/upload/life/technology_manage_1.png)



[技术管理到底管什么](https://mp.weixin.qq.com/s/QN1OKEFT3DiA82-OAp858Q)

1. 无论是春秋战国时候的丞相，还是三国时候的谋士们，技能大概分成两种：谋略和理事。谋略重在想办法，理事重在做事情。但凡有名的丞相谋士至少有一样特长，两者兼顾的自然是不世功勋唾手而来。

	* 谋略：技术架构搭建、新技术演进选型等，解决该做什么和怎么做的问题。
	* 理事：任务和人员协调、分配等，解决谁来做、哪件事先做的问题。

	把握好谋略和理事这两条，技术管理才能真正落地，团队战斗力才能真正体现出来。
	
2. 我们的目的应该是把事情做好，管人只是一种方式而已。以代码规范为例，最好的方式是，通过技术手段去保证，不按照规范去做的代码没法提交成功；次好的方式是，建立规范准则，要求大家去遵守；最坏的方式是，质问和批评为什么不这么做。不要轻易尝试去改变一个人，哪怕你是为他好，哪怕改的是缺点对他也有好处。

3. **管理者不应该是职级层面的上级，而应该是分工层面的决策和协调者。**
4. 觉得不写代码会心慌的人，说明你把太多精力花在理事上了，谋略给丢了。实际上，在技术架构满足不了业务增长需求的时候，是需要你（和你的架构师一起）去拿出新的架构的；组员讨论几个方案拿不定主意的时候，也是需要你去做决策的。这些都是需要你平时花时间去不断丰富和充实你的技术的。否则一定是一将无能累死三军。
4. 你并不应该陷入与人沟通和处理杂事的漩涡中，而是应该抽时间出来保持自己的技术敏感度。**管理者和普通员工在技术上的区别，在于和技术打交道的方式变了。普通员工是写代码，技术管理者应该是学习技术和思考架构。**

[技术的成长曲线](http://zhangtielei.com/posts/blog-growth-curve.html)熟手：技术还无法自成体系，能理解到的知识架构还有所残缺。他解决问题所依靠的，更多是经验而非缜密的逻辑。而从熟手向专家的突破，则需要系统地去补习知识架构。**技巧应该建立在对于普遍规则的理解之上.**

陈皓《左耳听风》降到技术领导力时提到

1. 能够发现问题
2. 能够提供解决问题的思路和方案，并能比较这些方案的优缺点
3. 能够做正确的技术决定
4. 能够用更优雅、简单、容易的方式来解决问题
5. 能够提高代码或软件的扩展性、重用性和可维护性
6. 能够用正确的方式管理团队

	* 让正确的人做正确的事儿
	* 提高团队的生产力和人效，找到最有价值的需求，用最少的成本实现之
7. 创新能力

这个顺序也基本指出了技术人的成长路径。那么如何选择自己的人身与职业发展呢？

1. 客观的审视自己。在职场上，审视自己的最佳方式就是隔三差五的出去面试一把，看看自己在市场上能够到什么样的级别
2. 确定自己想要什么
3. 注重长期的可能性，多经历、多去选择
4. 不要和大众的思维方式一样

很多事情能做到什么程度，其实在思想的源头就被决定了，因为它会绝大程度的受思考问题的出发点、思维方式、格局观、价值观等因素影响，这才是最本源的东西。

个人感觉程序猿水平晋级 跟玩户外是一样的

1. 只是参与出去玩，但事儿多
2. 出去玩，自己管自己
3. 出去玩，主动地做点事儿
4. 当押队，交代事情做
5. 当副队，是个可以商量的人，能全面考虑事情，给出建议
6. 当领队，独自筹划大部分事情
7. 不错的领队


## 心态上

到今年7月份就工作3年了，回过头看过去3年，再看以后，有哪些脉络和教训。

1. 第一个坎，从学生到工作的转变。第二个坎，不用带脑子也能完成一天的工作（成了一个熟手）。那么下一步怎么搞？
1. 头三年是锻炼基本能力的三年。说白了就是单兵能力的提升

	* 基本工作组件（语言、存储）的熟悉，以能实现编码任务
	* 技术依赖组件的熟悉，以使故障时能够发现原因
	* 源码阅读及分析
	* 对程序开发有个宏观认识

2. 那么以后呢？要做成更大的系统，一定是调动多个人的力量。要做成更大的项目，一定是团结多个团队的力量。为此

	* 做好心理上的准备。作为技术人，难免觉得技术才是最牛逼的。技术，更确切的是写代码，并不是难度最大的事情。但你敢这么说的 前提一定是 你基础比较扎实

3. 自己成为驱动的源头，驱动人，驱动事儿。做驱动，心理上的准备也是很重要的，“这事儿该不该我做” 是一个很费心神的问题。

	* 有一次跟一个工作十几年的大牛交流， 大牛说我工作这么多年，只有一次，就是那个人我跟着他干就行，做什么项目都可以。大部分时候你的身边找不到这样的角色， 那你就要勇于承担这样的角色。
	* 做好驱动的一个必要条件是，能从琐碎中脱身。一个是人的注意力有限，注意好琐碎就管不好大局。一个是人都有逃避心理，比如我负责一个项目，就很烦那个项目了。
	* 业余时间充电。这里有两点，要记得充电，要用业余时间充电。

你必须要接受，本来你可以十分钟干完的事儿，别人要干两个小时。你设计的很有美感的代码 被破坏殆尽。但该他负责的事情还是要他去做，否则他没有参与感，永远无法主动地做工作。很多事情你做了其实没有成长，但还是要带着别人一起做，帮助别人成长也是你工作的一部分。

曾经的一个困惑：“我知道很多事儿要干，但我不知道精力投向哪里”。迷茫，就是对当前的处境没有成体系化的认识，要多人交流， 整理，发现规律，指导实践。

要兼容不同的人，有的很有想法但落地能力不够，有的想法较少但好在认真负责 等等，不以自己认为的优缺点去套别人。

## 项目设计原则

[写给工程师的十条精进原则](https://tech.meituan.com/10_principles_for_engineers.html)

1. 设计优先，比如 开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。对应的，必须有n个xx级别以上的工程师参与讨论。
2. 设计的过程是一种智力上的创造，我们更希望它能成为个人与集体智慧的结晶。如何才能让我们的设计变得通俗易懂？我个人认为，设计应该尽量使用比较合理的逻辑，进而把设计中的一些点组织起来。比如可以使用从抽象到具体，由总到分的结构来组织材料。在设计过程中，**要以需求为出发点，**通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。
3. “P/PC平衡”原则，即产出与产能平衡原则。伊索寓言中讲述了一个《生金蛋的鹅》的故事。产出好比“金蛋”，产能好比“会下金蛋的鹅”。“重蛋轻鹅”的人，最终可能连产蛋的资产都保不住；“重鹅轻蛋”的人，最终可能会被饿死。产出与产能必须平衡，才能达到真正的高效能。**从系统的角度看，每一个系统都是通过持续不断地叠加功能来实现其产出，而系统的产能是通过系统架构的可扩展性、稳定性等一系列特性来表征。为了达到产出与产能的平衡，需要在不断支持业务需求的过程中，持续进行技术架构层面的优化。**“P/PC平衡”原则还适用于很多其他的领域，例如团队、家庭等
4. 波克定理告诉我们，只有在争辩中，才可能诞生最好的主意和最好的决定。

高噪声背景下提取有效信息的能力

## 工具集

善于利用工具、日程管理、任务管理，番茄工作法等。

分层无处不在，不要让一个函数 里出现不同抽象层次的代码，另一个角度说， 很多时候脑子乱也是如此。人的脑容量有限，一时思考不了过多维度的事情。所以要借助 日程管理、任务管理、表格 等归纳整理

实现一个新的业务系统，理解业务，提出抽象概念 ，定义概念和名词很重要，将几个小步骤 用一个词语 归纳很重要，可以有效的降低沟通成本。

### 分阶段管理项目

假设你同时负责几个项目，但不同的项目所处的状态是不一样的。比如策划阶段 ==> 调研阶段 ==> 设计阶段 ==> 实施阶段 ==> 维护阶段。

1. 策划和调研阶段，因为太模糊了，可能要独立完成
2. 设计阶段带着小伙伴一起做（业务架构图、类图、流程图、Swagger、数据库表设计等）
3. 实施阶段 每天检查下小伙伴的产出，确保没有跑偏即可
4. 维护阶段可以交给小伙伴，提取新的需求 进入新的循环

如果所有阶段的所有事儿 都需要你去做，那么一定有问题。如果一直如此，你可能不是纠结自己做什么，而是要换个人合作。

当你有了一定的人力资源之后，你解决问题的工具集不能  只有一个：一有问题自己上。 这个项目目前在什么阶段？最大的瓶颈在哪里？是否需要你直接参与？想好了再行动。

管住头尾，项目刚开始的时候都是很模糊的，这时候要你帮他明确目标，明确产出，并去校验那个产出。养成依靠工具的习惯，比如teambition。同时，形成一套自己的表格。

形成一套成体系的表格，进而决定轻重缓急，从哪切入、推动。我后来会在周报中整理表格体现这些内容，既用于汇报工作，也时刻提醒自己。

||所处阶段|本周产出/进展|瓶颈/问题|切入点/办法|
|---|---|---|---|---|
|项目1|开发|下周转入测试|暂无||
|项目2|维护|无|暂无|code review|
|项目3|维护|明确xx为负责人|依赖资源不到位|组织各个大佬开会|
|项目4|调研|整理文档以备开会|需求不明|开会|
|项目5|开发|无|当前算法难以支持高并发|小组讨论|

### 熟悉小伙伴

||主动性|技术能力|认真负责|项目熟悉程度、兴趣程度|
|---|---|---|---|---|
|小伙伴1|||||
|小伙伴2|||||

你如何画这个表格，本身就体现了你对这事儿的认识。
<commit_msg>[fix]add post<commit_after>---

layout: post
title: 尝试带好一个小团队
category: 生活
tags: Life
keywords: technology manage

---

## 简介

## 认知上

[十年技术老兵总结的自我修炼之路](https://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2651009003&idx=2&sn=9c48e19c584d7deacb4cdfa72ad31a05&chksm=bdbed7b88ac95eae78539cdf0201133c5dc51e49dba036f4787d9c624aeab32e84a492be415e&mpshare=1&scene=23&srcid=0904sCU1C4mt5FODn2JRNPL9%23rd)

![](/public/upload/life/technology_manage_1.png)



[技术管理到底管什么](https://mp.weixin.qq.com/s/QN1OKEFT3DiA82-OAp858Q)

1. 无论是春秋战国时候的丞相，还是三国时候的谋士们，技能大概分成两种：谋略和理事。谋略重在想办法，理事重在做事情。但凡有名的丞相谋士至少有一样特长，两者兼顾的自然是不世功勋唾手而来。

	* 谋略：技术架构搭建、新技术演进选型等，解决该做什么和怎么做的问题。
	* 理事：任务和人员协调、分配等，解决谁来做、哪件事先做的问题。

	把握好谋略和理事这两条，技术管理才能真正落地，团队战斗力才能真正体现出来。
	
2. 我们的目的应该是把事情做好，管人只是一种方式而已。以代码规范为例，最好的方式是，通过技术手段去保证，不按照规范去做的代码没法提交成功；次好的方式是，建立规范准则，要求大家去遵守；最坏的方式是，质问和批评为什么不这么做。不要轻易尝试去改变一个人，哪怕你是为他好，哪怕改的是缺点对他也有好处。

3. **管理者不应该是职级层面的上级，而应该是分工层面的决策和协调者。**
4. 觉得不写代码会心慌的人，说明你把太多精力花在理事上了，谋略给丢了。实际上，在技术架构满足不了业务增长需求的时候，是需要你（和你的架构师一起）去拿出新的架构的；组员讨论几个方案拿不定主意的时候，也是需要你去做决策的。这些都是需要你平时花时间去不断丰富和充实你的技术的。否则一定是一将无能累死三军。
4. 你并不应该陷入与人沟通和处理杂事的漩涡中，而是应该抽时间出来保持自己的技术敏感度。**管理者和普通员工在技术上的区别，在于和技术打交道的方式变了。普通员工是写代码，技术管理者应该是学习技术和思考架构。**

[技术的成长曲线](http://zhangtielei.com/posts/blog-growth-curve.html)熟手：技术还无法自成体系，能理解到的知识架构还有所残缺。他解决问题所依靠的，更多是经验而非缜密的逻辑。而从熟手向专家的突破，则需要系统地去补习知识架构。**技巧应该建立在对于普遍规则的理解之上.**

陈皓《左耳听风》降到技术领导力时提到

1. 能够发现问题
2. 能够提供解决问题的思路和方案，并能比较这些方案的优缺点
3. 能够做正确的技术决定
4. 能够用更优雅、简单、容易的方式来解决问题
5. 能够提高代码或软件的扩展性、重用性和可维护性
6. 能够用正确的方式管理团队

	* 让正确的人做正确的事儿
	* 提高团队的生产力和人效，找到最有价值的需求，用最少的成本实现之
7. 创新能力

这个顺序也基本指出了技术人的成长路径。那么如何选择自己的人身与职业发展呢？

1. 客观的审视自己。在职场上，审视自己的最佳方式就是隔三差五的出去面试一把，看看自己在市场上能够到什么样的级别
2. 确定自己想要什么
3. 注重长期的可能性，多经历、多去选择
4. 不要和大众的思维方式一样

很多事情能做到什么程度，其实在思想的源头就被决定了，因为它会绝大程度的受思考问题的出发点、思维方式、格局观、价值观等因素影响，这才是最本源的东西。

个人感觉程序猿水平晋级 跟玩户外是一样的

1. 只是参与出去玩，但事儿多
2. 出去玩，自己管自己
3. 出去玩，主动地做点事儿
4. 当押队，交代事情做
5. 当副队，是个可以商量的人，能全面考虑事情，给出建议
6. 当领队，独自筹划大部分事情
7. 不错的领队


## 心态上

到今年7月份就工作3年了，回过头看过去3年，再看以后，有哪些脉络和教训。

1. 第一个坎，从学生到工作的转变。第二个坎，不用带脑子也能完成一天的工作（成了一个熟手）。那么下一步怎么搞？
1. 头三年是锻炼基本能力的三年。说白了就是单兵能力的提升

	* 基本工作组件（语言、存储）的熟悉，以能实现编码任务
	* 技术依赖组件的熟悉，以使故障时能够发现原因
	* 源码阅读及分析
	* 对程序开发有个宏观认识

2. 那么以后呢？要做成更大的系统，一定是调动多个人的力量。要做成更大的项目，一定是团结多个团队的力量。为此

	* 做好心理上的准备。作为技术人，难免觉得技术才是最牛逼的。技术，更确切的是写代码，并不是难度最大的事情。但你敢这么说的 前提一定是 你基础比较扎实

3. 自己成为驱动的源头，驱动人，驱动事儿。做驱动，心理上的准备也是很重要的，“这事儿该不该我做” 是一个很费心神的问题。

	* 有一次跟一个工作十几年的大牛交流， 大牛说我工作这么多年，只有一次，就是那个人我跟着他干就行，做什么项目都可以。大部分时候你的身边找不到这样的角色， 那你就要勇于承担这样的角色。
	* 做好驱动的一个必要条件是，能从琐碎中脱身。一个是人的注意力有限，注意好琐碎就管不好大局。一个是人都有逃避心理，比如我负责一个项目，就很烦那个项目了。
	* 业余时间充电。这里有两点，要记得充电，要用业余时间充电。

你必须要接受，本来你可以十分钟干完的事儿，别人要干两个小时。你设计的很有美感的代码 被破坏殆尽。但该他负责的事情还是要他去做，否则他没有参与感，永远无法主动地做工作。很多事情你做了其实没有成长，但还是要带着别人一起做，帮助别人成长也是你工作的一部分。

曾经的一个困惑：“我知道很多事儿要干，但我不知道精力投向哪里”。迷茫，就是对当前的处境没有成体系化的认识，要多人交流， 整理，发现规律，指导实践。

要兼容不同的人，有的很有想法但落地能力不够，有的想法较少但好在认真负责 等等，不以自己认为的优缺点去套别人。

## 原则上

[写给工程师的十条精进原则](https://tech.meituan.com/10_principles_for_engineers.html)

1. 设计优先，比如 开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。对应的，必须有n个xx级别以上的工程师参与讨论。
2. 设计的过程是一种智力上的创造，我们更希望它能成为个人与集体智慧的结晶。如何才能让我们的设计变得通俗易懂？我个人认为，设计应该尽量使用比较合理的逻辑，进而把设计中的一些点组织起来。比如可以使用从抽象到具体，由总到分的结构来组织材料。在设计过程中，**要以需求为出发点，**通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。
3. “P/PC平衡”原则，即产出与产能平衡原则。伊索寓言中讲述了一个《生金蛋的鹅》的故事。产出好比“金蛋”，产能好比“会下金蛋的鹅”。“重蛋轻鹅”的人，最终可能连产蛋的资产都保不住；“重鹅轻蛋”的人，最终可能会被饿死。产出与产能必须平衡，才能达到真正的高效能。**从系统的角度看，每一个系统都是通过持续不断地叠加功能来实现其产出，而系统的产能是通过系统架构的可扩展性、稳定性等一系列特性来表征。为了达到产出与产能的平衡，需要在不断支持业务需求的过程中，持续进行技术架构层面的优化。**“P/PC平衡”原则还适用于很多其他的领域，例如团队、家庭等
4. 波克定理告诉我们，只有在争辩中，才可能诞生最好的主意和最好的决定。

高噪声背景下提取有效信息的能力

管住头尾，项目刚开始的时候都是很模糊的，这时候要你帮小伙伴明确目标，明确产出，并去校验那个产出。

## 工具集

善于利用工具、日程管理、任务管理，番茄工作法等。

分层无处不在，不要让一个函数 里出现不同抽象层次的代码，另一个角度说， 很多时候脑子乱也是如此。人的脑容量有限，一时思考不了过多维度的事情。所以要借助 日程管理、任务管理、表格 等归纳整理

实现一个新的业务系统，理解业务，提出抽象概念 ，定义概念和名词很重要，将几个小步骤 用一个词语 归纳很重要，可以有效的降低沟通成本。

### 分阶段管理项目

假设你同时负责几个项目，但不同的项目所处的状态是不一样的。比如策划阶段 ==> 调研阶段 ==> 设计阶段 ==> 实施阶段 ==> 维护阶段。

1. 策划和调研阶段，因为太模糊了，可能要独立完成
2. 设计阶段带着小伙伴一起做（业务架构图、类图、流程图、Swagger、数据库表设计等）
3. 实施阶段 每天检查下小伙伴的产出，确保没有跑偏即可
4. 维护阶段可以交给小伙伴，提取新的需求 进入新的循环

如果所有阶段的所有事儿 都需要你去做，那么一定有问题。如果一直如此，你可能不是纠结自己做什么，而是要换个人合作。

**当你有了一定的人力资源之后，你解决问题的工具集不能  只有一个：一有问题自己上。** 这个项目目前在什么阶段？最大的瓶颈在哪里？是否需要你直接参与？想好了再行动。

形成一套成体系的表格，进而决定轻重缓急，从哪切入、推动。我后来会在周报中整理表格体现这些内容，既用于汇报工作，也时刻提醒自己。

||所处阶段|本周产出/进展|瓶颈/问题|切入点/办法|
|---|---|---|---|---|
|项目1|开发|下周转入测试|暂无||
|项目2|维护|无|暂无|code review|
|项目3|维护|明确xx为负责人|依赖资源不到位|组织各个大佬开会|
|项目4|调研|整理文档以备开会|需求不明|开会|
|项目5|开发|无|当前算法难以支持高并发|小组讨论|

### 熟悉小伙伴

||主动性|技术能力|认真负责|项目熟悉程度、兴趣程度|
|---|---|---|---|---|
|小伙伴1|||||
|小伙伴2|||||

你如何画这个表格，本身就体现了你对这事儿的认识。

{'fraction_non_alphanumeric': 0.13039049235993208, 'fraction_numerical': 0.03259762308998302, 'mean_word_length': 11.038147138964577, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 11, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6122705', 'n_tokens_mistral': 8619, 'n_tokens_neox': 10130, 'n_words': 323}