@Rays
2018-07-04T00:48:19.000000Z
字数 2706
阅读 1386
DevOps
摘要： 在DevOps Enterprise伦敦峰会上，Carmen DeArdo和Nicole Bryan做演讲介绍了组织从项目导向转变产品导向的重要性。DeArdo曾任Nationwide Insurance的DevOps技术主管，Bryan是Tasktop的产品管理副总。
作者： Manuel Pais
正文：
在DevOps Enterprise伦敦峰会上，Carmen DeArdo和Nicole Bryan做演讲介绍了组织从项目导向转变产品导向的重要性（此处提供演讲幻灯片pdf文件下载）。DeArdo曾任Nationwide Insurance的DevOps技术主管，Bryan是Tasktop的产品管理副总。以项目为导向做出规划和预算，会导致IT和业务愿景间的脱节（IT在其中被视为成本中心和黑箱）、追踪行为而非输出、项目预算僵化等问题，这不适合当前在策略和方向上的改变速度。
以产品为导向是具有挑战性的，需要全面对管理预算、规划、团队、优先事项、可见性和风险实施新方法。InfoQ就这些挑战性问题采访了DeArdo。
InfoQ：您为什么建议应从项目导向转向产品导向？您能给出一个“项目出错”的现实例子吗？
Carmen DeArdo：在演讲的一开始，我们就提到了五个挑战，其中部分挑战源自于将IT视为“成本中心”，而非一种生成利润的关键能力。一个原因在于，IT看上去似乎是与业务愿景和战略脱节的。虽然企业（无休止地）试图建立业务与IT目标间的映射关系，但两者间的正常关联往往并不会为人所察觉。通过组建由业务和IT人员构成并直接共事的的产品团队，不仅可实现业务功能，而且还可以提供对业务的洞察，以深入了解在风险、缺陷和债务方面需要优先考虑的其它因素，并有助于实现业务上的直接协调。
对于项目出错的问题，我认为更多在于人们往往并未看到和优先考虑一些重要事项，即使这些事项可以对业务产生重大的影响，例如风险缓解等（Equifax事件就是一个例子）。在开发（Dev）和运维（Ops）之间存在孤岛（Silo），这将会导致问题。对于业务和开发之间，同样也是如此。项目结构总是趋向于在各种类型的工作和优先事项之间创建相同类型的孤岛，这些孤岛需要从整体上得到解决。
InfoQ： 这是否意味着不应再使用项目去规划我们的工作？
DeArdo：不。我认为Jon Smart在他的演讲中说得很好，“PMO已死。PMO永垂不朽”。我在贝尔实验室工作时，我们通过项目创造新的产品。所以，我从来不认为项目是没有必要的。而是项目导向的结构需要改进，以支持更好地完成产品。
InfoQ：从您的经验看，要在工作管理方法中实现上述改变，前三位的最大障碍是什么？
DeArdo： 在我们的演讲中，提出了在从项目导向转向产品导向过程中需要解决的七个方面问题。根据特定的企业现状和文化，排位前三的问题会发生变化。在我看来，我认为预算、成功（将IT视为一个成本需要降低的成本中心）以及团队工作方法（将工作赋予团队，而不是按项目组建团队）是排名前三位的问题。首要的挑战是如何围绕业务建立团队，并对从业务角度定义产品以提供支持。
InfoQ： 从预算的角度看，您认为产品导向具有哪些特定方法和优点？
DeArdo：人们已经意识到，对于一些组织而言，年度预算可能是必要的。但这并非是让企业去为数以百计的机会提供资金（有时甚至需要提前18个月做出预算），而是应为产品投资提供资金，然后让产品经理去确定其中的优先事项。我在贝尔实验室工作时，每个项目会三个月就重新审核一次，以确定是否需要更改产品资金。
Jon Smart在演讲中谈及了一种投资组合管理的敏捷方法。如果我们的价值流中实际上只有一小部分具有无论何种敏捷性，那么就不能说我们做到了敏捷。要真正地实现敏捷，必须从预算和项目组合管理流程着手。
InfoQ：您如何定义产品？
DeArdo：产品包括业务产品和IT产品。产品是具有为客户群提供价值的任何事务。我认为，过去我们并未按对待业务产品那样对待IT产品（例如，部署流水线），这就产生了问题。
InfoQ： 在演讲中您提到将员工看成是一个“资源池”并从中抽人去做项目的做法存在缺点。那么更好的替代做法是什么？产品导向对此有何帮助？
DeArdo： 一旦确定应该对产品做怎样的投资，我们就可以为支持该产品的主要团队提供资金。但需要注意的是，我们还谈及了这样的一个事实：让一个“双披萨”（two-pizza）团队完成某个特定产品的所有工作，这无疑是一个“童话故事”。但是，团队必须具有产品相关的跨技能资源。此后，一旦资金发生变化，如果我们确实实现了敏捷，那么我们就可以相应地调配人员。我认为这说起来容易做起来难，但它应该作为一个目标。
如果一个过程需要30天、60天和90天的“需求”视图，并具有长期SLA履行流程，那么该过程无论从任何意义上讲都不是敏捷的，不支持日益增长的对业务需求做出快速响应的需求。
InfoQ：您如何定义价值流？为什么说让工作和团队与价值流保持一致是非常重要的？
DeArdo：价值流是聚焦于为特定客户提供“价值”的一系列活动以及所花费的时间。价值流以客户为出发点和终止点。
价值流之所以非常重要，是因为任何企业的关注点都是为客户创造价值。价值流是实现该目标的一种机制。
InfoQ： 价值流和业务领域间具有怎样的关系？
DeArdo：如上所述，重要的是使业务产品与产品团队保持一致。许多领域中需解决的复杂问题在于，当前人们尚不清楚哪些会导致局部优化，而实际上并没有改善客户的价值流。
InfoQ： 产品导向如何能做到更好地管理和缓解风险？如果风险并未映射到某个特定项目，是否存在“遗忘”风险的可能性？
DeArdo：风险在本质上是与产品相关的。例如，如果我不为自己家用车更换机油或做其它维护，那么车辆就会出现故障。每辆车的风险的类型和发生时间都不尽相同。相对于每个交通产品具有自己的一套行为，包括风险（例如，召回）和维护（债务）活动，甚至可能是添加Sirus XM等“特性”，将这些风险整体作为“交通”项目的一部分要更加麻烦。
产品负责人（Product Owner）最好能够针对产品的最佳选择进行“系统思考”。在不断被优先处理和追踪的各种类型工作之间，存在着可见性。
最后一点，项目经理通常会因为能以最低代价交付业务功能而受到奖励。对于一个发布中的持续改进系统，在安全修复程序上付出代价并不符合这一目标。以产品为导向，使产品负责人得以在激励机制不发生相互冲突的情况下开展管理工作。