对比产品筹资和项目筹资

  • Rafiq Gemmail
  • 盖磊

2017 年 12 月 11 日

话题:语言 & 开发架构文化 & 方法

近期在Martin Fowler 的个人网站上,发表了一篇名为“对比产品与项目”(Products over Projects)的文章,比较了项目筹资(Project Funding)团队和产品筹资(Product Funding)团队。文章作者是Sriram Narayan,他也是《敏捷 IT 组织设计》(“Agile IT Organisation Design”)一书的作者。文中 Narayan 提出了“产品模式”(product-mode)的概念,指在长效团队中,筹资和交付是与推出产品紧密契合的。此外,Jeff Gothelf 最近也撰文谈及了以产品为中心的团队的优点。Gothelf 是《精益用户体验》(“Lean-UX”)和《感知与响应》(“Sense and Respond”)这两本书的作者。同时,敏捷评论员(Agile commentator)Leon Tranter 也撰文指出,项目筹资模式是导致他称之为“产品技术破产”问题的因素之一。

Narayan 在文中写道,一直以来项目筹资根据的都是“业务的预期收益”和“从大量优秀人才中招聘的员工”,筹资的目的在于“建立或增强某个系统或应用,并继续推进它们”。与此相对应,Narayan 将产品模式下的团队筹资描述为:

团队筹资针对的是一段时期内的某个特定业务问题或产品,工作的性质并非取决于要交付的一系列功能,而是取决于要解决的业务问题定义。我们称这种工作方式为“产品模式”。

Narayan 将基于项目的筹资模式与产品模式团队做了对比。他重点指出,以产品为中心的团队的努力方向,是沿着“与产品或业务战略保持一致的推进路线图”。Narayan 比较了用于预设解决方案的项目筹资和产品模式。在后者中,筹资“用于解决方案的构建、运行和迭代,甚至转而用于其它的解决方案,直到潜在的问题得到了可靠的解决”。

Gothelf 最近撰文介绍了 GE 公司是如何通过在产品交付中使用精益创业方法(Lean Startup),摈弃了以产品为中心的团队。文中指出,虽然精益创业本身就是一种可降低风险的策略,但是市场寻求的是可预期的利润、成本和投资回报率。文中写道:“精益创业的实践清晰地表明了,我们的世界已经发生了变化“。Gothelf 进而提出:

“设想”、“假定”、“实验”,这些用词本身就会被预算会议否决。它们听上去不像是可交付产品(或利润),而是会导致交付推迟、购买推迟,进而利润推迟。

在 Tranter 看来,项目筹资是导致产品质量下降和技术债务上升的因素之一。他写道:

在构建软件产品时,传统的“项目”筹资和工作管理方式是一种灾难性的愚蠢做法。它只会引发拼凑团队然后一拍而散、产品与市场严重不匹配、为达成任一期限而死亡行军(Death Match)等问题,并留下大量技术债务。

Tranter 写道,技术债务往往会形成需要新建一个项目去“解决混乱并从头开始”的状态。他指出,这是因为“变化成本曲线失控,以至于给出了负面价值,并耗费了团队的全部努力”,他将其定义为技术破产的一个导致因素。与之相对比,Narayan 写道,产品模式“允许团队使用短周期迭代实现快速重定向,同时保持了软件架构的完整性,进而保证了软件架构的长期有效性。”

Narayan 介绍了在架构选取上,项目筹资是如何鼓励团队做出短视的决定,而忽略了这些决定的长期成本:

项目模式中的激励措施会对团队造成压力,使得团队忽视了中期架构的整体性,更倾向于短期特征的交付。由于团队并未面对这种权衡的后果,因此他们不会从反馈循环中受益。这种反馈循环只会在长期所有权的情况下出现。

Gothelf 写道,优化短期利润的传统模式并不适用于当前情况,其中“几乎任何人都可以启动任何类型的业务,而所需的投资和所面对的风险都小得多”。他写道,精益创业是“一个放大镜,揭示了过时的规划实践并不适用于软件驱动的世界“。

Gothelf 指出,在逐步递增产品筹资之外,还需要改变筹资模式,以支持水滴石穿式的创新。 他写道:

需要同时存在另一条单独的筹资渠道,以提升组织对创新工作以及构建并扩展新业务的耐心度。鉴于有 90%的创业公司都未取得成功,你的组织是否有耐心去面对 90%的新想法会失败这一情况?

Tranter 警告说,仅仅摆脱基于项目的筹资是不够的。他举例说,他曾经看到有的组织在项目中放弃了“持续的价值流筹资”,进而采用了一种“推动”式系统取而代之。他写道:“对于工作内容、完成时间、工作优先级和构建方式,一个糟糕的团队是没有发言权的”。Tranter 阐明了对整个产品拥有完全所有权的团队情况:

如果团队构建了一个产品,那么他们就拥有该产品的所有权,这是在空间和时间上的全栈所有权。空间上的全栈所有权,意味着团队负责从用户界面到 API 和数据存储的整个技术栈,其间没有交接、中间件专家、组件团队……时间上的全栈所有权,意味着团队至始至终拥有特征或产品,其间没有交接、维修组、运维或 BAU 队。谁构建,谁负责运维和修复。

Narayan 文章的最后一部分内容预计于感恩节后不久发布,敬请关注MartinFowler.com

查看英文原文: Comparing Product to Project Funding

语言 & 开发架构文化 & 方法