影响持续交付的因素

Posted 2021-01-15 erbiao

与绝大多数理论分析一样，影响持续交付的因素也可归结为：人（组织和文化），事（流程），物（架构）

组织与文化因素

什么样的组织文化，才是“持续交付”成长的沃土（当然这也是定义好的组织的标准），我把它分成了三个层次：
第一个层次：紧密配合，这是组织发展，部门合作的基础：一般企业都会按照职能划分部门。不同的职能产生不同的角色；不同的角色拥有不同的资源；不同的资源又产生不同的工作方式。这些不同的部门紧密配合，协同工作于共同的目标，就能达到成效。

第二个层次：集思广益，这就需要组织内各个不同部门，或不同职能的角色，跳出自身的“舒适区”。除思考和解决本身职能的问题外，各部门还要为达到组织的共同目标，通盘考虑和解决所遇到问题和困难。这个层次需要增加组织的透明度，需要接受互相批评和帮助。

第三个层次：自我驱动，是理想中的完美组织形式。如果第二个层次能够持续地运转，就会形成自我学习、自我驱动的飞轮效应，并且越转越快，它甚至能自发式的预见困难，并自驱动解决问题。

那么，在形成理想组织的实际执行中会遇到哪些问题呢？
一般软件企业与交付有关的研发部门包括四个：产品、开发、测试和运维。而这四个部门天然地形成了一个生产流水线，所以形成理想组织的第一层次紧密配合，基本没什么问题。 
但是，要达到第二层次集思广益的难度，往往就很大。因为，每个部门有自身的利益，以及自己的工作方式和目标：
    比如，产品人员和测试人员就是一对矛体：产品人员希望产品尽快上线，而测试人员则希望多留时间进行更完整的测试。 
    开发人员和运维人员也经常矛盾：开发人员希望能有完全权限，而运维人员却控制着生产的 root。

那么，靠各个部门自己能解决这个问题吗，其实很难。组织的问题，还是需要通过组织变革来解决。通常我们会采用以下三种方案： 
    1、成立项目管理办公室（Project Manage Office，简称 PMO）这样的监督型组织，帮助持续交付落地； 
    2、独立建立工程效能部门，全面负责包括持续交付在内的研发效率提升工作；
    3、使用敏捷形式，如 Scrum，打破职能部门间的“隔离墙”，以产品的形式组织团队，各团队自行推进持续交付

当然，这三种方案各有利弊,如：
    1、成立项目管理办公室，虽然会带来非常强大的项目推进力，但它往往需要通过流程把控进行监督，这样就很有可能把流程变得更加复杂；
    2、而独立的工程效能部门，虽然能最大化地去做好持续交付工作，但其研发成本的投入也是需要考虑的，小团队的话，就不太适用了； 
    3、敏捷形式是比较适合中小团队的一种组织变革方式，但对个人能力的要求也会比较高，而且往往需要一个很长时间的磨合才能见效。 
    
所以，你需要根据当前组织的情况来选择。总而言之，持续交付必须有与其相适应的组织和文化，否则将很难实施

流程因素

持续交付对企业和组织改变最多的是流程

持续交付一定会打破的这三类流程是：
    1、耗时较长的流程。
    2、完全人工的流程。完全人工操作的流程，一般效率低下，且难以保证质量。
    3、信息报备类流程。持续交付过程中同样会产生各种信息流，有些需要广播，有些需要定点传送，实施持续交付后，这些信息报备类的流程一定会通过异步消息的方式进行改造。

在持续交付过程中，最难处理的是审批流程，审批往往指的是由人审核和批准，即是一个全人工流程，又是一个信息流转类流程，那么如何打破它呢，有几种思路：
    1、审批流程是否确定需要，若能通过系统保证，则可以去除
    2、审批流程是否可从事前流程转为事后流程
    3、审批流程是否可以被简化

但是，每家公司的流程都不太一样，所以我的这几个思路并不一定是放诸四海而皆准，但我希望你可以借鉴。

架构因素

相对于组织文化和流程因素，架构是真正和技术相关的因素