团队分工

以前写过初探技术管理(3)-团队建设，23年又总结了一次对管理的一些思考，其中有团队分工内容。

## 团队分工

分工是手段，是为了让大家更好的协作，最终能够办成大事。

### 分工原则

- 分工需清晰：任何不以分工清晰为前提的边界模糊化，结果都会事与愿违。
- 分工需稳定：因为只有稳定的分工才能体现出分工的价值。

书内信息简略，需实际操作体会。有点像《论语》里说的“夫子之文章，可得而闻也；夫子之言性与天道，不可得而闻也。”

为什么分工

无论是大团队还是小团队，负责的内容往往包含很多模块。做好分工能够实现

1. 有负责的人：当有需求和问题时，分工可明确责任人，避免模糊。如 “三个和尚” 故事能很好的解释这种情况。
2. 有提升的人：负责人专注模块，知优缺点并提升，同时提升自己。
3. 有归属的人：负责某个模块的感觉对我而言像是独立打拼的人有房子了，会有归属感，影响力随专项负责提升。

另外随着业务的发展，我们需要重新分工。

1. 负责模块增加，旧设计可能不合理
2. 成员新鲜感降低，重新划分带来新挑战。一般一年内至少盘一下重新分工
3. 一个人虽然有主负责的模块，但因为人力问题，很可能负责了别人的模块，时间一长，分工会出现模糊的情况，重新分工有助于帮大家重新画好范围

影响因素

影响分工的一些核心因素

1. 工作内容：总共负责哪些模块，这些模块范围有多大？有哪些是长期有的，有哪些是未来能发展出来的（和产品确认、自己盘算），有哪些可能被吃掉的
2. 人员数量：团队成员一共几人？要是只有一个，也无需分工了
3. 人员梯队：团队里是否有比较好的梯队，如高级工程师和初级工程师比例是否合理，还是都是初级工程师；这些工程师是否对项目很熟悉，还是刚组的团队大家对工作内容不熟悉

分工原则

1. 高内聚、低耦合：模块独立，非大型需求负责人可独立完成。
2. 工作量需要相当：各个同学负责的模块，避免模块工作量差异大，会让活多和活少的同学都不开心
3. 明确负责模块：指定清晰负责的任务，做好内部宣贯

这里有一个误区，我只负责自己模块，不是我的模块不要找我了。

• 如果+1不是同一个人，这种做法是合适的，毕竟有不同团队的概念
• 如果是同一个团队内部进行了分工，这个团队已经是最小的组织单位，承接具体的需求，那还是有可能要做一下别的模块的。一是因为人力有限，主负责的同学还没有从别的需求出来，二是团队内部也需要大家对别人的模块有所了解

分工过程

进行分工切记空想，要动起来，要写写画画，只靠空想很难把所有因素组合起来，除非有最强大脑。

架构图绘制

首先需要画出架构图，可以参考对画架构图的一些思考、如何画出优秀的软件系统架构图？。

如果到了给团队分工的职级，应该能够很清晰的知道有哪些模块、模块之间的关系是怎样的。可以按层划分，展示层、访问控制层、服务层、存储层、质量层等，类似这种，

架构图分析

根据架构图

• 首先分析哪些模块是聚合在一起的，分成一块块。
• 然后判断这块的工作范围是多大，分工到具体的同学，需要确保这块工作的范围是单人能够完全掌握的。如果觉得范围太大，一个人掌握不了，那就应该再进行细化，重新进行聚合，继续分工。这时候就是二级结构了，有的同学负责模块的一部分，高级工程师需要把控整个模块。

划分方式

划分方式有横向划分和竖向划分，一般推荐竖向划分。

横向划分：类似于商品服务的商品发布分给一个同学、上架/下架分给一个同学。这种情况一般用于产品开发早期，模块较少、人员相对充裕、产品形态没有完全确定的情况，让每个人有负责的point。这种方式缺点很明显，不内聚，往往一个需求需要把商品发布和上下架都修改。

竖向划分：商品服务分给一个同学、支付服务分给一个同学，服务对应的展示、运营后台等都归对应的同学负责。竖向划分就更加内聚了，而且这种分工无论对内对外都很清晰。当然商品服务可以分给多个同学，每个人都需要完全掌握这个服务也是可以的。