坚持正确的研发项目管理转型之路

近些年在国内的研发项目管理领域，有两个较为明显的趋势：一是伴随着 DevOps 运动的顺利发展，无论是何种类型的企业，是否采用敏捷开发，都已经在使用 DevOps 作为开发体系并配合一系列的工具和人员来进行项目管理；二是伴随着敏捷开发的普及，中大型的研发团队正面临规模化给项目管理带来的一系列问题与挑战。与这两个趋势相对应的，是国内企业的项目管理者在纷纷进行各自的转型升级，而相对于互联网企业来说，传统行业的研发项目管理转型之路则更具有代表性。

在帮助众多客户进行研发项目管理转型咨询的过程中，我们发现了一些在项目管理上做得较为成功的企业的共性特征：

01 比较先进的企业在践行 IT 定义业务

这样的模式可以帮助企业远远跑在其他企业前面。特别是在传统行业的某一个领域中，例如工业、消费领域，如果它能像互联网企业一样，用 IT 来定义自己的业务就意味着他已经把其他企业甩在了身后。

02 处在第二层次的企业在做 IT 帮助业务

主要是让 IT 提供一些数据，分析管理，仅仅把 IT 作为一种制度的固化和数据存储的平台，对企业的管理进行了一个赋能，节约了企业的管理成本和信息的成本。

03 疫情之下，公司暴露出哪些管理问题

业务的整个过程其实是不需要 IT 的，IT 团队的工作内容主要是一些仓库管理员或记录员的职能， IT 还没有作为企业业务的一部分。

这几个层次企业的区别，如果我们放在现在疫情的大背景下来看就是：后面两个层次的企业其实已经受到了更大的冲击与影响，因为 IT 并没有帮助他们完成一个在数字化时代疫情特殊情况下，通过远程办公来进行真正的协作办公和协作生产的效果。

但是如果你已经是 IT 定义业务的话，那么本身就意味着你已经是这个世界上一个唯一的供应商，在你所处的行业内就会有着垄断性的地位。

那么如何能让我们的企业做到软件定义业务，实现「IT Define Business」呢？顾宇也给出了他的一些建议。

首先在谈任何转型与升级的过程中，都要伴随着思维和工具两方面的改变。如果现在谈到 DevOps 仍然还处在工具链打通的阶段，这个组织的 DevOps 水平往往较低。工具往往是最好改变的，但是它产生的价值比较有限。短期内，三个月到六个月的时间，工具落地并适应后，DevOps 工具将会帮助大型的研发组织减少组织的沟通摩擦并提升企业的反馈速度，从而提升质量和加快交付速度。

在工具选择上，在保证安全性与灵活性的基础上与自身业务模式有相关性的工具是最好的选择，简单概括就是可以利用工具搭建起一套符合公司运作工作流，还有一个很重要的因素是这套工具最好可以实现在不同部门间流转，让跨部门跨团队形成有效信息流通。

而刚开始的研发效能提升中间蕴含着的是组织的变革。根据逆康威定律，你会得到一个符合 DevOps 的组织。但根据康威定律，组织也会对 DevOps 工具产生影响。究竟是组织影响工具还是工具影响组织，要看哪方的变更成本更大。

知名科技公司的组织架构

在工具落地建成的六个月之后，工具的投资可能就不会再产生新的价值，瓶颈也就随之而来。这就是经济学里的边际收益递减规律——只是单独增加某一要素，它的边际收益一定是逐渐递减的。很多企业也是在这个阶段数字化转型的脚步就停滞不前。接下来所能做的就是不断优化流程和不断地替换工具。而这些都不会带来质的转变，只有我能从上到下重新梳理我的企业数字化策略的时候才能带来质的改变。通过对产出价值的度量很容易得到这个结论。

DevOps 的主要阻力来自于组织内部的思想，特别是工作者自身的素质提升。做产品的思维和做项目的思维是不同的。做产品需要考虑如何用杠杆原理撬动最大的价值。而做项目则只是固定在一个回报率上，当然这个回报率也会随着竞争者的增加而递减。国内很多的组织的高管很难意识到自己是组织的瓶颈，即便是遇到了，也很难变革。每个企业都有自己的文化和基因，不可能通过复制另外一个企业而生存，也不可能把对方的高管挖过来而成功。都要走出自己的路。这个时候就需要外部顾问的力量。从第三方的角度来观察和提供那些被忽略的事实和“房间里的大象”。

____________________

现代管理学家德鲁克说：效率是“以正确的方式做事”，而效能则是“做正确的事”。