标签归档:团队管理

异地技术团队管理的三大模式六项注意

1 为什么会有异地团队

当一个企业成长到一定程度后,往往会在多地建立研发中心或者业务中心,这里企业的考量可能会有如下的一些点:

  1. 人才资源:不同的城市和地区可能具有独特的人才资源,通过在多个城市建立研发中心,公司可以吸引和招聘到更多具有不同技能和背景的优秀人才。这有助于公司在保持竞争力,并确保能够获取到足够的人才来支持研发和业务需求。
    比如深圳是中国的高新技术产业中心,其在硬件制造、消费电子、通信技术等方面具有很强的竞争力,对硬件制造、物联网、人工智能等领域拥有丰富经验的工程师较多,并且由于深圳地理位置优越,靠近香港,拥有国际化的人才环境,因此在跨境项目和多元文化沟通方面具备优势;
    又如北京是中国的政治、文化和教育中心,拥有众多顶级高校和研究机构,拥有大量理论研究和技术创新方面的顶尖人才,北京的互联网行业较为成熟,尤其是在互联网+政务、在线教育、大数据等方面有较多经验的人才。

  2. 市场覆盖:在多个城市设立研发中心有助于公司更好地了解和适应不同地区的市场需求。这可以让公司更迅速地响应市场变化,提供更符合客户需求的产品和服务。

  3. 成本优化:不同地区的劳动力成本、房地产成本和生活成本可能存在差异。在多个城市建立研发中心可以让公司充分利用各地的成本优势,降低整体运营成本。如一些深圳/北京的公司,会把一些研发中心放到西安、成都、武汉、长沙等城市。

  4. 政策支持:一些城市为了吸引优秀企业入驻,可能会提供各种政策支持,如税收优惠、低息贷款、用地优惠等。在多个城市建立研发中心可以让公司充分利用这些政策优势,降低研发成本。

除此之外,还有风险分散的考虑,技术合作与创新等等,最终都是帮助公司获得更多的资源和优势,提高整体竞争力。

2 异地团队会有什么问题

以技术团队为例,当有多个技术团队在不同的城市后,与所有技术团队在同一个地方相比,会有一些问题出现,主要分为以下的 4 个方面:

2.1 团队建设和凝聚力打造困难

由于缺乏面对面交流和互动,异地团队成员之间可能难以建立信任和凝聚力。而团队建设和凝聚力是影响团队绩效的重要因素。当技术团队分布在不同城市时,团队建设和凝聚力可能受到以下方面的影响:

  1. 面对面交流机会少: 当团队成员分布在不同城市时,他们的面对面交流机会将大大减少。面对面交流有助于加深团队成员之间的了解、建立信任和加强团队凝聚力。例如,共同参加团队活动、庆祝生日等场合,能增强团队成员之间的情感联系。而分布在不同城市的团队成员可能很难享受到这些互动的机会。

  2. 困难的团队文化塑造: 一个健康的团队文化对于团队建设和凝聚力至关重要。在异地团队的情况下,公司需要付出更多的努力来塑造统一的团队文化。例如,各地团队可能在工作习惯、价值观、沟通方式等方面存在差异,这些差异可能导致团队凝聚力降低。

  3. 时空的隔阂: 异地团队面临地理距离的挑战,以及各地工作安排导致的时间不一致的问题。这种情况下,团队成员可能较难以达到理想的实时沟通,而在中国实时沟通是大部分公司的必备品,大家更习惯于实时的沟通,而不是异步的非实时沟通。

  4. 缺乏有效的团队认同感: 异地团队成员可能会感到自己与其他团队成员的联系较弱,这会导致他们缺乏对整个团队的认同感。例如,一个异地团队成员可能对其他城市团队的工作情况和成果了解较少,难以形成归属感和共同的目标。

2.2 项目管理及实时协同难度大

异地团队成员可能难以实时协作,尤其是涉及紧急问题或需要即时反馈的情况。项目管理及协同难度增大主要表现在以下的 3 个方面:

  1. 沟通成本上升:当团队成员分布在不同城市时,团队之间的沟通成本会显著增加。团队成员需要通过电话、电子邮件、即时通讯等工具进行沟通,这可能导致信息传递的延迟和误解。例如,一个团队成员在深圳提出一个需求变更,另一个团队成员在上海可能需要数小时甚至一天后才能了解到这一变更,从而影响项目进度。

  2. 快速应对变化的能力变弱:异地团队可能在应对突发事件和变更需求时存在局限。假设一个重要客户要求对产品进行紧急修改,跨城市的团队成员可能需要在短时间内协调资源和安排工作,而地理隔离使得这一过程变得更加困难。

  3. 时间管理和跨团队协调困难:不同城市的团队可能存在不同的工作时间和节假日安排(比如某个城市因为办公场地原因而全员居家),这可能导致某些任务在协作过程中出现延迟。例如,在一个紧急 bug 修复的情况下,由于一个城市的团队正在度假,另一个城市的团队需要独自解决问题,可能导致修复速度变慢。

2.3 监督和管理困难

在异地团队中,监控和评估团队成员的绩效可能较为困难。管理者需要找到合适的方法和指标,以便对团队成员的工作成果进行公平、准确的评估。监督和管理困难主要包括以下的一些情况:

  1. 工作状态难以掌握:由于地理隔离,管理者可能无法直接了解团队成员的工作状态和情况。例如,一个城市的团队可能遇到了技术难题,导致项目进度受阻,但管理者由于无法亲自与团队成员交流,可能难以及时发现问题并采取相应措施。

  2. 绩效评估困难:在异地团队中,评估团队成员的工作绩效可能变得更加困难。由于缺乏面对面交流,管理者可能无法准确评估团队成员的工作质量和效率。例如,一个城市的团队成员可能在某个任务上花费了较长时间,但管理者无法确定这是否是由于技术难题还是工作效率低下。

  3. 难以建立信任和团队凝聚力:地理隔离可能导致管理者难以建立与团队成员的信任关系,从而影响团队凝聚力。例如,一个城市的团队成员可能对管理者的决策表示质疑,由于无法进行面对面沟通,管理者可能无法充分解释决策背后的原因,从而导致信任度降低。

  4. 协调和调动资源困难:异地团队的管理者可能在协调和调动资源方面面临挑战。当项目需求发生变化或出现紧急问题时,管理者需要快速协调各地团队的资源,但地理隔离可能使这一过程变得更加复杂。例如,在一个紧急项目中,管理者需要从多个城市的团队中调集人力资源,但由于异地情况,这可能导致资源调配的速度和效果受限。

整体来说,主要是由于沟通与协作问题导致的各种延展性问题。缺失的面对面沟通、缺少肢体语言、表情语言等,可能导致信息传递不畅、误解和沟通成本的增加。我们无法彻底解决这些问题,但是能通过一些手段来缓解。

3 三大模式

为解决上面这些问题,我们在工作中发现了一些在不同的环境和场景中具有普遍适用性的解决或缓解问题方法,以模式的形式表述出来。

3.1 代理模式(Proxy Pattern)

代理模式在团队管理中可以被用于创建一个协调人或代表角色,负责处理某个团队或多个团队之间的沟通与协作。代理角色在此情景下充当一个中介,处理跨团队的需求、问题解决和资源协调。代理模式有助于简化沟通流程,提高团队协作效率。

具体实施方案:

  • 为每个团队或职能领域设立代理角色,如前端代理、后端代理、QA 代理和移动端代理。
  • 代理角色负责处理跨团队的需求和问题,同时将反馈和解决方案传递给相应团队。
  • 组织定期的代理角色会议,让代理们相互沟通和协作,以确保团队目标的达成。
  • 建立代理角色的沟通汇报机制,如定期晨会、周报和项目维度的回顾会。

3.2 门面模式(Facade Pattern)

门面模式提供了一个统一的接口来访问子系统中的一组接口。在团队管理中,可以创建一个统一的协调角色(如项目经理或技术负责人),该角色负责协调团队成员的工作,并充当各个团队之间的沟通桥梁。这有助于确保团队之间的沟通更加高效,降低沟通成本。

具体实施方案

  • 设立项目经理、技术负责人或者某个业务模块的 DRI 角色,负责跨团队协调和沟通。
  • 为每个团队成员分配具体的职责和任务,以便在项目经理或技术负责人的协调下高效协作。
  • 定期召开跨团队会议,确保团队之间的沟通畅通,及时解决问题。

门面模式和代理模式看起来有一点相似,其本质上是有区别的,区别在于授权的范围,门面模式不用太关注其内部实现,而代理模式在管理上要更深入细节一些。

在实际应用中,我们通常在各职能和各业务模块中使用代理模式,而针对不同的区域使用门面模式,由当前地区的负责人提供统一的输出。

3.3 观察者模式(Observer Pattern)

观察者模式在团队管理中可以应用于实时通知和信息共享。当一个团队成员对项目状态或任务完成情况进行更新时,其他相关成员可以作为观察者实时收到通知。这种模式有助于保持团队成员之间的信息同步,提高沟通效率。

具体实施方案

  • 为团队成员创建一个共享平台,如任务管理工具、项目管理系统等。
  • 当某个团队成员更新任务状态或项目信息时,系统自动通知其他相关成员。
  • 通过观察者模式,确保团队成员之间的信息同步,减少冗余沟通。

4 六项注意

4.1 相互信任

信任是团队协作的命脉。要想促进并保持长久的关系,你就必须信任他人,他们也必须信任你。与此同时,他们还必须相互信任。

信任来自相互理解对方的价值观、个人经历和立场。为了实现这一目标,我们必须承认自己的弱点,我们必须开放。这样我们才能够建立起共同的价值观和彼此信任。

信任在异地团队中有如下的好处:

  1. 提高团队凝聚力:信任关系有助于增强团队成员间的默契,从而提高团队凝聚力。当团队成员信任彼此时,他们更愿意携手合作,共同解决问题。
  2. 提高工作效率:信任关系可以促使团队成员更加开放地分享信息、资源和建议,从而提高整体工作效率。当团队成员相互信任时,他们更可能分享自己的想法和专业知识,共同解决问题。
  3. 降低沟通障碍:信任有助于消除团队成员间的沟通障碍,提高沟通效果。当团队成员彼此信任时,他们更愿意倾听对方的意见,以开放的态度接受建议和批评。
  4. 降低管理成本:信任关系有助于减轻管理压力,降低管理成本。当团队成员相互信任时,他们更可能自我管理,减少管理者的介入。
  5. 增加创新和风险承担:信任关系有助于创造一个安全的环境,使团队成员更愿意尝试新的想法和承担风险。当团队成员彼此信任时,他们更可能勇于创新和承担失败的风险。

建立相互信任关系的方法,以下是一些常见的方法:

  1. 增加沟通

    • 定期开展团队会议,让团队成员分享项目进展、遇到的困难和解决方案。
    • 鼓励一对一交流,让团队成员有机会深入了解彼此的工作、兴趣和需求。
    • 举办团队活动,如团队建设、庆祝活动和知识分享,促进团队成员间的互动和信任。
  2. 增加透明度

    • 使用项目管理工具,让团队成员能够实时查看项目进度和任务分配。
    • 定期分享业务战略、目标和团队绩效,让团队成员了解公司的发展方向。
  3. 赋予责任和权力

    • 根据团队成员的专长和兴趣分配任务,让他们在完成任务时有更大的自主权。
    • 鼓励团队成员在解决问题时提出建议和改进方案,展现对他们的信任。
  4. 鼓励支持和合作

    • 创建一个支持性的氛围,让团队成员在遇到问题时不惧于寻求帮助。
    • 鼓励团队成员互相学习、分享经验,以解决共同面临的问题。
  5. 表扬和认可

    • 在团队会议上表扬团队成员的优秀表现和努力。
    • 为表现突出的团队成员提供奖励,如奖金、晋升和表彰。
  6. 建立公平的环境

    • 确保团队中的决策过程透明,鼓励团队成员参与讨论和决策。
    • 设定明确的激励和奖惩

4.2 仪式感

在异地管理中,仪式感是一种有意识地营造正式或非正式场景,以传递重要信息、强化文化价值观、增强团队凝聚力和提升员工信任感的方式。

在异地团队中,恰当的仪式感具有以下好处:

  1. 增强团队凝聚力:仪式感有助于让团队成员感受到归属感和团队精神,从而增强团队凝聚力。
  2. 传递公司文化和价值观:通过仪式感,可以传递公司的文化和价值观,帮助团队成员更好地理解和认同这些价值观。
  3. 提升员工士气和信任感:仪式感可以激发团队成员的积极性和参与感,从而提高员工士气和信任感。
  4. 建立清晰的期望和目标:仪式感有助于确立团队成员的期望和目标,提高工作效率和执行力。

那如何建立恰当的仪式感呢?

  1. 定期召开团队会议:固定时间、地点召开团队会议,让团队成员汇报进展、分享经验、讨论问题。如每周一召开全体成员参加的在线例会,或者对于管理团队,定期如开包含问题同步和处理,学习分享的管理例会。
  2. 庆祝重要节点和成就:为团队的重要成就和里程碑设立庆祝活动,以增强团队成员的归属感和自豪感。如在项目完成时,举办在线庆祝活动,表彰优秀团队成员。
  3. 组织团队建设活动:定期组织线上或线下的团队建设活动,增进团队成员间的联系和互动。如每季度举办一次线上游戏比赛,增强团队成员之间的合作和交流。
  4. 激励和认可:对团队成员的努力和成果给予表扬和认可,提高他们的信任感。如每月颁发「最佳团队贡献者」奖项,表扬表现优秀的团队成员。
  5. 传递公司文化:通过仪式感传递公司文化,帮助团队成员理解和认同公司的价值观。如每年举办一次公司文化分享活动,邀请公司领导和团队成员分享公司文化和价值观。

4.3 严格目标管理,注重结果

在异地技术团队管理中,严格的目标管理和注重结果至关重要,因为这有助于确保项目按时完成、质量达标,并提高团队成员的工作效率和执行力。

以下是实行严格目标管理和注重结果导向的好处:

  1. 明确工作目标:设定清晰的目标和期望,帮助团队成员明确工作重点,避免资源浪费和目标模糊。
  2. 提高工作效率:明确的目标和期望有助于团队成员更高效地完成任务,降低拖延和低效的可能性。
  3. 便于评估和改进:结果导向的管理使团队可以通过衡量实际成果来评估工作效果,从而找出不足并进行改进。
  4. 激发团队成员积极性:目标明确、注重结果的管理方式有助于激发团队成员的积极性和责任心,鼓励他们为实现目标而努力。
  5. 有利于项目按期完成:严格的目标管理和注重结果有助于确保项目按计划进行,按时完成,避免延期。

那么如何实施严格的目标管理和注重结果导向?有如下 7 个方法

  1. 设定明确的目标:为项目和团队设定明确、可衡量、可达成的目标。如在项目开始时,为团队设定一个明确的项目交付日期,并明确交付内容的具体要求(也就是大家常说的 deadline 是第一生产力)。
  2. 制定详细的计划:为实现目标制定详细的计划和进度表,包括任务分配、时间安排等。如使用项目管理工具(如Trello、Jira等)制定详细的任务列表和时间表,如果没有这些工具,搞个在线表格也是极好的。
  3. 定期检查进度:定期与团队成员沟通,了解项目进度和遇到的问题,确保项目按计划进行。如定期的项目晨会(可以按周,或按天,也可以一周两次,根据实际情况调整),让团队成员报告各自的任务进展和遇到的问题。
  4. 强调结果导向:鼓励团队成员关注实际成果,以实现预定目标。在管理过程中对团队成员的绩效评估更注重实际完成的任务和贡献,而非工作时长或其他表面指标(不要卷加班)。
  5. 及时反馈和调整:根据实际进度和成果,及时给予团队成员反馈,调整目标或计划。如当发现某个任务进度落后时,及时与相关成员沟通,分析原因,并调整计划或提供支持。如当发现某个任务进度落后时,及时与相关成员沟通,分析原因,并调整计划或提供所需资源,以确保项目仍能按时完成。
  6. 定期总结和复盘:项目结束后,与团队成员一起总结经验教训,分析成功与失败的原因,以便在未来项目中持续改进。如项目结束后,组织团队进行复盘会议,总结项目的优点和不足,制定改进措施。或者迭代结束后做一些回顾。

我们在团队管理中,目标管理是一个非常重要的点,一定要自己主导,不能授权,作为一个技术团队的负责人,方向是你来定的,未来在你的手里

4.4 扁平、弹性的组织架构

在异地技术团队管理中,组织架构至关重要,因为组织架构会影响团队的沟通效率、决策速度、责任分配和协作。适合异地技术团队的组织架构应具备以下特点:扁平化、模块化、弹性和高度协作。

  1. 扁平化:扁平化的组织结构有助于提高沟通效率,减少信息传递过程中的失真和延迟。扁平化组织中,每个成员能够直接向上级汇报,决策速度更快,执行力更强。

  2. 模块化:将工作划分为具体的、相对独立的模块,有助于提高团队的协作效率。每个模块可以由一个或多个团队负责,这样可以减少跨团队协作的复杂度,降低沟通成本。

  3. 弹性:适应不断变化的项目需求和团队规模,组织架构需要具备一定的弹性。弹性的组织架构可以快速调整资源分配和团队规模,以满足项目发展的需要。

  4. 高度协作:鼓励团队成员之间的协作和互助,以提高工作效率和质量。高度协作的团队可以更好地应对复杂问题,减少重复劳动和资源浪费。

以下是如何实现适合异地技术团队的组织架构:

  1. 利用技术手段优化沟通:使用沟通和协作工具(如钉钉、企业微信、飞书、Microsoft Teams等)提高沟通效率,方便团队成员跨地域、跨部门协作。
  2. 决策下放:授权团队成员在其负责领域做出决策,提高决策速度。如将需求评审的决策权下放至小组 leader 或 DRI,甚至一线开发,让他们根据自己的专业知识对需求进行评估和调整。
  3. 设立技术负责人或项目经理:在每个地区或团队设立技术负责人或项目经理,负责协调团队成员的工作,确保项目顺利进行。如在各城市的团队中各设立一名项目经理,负责当地团队的项目进度和资源协调。
  4. 定期进行跨团队沟通:组织定期的跨团队会议,让各个团队分享进展、问题和解决方案。这有助于提高团队间的了解和协作。如每两周组织一次跨团队分享会议,让各个团队汇报自己的进展和挑战,共同寻找解决方案。
  5. 提供培训和支持:为团队成员提供技能培训和支持,以便他们更好地适应组织架构变化。如提供关于敏捷开发、跨部门协作等方面的培训课程,帮助团队成员提高工作效率和协作能力。
  6. 鼓励创新和变革:建立一种鼓励创新和变革的文化,让团队成员敢于尝试新方法,优化工作流程。如设立创新奖励计划,对于提出改进方案并成功实施的团队成员给予奖励。或者团队负责人亲自来参与或推进一些创新的事项,如最近的比较热的 AI。

4.5 统一的技术栈

在异地技术团队管理中,统一技术栈非常重要,因为它能为团队带来以下好处:

  1. 提高协作效率:统一技术栈能确保团队成员之间更容易进行技术交流和协作,避免因技术差异导致的沟通障碍和额外工作量。
  2. 降低维护成本:使用相同的技术栈,使得维护、调试和优化工作更加简单,减少因为技术差异导致的额外成本。
  3. 增强团队能力:统一技术栈有助于团队成员互相学习,提高整体技术能力,使得团队在面对复杂项目时更具备应对能力。
  4. 简化招聘和培训:统一技术栈使得招聘和培训过程更加简单,因为公司可以针对特定技术栈进行招聘和培训,提高招聘效率和培训质量。

为实现统一技术栈,我们可以采取以下方法:

  1. 制定技术规范和标准:制定统一的技术规范和标准,确保各地团队遵循相同的技术实践。如制定统一的编码规范、代码审查标准和自动化测试要求。
  2. 组织上增加架构设计的职能或者技术通道的职能组织: 通过组织的方式构建技术栈统一的土壤。
  3. 搭建技术共享平台:创建内部技术分享平台,让团队成员分享技术心得、问题解决方案和最佳实践,有助于统一技术理念和实践。如搭建一个内部的技术博客平台,鼓励成员撰写和分享技术文章。
  4. 统一基建和开发流程中的系统: 通过使用工具的统一达到技术栈的统一。
  5. 选型时充分调查和论证:在技术选型阶段,充分调查并论证各种技术方案的优缺点,确保选择的技术栈适合公司的业务需求和发展战略。
  6. 定期评估和调整:定期评估技术栈的合理性和有效性,根据项目需求和团队能力进行调整,以保持技术栈的统一性和先进性。如每年定期组织技术栈评审和审查,了解目前所使用的技术栈是否仍然满足业务需求,或者是否有新技术可以更好地支持业务发展。

通过以上方法,异地技术团队可以实现技术栈的统一,从而提高协作效率、降低维护成本、增强团队能力,并简化招聘和培训过程。这将有助于提高团队整体的研发效能,使得公司在面对市场竞争和业务挑战时更具备优势。

4.6 高效的沟通机制

异地团队最突出的问题是沟通问题,在我们平常的沟通过程中需要选择合适的沟通渠道和做有准备的沟通。良好的沟通有如下的好处:

  1. 能提高沟通效率:采用合适的沟通方式可以确保信息准确、及时地传递给相关人员,避免因沟通不畅导致的误解和冲突。
  2. 增强团队凝聚力:良好的沟通方式有助于增进团队成员之间的理解和信任,提高团队凝聚力。
  3. 减少资源浪费:有效的沟通方式能够减少不必要的会议和重复工作,降低资源浪费。
  4. 支持项目管理:清晰的沟通方式有助于确保项目进度、需求和问题得到及时解决,保障项目顺利进行。

我们可以通过如下的一些方式达到比较高效的沟通机制:

  1. 明确沟通目标和内容:在沟通开始前,明确沟通的目的、内容和预期结果。如:在项目会议开始前,列出讨论议题、相关人员和预期决策。
  2. 选择合适的沟通渠道:根据沟通内容和参与人员,选择合适的沟通渠道。如:对于紧急问题,可以使用电话或即时通讯工具(如微信、钉钉等)进行沟通;对于团队日常工作,可以使用邮件或者项目管理工具(如Jira、Trello等)进行沟通。
  3. 建立沟通规范:制定团队沟通规范,确保沟通有效进行。如:要求团队高效会议,或者要求团队成员在邮件中使用清晰的主题行、合理的收件人列表以及简洁明了的正文。
  4. 鼓励开放和诚实的沟通:营造一个鼓励团队成员开放、诚实地表达观点和需求的氛围。如:在团队会议上,鼓励成员提出问题、建议和想法,避免惩罚性的反馈。
  5. 定期进行沟通培训:为团队成员提供沟通技巧培训,以便他们更好地进行沟通。如:提供关于有效沟通、团队协作等方面的培训课程。

值得注意的是,异地的沟通中尽量少用邮件,邮件适用于传达信息和事实,撰写时还需要注意措辞,以防误会的发生。

单纯的文字无法传递情绪,如果要传达你的想法时,最好拿起电话进行视频,通过视频也能制造多次「见面」的机会更有利于建立信任。

现在用 IM 类工具也比较多了,在清晰的文字表达的基础上,多用表情包。

5 后记

上面说了这么多,有点啰嗦,简单点来说就是:多见见,多一起喝点酒,多一起搞定一些事情,保证基本的机制、流程、标准、工具和系统,也就差不多了。

异地的问题表象是见不着,核心要解决的是效率的问题。

技术团队的管理更多的还是人的问题,还是需要有情感的交流和因为长时间的一起工作而产生的向心力。 我们所做的这些仅能缓解这些问题。

当然,可能有同学会更喜欢异地/远程的工作协同模式,此处因人而异,从个人的角度来看:从团队的角度,从效能的角度,本地化团队会是更高效的选择。

当然以上的模式和注意事项在非异地团队的情况下也是可以使用的,而且效果会更好,因为这些的本质是授权管理和过程管理的逻辑。

技术团队管理中的 4 个基本认知

在技术团队的日常管理工作中,一个管理者做得最多的事情是决策、开会,最不想看到的是线上事故,线上事故给技术团队带来非常大的冲击,而给线上系统带来风险最大的研发环节是线上环境的变更,甚至有人说:「没有变更就没有问题」,对此我们不置可否,但这些变更之所以会导致事故,从根源上来讲大部分是技术同学犯了错。

这里的决策、会议,变更,错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的,今天我们就来聊聊这 4 个基本认知。

1 决策

在带团队的过程中我们会做非常多的决策,如去决策是否投入足够大量的人力满足某个业务,或者升级架构,或者构建某个流程机制等等。

这些决策中从服务于时间维分为两种:

  • 当下的决策,如评估需求优先级,先做什么,后做什么,关注的是当下和已有的
  • 未来的决策,如评估技术架构演进、团队演化和发展等等,关注的是未来

当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。

对于产品需求,技术管理者的作用是把价值不高,或者没有价值的需求干掉,不让其进入研发,不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题:

  1. 为什么会有这个需求? 一般是想看这个需求是怎么来的,用户故事是怎样的;
  2. 这个需求的价值是什么? 一般是想看这个需求做了之后对产品或业务的好处,看产出;
  3. 如何度量这些价值? 一般是想通过数据看到需求的价值,把价值反馈在指标上,如营收指标、效率指标等。

对于技术需求或技术方案,技术管理者的作用是来评估当下的选择是否正确。一般我们会评估如下的点:

  1. 有没有做过方案评估,即有没有评估过业内的方案、公司内的方案以及对于当下的现况的分析;
  2. 是否合理的方案,有没有明显的缺陷或漏洞;
  3. 有没有显得特别高大上,特别先进,防止过度设计,浪费资源。

未来的决策更多是管理者站在当下思考团队的发展,人员的发展和技术架构的发展等,是一种未雨绸缪的远见。

是基于公司战略,在组织的先进性、技术的先进性的前瞻性布局。如现有的人才梯队和人才密度是否能满足公司三到五年的发展,现在的技术架构是否能满足公司三到五年后的战略,对于行业内新的技术是否我们需要扩大资源投入,去预研并应用在业务中。

这些前瞻性的决策都是管理者基于对公司业务和业务未来发展有足够的认知和理解后做的。

我们所做的这些决策都是以有限的资源达成我们的目的,其本质是资源的分配。当我们分配资源的时候,最最重要是看投入产出比以及和公司战略的方向是否一致。

2 变更

这里的变更是指生产环境的变更。首先我们看一下定义,什么叫生产环境?生产环境是指服务于客户的应用及其运行环境,以及和这些环境相关联的环境和系统。

如果一个应用或环境和生产环境有接触,那它也是生产环境。

什么叫变更管理,变更管理包括什么?

变更管理是指以可控的方式对线上的服务、配置或基础设施进行变更,从而减少变更对业务和服务质量的影响,快速处理变更可能带来的问题,提升系统的稳定性。

在日常工作中我们见到变更有如下 4 种:

  1. 应用变更,也称为代码变更,是我们最最常见的变更类型,主要是通过修改代码改变应用程序并通过发布系统发布到线上。这也是我们变更管理中风险最大的地方,因为变更的人,变更的位置和逻辑等都是不确定的。除了正常的发布变更,应用的回滚也是应用变更的一种,因为其改动了线上的应用;
  2. 配置变更,是指应用系统的配置变更,一般是通过配置系统来变更,触发线上应用的热更新或滚动,配置如果是写死在代码中,会变为代码变更;
  3. 基础设施变更,此变更一般是运维同学来操作,可能涉及网络设施变更,服务解析变更等等,如 DNS 的解析,网络安全配置等等,这些都算到基础设施变更里面,而不是配置变更,又如宿主机挂了,需要替换宿主机,此时也会导致基础设施的变更;
  4. 容量变更,此处单独列出是因为相对于基础设施,容量变动的影响逻辑不一样,其主要是通过垂直或水平的方式提升系统的容量,特别是当出现容量告警的时候,此变更经常由运维同学手动,或者系统自动触发。

那么如何控制变更?这里我们先提一下变更管理的标准流程。

变更管理的标准流程:

  1. 变更申请:在我们的流程中可能是创建发布记录,或者申请紧急发布
  2. 变更评审:变更评审主要是检查变更过程是否完备,以降低变更的风险,其包括如下内容:

    1. 就绪分析:材料是否完备,人员、设备、软件、网络是否就绪,测试是否达到上线要求等。
    2. 风险分析:架构、性能、业务、合规等方面的风险评估,变更内容是否属于需求范围,变更是否可控。
    3. 重要程度:变更属于一般、重要、紧急、标准哪一种。
    4. 变更审查:内容是否满足业务需求,内容是否通过测试,测试是否全面、有效。
    5. 应急管理:变更步骤、应急方案、回滚方案、应急预案是否完备。
    6. 变更实施:变更计划时间如何安排,发布及回退操作步骤是否完备,自动化步骤情况。
    7. 变更验证:变更涉及的业务、技术验证方法与时间安排。
  3. 变更审批:相关负责人对于变更评审的结果进行确认,并审批通过。
  4. 变更执行

    1. 根据发布计划执行发布操作,一般应该有一个灰度的过程;
    2. 验证线上功能并回归主流程;
    3. 持续灰度,观察用户直到灰度完成。
  5. 变更验收

    1. 对发布的功能进行验收,对于影响范围内的功能进行验收,对业务主流程进行回归验收;
    2. 留守,并观察日志、监控服务负载等,这个操作是为了及时发现验收检查漏掉的问题,或者及时处理隐藏的问题,以减少变更后产生的问题对线上业务的影响。

我们做这个流程是形式上的安慰,还是僵化的惯性,还是能真正地解决问题,是我们在做这个流程以及执行这个流程中需要着重思考的问题。

在变更前,即我们变更线上环境前需要自己做 Code Review,以及交叉的检查,以尽量减少问题流转到后面的操作中,节省问题的处理成本。

变更管理没有银弹,我们能做的是控制节奏,敬畏线上,以更机制化的方式提前发现问题并解决问题。

3 会议

会议是一个相互沟通、交互信息、形成一致看法,从而解决问题的管理工具。

从会议的定义来看,会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。

当我们思考一个会议要不要开时,可能需要先思考这个会议的目的是什么。

如果一个会议没有需要讨论的地方,没有明确的目的,可能大概率是一个不需要开的会的,又或者仅仅是一个简单的信息同步,直接文档或者在群里同步就可以了。除非文档没法完全解决问题,比如一些战略的宣讲,一些大的事项的发布,需要有一个仪式感的会,现场答疑的会。

如果发现两个会的参会人差不多,那么是否取消其中的一个会呢?不一定,看目的是否一致,如果解决的问题不一样,可以同时存在。

回顾我们常开的几种会议。

  • 项目例会:项目信息同步,问题卡点讨论,待办相关同步,这里的项目例会又包括常规项目例会和专项的项目例会,是项目管理中的信息渠道;
  • 管理例会:团队仪式感必不可少的部分,除了事项的讨论,还有一个作用是发散的聊天,不用那么严肃,闲谈之中迸发一些火花,并达成一些共识和认知上的一致;
  • 单独定期沟通会议:更私密一些的沟通会议,除了常规事项同步,更多的是一个散而不散的个人想法、规划、思路等的探讨;
  • 复盘会议:对特定事项和问题的总结,讨论,属于常规会议机制的一种,起总结,沉淀的作用;
  • OKR 会议:目标对齐,起方向对齐的作用;
  • 需求规划会:有计划的对于需求进行规划,评审,然后进入迭代,开发测试并交付;
  • 技术方案评审会:严格准入技术方案,集众人之力评估方案的可行性,看是否有什么缺漏。

着点讲一下周会,周会我们一般是指周例会,属于例行会议的一种,按周或双周召开。

周会的目的是根据会议的属性,定期回顾讨论总结指定的项,可能是专项,也可能是过程中的事项或突发的事情等。开会的目的主要是交流和讨论,那么在周会上我们讨论什么,在确定讨论内容之前,我们先看看哪些不要在周会上讨论:

  1. 紧急的事情不适合在周会讨论,出现的时候直接搞定;
  2. 非跨团队的问题不适合周会讨论;
  3. 纯执行细节问题不适合周会讨论;
  4. 大方向决策问题不适合周会讨论。

总结下来,就是涉及与会各团队的,对整体性计划或者需要协同配合的问题,或者里程碑式的改进型问题适合在周会上讨论。

当然,也不绝对,这还是一个人治的过程。

如果是你一个会议组织者,在组织一个会议的时候,需要考虑以下三件事:

  1. 这个会议最重要的事情是什么,是想解决什么问题?想讨论什么?
  2. 能否达到目标? 大家对于目标是否有所了解?
  3. 如何达到目标? 达到目标的关键路径是怎样的?干系人都在吗?

4 错误

工作中我们会出一些错误,生活中我们也会出一些错误,这些错误可能会影响同事朋友,或者影响线上产品,公司业务,甚至可能会造成个人或公司的经济损失,错误有其类型,在了解了这些类型后,我们可以适当的减少出错或规避这些错误。

从个人的角度来看,错误可分为成长之错,无心之错和性恶之错。

  1. 成长之错,我们都是从懵懂孩童,成长为有知识的学生,到长大成人,出来工作,工作中也是从不会到会,到熟练和精通,在这个过程中,正是因为一个个的错误,才成就了我们的成长,成长之错为正常之错,可允之;
  2. 无心之错,非有意为之的错误,一时失察导致工作出现错误,从而给别人带来不好的影响,或者粗心导致过错,其出发点都非有意,出错了就认,改过即可,不可连续;
  3. 性恶之错,以人性之恶为出发点或者动机,此种错不可原谅。

从工作的角度,错误可以分为超出型错误,信息型错误,粗心错误,态度型错误和风险型错误。

  1. 超出型错误,当你尝试去做能力之外挑战的时候,或者你不熟悉的领域或知识盲区,或者超出当前因为自身能力或其他条件的束缚,做得不够好而犯的错。比如一些新的想法的落地,一些新技术的试点等等,这些都没有人前人尝试过,至少在当前范围内没有,此时可能会遇到想象不到的坑,或者无法解决的问题,从而出现错误,甚至失误。这种创新或者超前的错误是可以接受的;
  2. 信息型错误,属于信息不对等,或者信息不全,知识不全面导致的错误,特别是对于工作中面对某个项目一些信息没有,或者没有去全面了解背景信息从而做出错误的决策,这种错误不会反复出现,但尽可能避免在不同类型的事情上犯同类型的错误;
  3. 粗心错误,这种比较常见,与无知错误不同,这种情况是你明明知道怎么回事,但是因为不小心或者忘记了而导致的错误,如果是粗心之人,可能会一错再错,此时需要反思自己,以某种方式规避;
  4. 态度型错误,指做事的态度有问题,比如眼看自己负责的一件事情要出问题或者已经出问题了,但是没有想办法去解决,没有付出努力,而是躺平,让事情自己变坏,甚至影响面不可控,这种错误是不允许的;
  5. 风险型错误,主动去做事情,但风险很高,是否会犯错不受自己的控制。比如你面临一个重要的选择,但在结果出来之前,你之前掌握的所有信息都无法告诉你哪个选择是绝对正确的,你只能去做自己认为是大概率的选择。而这种错误在工作中是极有可能遇到的。

对于工作中的错误我们应该如何减少或者规避呢?

  1. 超出型错误,从公司层面或者团队层面提供一些培训,或者在新人安排导师,提升大家的能力,或者通过流程机制让更有经验或者能力更强的人对于新的内容做一些把关;
  2. 信息型错误,信息型错误可以在公司层面搞定完善的文档和快捷的查询机制,任何技术或产品讨论以及达成的共识,要尽可能用某种沟通渠道发送到所有相关的人。让大尽可能的掌控更全面的信息;
  3. 粗心错误,设定一些机制来规避,如复盘机制,通过复盘,深挖过程中的问题,总结经验,为后续减少此类问题做准备,同时可以在流程上做一些 check 机制,通过多人的 check 减少错误的出现;
  4. 态度型错误,本着治病救人的态度先看看,如果实在不行,考虑换个人吧;
  5. 风险型错误,针对高风险的事情,尽可能的准备一个 PlanB,当事情没有按我们预想的方向发展时,启用 PlanB,减少损失,这也是我们下棋时通常会用到的策略,走一步,想三步。

从团队来看,一个人犯错,可能是人的问题,一群人犯错,一定是机制或系统出了问题。

当然,工作中我们允许试错,但是不能一错再错,避免一些不应该犯的错误,最大可能从错误中成长,这才是我们应有的态度。

除了以上,《清单革命》中说人类的错误可以分为两大类型。第一类是「无知之错」,我们犯错是因为没有掌握相关知识。第二类是「无能之错」,我们犯错并非因为没有掌握相关知识,而是因为没有正确使用这些知识。

现在,我们面临的错误更多的是「无能之错」,也就是如何持续、正确地运用我们所掌握的知识。「无知之错」可以原谅,「无能之错」不被原谅。

5 后记

管理是门实践的科学,大多数的书籍和文章都是个人或组织的经验之谈,没有公理,只能在俗世不断修行和精进,以求能「知行合一,止于至善」。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com

技术管理者的 4 个基本思考点

技术团队管理者在日常工作中可能经常会遇到如下一些状况:

  1. 自测质量差
  2. 转测 BUG 多
  3. 项目延期
  4. 加班赶工
  5. 高强度加班后,小伙伴状态不好,导致更多的问题出现

从第 1 点状况演变成第 5 种状况,第 5 点状况继续推动第 1 种状态的持续加强,从而导致整个团队的状态极差,陷入 BUG 多 –> 延期 –> 加班 –> BUG 更多 –> 更多的延期 的死循环。

除了上面的死循环,可能还会有一些非功能性的问题,如性能、扩展性问题等等。

当团队大时,还可能遇到有小团队,各小团队各行其事,各为其主,心不往一处,力不出一孔。 这些问题让技术团队的管理者焦头烂额。

那么如何解决这些问题呢?个人认为可以从以下 4 个方面来逐一思考和优化,从而在一定程度上解决这些问题。

1. 把正确的人放到合适的岗位

所有的执行最终都是落到人身上,有了正确的人,事情会事半功倍。 说到人,我们往往会提起人的「选用育留」,这是一个很大的题目,我们不做详细的讲述,只关注选和用的一小部分。

管理上有一个在大部分场景适用的套路:选拔优先于培养。 这个套路背后有两层逻辑:

  1. 改变一个人太难,比如有些人就是懒,抽一鞭子动一下;又或者家境优渥,态度佛系,无欲无求,根本就是油盐不进;又或者玻璃心,安全感差,都很难搞;
  2. 成本太高,即使这个人具备可培养性,但从 0 到 1 把一个人培养起来,时间成本太高,而管理者的时间很贵,公司等不起。

所以我们这里是选人,从现有的人中找到合适的,从人才市场找到合适的,能直接用的。

本小节主要是回答两个问题:

  1. 正确的人是怎样的?
  2. 如何把正确的人放到合适的岗位上?

1.1 选人

在人的层面,主要包括两个部分,执行者和管理者,这里管理者包括整个团队负责人自己。 不同的部分,要求不同,选人的标准也不同。去掉专业技能部分,去掉历史经验部分,我们希望我们的伙伴是这样的:

  • 喜欢和投入:对于技术热爱,对工作有投入度,能够专注于自己手上的工作,找到成就感;
  • 知道自己想要什么:有一定长远的规划,知道自己走在什么样的路上,不限于一时一城之得失;
  • 一路人:认同企业的价值观,价值观认同其本质上是「人以群分」;
  • 宁缺毋滥:如果实在没有人,宁缺毋滥吗?这是一个好问题,严格来说是这样的,但实际中往往我们会妥协一部分。

我们选人一个常见的问题是注重人当下的表现和历史的成绩,然而我们选人是要解决未来的问题,更要关注其潜力。 那么如何看一个人的潜力呢?如果具备以下的特性,大概率是一个有潜力的人:

  1. 有意愿,什么叫有意愿,就是指一个人想变好,有内在的动机去追求更高的目标;这里扩大一些,还包含积极的态度、好奇心和进取心;
  2. 有静气,特别是遇大事时有静气,临危不乱;遇到繁琐的事情能一步一步慢慢做好;
  3. 有度,做事有度,知道做事的边界在哪,进展有度,但是并不是事事划边界,事事划边界显得格局太小,多数事情还是从大局着眼;
  4. 能扛事,遇到事情找方法,不找借口,执行力强;
  5. 有所为,天赋决定了能达到的上限,努力程度决定了能达到的下限。努力去做,有所为,并且 以现在绝大多数人的努力程度之低,还远远没有达到比拼天赋的程度。 这里的有所为不仅仅是做事,更多的是学习,不停地学习,提升自己。

1.2 用人

1.2.2 人才梯队

人才梯队从时间上看分为现在和将来。 现在是指盘点现有人才情况,梳理人才结构,对团队中的人进行分层,形成「梯状」。

当前状态的人才梯队分为两个层面,一个是分层,另一个是分层后的职责。 当团队大一些后,需要明确团队的组织分层,这里可能是正式认命的 Leader,也可能是虚拟的负责人,不管是实的还是虚的,最终都会有一个层存在。

分层本质上是一个分饼的行为,什么样的人拥有什么样的资源,承担什么样的责任,行使什么样的权利。

作为一个研发团队的负责人,需要梳理这些层,确定是否有合适的人,这些层的负责人形成了我们所说的「人才梯队」。

德鲁克曾说:「一个组织应该使每个人,特别是每个管理人员和每个专业人员(但也包括每个管理单位)都理解自身的任务」。 在我们做分层的过程中,需要关注每一层的职责和其解决的问题,如我们在软件架构设计的时候一样,每一个分层都有其作用,无用的分层只会增加性能的损耗。

对于将来,未雨绸缪。

当现在的人才正在发挥作用时,培养接班人,我们经常称之为 B 角。当有人才变动时可以快速补位上去。常用的方法有内部培养,跨团队轮岗,外部招聘等。

这块特别狠的可能要算宇宙厂了,在现有人员已经能满足工作需要的同时,会继续招聘,如果更优,可能会换人。

1.2.2 艰难的决定

在我们构建人才梯队的时候,想要做到知人善任是一件很难的事情,并且让每个人的表现都达到预期水平更难。当有些人并不能胜任他当前的工作时,我们应该怎么做?这里可能有以下两种常见的方式:

  1. 调岗,一般这种情况可能只是人岗不匹配,或者有些变化跟不上,但是对于人的部分能力还是比较认可。此时我们在公司内给他找一个匹配的岗位,更好地发挥其潜力。在技术团队最常见的例子是有些高 P 的技术同学,被推到管理岗,过了一段时间,发现适应不了,此时我们可以将其调到更能发挥其能力的岗位上来。又或者一些管理者因为团队扩大或者一些其它原因,管理的范围一下子增加了很多,一段时间后发现无法搞定这样的团队,此时可能将其调整到稍微低一级的职位上更合适一些。
  2. 离开,尽量让对方体面的离开,公司和个人都体面的分手,该赔偿的赔偿,该理解的理解,如果在外面有合适的机会,顺手推一把,也是个不错的善缘,不枉同事一场。这里经常出现的问题是犹豫不决,最终导致大家都不开心,不欢而散。管理上常说:「心要慈,刀要快」,就是要规避这种犹豫。

1.3 管理者自己

在用人中还包括管理者自己,一个技术管理者,不仅仅要注重技术,不仅仅要设定明确的目标并排出优先顺序,跟进过程发现问题解决问题,拿到结果,还要注意另一个重要的点:业务参与者。

一个优秀的管理者和一个不那么优秀的管理者的主要差别就是他们对业务的参与程度。事实证明,对所负责业务参与的程度越深,你就越能做出更加明智的决策。

什么叫业务参与度?

我认为它不是事无巨细地了解进展,应该到一线去,怎么到一线去,去写代码,去做代码评审?

到一线去,有两个层次,一个是业务的一线,用户或产品,看用户的反馈,产品的实现,二是工作的一线,看工作流程的卡点,系统化的情况,可视化的情况。不要自己去做这些事情,主要是收集信息,决策或者发现问题解决问题,这里确定做什么的原则是: 你做的事情的价值大小,而价值大小可以从时间杠杆,团队杠杆上来指数级扩大,如果做一件事只有短期的一件事的价值,那这些事情就不是你应该做的,应该停下来去思考要做的事情。

2. 组织

说到组织,你是想要一个「令行禁止,使命必达」的组织,还是一个「简单可依赖」的组织?

组织是为实现共同目标而采取的一种分工协作体系,是人与人之间的关系,组织结构往往会随着组织的重大战略调整而调整。

而企业在商场中求生,随着外部环境的变化,行业的变化,内部环境的演进而会不断进行迭代,不断调整组织结构,因此我们经常需要重新设计组织结构。

2.1 设计组织结构

我们在设计组织结构的时候通常要思考以下五个问题:

  1. 组织的目标是什么?因为组织是为了共同目标而存在的人与人的关系,目标不清楚,组织结构肯定也是不清楚的。
  2. 组织由哪些层,哪些单位组成?组织是一个体系,由不同的单元组成,需要明确各层或单元分别是什么,职责是什么,其作为一个子结构需要有自己的目标和使命。
  3. 组织各部分的规模和形式应该是怎样的?根据现实的情况,在设计组织结构时需要着重考虑规模和形式,多少层级?流程型?考虑管理者的有效管理幅度。
  4. 组织的哪些部分应该结合在一起,哪些部分应该分开?
  5. 组织内各单元之间的关系和协同应该是怎样的?

设计组织结构最难的问题可能是分和合的问题,这里有一个原则: 凡是做出同样的贡献的活动可以结合在一个部门中统一管理,不论它们的技术专业是什么。那些不是做出同样贡献的活动则一般不应合在一起。

在考虑组织结构,特别是研发团队的组织结构的时候,千万不可忽略了康威定律,甚至我们有时需要「逆康威定律」,通过适配康威定律,在明确技术架构方向的基础上,以组织结构的调整来推动技术架构的演进。

2.2 组织的形态

每家企业都有自己的文化和组织形式,抽象出来大致可以分为权力型,流程型和交易型,落到研发团队内部,一般只有前两种。

现在许多人强调去中心化、去科层化、去权力化,实际上,在大多数情形下,权力连接还是最直接、最简单、最有效的机制。权力组织讲究的是执行。

组织中的权力主要有四种。除了决策权,还有建议权、审核权和知情权。

  • 决策权,对一个事情决定资源投在哪里,是不是可以做的权力;
  • 建议权是提出方案、预案的权力。注意,这是一种权力:建议权拥有者如果未提出建议,上级决策者不能替代或强压;
  • 审核权是对有关事项程序性、合规性的审查与核准。注意,这种权力不是对事项进行决策;只要有关事项符合程序、合乎标准和规范就予以通过放行。我们经常会看到一些企业的职能管理部门把审核权误当成了批准决定权,导致审批流程变长、决策效率降低,这是需要反思改进的。
  • 知情权是信息共享权,即获取信息的权力。

以上 4 个权限很容易让我们想到项目管理里面的 RACI 矩阵:

  • 谁负责:(R = Responsible),即负责执行任务的角色,他/她具体负责操控项目、解决问题。
  • 谁批准:(A = Accountable,决策权),即对任务负全责的角色,只有经他/她同意或签署之后,项目才能得以进行,是整个事情的决策者;
  • 咨询谁:(C = Consulted,建议权),拥有完成项目所需的信息或能力的人员,多提出建议。
  • 通知谁: (I =Informed,知情权),即应及时被通知结果的人员,却不必向他/她咨询、征求意见。

以上四种权力,决策权和建议权是权力主线,审核权和知情权是权力副线。主线是上下级逻辑,副线是平级或流程型逻辑,而我们往往理解的权力是主线权力。

在强权力主线的基础上,权力型组织的有以下 3 个缺点:

  1. 唯上,组织内的成员对决定其资源或发展的上级负责;
  2. 组织的发展由上级决定,当上级缺位、能力不足或脱离实际时可能会出现瞎指挥,乱指挥的情况;
  3. 层级过多,导致执行和决策的效率低下。

为规避这些缺点我们需要减少层级,增加连接和协同。

如果把管理层只分为三级,我们一般称之为高层、中级和基层。这三个层要解决的问题不同。高层解决长期发展的问题,中层解决系统效率的问题,基层解决的是事情本身的问题。

比如技术管理者常规上可以分为三个大层:

  • 高层管理:解决长期发展的问题,使企业/团队有前途,关注的是未来,不管是技术发展的未来,还是业务发展的未来;
  • 中层管理:解决系统效率的问题,使系统更有效率,要不断强化研发流程的统一性和适应性,确定并执行好标准和规范,提升协同的效率,标准化和系统化,同时为上层的选择和决策提供依据和保障;
  • 基层管理:解决事情本身的问题,而事情往往会落到一线的开发同学身上,于是经常我们基层管理者的主要工作是使一线开发同学工作有成就,培养一线开发同学,提高他们承担工作的能力和意愿,帮助他们解决问题。

我们期望是每个层能做好自己的事情,但是实际上往往是高层在做中层的事情,中层在做基层的事,基层在做一线的事情,错位了。于是,我们需要将管理层归位,各行其职,更专业的做事情。

在明确职责的基础上,尽量减少管理的层级,尽量不要出现 「副XX」 的岗位。

在协同方面我们用流程来解决协同合作的问题。流程本身的逻辑是对事情负责,对自身的任务及向下事项/环节负责。其驱动力是责任感和依赖。百度文化里面的「简单可依赖」能较好地说明流程的底层逻辑。当我们使用流程来解决协同的问题时,要经常迭代流程以优化协同的效率:

  • 注意流程是为了解决过程中的问题,不是为了设置卡点,每个人都有扩大自己权力的欲望,这是我们在流程建设中要特别注意的;
  • 尽量减少流程环节,聚合责任主体,我们经常遇到一个事情在某职能部门还需要经过两三道审核的情况,这种损耗可以通过聚合责任主体的方式来解决;
  • 控制流程时长,这里控制流程时长还包括流程环节的前置准备,就和我们开会一样,如果开会前准备充分,会议本身的时长就有极大可能减少。

用权力解决「力出一孔」的问题,用流程解决协同合作的问题。

简单来说,在权力体系的基础上,用流程连接各环节和负责主体,现在比较常见的矩阵式组织结构基本符合这个逻辑。当然这里有一个以流程为主还是以权力为主的问题,具体是哪种,还得看公司当前组织结构的逻辑。

2.3 分工的粗和细

Adam Smith 在 1776 年的《国富论》中提出了分工,分工对于手工业生产效率有较大的提高,其总结了三个优点:

  • 熟练程度的增加,当一个人专注于一块工作,不停的练习极大的增加了熟练度,熟练度的增加将导致质量和产量的增加;
  • 当熟练后,人们对于重复的操作进行机械化或自动化,从而更大的提高质量和产量;
  • 分工明确了输入和输出,在明确的分工下,从一个工序转为另一个工序的时长减少了。

自从分工提出来了,产生了大量的争论,有人提出了以下的一些缺点:

  • 一叶障目,不见泰山,分工越细,所关注的东西都小,当人陷于某个事情越来越小的部分时,其大局观往往受限,可能会导致局部提升而全局受损的情况;
  • 分工越细意味着沟通协作成本的增加,当分工获得的收益小于沟通协作的收益时,将产生极大的成本浪费;
  • 分工一定关系到组织结构的分块,当沟通不畅或没有沟通时,有可能出现组织上的「孤岛」

分工落到一个研发团队,我们通常按编程语言分为 Java、PHP、C++、Javascript,或按端分为安卓端、iOS 端、前端、后端、算法、数据等,又或者大一点分为开发、测试、运维,架构师。

虽然「术业有专攻」,但多跨一步会让分工后的协同更高效一些,这里最常见的可能是测试左移和测试右移。

  • 测试左移是指在研发流程中,把测试的覆盖范围从传统的测试节点中释放出来,将其向左扩展,介入代码提测之前的部分,如开发阶段阶段,需求评审阶段,让研发人员在架构设计时就考虑产品的可测试性,并尽量进行开发自测,同时评估需求的质量,比如分析需求的合理性以及完整性等。
  • 测试右移是指把测试的覆盖范围从传统的测试环节中切出来,将其向右扩展,更多地融入代码部署、发布,甚至上线之后的步骤中。

更极端一些,走全栈路线,一个人从头到尾完成需求的所有工序。但是这种方式,对于人员素质的要求,对于团队组织的要求和常规不一样,且人的精力是有限的,能在每个方面都做到精通的,少之又少,除非所做的事情只需要略懂即可。

思考一下,你所在团队应该如何来做?

成本和效率?组织大小?技术发展?架构演进?

3. 机制

3.1 DRI 机制

3.1.1 DRI 的由来

DRI 是 Directly Responsible Individual 的简称,中文翻译为「直接负责人」。最开始是从苹果流传出来的内部管理概念。

DRI 不是流程、过程,也不是框架,而是一个负责人,对某部分的整体负责,小到 BUG,大到技术方向。 DRI 是为了解决责任主体的问题,其有助于避免责任分散。责任分散这个概念也被称为「旁观者效应」,也就是人们身处团队中时无法对某事负起责任,责任分散到了团队中的每个成员身上,而不是集中在真正有责任的人身上,因为每个人认为那个责任应该由其他人承担,表现得像一个旁观者。

3.1.2 DRI 的职责

  • 聚焦目标;
  • 督促、监督团队成员完成自己的任务;
  • 清楚团队中发生的一切;
  • 统筹策划,搞定所有的干系人,从头到尾负责到底,说简单点就是团队成员专注的做好手上的事儿, DRI 排除干扰,解决各种烦人的问题来,发现问题,解决问题;
  • 有一定的领导责任。

简单来说,当你是某个事情的 DRI 后,这个事情就是你自己的事情。特别是当职责不清或者突发问题时,DRI 就需要发挥主人翁的精神,拉起团队成员去分析问题,解决问题。

3.1.3 什么人适合做 DRI

DRI 和工作年限无关,和是否资深无关,和技术工种无关,你想你就是。

但是在操作过程中,我们会根据实际的场景做一些偏重。如果是一个后台的活儿居多的项目,其 DRI 大概率是后台的开发同学,如果是一个质量问题较多的项目,其 DRI 大概率是一个 QA 同学。

这里我们会充分考虑同学的主观意愿,有些同学想,有些同学不愿意,只想做好手上的工作,那么他做好他手上工作的 DRI 就可以了。

DRI 无关项目大小,无关职位高低,无关所在层级,每一件大事,小事都需要有一个 DRI,且只有一个 DRI

这玩意儿换成中文其实就是我们在标语里面经常看到的「责任到人」差不多,但是更强调责任主体的唯一性。

3.2 构建良好的协同机制

公元前 221 年,秦始皇用了十年的时间,先后灭了韩、赵、魏、楚、燕、齐六国,完成了统一中国的大业。在以后,他陆续颁布了多条律法,以稳固国家的统治,包括「书同文」、「车同轨」、「度同制」等。

一个国家,一个组织,要想成为一个高效执行的团队,一定要有标准,一定要有人告诉大家怎样做是对的。 落到我们团队管理,标准,流程是必须要做的,特别是当你的团队是由若干个团队整合或融合的时候。

3.2.1 统一标准规范

当你的团队是由原来多个业务的团队融合而成,大家原来都有做一些标准,现在我们需要按统一的标准达成共识并推行下去。又或者本来标准不完善,需要系统梳理标准来达到标准的统一。

行业标准一般是为了互联互通,而对于研发团队的研发过程来说,标准主要是为了减少过程中的认知成本,提升研发的效率,比如数据库规范,大家按统一的规范来设计数据库,当有其它同学接手你负责模块的时候,能减少在基本结构的认知成本,以及在一些模块间整合或数据迁移时,对于工作会比较友好一些。

标准是什么,标准是一件行为准则,其关注的是结果。

标准和规范一般是为了告诉人们什么是好的,关注的结果,而统一标准是为了让大家互联互通。

标准不是为了成功,而是为了让整个事情不至于太坏,尽量不出现重大的问题。 具体到研发团队,我们一般需要统一如下一些标准:

  • 研发过程
    • 代码风格规范
    • 数据库设计规范
    • 代码分干管理规范
    • 代码提交规范
    • 错误码规范
    • Code Review 标准
    • 代码权限管理规范
  • 沟通协同
    • 架构规范
    • 技术方案规范
    • 文档规范
    • 接口规范
  • 质量标准
    • 代码质量标准
    • 自动化测试标准
    • 测试质量标准
    • 线上质量标准
  • 性能标准
    • 服务端性能标准
    • 客户端性能标准
    • 前端性能标准
  • 安全标准
    • 信息安全标准
    • 代码安全标准
    • 数据安全标准
    • 线上安全标准

3.2.2 统一流程

流程是什么?

流程是基于时间线,有一定先后序列规则的完成一件事的过程。流程是线性的、连续的。

统一流程是什么?

统一流程就是把一些验证过的好的做事方式,好的经验通过流程的方式固化下来,防止大家重蹈覆辙,在一个坑里踩多次,并且为不熟悉的同学做好指导。

我们做任何一件事都是有流程的,有些是设计过的,有些是自然而然的,设计过的流程可能是别人的经验。并且流程需要持续迭代。

在研发管理中我们常常会构建的流程如下:

  • 敏捷流程
    • 需求迭代流程
    • 紧急需求流程
    • 值班需求流程
  • 研发流程
    • 代码审核流程
    • 代码发布流程
    • 紧急发布流程
  • 协同
    • 对接流程
    • 资源申请流程
    • 线上问题/告警处理流程
    • 事故处理流程
    • 安全问题处理流程

3.2.3 统一工具

以上说了要统一标准,统一流程,这些第一步是要把这些标准和流程做出来,形成文档,落到知识库中。 如果只做到这一步,这些标准和流程可能就真的只是一个文档,情况好一点,有人来推进重视,可能会落实一些,但一旦这个推进人不在了,或者不再关注了,很多形式就不了了之。

要解决这个问题只能通过工具或系统,以工具或系统的形式固化标准和流程,把这此好的经验和方式以更物理的方式沉淀下来。再以这些工具或系统为杠杆,提升整体研发的效率,创造增量的价值。

4. 系统

这里的系统不仅仅是指使用某个系统,在使用系统的基础上整合,实现我们高效执行的目的。 前面我们有了机制,但是事情太多,不能让所有的事情用人来去解决,需要用系统来解决。

机制解决规模化的问题,系统解决规模固化的问题。 系统解决的问题有两个层面,一个是过程跟进,一个是结果度量。

4.1 工作流和过程跟进系统

一个研发部门可以看作一个系统,需求从一端进入,经历各种正确的工序,才能变成产品,如期从另一边离开。 当系统内部存在冲突,或者不和,或者互相针对,那么就会发生各种想象不到的问题,从而让整个系统的产出变少,甚至没有。

着眼于整个工作流,确认瓶颈点在哪,尽可能的运用各种技术和流程来确保工作在计划内有效的执行。因为我们知道:在代码投产之前,实际上并未产生任何价值,因为那只是困在系统里的半成品。

在实际中我们如何让大家更好的协同,更好的让这个工作流运转起来呢?以前可能是 Excel、Word 或者 todolist,再加上邮件或 IM 传来传去,现在更进一步有在线的表格协同,还有更完整的项目管理系统,如 Jira 、Trello、腾讯的 TAPD、阿里的 Teambition、禅道等。工具不同,但是目标是相同的,都是希望做到对项目执行的管控、对团队事务(问题)的跟踪,对需要多人协作任务的快速流转和处理。

除此之外,还需要文档管理,即过程中的物料也需要跟进起来,关联起来。至于是一个系统,还是多个系统,都是可以的。

系统虽有,但用得怎么样不好说,一个好的系统用不起来也是白搭,这里作为管理者需要推动起来的。

4.2 工作可视化

项目管理的系统用起来后,我们的工作流转就会落到系统里面,此时根据系统的数据,我们可以让工作可视化,透明化,能够清晰的观察工作流动的情况,从而发现瓶颈。发现问题是最难的,很多时候我们不知道有什么问题,包括自己。发现问题,才能解决问题,方法总是有的。 在资源有限的情况下,对非约束点的改进看起来很正确,但实质上毫无帮助,甚至会消耗宝贵资源拖累真正需要解决的问题。

我们可以构建一些看板,看一个产品从产品到设计、到研发实现,到测试完成,上线发布,再到线上问题跟进等等的情况。看效率,看一个需求从出现想法到用户看到需要多少时间,每个环节需要多少时间,哪些需求在哪些环节停留太久?不同的需求,不同的人,不同的产品做多个层次的对比,从而发现问题解决问题,让一切都在阳光下进行。

同时,我们可以让系统和数据告诉我们,整体团队的投入如何,有多少同学的工作是可以追溯的,有多少人力是隐藏在不为人知的地方的,能看到我们的时间都去哪了。

基于这样的看板,我们从两个角度优化整个系统:

  • 从左到右的流动,看从产品、设计、研发到运维的工作情况。为了最大程度地优化工作流,需要将工作可视化,减小每批次大小和等待间隔,通过内建质量杜绝向下游传递缺陷,并持续地优化全局目标;
  • 从右向左的反馈,每个阶段中,应用持续、快速的工作反馈机制。通过放大反馈环防止问题复发,并缩短问题发现时间,实现快速修复。通过这种方式,我们能从源头控制质量,并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统,还可以在灾难性事故发生前就检测到并解决它。

总体来说,先透明出来,再优化,打开黑盒,问题会简单很多

4.3 其它

以上的两个是从任务跟进和结果度量的角度,或者说从项目管理的角度来看整个团队的运转。 换一个角度,从研发同学工作本身,有没有需要系统化的地方?

代码管理是否系统化,Code Review、接口文档、接口自动化测试、Mock 数据、测试数据集管理、用户数据自动脱敏重放,代码从写完提交到代码库之后到上线,线上巡查等等这些是否有系统化?

这并不是今天我们要讲的话题,但是就系统化来说,这些都是必不可少的关键点。不管是哪方面,我们的原则是尽量减少人工介入,把人的经验变成代码和系统。

5. 后记

这篇文章务虚居多,也比较散,但是确实是技术管理者日常工作中要不停思考的点。 思考这些是用来帮助厘清思路,并不具备实操性,也就是不能实际的解决问题。 不同的公司,不同团队,问题不同,解决的方法也不同,欢迎一起探讨。

打开「黑盒」,问题会简单很多。常思考人、组织、机制和系统,这 4 个方面,发现其中的问题,并厘清解决问题的思路,一步一步,有节奏的去解决。

你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: www.phppan.com