对比产品筹资和项目筹资

文化&方法

摘要： 本文给出了一些对产品筹资与项目筹资的新思考。文中对几篇最新的文章进行了概述，给出了ThoughtWorks的Sriram Narayan、《精益用户体验》一书的作者Jeff Gothelf和敏捷评论员（Agile commentator）Leon Tranter在以产品为中心问题上的观点。

作者： Rafiq Gemmail

正文：

近期在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