传统组织如何转型敏捷组织
我一直在想我的客户已经成功地从基于项目/资源效率的组织转变为基于产品/流程效率的组织。 他们有以下共同点：
- 资深人士使经理们可以安全地进行实验。
- 他们创建了非常小的实验（经理或团队，或一起）。
高级经理经常问这样的问题：
您需要我什么，才能转到产品组织，我们在那儿优化产品流向客户的流程以及员工的满意度？
这是一个大问题。 这也是一个引人入胜的问题。 这个问题说明了预期的结果，但没有告诉人们如何实现。
那意味着没有食谱。
可能不适合您的三个选项
我的客户已经尝试了这些选项。 我不知道它们中的任何一个都适合您，但我提供了这些可能性。
选项1：从测量驱动变化开始。
一个组织改变了他们的测量。 测量的周期时间，交货时间，员工满意度（值得付出的工作）和客户满意度。
当他们在接下来的六个月内工作时（是的，这并不很快），一些经理要求成为产品所有者和产品经理。 一些经理要求成为技术主管或架构师。 一些经理离开了。
他们随着时间的推移不断发展组织，以实现他们想要的结果。
选项2：从重组开始。
在一个组织中，经理们直接进入了所需的最终状态，即围绕产品进行的重组。
经理们变成了一个自组织的管理团队，他们经过重组以扩大产品的商业价值并为人们创造令人满意的环境。 从第1天起，一些经理选择了转而担任各个团队职位，而不是经理。
管理人员作为一个团队（上下，左右）改变了薪酬体系和他们的测算方法。 （不要低估此步骤的价值和难度。）
同时，管理人员要求团队进行重组，以成为功能设定的团队。 （所有产品都超过一个团队。）
他们经历了大约三个月的混乱，然后一切都解决了。 当需要进行年度审查和薪酬时，他们在人力资源副总裁上遇到了很多麻烦。 高级经理不得不取消吵架。 他之所以成功，是因为该产品线赚了很多钱，HR同意了他们的新薪酬方式。
选项3：从团队开始。
一位高级经理（产品线经理）决定，他将要求团队自组织成功能集。 而且，他要求他们选择经理和产品负责人/产品经理。
团队很高兴。 许多经理人觉得他们的经理人已经放弃了他们。 另一方面，那些不是仆人领导的经理很快就选择了其他角色。
这些团队弄清楚了最初几周该做什么。 他们建立了有用的频繁交付方式。 经理们混乱了几个月，试图了解如何为组织提供帮助。 一些经理离开了。
产品线经理意识到他的组织过于扁平化。 他向团队寻求帮助。 他们要求再增加两名经理，并提供不同的仪表板。
团队在此转换方面几乎没有问题。 高级经理看到了他想要的结果。 而且，他说：“我不确定事情为什么会发生。 我担心我没有足够的见识。 我从没想过只有七个经理就能为100个人提供服务。 但是，每个经理都了解事情的运作方式。 我们现在还可以。 ”
变化需要时间和挑战我们许多人
每个组织失去了一些有价值的信息的有价值的人。
当团队成员离开时，团队发现他们可以相当快速地重构代码，并且如果他们合作可以更好地理解代码。
当其中一名开发经理离开时（“我不是产品所有者。而且，我不是管理测试人员。我是开发经理”），整个组织的人流量增加了。 是的，有些开发人员错过了与该开发经理的合作。 但是，这些人更喜欢他们的工作。
这些选择对他们组织中的所有人都不容易。 这是因为变化是个人的，是每个人都能控制的步伐，并且不是线性的。 （有关变更模型的完整说明，请参阅定义“扩展”敏捷，第6部分：创建敏捷组织 。）
一个组织尝试了选项3，但这些团队无法定期交付。 他们的实验太大。 这不是失败的安全。 该组织被收购了，到现在，大多数人都离开了。
对您的组织有什么影响？
成为产品组织不是目标。 目标是创造更多的商业价值，更快乐的客户和满意的员工。
如果经理可以作为一个协作团队工作，您是否需要改变他们的位置？ 他们可能需要更改他们的工作，因此体系结构看起来不像管理结构。
这是一个可能有帮助的问题：
您可以做的最小的实验是什么，以获取知识并了解对产品流程有什么帮助？
我不知道这个系列会这么长。
本系列的所有文章：
- 项目工作与产品工作 （我没有意识到我已经开始了本系列。）
- 产品定位需要技术卓越
- 设计产品方法的组织，第1部分
- 设计产品方法的组织，第2部分
- 定义产品方法的经理角色，第3部分
- 产品方法的可能更改，第4部分
- 产品方法可能的组织变更，第5部分
- 开始产品组织转型，第6部分
翻译自: https://www.javacodegeeks.com/2018/10/product-organization-part-6.html
传统组织如何转型敏捷组织