你有没有遇到过这种情况：团队每天站在一起开会，任务写在看板上，两个星期交付一次，一切看起来都很“敏捷”。但客户却总说你们听不懂需求，交付的东西用不上，销售也抱怨产品卖不动。这不是你的错，而是你用的那套敏捷方法，可能从一开始就不是为你们这种公司设计的。
敏捷开发（Agile）这个词最早来自软件工程，核心是快速迭代、小步快跑、不断根据反馈调整。这套方法在消费级产品（比如手机App）上很成功，因为用户数量大、反馈快、改一个按钮明天就能看到数据变化。但当你做的是企业级产品（Enterprise Product），也就是卖给公司、机构、政府的软件时，情况完全不同。你的客户可能只有几十个，每个客户都要求定制，签约周期长达半年，部署一次要等三个月，而且客户内部有层层审批、安全合规、IT架构等一堆你控制不了的东西。这时候，传统的敏捷方法，比如每两周做一个新功能、然后让用户试用，根本跑不起来。因为你根本没法在两周内把一个新功能部署到客户的真实环境里，客户也没有时间每周跟你开反馈会。
文章里提到一个具体案例：一家做企业安全软件的公司，团队按照敏捷教科书的方法，每两周规划一次冲刺（sprint，即一个固定时间段的开发周期），每次冲刺结束都演示新功能。但客户公司的安全策略非常严格，不允许外部软件随便连接内部网络读取数据。所以团队每开发一个新功能，都要花大量时间跟客户的IT部门沟通、申请权限、等待审批。结果两个星期的冲刺，真正写代码只用了三天，剩下十一天都在等。客户也很痛苦，因为他们内部流程慢，等他们试用完一个版本，团队已经又迭代了两轮，版本对不上了。
问题出在哪里？出在敏捷方法默认的假设，你的用户能立刻试、立刻反馈、立刻采纳，在企业环境里不成立。企业客户的决策链很长，一个采购决定可能涉及技术评估、法务审核、预算审批、高管签字。你面对的不是一个“用户”，而是一群利益不同的人：IT部门关心安全，业务部门关心效率，财务部门关心成本，老板关心战略。你做的功能，要同时让这些人满意，而不是像消费产品那样只要让一个普通用户觉得好用就行。
那怎么办呢？文章给出的思路是：不要照搬消费级敏捷，而是根据企业客户的实际节奏来调整你的开发周期。比如，把冲刺周期从两周拉长到四周甚至六周，因为客户那边的部署和反馈周期就是那么长。同时，不要每个冲刺都做新功能，而是把时间分成“探索期”和“交付期”。探索期用来跟客户反复沟通、做原型、验证想法，可能花好几周；交付期再集中开发、测试、部署。这样客户不会觉得你们在不停地变，团队也不会因为等反馈而空转。
还有一个关键点：企业产品的“最小可行产品”（Minimum Viable Product，即能验证核心价值的最简版本）不是给一个客户试用一个粗糙功能，而是要让一个客户愿意掏钱买、并且能真正用起来。所以你的第一个版本可能不是最简功能集，而是最简“可销售”版本，要包含必要的文档、培训材料、部署工具、售后支持流程。这些东西在消费产品里可以后补，但在企业产品里，缺了它们客户根本不会签合同。
文章里还讲了一个做企业数据分析平台的公司。他们一开始也按消费产品的做法，先做一个简陋版本让客户免费试用，结果客户试用后发现数据格式不兼容，同一份销售数据在客户的Excel表格里和他们的系统里写法不同，彼此认不出来。客户的技术人员花了三天才把数据整理好，然后发现分析结果也不对，因为他们的算法没考虑客户行业特有的统计口径。最后客户说：“你们这东西根本不能用。”团队很受打击，但后来他们改变了策略：先派一个产品经理去客户现场，花两周时间跟客户的业务人员一起工作，搞清楚他们每天怎么处理数据、用什么公式、报给谁看。然后才回来设计产品。这个版本上线后，客户觉得“这就是我们想要的”。
所以，做企业产品，敏捷的核心不是“快”，而是“对”。你要先理解客户的工作流程、痛点、决策逻辑，再决定做什么、什么时候做。不要为了遵守敏捷的形式而牺牲对客户真实需求的理解。文章的标题是“Dear PMs, It's Time to Rethink Agile at Enterprise Startups”，意思是产品经理们，是时候重新思考敏捷在企业初创公司里的用法了。读完你会明白，敏捷是一种精神，不是一套教条。你需要根据你的客户、你的市场、你的产品类型，裁剪出适合你自己的节奏。
最后，你可以带走一个判断：如果你在做企业产品，而你的团队还在照搬两周冲刺、每天站会、用用户故事（user story，一种描述功能需求的格式，通常写成“作为某角色，我想做某事，以便达成某目的”）来写需求，那么你可能正在用错误的方法做正确的事。停下来，去看看你的客户真正需要什么，然后调整你的流程去匹配他们的世界，而不是让他们适应你的节奏。