了解某些功能无法交付的原因通常很困难。管理层可能会责怪技术团队，而技术团队又会指责管理层。与此同时，业务部门夹在中间，试图找出根本原因，同时不顾一切地追求成果。这种情况通常发生在公司大幅增长之后，或者之前很容易解决的问题随着时间的推移而被忽视的时候。人们普遍误以为科技公司的所有问题都是纯技术性的；这远非事实。

在本文中，我将概述公司组织内可能严重阻碍功能交付的领域。我还将建议调查方向，以确定根本原因，然后可以在您的权限范围内上报或解决。

在实施任何变革或改进之前，了解我们的工作环境至关重要。尽管关于这个主题已经有很多富有洞察力的书籍，但并非所有方法都适合每家公司。这并不是说我们做错了什么，而是承认每家公司都有其独特性。

需要注意的是，这里分享的见解主要与软件开发有关，最适用于拥有 50 名或更多员工的公司或部门。

组织结构

首先，了解公司的规模和结构。确定各个部门并明确您对每个部门的期望。评估所有这些部门是否都是必要的。创建组织结构图，详细说明每个部门及其角色，确保您了解他们做什么以及他们存在的原因。通常，每个部门都由几个团队组成——也将这些团队包含在您的图表中，但暂时不要描述它们，只保留团队名称。

随着公司的发展，组织结构会变得复杂，难以跟踪进展。在这种复杂性中，您可能会忘记创建某些部门或团队的初衷。一些团队可能是为了解决不再相关的问题而成立的。以下是高层次上的情况。

一旦你有了清晰的组织结构图，下一步该做什么？

员工层级

接下来，绘制员工层级结构至关重要。了解谁向谁汇报以及为什么汇报至关重要。无论是管理大型业务部门还是小型团队，直线经理都需要与下属进行有效沟通。沟通应该清晰，无论是使用技术语言还是业务语言，因为处理这两种语言都很有挑战性。在较大的公司中，可能会有直接和职能经理负责不同的职责范围，这应该在层级图中清楚地表示出来。

员工层级不仅可以明确报告路线，还有助于识别组织内的垂直部门。垂直部门是跨多个部门（例如设计师、人力资源、DevOps 甚至开发人员）的共享资源的层级结构。虽然垂直部门可能非常有益，但有时也会成为瓶颈，尤其是当开发人员从事不同的项目并向不熟悉业务目标或技术挑战的经理汇报时。结果，开发人员得不到适当的反馈，经理没有适当的背景。因此，了解层次结构对于识别和分析潜在问题或任务的优先级至关重要。最后你会得到这样的结果。

注解

CEO —— 首席执行官
CPO——首席产品官
CTO-首席技术官
COO——首席运营官
HD — 设计主管
PO——产品负责人
HE — 工程主管
HS — 销售主管
HM — 营销主管
D — 开发人员
PM——产品经理
TL — 技术主管
EM — 工程经理
S — 销售经理
M — 营销人员

将您的组织结构与您的报告线进行比较，以深入了解每位员工参与各种活动的情况。此外，将您的组织结构与员工层级保持一致可以帮助确定个人是否在同一部门和团队内工作并朝着共同的目标努力。映射模板完全由您决定，但可以像这样。

团队职责

明确定义每个团队的运营领域非常重要。如果团队使用代码，请指定他们使用的服务和他们拥有的服务。令人惊讶的是，这些服务通常可能不同。确定团队是否仅在一个部门内运营，或者是否是一个平台团队，致力于其他团队使用的核心功能，而不会直接改变它们。

创建一个表格会非常有用，其中包含以下列：团队名称、部门、拥有的服务列表、团队可以修改但不拥有的一般服务列表（理想情况下，不应有此类服务）以及简短描述。此表将帮助您检查是否有多个团队在同一个代码库上工作，从而导致冲突，或者他们的责任范围是否不明确。它还可以揭示团队是否主要在修复错误或涉足各种任务而没有明确的重点。

这种详细程度对于识别团队职责的重叠、冲突和差距至关重要，确保更顺畅的协作和更高效的项目执行。

员工职责

除了描述团队之外，了解一般员工的职位并准备一份详细的职责描述也很重要。管理层的设想通常与员工实际所做的工作大不相同。软件开发行业有各种各样的职位，不同公司的期望也大不相同。例如，工程经理的角色可能有很大差异，更不用说交付经理、数据科学家、架构师、技术主管等角色了。在一些公司，一个人可能需要承担多个角色。

为每个职位设定明确的期望至关重要。这种清晰性不仅有助于正确跟踪活动，而且还能确保员工了解对他们的期望以及哪些超出了他们的范围。这适用于组织内的所有职位。明确的角色定义有助于防止重叠、减少混乱，并确保每个人都以高效、有组织的方式朝着共同的目标努力。

功能交付流程

到目前为止，您应该已经清楚了解了公司结构、员工层级及其职责。虽然事情可能看起来令人困惑，但目标是在进行任何更改之前先了解当前状态。现在，是时候描述您的功能交付流程了——业务功能如何从最初的想法转变为生产。

请不要关注 CI/CD 等技术方面，而应关注从业务到开发人员的流程，假设开发人员编写代码并将其直接部署到生产中。目的是识别从业务到团队的流程中存在的问题，并查看员工的配合程度。

请考虑以下方面：

• 您多久规划一次新功能并为每个部门和团队分配工作？
• 您如何设定和衡量关键绩效指标？
• 您是否使用里程碑？谁参与了里程碑的初始准备？您如何与团队一起规划里程碑？
• 谁协调规划和执行过程？
• 你们真的是一家敏捷公司吗？你们使用 SAFe、Prince2 或 PMP 等框架吗？或者你们有适合自己的定制框架吗？
• 您如何处理跨团队的复杂任务并控制进度？您是否采用结构化方法，还是依靠以某种方式解决问题？

请记住，无论方向如何，每个管理和报告级别都会增加复杂性和不确定性。最终，您的流程图应该回答一个简单的问题：“如何？”

您可以使用模板并根据自己的需要进行调整。这是交付流程的高级示例，没有监管交付的关键参与者，但有时间限制。

如果您不确定如何创建此图表，请考虑使用 BPMN（业务流程模型和符号）或更简单的格式（如矩形和线条），以确保所有利益相关者的清晰度和理解度。关键是要使流程清晰易懂。

收集反馈

规划好公司结构、员工层级、团队和职位职责以及交付流程后，请与组织分享您的所有发现并进行调查，最好是匿名调查。此基准突显了贵公司的运营方式。虽然您可能自己准备了此概述或委派了一些任务，但开发人员、设计师和分析师可能并未直接参与。他们的反馈对于评估您的发现的准确性至关重要。

让员工评估文档的质量。他们对交付流程有何看法？它是否真实反映了工作完成情况？他们在哪里看到了障碍？

您会收到各种各样的投诉和反馈，它们将帮助您完善调查结果，使其更符合公司运营的实际情况。这种反馈至关重要，因为背景信息通常会在多个层级之间丢失，而收集来自各个层级的意见将提供更清晰、更准确的组织图景。

估算结果

现在，您已经全面了解了公司或部门的运作方式，您可以开始分析和寻找潜在问题。此基准为理解和解决问题提供了清晰的起点。

以下是一些需要重点关注的领域：

• 你们的部门结构合理吗？报告线清晰吗？
• 直线经理真的能针对其职责范围提供反馈吗？
• 将业务需求转化为技术任务是否存在混乱或不确定性？
• 是否存在对其他团队的依赖从而导致开发延迟？
• 员工是否参与了其主要职责范围之外的活动，从而妨碍了他们的主要任务？
• 员工层级与团队结构的契合程度如何？
• 报告层次是否有效，或者是否存在沟通和背景的差距？
• 不同的团队是否在处理相同的服务，从而导致冲突并在决定任务所有权时浪费时间？
• 是否存在职责不明确或缺少关键人员的团队或部门？
• 有些团队是否没有融入任何部门？

最后，您可以准备一份公司实际存在问题的清单，这是您将要解决的问题。按优先级从需要立即互动的关键问题到“值得改进”的问题。

如何做出改变

您可能会想，“这一切听起来很棒，但我如何才能真正改善现状？”这是个好问题，诚实的回答取决于您发现的具体问题和您的业务需求。但是，一个关键的建议是避免试图一次性改变一切。相反，逐步实施小的改变，评估结果并进行迭代。请记住，敏捷方法不仅适用于软件开发，还可以应用于任何类型的组织变革。

以下是指导您的改进过程的一些步骤：

• 确保员工清楚地了解自己的职责范围以及超出自己职责范围的内容。
• 创建明确定义的部门或域，并为每个域分配特定的团队。
• 定义明确的责任范围并尽量减少部门和团队的重叠。
• 考虑熟悉团队拓扑方法，该方法引入了平台、流程一致、支持和复杂子系统团队来涵盖软件开发的各个方面。
• 审查并调整您的员工层次结构以适应新建立的领域和团队。
• 确保报告结构清晰、进度跟踪简单。
• 选择将用于功能交付和跟踪结果的方法或框架。
• 测试任何部门的变化（最好不是关键部门）并评估影响，根据反馈和结果改进您的方法。
• 通过将选择的思维方式应用于组织变革来不断改进。

通过遵循这些步骤，您可以做出明智的、渐进的改变，逐步提高组织的效率和效力。

概括

我的目的是强调任何公司或部门都可能出现的常见问题。我有意避免推荐特定的框架或方法，因为每家公司都有独特的目标和结构，决定哪种方法最适合您至关重要。

再次强调，我们很容易将责任推到开发人员身上，但请记住，他们可能没有意识到业务优先级，或者被不明确的交付流程所阻碍。有时，业务本身也会无意识地制造阻碍。我希望本文能帮助迈出改进的第一步。