# 分享一些技术管理上的心得
背景：公司最近一年来技术团队扩招，技术人员多了，需要提拔一批骨干作为基层的技术管理人员。目前我所在的部门已经有23位开发人员了，如果让我的leader直接管理这么多人，显然是不现实的。所以把这23人，分成3小组。我负责其中的开发2组，包括我7个后端开发工程师，工作经验均在1到7年。我们小组主要负责用户、营销、内容、分佣、直播等支撑领域的微服务开发。为了让我们这些储备leader更好的上手技术管理，公司请了专业的讲师，开展了一个为期4个月、每周二集中学习的的技术管理培训《技术管理实战36讲》。有感而发，整理一下我的一些经验、体会。
技术管理总的来说，就三块：带人、做事、看方向。
# 带人
# 团队里需要怎么样的人？
团队需要有梯度，要有各种经验、能力的工程师组成。这是对于成本、成员的积极性、成长性作出的考量。
一般难度的业务系统的开发，高（5年以上）、中（3年左右）、初（1年左右）级的工程师配比是1:3:3或2:3:2。
除了技术、经验外，韧性、积极性、沟通能力、解决问题的能力也非常重要。
# 对每个人、每件事，我应该如何管理？
这问题实际上是管理风格的问题。当然了，以下介绍的3种管理风格，并不是泾渭分明的，而是相互配合使用的。
指令型的管理风格。给团队成员明确指定或者提供总体目标、基本任务、完成路径、里程碑，并且通过工作指引、规则之类的限制来约束团队成员。一般适用于没什么经验的实习生，或者非常紧急的事情。通过约束，使项目相对可控。团队成员的参与感、成就感受限，有一种工厂打螺丝的感觉，只关注当前的任务而失去了总体、长远的规划、目标。这种管理风格会消耗管理人员大量的时间、精力。
教练型的管理风格，此管理风格着重培养。需要给团队成员明确指出、提供总体目标，提供支持、资源、学习、参考的资料等。在项目进行过程中，随时交流，并据此了解他们的思路、想法，并且提供改进的期望、方法、目标。适用于不是非常紧急的事并且有一定经验的人，要求管理人员专业能力过硬，且对团队成员有一定程度上的了解。这是我最常用的管理风格，只有团队成员的能力变强了，管理人员才有可能释放自己的时间。
支持型的管理风格，此管理风格，管理人员的角色更像MOBA游戏中的辅助位。管理人员主要提供总体目标、资源、协助等支撑，协助团队成员更好的完成工作，为团队争取更好的项目、工作机会。适用于项目信息充分同步并且有丰富经验的团队成员。这是我对每位团队成员的成长期望。
# 做事
# 需求分配
分配原则：避免服务单点维护，两人以上维护统一服务。简称：一精多会（一人精通，多个人会）。考虑成员当前季度的排期，以及接下来的规划。酌情考虑组员意愿。
# 项目管理
# 项目启动
先写出总体规划，内容包括各业务模块的任务、集成方案、初评工作量、预期deadline。心里清楚项目的实际deadline，但暂不公开，避免项目成员根据deadline评工时。拉上各业务模块的负责人进行review方案。
接着把任务拆解成需求，由业务模块负责人或者具体的开发人员给出各个需求的deadline。注意需求的依赖问题，完成的最长任务路径。如果排期紧，则需要和产品、项目、技术三方讨论功能的优先级问题，分版本迭代。
最终确认排期后，落实到tapd上，具体为需求的预期上线时间。这个预期上线时间关联每个成员的季度绩效。
项目进入开发阶段，需要及时的跟进、push。尽量在deadline到来前完成，冗余时间处理各种突发的问题。
# 跟进时机
1）每周一次站会、一次周会。全组过手上的需求，以及本周的计划以及遇到的问题。
一般站会在周一或周二，周会周四或周五。
站会10分钟内结束。
2）日常了解。一般项目一到三天问一次。
3）每日对进度、情况。重点项目每天到白版前对进度，以及遇到的问题，找解决方案。
# 跟进内容
1）项目情况。
2）需求进度。各个分解的需求的产出情况，包括技术设计、编码、测试用例，注意被依赖的需求需要先完成。
3）遇到的问题。看是哪方的问题，关键路径或影响项目推进的问题需要优先推进解决。一般情况有：产品没出完需求、需要组外的同事协助，但没资源、依赖需求没开发完、产品方案或技术方案有改动。
4）需求是否有变动。小改动评论tapd，同步项目组，直接改。中大改动走需求变更，跟项目经理同步。
# 汇报
汇报，一般有两种目的：汇报项目进度；拉齐管理层、利益方、团队成员的期望。
# 汇报时机
- 定期汇报。根据项目的重要性、紧急程度，每天、每周进行汇报。
- 项目状态变化、进入新的里程碑。
# 汇报内容
- 各关键产出的完成内容。如果汇报对象关注产品、技术、测试中的某些项目，则重点描述，并且附上相应文档资料。
- 各关键产出的完成进度，是否有延期风险。主要包括：预期完成时间、实际完成时间。
- 需要额外获得各方的资源、支持。比如：要需要哪个部门，什么样的支持（加测试资源、技术专家评审方案）。
- 项目进行过程中，是否有发现不合理的设计、遇到的问题，已知、可行的改进方案。汇报主要是获得各方支持，而不是问方案，尽量让上级做选择，而不是想方案。毕竟上级难以获得第一手全面的信息，信息不全面的情况下，容易产生误判。
- 上线后，使用情况、运行的数据量、用户反馈、产品性能等运行情况。用于后续改进、优化。
- 上线一段时间后，总结项目进行期间遇到的比较大的问题，以及提出产品优化的方向、改进组织作业流程的办法。
# 看方向
产品迭代方向
一般中小型企业在市场上扮演的是追逐者、挑战者的角色。产品功能、业务流程上相对不完善，产品的方向、微创新，成为了破局的关键。一般我通过这四个途径，看产品的迭代方向：
- 团队内讨论。开发、上线后维护的过程中，团队内的成员是最主要的开发者，得到的信息、反馈是最全面的。他们或多或少都会有自己的一些想法，可能会出于不给自己增加工作量、不给自己添麻烦、不自信之类的原因，没主动说出来。我一般在季度末、项目上线之类的时间节点，和团队成员进行谈话，找找新的可能性。当然了，开会的时候一起讨论产品的优化点，也是一个很不错的方法。
- 参考竞品、产品设计相关书籍、课程。这里推荐《电商产品经理宝典》、《产品思维三十讲》，前者给出了很多成熟的电商系统的产品设计，在我做电商相关的服务的时候，给了我很多的直接的帮助，特别是产品也没有提供很好的方案的时候。后者我当时听的是音频，深入浅出，可以快速的了解产品设计的一些基础的思想，更好的理解产品经理的设计。
- 使用反馈。包括普通用户、系统运营管理人员、实施人员的反馈，深入他们最真实的使用情况，有机会可以现场观察他们的操作过程、问他们的使用体验和想法。经验上，技术工单较多的模块，如果不是有bug，就是产品设计、交互有问题，导致系统用户误操作。
- 观察数据。经验上，非管理性质的，操作频率少的功能，不是需求量少的功能，就是不好用的功能。短时间，同一个客户操作频率高的功能，可能交互需要优化，提高用户的操作效率。
技术方面的目标
主要是提高用户体验、性能优化、服务质量、工作效率。
- 技术选型方面。包括了解市面上广泛应用的组件、技术的流行趋势、已有组件的重要特性更新。条件允许、风险可控的情况下，尝试将新的技术应用到项目开发、系统优化中。比如，PolarDB的新特性：热点行更新优化，如何在项目中运用起来？
- 技术方案设计、性能优化方面。通过架构设计、模块划分、代码设计等，保证成本可接受的前提下，一定程度的可扩展性和可维护性。了解市面上相似服务的一些工业化的优化设计方法。随时准备在业务量起来的时候，快速响应提供支撑。
- 服务质量、测试方面的总结。主要解决三个问题：如何提高测试场景覆盖率；如果出现BUG，如何快速解决；如何快速响应，租户临时要求的系统功能、数据变动；
- 工作效率。针对性地进行改进。主要包括三个方面问题：工作分配、排期，避免出现维护人员单点问题、过多需求积压到同几个成员头上；团队沟通、协作，文档、接口定义，尽量前期确定达成共识，避免后期反复修改；考虑不周引起的返工、低级BUG过多，导致占用过多自己以及其他项目成员的时间。