软件开发中的产品思维与项目思维

当今的组织需要将敏捷性置的开发于优先地位，以便能应对不断变化的客户需求和市场趋势。从项目思维转向产品思维能够实现这一点。

在软件开发与DevOps领域，“项目思维”和“产品思维”这两个术语听起来似乎可以互换。毕竟，大多数软件产品是通过项目来管理的，而大多数开发项目也会产出一个产品。

但项目思维与产品思维之间存在显著差异——相关的项目管理实践与产品管理实践也是如此。让我们剖析这些差异，重点解释为何现代团队更倾向于采用以产品为导向的方法。

项目思维与产品思维

项目思维与产品思维都能服务于同一个最终目标——打造优质软件。不过，二者完成任务的方式截然不同：

•项目思维聚焦于在特定时间框架内达成预定目标。在项目思维下，项目交付成果为开发者和其他相关方的工作方式奠定基础。

•产品思维则优先考虑打造一款能尽可能创造商业价值的产品，即便这意味着需要偏离项目计划。

这些方式上的差异引发了项目思维与产品思维之间的其他重要区别，包括以下几点：

交付成果与成果。项目思维聚焦于按时且在预算内完成交付成果。相比之下，产品思维强调朝着积极成果努力，比如产品改进。只要产品在改进，它更能容忍未完成交付成果的情况。

生命周期与时间线。项目思维通常强调遵守预定时间线以达成特定交付成果。在产品思维下，团队通常将时间线视为更灵活；只要他们在做改进产品的改动，即便错过预设期限，也认为工作成功了。

业务与IT的对齐。项目通常会配备预先组建的开发者团队。这可能让整合其他相关方变得更难，比如那些能就如何最好地实施新功能提供见解的业务用户。项目初期就将业务用户排除在外，可能导致业务与IT组织之间对齐不佳。产品思维在这方面更灵活，因为它能更容易地整合来自IT部门之外的相关方。

岗位角色。尽管两种思维都需要开发者贡献代码，但在其他岗位角色上存在差异。在项目思维下，项目经理或管理团队通常监督运营。在产品思维下，方向由产品经理主导。

范围。项目通常有预定范围——比如“实现X和Y两项新应用功能”。相比之下，产品思维鼓励采用开放式的持续方法，让开发者不断改进应用。

项目管理与产品管理

要更全面理解项目思维与产品思维的差异，区分项目管理与产品管理会有帮助。

项目管理是监督特定项目完成的实践。项目经理确保在团队朝着达成交付成果努力的过程中，相关方能按时完成任务。

相比之下，产品管理聚焦于长期管理产品的方方面面。产品经理的主要目标是确定哪些产品改进能满足客户需求并创造商业价值。

重要的是，项目管理与产品管理并非相互排斥。相反，它们通常相辅相成。当开发者们为改进产品而努力时，项目经理对协调他们的各项工作很重要。产品经理能帮助确定项目应包含哪些交付成果。

项目思维的弊端

大多数现代企业组织已逐渐认识到项目思维的弊端——即所有人都较少关注产品和用户需求。

一套完美的项目管理系统能完成每一项任务，但到了推向市场时仍可能失败。这是因为成功的项目未必能造就成功的产品。

以现实中项目思维的弊端为例，看看苹果公司。苹果在历史上既有项目思维也有产品思维。苹果一些最重大的成就——比如iPhone的推出及早期快速改进——就源于产品思维，这种思维让公司能快速创新并响应用户需求。

然而，如今一些批评者指责苹果每年推出的iPhone几乎都是翻版——这种做法体现了项目思维。在这些批评者看来，这些手机的产品质量已停滞不前，因为苹果在完成项目时很少或根本不考虑产品成果。这种对项目导向思维的依赖可能让苹果易受冲击，并让其他公司在手机创新上获得优势。

现代团队必须在优先考虑产品的同时，留意市场的动荡。如果一个项目耗时太久，团队又盲目遵循项目时间线，那么软件到达消费者手中时，产品可能早已过时。有了产品思维，企业能保持适应性。团队会不断从目标用户那里获取直接反馈并做出调整。

产品思维的优势

产品思维的关键优势在于它将重点放在客户和价值上，而非代理指标和活动。

如此一来，产品管理与交付助力实现吉恩·金（GeneKim）提出的DevOps关键目标，即所谓的DevOps三原则：

•流动（Flow）：优先考虑系统整体的表现——而非单个环节。

•反馈（Feedback）：组织用它来改进产品。

•持续学习（Continuallearning）：鼓励创新、承担风险与实验。

组织不能仅靠CI/CD就采用更快的发布节奏。相反，他们必须专注于软件开发如何影响业务和客户。如此一来，组织能将DevOps原则推广到业务层面。

随着优步（Uber）、爱彼迎（Airbnb）等数字优先型公司颠覆传统行业，更多公司认识到产品思维的价值。对传统企业组织而言，转向以产品为导向的开发是关乎生存的问题。

项目思维涉及自上而下的命令控制式方法，这可能让企业组织处于不利地位。许多大公司如果不适应颠覆者采取的创新方法，就可能面临落后风险。

产品思维的实例

以下场景展示了产品思维在实践中是怎样的，以及它如何让DevOps团队受益。

受围绕生成式AI的热议启发，一家IT软件供应商着手为一款监控工具添加一个生成式AI驱动的功能，该功能能让IT分析师用自然语言就日志文件提问。供应商计划通过将用户查询和日志数据输入第三方生成式AI服务来实现该功能，该服务随后会解析日志数据以回应查询。公司为此集成的构建定义了交付成果，并指派开发者完成。

然而，项目开展几个月后，产品经理收到客户反馈，称一些客户对新功能的设计方式感到不安。该功能要求用户将潜在敏感的日志文件暴露给第三方生成式AI服务，尽管该服务有数据安全政策，一些客户仍认为这不安全的。此外，公司首席财务官对该生成式AI服务的费用表示担忧。他们认为新功能带来的收入未必能超过这笔开支。

基于这些来自外部和内部相关方的反馈，产品经理意识到他们正在构建的功能并不适合客户需求，对公司而言也不是一项性价比高的功能。

为此，他们改变了方向。放弃了原项目交付成果，转而决定通过自建生成式AI服务来实现日志查询功能。这种方法避免了客户将数据暴露给第三方服务的需要，长远来看也能为公司省钱——因为他们无需支付外部生成式AI集成费用。

在这个场景中，产品思维让DevOps团队免于在一个行不通的功能上浪费时间和金钱。若采用项目思维，放弃原交付成果并采用新方法会更难。