扩展屏幕使用技巧_产品人员的10个扩展技巧

扩展屏幕使用技巧

管理不断增长的产品既有挑战性，也有收获：使更多的人和团队参与进来并扩大规模从来都不容易。 本文分享了10条实用技巧，以帮助您有效地扩展产品负责人。

1让合适的人参与

一小撮具有适当技能和动机的合格个体比许多缺乏必要专业知识并无所作为的个体更有生产力。 根据我的经验，对于产品人员和开发团队成员都是如此。 因此，请努力让合适的人参与进来。 这将使您移动得更快，保持较小的空间更长的时间并且更具适应性。

尽管这听起来像是常识，但我已经看到不止一个组织试图通过将人们投入产品来完成更多工作。 例如，我与一家公司合作，分配了开发人员，他们使用古老的编程语言在企业系统上工作，以开发具有最新技术的全新嵌入式产品。 难怪个人挣扎，产品遭受损失。

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

2不要过早缩放

我曾经从事新产品开发工作，从项目开始就已经在三个地点分配了一百多名开发人员。 最初，没有足够的工作来保持这么多人的忙碌，而开发团队却不愿费力地开始编写软件。 这导致了base肿的，过于复杂的代码库，以及难以适应且维护成本昂贵的产品。

不要过早扩大规模，而要尽可能缩小规模，直到您接近产品市场适应性。 这使您可以快速响应市场反馈，尝试新想法，并进行进入增长阶段所需的任何体系结构和技术更改。

3建立MVP

减少规模需求的另一种好方法是推出最低可行的产品（MVP） 。 与更雄心勃勃，功能丰富的产品相比，这种产品通常需要更少的时间和更少的开发人员。 而且，可以更轻松地适应市场React，从而实现产品与市场的契合。

您的产品的最小数量取决于其市场。 例如，在原始iPhone的情况下，Apple开辟了一个新市场，因此可以提供相对简约的产品。 与Apple Watch形成鲜明对比的是，Apple Watch进入了现有市场，并直接与三星，Garmin和Fitbit等公司提供的成熟产品竞争。

4帮助开发团队实现自给自足

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

为了减轻这种风险，例如，通过使团队成员参与用户研究（作为产品发现工作的一部分 ）并使他们早日获得用户反馈 ，可以帮助开发团队尽快了解用户并了解他们的需求。产品增量 。 这将使团队成员拥有解决方案并做出正确的UX和技术决策，增加人们的动力，为添加更多团队奠定基础，并使您不必创建大量细节的用户故事，而在此过程中仍然可以回答许多问题冲刺。

5有机成长

早在1968年，梅尔文·康威（Melvin Conway）观察到“ 系统的结构与设计该系统的组织的结构之间存在非常密切的关系 。” 这意味着，如果从三个开发团队开始，则产品的软件体系结构可能将由三个主要子系统组成，无论该体系结构是否支持所需的用户体验和功能。

为避免这种风险，请从一名产品负责人，一个开发团队和一名Scrum Master开始。 确认主要的UX和技术风险后，请要求团队进行拆分以扩大规模。 然后将更多人添加到新组建的团队中。 这种方法也称为有机生长 ，因为它模仿了生物的细胞分裂。

除了逃避上述的《康威定律》外，有机增长还有两个好处：它平均分散了使新人们加快工作的精力，而不是与所有新手组成一支无能为力的开发团队，并且它使您可以衡量在生产力和基础设施方面增加更多的人员。

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

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

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

将功能团队添加到开发工作中（希望通过有机增长）时，您还必须考虑对工作量的影响。 我的经验表明，一个产品人员通常不能与三个以上的敏捷开发团队一起工作。 因此，您将不得不考虑让其他拥有产品功能并指导功能团队的产品人员参与。 我称这些人为特征所有者 。 下图显示了如何应用角色。 有关更多信息，请参阅我的文章“ 扩展产品所有者角色 ”。

7从一个站点开始，然后逐步分配工作（如有必要）

虽然很难找到合适的人，但是与在分散的团队中展开新产品开发工作相比，软件开发中几乎没有什么事与愿违的。该团队的成员在不同的地方工作，例如伦敦，波士顿和班加罗尔。

根据经验，不确定性，更改和创新越多，参与开发工作的每个人（包括产品负责人）在同一地点就越重要。 这使您可以建立融洽的关系，建立有效的协作关系，并就共享标准达成一致，例如，如何协作完善产品待办事项并进行有效的冲刺审核 。

因此，请一个团队在一个站点上开始新产品开发工作。 解决了主要的用户体验和技术风险后，如果需要，可以考虑将工作逐步扩展到其他站点。 这使您可以找到如何改进实践以使分布式设置成功的方法，包括协作产品策略审查和通过视频会议举行的产品积压改进会议。

8考虑取消捆绑功能并创建产品变体

增长是一件有趣的事。 尽管这是值得庆祝的理由-该产品终于进入了成长阶段并取得了成功-我们现在必须应付一个越来越庞大和多样化的目标群体，更多样化的需求，更多功能以及更多开发团队。 但这不一定是这种方式。

还记得Facebook在2014年对Messenger进行捆绑销售并将其作为独立应用程序启动时的情况吗？ 捆绑销售是一种很好的技术，可以避免成功的产品变得越来越大，种类越来越多，并且需要越来越多的人来管理和开发它。 取而代之的是，您需要拥有自己的专用产品人员和开发团队来创建新的专用产品。

产品变体可以完成类似的工作：但是，您不必创建一个或多个功能，而是创建一个针对特定目标群体的版本。 例如，微软的制图工具Visio，该公司提供了Visio Standard和Visio Professional的变体。 每个变体可以由一个单独的团队开发，并有自己的产品负责人。

9利用平台

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

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

我的建议是从集体所有权开始。 这最大程度地提高了平台在支持面向最终用户的功能方面所做的出色工作的机会，并且最大程度地降低了构建难以使用和集成的雄心勃勃的平台的风险。 如果平台已经发展壮大，可以集体维护和升级，请考虑雇用专门的产品人员和开发团队。

10永不扩展到游戏后期

成功扩展规模需要仔细的考虑和准备。 挽救陷入困境的开发工作绝不是紧急措施，因为“将人们添加到较晚的开发工作中会使工作变得更晚”（ 布鲁克定律 ）。

但是，我与一个以上的组织合作，认为该法律不适用于该法律，并增加了更多的人来加速有可能错过其目标日期的项目，只是发现这会导致其他问题并延迟该项目甚至进一步。 因此，请考虑使用其他选项来保存较新的项目，例如部分提供或删除功能以及推迟发布日期。 扩展不应是紧急措施。

翻译自: https://www.javacodegeeks.com/2019/04/scaling-tips-product-people.html

扩展屏幕使用技巧