设计产品方法的组织，第2部分

在第1部分中 ，我建议当我们按职能进行组织时，认可和奖励可能会阻止成功的敏捷转型。 在这一部分中，我将讨论面向产品的组织的选项。

考虑一个面向产品的组织

与其按功能组织，不如考虑一个面向产品的组织。 再说一次，我并不是说这是产品组织的唯一方式，但这是有可能的。

高级经理负责整个产品线的损益（包括利润和损失），包括产品管理（针对该产品线），客户支持，培训等。

为什么？ 这样高级经理就可以决定产品和服务的组合是一条产品线。 高级经理是否应该在整个组织内工作以管理组织的项目组合？ 当然。 但是，请注意，该组织（通过中层经理）可以管理自己的项目组合，因为该组织拥有所需的每个人。

请注意，每个团队都有其所需的所有技能和能力。 这包括产品所有权。

每个团队不仅拥有所需的全部技能和能力，而且产品线也具有管理文化所需的全部技能和能力。 请注意，营销，财务，人力资源都是该产品线的一部分。 这些组可能具有“集中式”功能，但是开发和支持该产品的所有人员都在产品线中。

您需要多少位经理？

如果中层经理只能为一个团队服务，那么他们在工作人员和高级经理之间可能不需要另一层。 这取决于经理服务的功能集和产品团队的数量。

以我的经验，职能管理需要更多的经理。 这是因为职能经理必须将人员分配到团队中。 如果经理人员不足，则应该以某种方式“拆分”该人员。

产品线使用流动效率思维。 使用产品线，您可以在没有足够人手时轻松查看。 你是做什么？ 您可以决定如何管理团队缺乏所需能力和技能的风险。 您可以雇用。 团队的工作方式可能有所不同。 您可能暂时停止对该功能集或其他功能集进行工作，直到可以创建一个完整的团队为止。

您不会自欺欺人地认为自己可以“事半功倍”。 那从来都不是真的，我也不知道那是真的。

如果他们不再是职能经理，我将在后面的部分中讨论。 （我仍在起草中，因此我不承诺参与哪一部分！）

您的经理如何服务人员和产品？

我使用“充当仆人领导”一词。 我发现敏捷管理者在提出以下问题时可以成功：

• 如何使人们更容易做正确的事？
• 如何使更容易更快地交付高质量产品？

您可能需要更多问题。

几年前我曾担任这个职位。 我是导演 那时我对敏捷方法一无所知。 相反，这些项目使用分阶段交付生命周期 ，这是跨职能团队和每月演示的增量方法。 （这不是一种敏捷的方法，但是比瀑布更近。）

我想让人们容易地做正确的事情，例如工作的等级和工作所需的技术卓越性 。

我对给定产品线负责损益的唯一原因是该公司希望逐步淘汰该产品线，并用另一组产品替代它。 随着新产品线的增加，我本应优雅地管理日落。

很好 我们都知道我们必须做什么。

除此以外，新发展被推迟了。 我不再应该减速。 相反，我本应处于待命状态。

保留模式的问题在于它们不保留。 如果您不改进产品，则客户会开始等待新产品，而他们不会购买更多旧产品。 如果确实要通过新版本改进产品，则可以继续进行销售并增加支持合同。 用项目组合术语来说，这些是“按当前方向继续”项目。

我们没有让世界着火。 我们仍在研究仅剩余数年寿命的较旧产品。 但是，我注意到我们的吞吐量比拥有更典型的职能组织时要高得多。

我们都有一个共同的目标：使该产品线成功。 我们拥有了所需的所有人。 而且，我们有接近我们的市场营销和客户支持人员。 （客户支持不是并置的，但是他们与我们有着密切的联系。我们是一个庞大的“团队”，为了产品的良好而共同努力。）

明年我们发布了一些小型新产品。 我们增加了客户支持合同的百分比，并大大增加了新产品和支持的收入。 我们的客户很高兴。 我们的收入比上一年增长了25％。

怎么样？ 我们管理了项目组合，因此我们有一些小项目可以完成并移至下一个项目。

我们通过功能与团队合作来学习功能集的内部知识。 每当我们的排名发生变化时，就会经常有团队作为一个团队来帮助另一个项目。

我们将客户支持整合到我们的演示中，因此他们了解我们发布时将面临的挑战。 我们并不完美。 我们还不错。

新产品的人们陷入困境。 即使他们只有3个团队，他们都向不同的经理报告。 作为产品开发组织，他们没有一个目标。 中层管理人员和高级技术人员无法就产品的体系结构达成共识。 因为人们没有按功能集工作，所以他们什么也没做。 那是一场灾难。

认可和奖励并没有帮助情况

我做了一件“坏”的事情：我增加了我们本应停产的产品线的收入。 我不是一个人做。 我的整个产品线都取得了成功，因为我们拥有了我们需要的每个人，并且没有阻碍合作的障碍。 我们有一个明确的目标。 我们有负责工作的团队。 而且，我们没有太多拥有不同议程的经理。

我的同事在新产品线上？ 他们没有我们的流动效率优势。 他们的问题相当困难。 而且，他们有很多技术人员的经理。

为什么我“不好”？ 因为我“出现”了其他经理。 我与经理讨论了这个问题：他不是想要收入吗？ 嗯，是。 但不冒其他人自负的风险。 我公司将资源效率的思想转化为认可和奖励。

在第3部分中，我将讨论如何从产品线方法开始。而且，如果您看到了对您有用的其他组织原则，请告诉我。

翻译自: https://www.javacodegeeks.com/2018/10/designing-organization-product-approach-part-2.html