BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

对比产品筹资和项目筹资

| 作者 Rafiq Gemmail 关注 6 他的粉丝 ,译者 盖磊 关注 2 他的粉丝 发布于 2017年12月12日. 估计阅读时间: 6 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT