标签：部门 好的 man 办公室 哪些 广播 选择 比较 使用
什么样的组织文化，才是“持续交付”成长的沃土（当然这也是定义好的组织的标准），我把它分成了三个层次：
第一个层次：紧密配合，这是组织发展，部门合作的基础：一般企业都会按照职能划分部门。不同的职能产生不同的角色；不同的角色拥有不同的资源；不同的资源又产生不同的工作方式。这些不同的部门紧密配合，协同工作于共同的目标，就能达到成效。
第二个层次：集思广益，这就需要组织内各个不同部门，或不同职能的角色，跳出自身的“舒适区”。除思考和解决本身职能的问题外，各部门还要为达到组织的共同目标，通盘考虑和解决所遇到问题和困难。这个层次需要增加组织的透明度，需要接受互相批评和帮助。
第三个层次：自我驱动，是理想中的完美组织形式。如果第二个层次能够持续地运转，就会形成自我学习、自我驱动的飞轮效应，并且越转越快，它甚至能自发式的预见困难，并自驱动解决问题。
那么，在形成理想组织的实际执行中会遇到哪些问题呢？
一般软件企业与交付有关的研发部门包括四个：产品、开发、测试和运维。而这四个部门天然地形成了一个生产流水线，所以形成理想组织的第一层次紧密配合，基本没什么问题。
但是，要达到第二层次集思广益的难度，往往就很大。因为，每个部门有自身的利益，以及自己的工作方式和目标：
比如，产品人员和测试人员就是一对矛体：产品人员希望产品尽快上线，而测试人员则希望多留时间进行更完整的测试。
开发人员和运维人员也经常矛盾：开发人员希望能有完全权限，而运维人员却控制着生产的 root。
那么，靠各个部门自己能解决这个问题吗，其实很难。组织的问题，还是需要通过组织变革来解决。通常我们会采用以下三种方案：
1、成立项目管理办公室（Project Manage Office，简称 PMO）这样的监督型组织，帮助持续交付落地；
2、独立建立工程效能部门，全面负责包括持续交付在内的研发效率提升工作；
3、使用敏捷形式，如 Scrum，打破职能部门间的“隔离墙”，以产品的形式组织团队，各团队自行推进持续交付
当然，这三种方案各有利弊,如：
1、成立项目管理办公室，虽然会带来非常强大的项目推进力，但它往往需要通过流程把控进行监督，这样就很有可能把流程变得更加复杂；
2、而独立的工程效能部门，虽然能最大化地去做好持续交付工作，但其研发成本的投入也是需要考虑的，小团队的话，就不太适用了；
3、敏捷形式是比较适合中小团队的一种组织变革方式，但对个人能力的要求也会比较高，而且往往需要一个很长时间的磨合才能见效。
所以，你需要根据当前组织的情况来选择。总而言之，持续交付必须有与其相适应的组织和文化，否则将很难实施持续交付一定会打破的这三类流程是：
1、耗时较长的流程。
2、完全人工的流程。完全人工操作的流程，一般效率低下，且难以保证质量。
3、信息报备类流程。持续交付过程中同样会产生各种信息流，有些需要广播，有些需要定点传送，实施持续交付后，这些信息报备类的流程一定会通过异步消息的方式进行改造。
在持续交付过程中，最难处理的是审批流程，审批往往指的是由人审核和批准，即是一个全人工流程，又是一个信息流转类流程，那么如何打破它呢，有几种思路：
1、审批流程是否确定需要，若能通过系统保证，则可以去除
2、审批流程是否可从事前流程转为事后流程
3、审批流程是否可以被简化
但是，每家公司的流程都不太一样，所以我的这几个思路并不一定是放诸四海而皆准，但我希望你可以借鉴。标签：部门 好的 man 办公室 哪些 广播 选择 比较 使用
原文地址：https://www.cnblogs.com/erbiao/p/9869923.html
