产品人员的 10 个扩张技巧

管理一个不断增长的产品既有挑战又有回报：让更多的人和团队参与进来并扩大规模绝非易事。本文分享 10 个实用技巧，帮助您作为产品负责人有效地扩大规模。

1 让合适的人参与

与许多缺乏必要专业知识和出于义务行事的个人相比，一小群拥有适当技能和积极性的合格个人可能更有成效。根据我的经验，对于产品人员和开发团队成员来说都是如此。因此，努力让合适的人参与进来。这将使您移动得更快，保持较小的时间更长，并且更具适应性。

虽然这听起来像是常识，但我见过不止一个组织试图通过让人们参与产品来完成更多工作。例如，我工作过的一家公司指派曾使用古老编程语言开发企业系统的开发人员使用最新技术开发全新的嵌入式产品。难怪个人会挣扎，产品会受到影响。

你的 Scrum Master 应该能够帮助你找到合适的人并解决任何可能阻碍你这样做的障碍——例如，在没有考虑他们的技能和动机的情况下分配个人。

2 不要过早扩大

我曾经从事一项新产品开发工作，从项目一开始就在三个地点分配了 100 多名开发人员。虽然最初没有足够的工作来让这么多人忙碌，但开发团队不想浪费时间并开始编写软件。这导致了一个臃肿、过于复杂的代码库和一个难以适应且维护成本高昂的产品。

与其过早地扩大规模，不如尽可能地保持规模小，直到接近产品市场契合度为止。这使您能够快速响应市场反馈、试验新想法，并进行任何可能需要的架构和技术更改，以进入增长阶段

3 建立一个 MVP

减少扩展需求的另一种好方法是推出最小可行产品 (MVP)。与雄心勃勃、功能丰富的产品相比，这样的产品通常需要更少的时间和更少的人员来开发。更重要的是，它可以更容易地适应市场反应，以实现产品与市场的契合。

您的产品可以有多小取决于它的市场。例如，就最初的 iPhone 而言，Apple 创造了一个新市场，因此可以提供相对简约的产品。将此与进入现有市场并直接与三星、Garmin 和 Fitbit 等公司的现有产品竞争的 Apple Watch 形成对比。

4 帮助开发团队自给自足

随着产品的增长，您的工作量通常也会增加：满足越来越多的用户需要付出更多的努力来了解他们通常异质的需求，并决定如何最好地解决这些问题。如果您的开发团队在此阶段仍需要接受详细的需求，那么您的工作量可能会变得不堪重负。

为了减轻这种风险，帮助开发团队尽早了解用户并了解他们的需求，例如，让团队成员参与用户研究（作为产品发现工作的一部分）并让他们尽早接触直接的用户反馈产品增量。这将使团队成员拥有解决方案并做出正确的用户体验和技术决策，提高人们的积极性，为增加更多团队奠定基础，并使您不必创建详细信息丰富的用户故事并在开发过程中仍然回答许多问题。冲刺。

5 有机生长

早在 1968 年，梅尔文康威就观察到“系统的结构与设计它的组织结构之间存在着非常密切的关系”。这意味着，如果您从三个开发团队开始，那么您的产品的软件架构可能会包含三个主要的子系统——无论该架构是否支持所需的用户体验和功能。

为了避免这种风险，从一个产品负责人、一个开发团队和一个 Scrum Master 开始。一旦验证了关键的用户体验和技术风险，就可以通过要求团队拆分来扩大规模。然后将更多的人加入到新组建的团队中。这种方法也称为 有机生长，因为它模仿生物体内的细胞分裂。

除了逃避上述康威定律之外，有机增长还提供了两个好处：它平均分散了让新人跟上速度的努力，而不是让一个没有生产力的开发团队与所有新手一起工作，并且它可以让你衡量影响在生产力和基础设施方面增加更多的人。

后者可能看起来相当乏味，但我曾与一家组织合作，该组织为了加速开发而一次性从三个开发团队增加到八个。不幸的是，没有人预料到基础设施无法应对新团队带来的网络流量增加。因此，签入和签出代码突然需要几分钟而不是几秒钟，这意味着开发速度大大降低，直到最终执行所需的升级工作。

6 雇用功能所有者和功能团队

当您将更多的人加入到开发工作中时，请考虑与特性团队合作——端到端实现功能的团队——而不是负责照管前端或持久层等架构构建块的组件团队。与组件团队相比，功能团队具有更少的团队间依赖性，并降低了次级优化的风险，以整体产品性能为代价优化单个架构构建块。然而，他们确实需要共享标准，以避免不希望的变化和代码重复：您通常不希望每个功能团队都使用自己的 UI 设计风格并编写已经开发的代码。

当您将功能团队添加到开发工作中时（希望通过有机增长），您还必须考虑对工作量的影响。我的经验表明，一个产品人员通常无法与三个以上的敏捷开发团队一起工作。因此，您将不得不考虑让可以拥有功能并指导功能团队的其他产品人员参与进来。我称这些人为 Feature Owners。下图显示了如何应用该角色。

7 从一个站点开始，逐步分配工作（如果需要）

虽然很难将合适的人召集到一起，但在软件开发中，没有什么比与分散的团队开始新产品开发工作更适得其反了——一个成员在不同地方工作的团队，例如，伦敦、波士顿和班加罗尔.

根据经验，存在的不确定性、变化和创新越多，参与开发工作的每个人都位于同一地点就越重要，包括产品负责人。这使您能够建立融洽的关系，建立有效的协作并就共享标准达成一致，例如，如何协作改进产品待办事项列表项并进行有效的冲刺审查。

因此，在一个地点与一个团队一起开始一项新产品开发工作。解决了关键的用户体验和技术风险后，如果需要，请考虑以逐步方式将工作分散到其他站点。这使您能够了解您必须如何改进您的实践才能在分布式设置中取得成功，包括通过视频会议举行的协作产品战略审查和产品积压改进会议

8 考虑分拆功能并创建产品变体

成长是一件有趣的事情。虽然这是一个值得庆祝的理由——产品终于进入了成长阶段并取得了成功——但我们现在必须应对日益庞大和多样化的目标群体、更加多样化的需求、更多的功能以及更多的开发团队。但它不必是这样的。

还记得 Facebook 在 2014 年拆分 Messenger 并将其作为独立应用推出吗？分拆是一种很好的技术，可以避免一个成功的产品变得越来越大，越来越多样化，并且需要越来越多的人来管理和开发它。相反，你创建了一个新的、专门的产品，有自己专门的产品人员和开发团队。

产品变体做类似的工作：但不是衍生出一个或多个功能，而是创建一个为特定目标群体量身定制的版本。以微软的图表工具 Visio 为例，该公司提供 Visio Standard 和 Visio Professional 的变体。每个变体都可以由一个单独的团队开发，并有自己的产品人员来照管它。

9 利用平台

平台捆绑共享资产，例如共享前端或后端组件或公共服务，如持久性、日志记录和安全性，并标准化它们的使用方式。使用平台在扩展上下文中有两个好处：首先，它鼓励重用并避免每个团队开发自己的日志服务的需要。其次，它创建并执行跨不同功能和团队的标准，例如通用用户界面设计。

创建平台时，您有两种选择：您可以采用集体所有制，并要求不同的功能团队共同维护和推进平台。或者，您可以通过专门的平台所有者和团队将平台作为产品单独管理。（请注意，平台所有者通常需要深入的技术技能，因为个人通常需要与功能团队讨论新界面和对现有界面的更改。）

我的建议是从集体所有制开始。这最大限度地提高了平台在支持面向最终用户的功能方面做得很好的机会，并最大限度地降低了构建难以使用和集成的雄心勃勃的平台的风险。如果平台发展壮大到需要集体维护和改进时，请考虑聘请专门的产品人员和开发团队。

10 永远不要在游戏后期扩大规模

成功地扩展需要仔细的深思熟虑和准备。它永远不应该是挽救陷入困境的开发工作的紧急措施，因为“在后期开发工作中增加人员会使事情变得更晚”（布鲁克定律）。

尽管如此，我曾与不止一个认为这项法律不适用于它的组织合作，并增加了更多人手以加速一个有可能错过目标日期的项目，结果发现这导致了额外的问题并延误了该项目更进一步。因此，请考虑其他选项来保存延迟项目，例如部分提供或删除功能以及推迟发布日期。缩放不应该是紧急措施。