如何做好技术基层的管理工作？

关键词

团队管理：明确的目标、标准化的流程（持续改进）、团队成员的发展与激励、决策和问题解决、沟通力等。

再浓缩一点，我觉得可以简化为：事、人、风险。

一、事

事，也就是我们要达成的愿景和目标，或者也可以细化到一个个具体的需求，这都属于「事」的范畴。本章节主要围绕 事情是什么、事情怎么做 展开。

我们做团队管理，尤其是基层的团队管理，主要就是围绕「事」展开的。而作为管理者，我们需要做的就是：

• 明确目标： 确定团队的目标和愿景，明确团队的职责和责任。
• 制定计划： 制定团队的工作计划和时间表，确保团队按照计划完成工作。
• 定期评估： 定期评估团队的绩效和进展，及时调整团队的工作方向和策略。
• 持续改进： 持续改进团队的运作方式，提高团队的效率和效果。

以上内容，就是围绕做好「事」的工作进行总结和提炼的。它看起来似乎很简单，但实际上却包含了团队管理中很多关键的步骤和策略。

我从几个关键点来展开说明，并附上相应的案例和示例，以帮助大家更好地理解。

1. 明确目标

核心关键词：做什么、为什么做。

明确目标，是团队管理中非常重要的一步。我们需要设定一个清晰的目标，并确保团队成员清楚了解这个目标，以便他们能够朝着这个目标努力。

这里稍微提一嘴，如何明确目标，需要管理者自己对事情有清晰的认知，并反复向上（上级领导）确认核实对齐该事情，避免出现“南辕北辙”，“货不对版”的情况。

例如，我们可以设定团队的目标是：提高团队的工作效率和产出。这个目标可以分解为具体的任务和目标，例如：提高团队的工作效率、提高团队的产出等。

同时，我们还需要设定团队的愿景，即团队的长期目标，例如：提高团队的竞争力和市场份额。

这些都是需要非常具体的、可被衡量的、可实现的，并且要与团队的价值观和目标相匹配。这也是为什么很多公司会制定并执行 OKR、KPI 等目标管理工具的原因。

这也和我之前的文章《有的放矢的重要性》中提到的，明确目标 的重要性是一致的。你如果不知道车要开到哪里去，你终究到达不了目的地。

2. 制定计划

核心关键词：阶段性产物。这个计划表中，阶段性产物是一定要有 deadline 的。

制定计划，也是团队管理中非常重要的一步。我们需要制定一个清晰的工作计划，包括团队的职责和任务，以及团队的资源分配和时间表。

例如，我们可以制定一个工作周报，包括团队成员的工作内容和进展，以及团队的资源分配和时间表。

同时，我们还需要定期召开团队会议，讨论团队的进展和问题，并制定团队的下一步工作计划。

有了目标，但是没有可落地执行的计划（一定是要有周期的），说到底还是空谈，空中楼阁而已。这也是用来指导（或指引）我们日常工作是如何一步步向前推进并最终实现目标的。

3. 定期评估 & 持续改进

关键词：定期、评估、改进。

定期评估，同样也是团队管理中非常重要的一步。我们需要定期评估团队的绩效和进展，并针对团队的不足之处进行改进。

例如，我们可以定期召开团队会议，讨论团队的进展和问题，并针对团队的不足之处进行改进。

同时，我们还需要制定相应的评估指标和标准，以便我们能够客观地评估团队的绩效。

我们最初制定工作目标和计划的时候，可能会比较模糊，做着做着发现事情没有想象的那么简单，很多情况下这是不可避免的。当然这里面又涉及到更多衍生内容去更好的规避这种问题，比如「关键技术点的预研」、「技术选型」等等。这些可以操作可以在很大程度上帮助我们在制定计划的时候，论证事情的可行性，提前做好评估和准备。不至于遇到问题的时候，措手不及，或者需要推倒重来。关于前期论证这个点，我就不在这里展开和赘述了。

举例来说，最开始的前端只有 1 个前端工程师，而到了后期，团队规模扩大到了 5 个前端工程师。这时候，我们就要重新评估我们的工作流程（团队成员的协作），以适应团队的规模和变化。说的更直白点就是，一个人提交代码或修复 bug 是一种工作流程，多个人操作的时候，工作流程可能就变得更为复杂了，就需要处理冲突、沟通、协调等问题，这就会引申出来「代码提交规范」「代码自测流程」等等。

综上三点所述，我们会发现整个做事的逻辑和流程，和「PACD 模型」是极其类似的。 有兴趣的朋友可以看看我之前写的文章《极简版的 PACD 模型》。

这里再提一嘴，有了清晰的目标和可落地执行的计划后，一定要周期性的做产出评估并向上汇报当前进度和成果，达成「上下共识一致」非常重要。

二、人

人，上面已经把「事」的核心关键词都列出来了，这里主要围绕 人 展开。我们先了解几个关键点，然后再做详细说明。“人”是从哪里来的？TA 要到哪里去？TA 会什么？TA 有什么优势和不足？

不管是做技术管理，还是做业务管理，也不管你是空降的管理者，亦或者是从零到一组团的管理者，我们都需要关注团队成员，因为团队成员是团队的核心。我们需要了解团队成员的技能、经验、性格、价值观等，以便我们更好地管理和激励团队成员，提高团队的效率和效果。

简单来说，人 就是团队的灵魂，是团队的根基。从另一个角度来看，我们必须对“人”是有清晰的了解和认知的，否则我们就无法对团队进行有效的管理和激励。

比如，我们团队需要一个技术专家，那么我们就需要找到一个技术专家，而不是一个只会写代码的程序员。

再比如，我们团队需要一个业务专家，那么我们就需要找到一个业务专家，而不是一个只会写代码的程序员。

再比如，我们团队需要一个产品经理，那么我们就需要找到一个产品经理，而不是一个只会写代码的程序员。

再比如，我们团队需要一个设计师，那么我们就需要找到一个设计师，而不是一个只会写代码的程序员。

再比如，我们团队需要一个认认真真会写代码的程序员，你就不能找个产品经理或者技术专家。

这个在我们作为管理者的时候，需要特别注意。你招聘团队成员的时候，也一定要做到心里有数，你要什么样的人？你能给这样的人提供什么？你提供的东西是 TA 想要的吗？

1. 明确角色和责任

核心关键词：角色、责任。

明确角色和责任，是团队管理中非常重要的一步。我们需要确定每个团队成员的角色和责任，确保团队成员能够明确自己的职责和责任，并能够有效地履行职责。

例如，我们可以确定每个团队成员的角色和责任，例如：技术专家、业务专家、产品经理、设计师等。同时，我们还需要确定每个团队成员的职责和责任，例如：技术开发、业务分析、产品规划、设计创意等。

2. 项目管理和任务分配

• 1）合理分配任务：根据每个成员的技能和经验分配任务，确保任务合理分配。

  • 难易程度：高手做难的（有挑战性的），新手做基础的、容易的；
  • 开发周期：考虑任务的开发周期和截止日期，优先安排那些截止日期较早或时间紧迫的任务，以确保项目能够按时完成。同时，要合理评估团队成员的工作负荷和能力，避免任务过度集中在某一人员身上，导致资源不均衡和工作效率低下。
  • 过往经验：考虑团队成员过往的工作经验和专业领域，尽量将任务分配给曾经在相关模块或领域有成功经验的人员。这样可以利用其熟悉的技术栈和流程，减少学习成本和开发风险，提高任务的完成质量和效率。（eq. 这个模块是这个人之前负责开发的）
  • 资源优化：综合评估团队成员的工作负荷和能力，灵活调整任务的分配，实现资源的最优利用。

• 2）进度跟踪：使用项目管理工具跟踪任务进度，确保项目按计划进行，每个事情有专门的“人”进行处理跟进。

  • 定期更新任务进度，确保每个任务都有明确的状态（如未开始、进行中、已完成）。
  • 设置关键里程碑和检查点，定期审查项目进展。

3. 关注个人职业发展规划

• 1）职业发展规划：帮助团队成员制定职业发展规划，提供晋升和发展的机会。
  • 与每个团队成员进行一对一的职业发展讨论，了解他们的职业目标和期望。
  • 制定个人发展计划，明确短期和长期目标，以及实现目标的具体步骤和资源支持。
• 2）绩效评估：定期进行绩效评估，帮助成员了解自己的优势和需要改进的地方。
  • 定期（如季度、半年）进行绩效评估，评估标准包括任务完成情况、技能提升、团队合作等。
  • 提供具体的反馈和改进建议，帮助成员了解自己的优势和需要改进的地方。

另外，针对“人”这个话题，我再补充一个关键词：感受。

不知道大家是否听说过 峰终定律？

峰终定律

峰终定律（Peak-End Rule）是心理学中的一个概念，由心理学家丹尼尔·卡尼曼（Daniel Kahneman）提出。这一理论指出，在评估过去的体验时，人们往往不会平均考虑整个体验的每一个瞬间，而是主要受到体验中的最强烈（或最低点）和最后一刻的影响。换言之，人们对某个事件的总体记忆倾向于由经历中的“峰值”（不论是高峰还是低谷）和“结束”时刻定义。

• 两块糖：一块峰值提供，一块终点提供。
• 结果为导向，过程也重要：带领团队研发时，需要关注团队的情绪峰值以及对最终结果的评判
  • 1）取得好的结果：哪怕过程中艰辛，团队成员依然会觉得值得，有成就感；
  • 2）要关注团队中的情绪变化，注意峰值（鸡血需要打，但不能经常打）；
  • 3）既要以结果为导向，也要关注以人为本，关注团队成员的需求。

要把事做成，核心推动力还是人。既要人尽其责把事情做好，也要让人能在做事的过程或者结果中得到收获。管理者作为公司和基层员工的中间层，必须起到良好的润滑剂作用。一味的从公司角度出发，极限压榨员工的产出，注定无法长久（除非公司的模式就是“打一枪换一地”，本着这批“人”用到了极致后就直接换一批的思路的话，那就另当别论了）。一味的站在员工角度，充当职场“老好人”角色，而不注重关键性的产出，这也是不合格的管理者。

三、风险

风险管理是确保团队顺利完成任务的重要环节。管理者在某个项目（或事情）的推进过程中，必须要有「风险清单」、「待办事项」、「具体排期分工」等清单表。

1. 识别风险

• 项目初期：识别技术难点和潜在问题。项目启动会议中识别技术难点，设立风险清单。这个非常考验我们（管理者）对「事」的整体把握，要做到什么程度，哪些是重点，哪些是次要，哪些是可忽略的。然后就是一定要有 以点破面 的思维方式，把整个项目（或者需求）拆分成一个一个的点，哪些点是决定这个事情能不能继续往下推进的核心点（是必须完成的），这些核心点必须在项目真正启动前就进行有效的技术预研和方案应对，否则，等到项目真正启动，可能已经晚了。
• 定期评估：通过会议和工具持续监控风险。

  每日早会（晚会）很有必要，对于提升团队集体参与感、高效处理当前问题和把控整体进度都很有帮助。

2. 制定应对策略

• 预研和选型：提前进行关键技术点的预研。这个也就是我上面在「事」的维度上提到的策略：「论证事情的可行性」。
• 制定应急计划：为潜在风险制定应急预案。有时候技术预研可能也会存在局限性，那么理想的状态是我们能提前准备 Plan B。

以我做项目经理的经验来看，做好 风险公示，并落实风险应对方案和相关负责人非常重要。 这样做有两个好处，第一是团队成员可以提前了解风险，相关负责人可以提前做好应对措施；第二是如果真的发生风险，团队成员可以有依据的进行应对。

总结

所以，做好技术基层管理工作，需要围绕“事、人、风险”展开：

• 事： 明确目标、制定计划、定期评估和持续改进。
• 人： 明确角色和责任、合理分配任务、关注职业发展和绩效评估。
• 风险： 识别风险、制定应对策略和应急计划。