苹果开发者,变更组织
我们如何从基于项目的组织转变为产品组织？
我们至少需要更改两个工作系统：
- 管理体系与管理文化
- 团队的工作方式和团队文化。
我不确定解释是否这么简单。 可能还有更多我看不到的系统。
我已经注意到那些想要转向以产品为导向的方法的公司所面临的挑战：
- 奖励系统奖励资源效率，而不是流量效率。
- 该公司有很多经理：人员经理，项目经理，技术主管，架构师。 所有这些人都告诉团队该怎么做。
- 该公司没有足够的产品人员（产品经理，产品负责人，可以决定团队需要交付什么以及以什么顺序做出决定的人员）。
看起来很重要，对吧？ 它是。 我认为它类似于软件中的“泥泞大球”反模式。
我们需要改变团队和经理的行为。 而且，我们需要从慢开始，以便我们可以帮助人们尝试新的行为和习惯。 这样，人们可以及早学习。 （忘了快速失败的废话。没有人喜欢失败。我们喜欢学习。）
通过团队行为努力建立产品组织
我想知道第一件事是否是要了解我们当前系统的本质复杂性。 如果是这样，我们可以举一个例子为例。 我们在墙壁或木板的右侧写下该作品的名称。 现在，从右到左，我们确定创建该作品的所有步骤。 有关如何执行此操作的特定演练，请参见挖掘项目的延迟 。
经理的第一步服务是打破对其他团队的依赖。
如果我们把所有人都贡献给了这个交付成果，那么他们可以重新考虑组成团队的流程 。 他们可以看到决策滞后时间。 他们可以创建所需的团队。
您可能想看看我前一段时间写的Scaling系列 。 它具有如何执行此操作的更多详细信息。
提供经理新行为
我们如何降低管理复杂性？ 将经理的角色改组为在团队中管理/培养人际交往能力，产品业务价值以及通过实践社区不断学习的角色。 管理者从“控制”转向“服务”。
经理（职能经理，项目经理，Scrum Masters等）不对团队的成果负责。 经理帮助团队的过程。 这就是为什么经理不能成为该团队的产品负责人的原因（请参阅谁应该成为您的产品负责人？ ）。
这意味着我们必须改变对经理的奖励机制。 如果我们“让经理人对可交付成果负责”，他们将很少采取长远眼光。
当我们更改经理人的奖励机制时，他们可以彼此协作。 当我们改变职业阶梯时，更喜欢技术角色的人可以做到而不会赔钱。 当我们解释说我们需要更多的产品所有权（并适当地奖励该角色）时，有兴趣的人会搬到那里。
打破支持服务的集中化
当人们考虑迁移到产品组织时，我想问以下问题：
- 我们如何销售，生产和支持产品？
- 我们如何聘用，留住和整合人员？
这是本质：
我们如何优化为产品定位所做的一切？
答案之一是打破功能的集中化。
如果查看产品组织的图像（在本文顶部），您会看到产品组织在产品线中具有自己的客户支持，销售，人力资源，财务，市场营销功能。 没有人需要去找另一个副总裁来解决问题。
我确实认为这些功能支持产品开发活动。 它们仍然至关重要。 如果我们没有产品，我们将无法销售。 如果我们没有销售人员（或其他人员），那么我们建造什么都没关系。 其他所有功能都相同。 我们正在针对我们为客户销售，运输和支持的产品进行优化。
改变措施
经理经常通过团队完成特定日期的程度来衡量。 问题在于日期通常是任意的。 设置日期可能没有考虑发布的延迟成本。
取而代之的是，这里有一些可能是多维的度量，可以帮助人们思考流动效率：
- 功能，功能集，项目的延迟成本。 （是的，我们可能仍在产品组织中有项目。）如果我们了解延迟成本，则可能不需要日期。
- 功能的周期时间。 如果某个团队的周期时间超过一天，这就是一个症状：故事太大，代码混乱，测试不足，团队成员不足等。如果经理帮助团队解决此问题，则项目准备时间会减少，并且客户收到产品的速度更快。
- 功能，功能集，项目的交货时间。 交货时间越长，组织之间的协作就越少。 经理添加的东西超出了组织可以合理实现的范围（计划中的WIP过多），或者团队没有进行协作（出于多种原因），或者代码库，测试库，周期时间仍然存在问题， 和更多。 这是查看工作系统可以提供帮助的地方。
我不确定这些是唯一必要的措施。 我担心这里没有关于质量的特定信息。 对我来说，这是周期时间的一部分，但不是所有其他人都可以。 我在这里也没有任何关于会计的信息。
我将在最后一篇文章中做一个总结。
苹果开发者,变更组织