写点什么

如何制定工程战略

作者:俞凡
  • 2024-06-10
    上海
  • 本文字数:3663 字

    阅读完需:约 12 分钟

本文介绍了领导者如何有效制定工程战略,包括理解战略核心、如何收集信息并制定可行的策略,以及如何利用行业最佳实践和技术债务管理来提升团队效能和产品质量。原文: How to Build Engineering Strategy



如果你了解过目标框架(如 OKR)背后的理论,通常会发现战略和目标应该是层层递进的。这类方法从公司使命和关键指标(KPI)开始,到公司目标,再到产品战略,然后将战略细分为团队或部门的具体目标。


然而,现实与理论却大相径庭。产品战略往往只是一份要实施的产品功能列表,并不包括技术债务、维护、SDLC 流程、自动化或工作方式等内容。在某些组织中,作为工程领导者,你是唯一知道需要做什么来提高产品整体质量、缩短上市时间和改进底层软件架构的人。只有你知道框架版本的支持何时结束,也知道数据存储解决方案的扩展性不佳,需要迁移。


根据我个人经验,作为技术负责人(公司的一级经理),我负责移动应用平台。尽管公司管理层知道想要提供什么样的产品,但只有我和我的团队知道如何打理我们构建的平台(维护、架构、自动化等)。


作为工程领导者,不仅要确保交给团队的产品任务得以执行,还意味着要制定计划,使团队的工作成果更加完美。为此,你需要有一个好的计划。



本文将探讨一些工具和技术,从而帮助我们制定长期工程战略。有些工具和技术在组织层面效果最佳,因为产品部门和技术部门可以合作应对挑战。有些工具和技术可以成功应用于团队层面,自下而上的激励组织的其他成员。


伟大的领导者都有计划


糟糕的领导者会执行,优秀的领导者会改进,而伟大的领导者则会整合。


整合不是即兴发挥,而是针对未来的战略挑战采取一整套连贯的行动。如果你想制定这样一个计划,理查德·鲁梅尔特(Richard Rumelt)的好战略/坏战略是最好的灵感来源。


虽然鲁梅尔特的著作主要侧重于整个组织的战略,但对较低层次的工程管理人员仍有借鉴意义。


即使作为一级领导(技术领导),也可以运用鲁梅尔特的见解为团队和技术栈制定 12-18 个月的计划。这种方法使团队能够重新构建解决方案、迁移技术栈、减少分心、集中精力、提高质量等等。


作为工程经理或技术主管,你已经负责管理部分技术堆栈、特定领域,甚至可能是整个产品。你应该有足够的背景来诊断问题、制定策略并选择具体的行动来推进工作。

什么是战略?

战略是为应对未来挑战而设计的对策。


理查德·鲁梅尔特认为,好的设计包含三个核心方面:


  • 准备(Anticipation):观察和学习。

  • 预谋(Premeditation):制定指导性政策,避免临时抱佛脚。

  • 设计协调行动(Design of Coordinated Actions):制定在空间和时间上协调一致的计划。


建立在这些方面基础上的战略框架侧重于对长期计划至关重要的三件事(理查德·鲁梅尔特称之为"战略内核"):


  • 诊断(The Diagnosis):了解现状,确定组织面临的主要挑战。

  • 指导政策(The Guiding Policy):规定组织或团队应对挑战的总体方法。

  • 一致行动(The Coherent Action):包括一系列旨在实施指导政策的协调行动。

如何制定战略

简而言之,包括四个步骤:


  • 收集输入(Collecting Input):收集有关优势、挑战、机遇、瓶颈、当前计划和干扰因素的信息。这些信息可能与团队、技术栈或组织(利益相关者、管理层等)提出的问题有关。

  • 战略模块分组(Strategic Blocks Grouping):对上一步的所有输入进行分类,考虑鲁梅尔特书中的战略要素,如杠杆作用、近似目标、利用优势等。

  • 构建战略内核(Build Strategy Kernel):根据收集和分类的信息,制定战略内核--诊断、指导政策和一致行动。

  • 迭代和完善(Iterate and Refine):收集输入、分组以及描述策略内核的过程可能需要数周时间,在此期间,应不断进行修改,并与团队和其他利益相关者分享,直到每个人都认为战略是合理的。


如需更全面的指南,建议查看实用工程管理(Practical Engineering Management),其中详细探讨了这一过程:工程战略框架

为战略献计献策

如果你想寻找战略模块的灵感和范例,还是推荐你参考理查德·鲁梅尔特,他列出了这些要点:


  • 关键目标(Leverage Objective):需要重点关注的最关键目标。

  • 阶段目标(Proximate Objective):尽管存在模糊性和复杂性,但仍足够接近可行的目标。

  • 链条中最薄弱的环节(Weakest Link in Chain):首先需要解决的限制因素。

  • 设计的力量(Power of Design):决定是将资源和工作结合起来还是分离开来。

  • 利用优势(Using Advantage):利用你的优势和机会。

  • 屹立潮头(Riding the Wave of Change):识别和评估行业和环境重大变化的早期迹象。

  • 了解惯性和熵(Understanding Inertia and Entropy):惯性是组织内部对变革的抵制,熵是系统和组织走向无序的趋势,

战略模块示例

下面是软件工程实践中的几个例子:


关键目标/修复干扰因素 -- 去除阻碍工程师进入心流状态的障碍。可能包括在开放空间环境中使用降噪耳机,或减少告警系统噪音,从而避免每天数十次的错误告警。还可能包括重新安排团队日程表,让每位工程师每天至少有 4 小时专注工作,或者限制正在进行的工作--"停止开始,开始完成(stop starting, start finishing)"。


题外话:心流状态是开发人员体验的关键因素。 请在 Abi NodaDevEx 框架中阅读更多相关信息。



阶段目标/改造 SDLC 流程 -- 最终目标--真正的持续交付或部署--往往过于雄心勃勃,难以一蹴而就。首先,必须将其分解为可实现的步骤,如良好的测试实践、发布和回滚解决方案、良好的监控和告警、软件稳定性等,其中每个步骤本身都可以是一个阶段目标。



链条中的薄弱环节/技术债务 -- 技术债务分类是一个真正的链条中的薄弱环节。总有一些工作要做--系统解耦、库更新、重构。在这里,主要工作就是找出最拖后腿的部分。为了进行分类,可以参考十种技术债务类型



有关行业和软件工程实践中的更多示例,以及关键目标、阶段目标或链条中的薄弱环节等反模式,建议查看工程战略的战略模块示例

信息来源

在制定战略时,可以利用无数的信息来源:一对一交流、人们的反馈、产品战略背景、分类技术债务等等。如需灵感,建议查看 Practical Engineering Management 上的这些文章:


工程领导者的信息信号 -- 知识来源可分为三类:拥有的知识(你已经知道的)、外部来源(在公司外部可以观察到的)和内部信号(公司的数据、洞察力、仪表盘)。作为工程领导者,你的任务是:a)为捕捉内部信号奠定坚实的基础;b)利用这些数据推动决策和长期战略。



掌握反馈 -- 反馈是一种特殊的知识来源,其并不总是经验事实,而往往只是意见、信念和个人看法。尽管这些信息并不总是量化的,但往往与遥测数据和产品仪表盘上的数据一样具有洞察力。如果没有收到反馈,并不意味着没有什么需要改变的,也许只是意味着没有与你分享的空间。作为工程领导者,必须在给予和接受反馈这两方面都游刃有余。


结构化信息来源

DevOps 文化 -- 科技行业尽管日新月异,但全球数以千计的成功企业积累了数十年经验和最佳实践。尽管大多数科技企业都认为自己是独一无二的,但通常都会解决经典的、众所周知的软件工程问题。这意味着有许多经过验证的实践也可以在你的组织中发挥作用--与其重新发明轮子,可以采用现有的行业标准,以满足我们的需求。


要制定长期计划,可以采用 DevOps 文化,这是一种促进工程团队和其他团队协作和分担责任的思维模式,帮助团队快速可靠的交付高质量软件。


以下是值得在团队中评估的 DevOps 文化的几个因素:


  • 注重高度信任的文化和协作学习的环境。

  • 围绕自动化、CI/CD 和遥测的开发实践。

  • 团队架构和流程注重独立性和长期目标。

  • 可预测的部署和发布管理。

  • 每个人都对质量负责的弹性组织。

  • 以成果而非任务为导向。


如果想对 DevOps 文化进行全面自我评估,以便更轻松的制定工程战略,建议查看 Practical Engineering Management 上的资料和模板:DevOps 文化清单



技术债务分类 -- 有些公司,如 Google 或 Thoughtworks,已经制定了自己的技术债务分类,采用它们的框架可以帮助你找到适合你的软件工程战略的模块。


以下是谷歌定义的十种类型:


  • 需要迁移或正在迁移

  • 项目和应用程序接口 (API) 文档

  • 测试

  • 代码质量

  • 死代码和/或废弃代码

  • 代码退化

  • 团队缺乏必要的专业知识

  • 依赖关系

  • 执行不力或放弃迁移

  • 释放过程

结束语

为团队和技术制定良好的工程战略是最具挑战性和最耗时的工作之一。然而,有了这样一个计划,你就能成为一个真正有影响力的领导者,从而带来巨大的变化。


在我担任工程总监、工程主管和工程经理/技术领导的职业生涯中,制定了多种战略。最成功的战略充分利用了从理查德·鲁梅尔特(Richard Rumelt)所著的好战略/坏战略一书中吸取的经验教训。


希望这里分享的资料能激励你制定自己的长期计划,并成为一名能扩大影响力的领导者。




你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!

发布于: 刚刚阅读数: 2
用户头像

俞凡

关注

公众号:DeepNoMind 2017-10-18 加入

俞凡,Mavenir Systems研发总监,关注高可用架构、高性能服务、5G、人工智能、区块链、DevOps、Agile等。公众号:DeepNoMind

评论

发布
暂无评论
如何制定工程战略_团队管理_俞凡_InfoQ写作社区