我们如何用敏捷管理创业公司

我们如何用敏捷管理创业公司

去年 11 月，我的一个客户，做跨境支付 SaaS 的 9 人团队，差点因为“完美落地 Scrum”而倒闭。

他们严格执行两周 Sprint、每日站会、Sprint 评审、回顾会议，甚至还雇了一名认证 Scrum Master。表面上一切标准、规范、可控。但实际上，Sprint 到第 5 天时，客户突然要求调整交易路由逻辑，因为东南亚某国改了合规条款。产品经理说：“这个需求我们记在 Backlog 里，下个 Sprint 排期。”客户说：“等不了两周，三天内不解决，我们切走。”

那个 Sprint 最终以“流程合规”收场，同时丢掉了公司第三大客户。创始人找我复盘时，问了一个让我至今记忆犹新的问题：“我们到底是来做敏捷的，还是来活下去的？”

这篇文章想讨论的，就是这个问题的答案。我做了 8 年研发管理咨询，辅导过 40 多家从 3 人到 200 人不等的技术团队。我越来越确信一件事：创业公司需要的不是教科书版 Scrum，而是一种“为生存优化的轻量敏捷”，保留验证速度，砍掉仪式冗余，把每一分精力用在看清方向和交付价值上。

一、核心结论：敏捷的本质不是仪式，是“获取有效反馈的最短路径”

如果只能给创业公司一条敏捷原则，我会选这个：在最短时间内、用最小成本，验证一个商业假设是否成立。

其他一切，Sprint、站会、用户故事、故事点估算、燃尽图，都只是手段。当手段变成目的，敏捷就死了。

我在 2018 年接手过一个案例：北京一家做企业培训平台的初创公司，12 个人，创始人技术出身，对流程有执念。团队严格执行 Scrum Guide 的每一个仪式，包括 Sprint 评审会上用 PPT 演示、故事点估算使用 Fibonacci 数列、每日站会严格控制在 15 分钟。结果是：每个 Sprint 的交付物都很“标准”，但客户续费率只有 41%。深度调研后发现，客户真正需要的不是新功能，而是把现有功能跑通、跑稳。但团队全部精力都耗在了“按 Backlog 优先级做下一个用户故事”上，没人回到客户现场去验证一个功能是否真的解决了问题。

后来我们做了一个极端调整：砍掉所有仪式，只保留一个动作，每周二下午，团队带着最新版本去见一个真实客户，当面看对方操作，记录下所有卡住的地方。三个月后，续费率从 41% 回升到 76%。不是因为流程更规范了，而是因为反馈回路从两周缩短到了以天为单位。

所以我的核心结论很简单：如果一项敏捷实践不能让你更快地获取有效反馈，那就暂时不需要它。 创业公司最大的优势是快，最大的劣势是资源少。你的敏捷实践必须放大优势，而不是暴露劣势。

二、真实场景：创业公司的“末日四骑士”

在展开方法论之前，我想先把创业公司面临的根本困境说清楚。否则你会误以为“不就是把流程简化一点吗”，然后做出来的简化版依然不对。

我观察了这几年服务的早期创业团队，发现几乎所有团队都困在四个核心问题上。我把它们叫作创业公司的“末日四骑士”：

1. 变化速度远超规划速度

创业公司的需求变更不是“异常”，是“正常”。我今天上午跟客户开会，对方说“如果你们能支持微信支付分账，我们就签年单”。下午产品经理把需求写进 Backlog，但排期在下下个 Sprint，这时候竞争对手可能在三天内上线这个功能。

我统计过 12 家 A 轮前的 B2B 创业公司：平均每周有 2.3 个来自客户的“紧急需求”，其中 67% 的需求在两周内如果不响应，客户会直接流失或大幅降低合作意愿。传统 Sprint 的刚性边界在这种环境里不是保护，是枷锁。

2. 资源极度有限，没有冗余

大厂做敏捷可以有专职 Scrum Master、专职 PO、架构师、测试团队。创业公司呢？一个全栈工程师可能同时承担前端、后端、运维、甚至部分产品工作。我见过最极端的情况是一个 5 人团队，CTO 同时兼任 Scrum Master、PO、架构师和核心开发，而他自己还要亲自写代码。

在这种资源密度下，任何不能直接产生价值的活动，比如用半小时估算故事点、开一小时 Sprint 回顾会，都是在消耗团队的生存资本。

3. 客户认知不成熟，需求来源极度分散

大企业的客户通常有明确的采购流程、技术评审和需求文档。创业公司的早期客户往往自己也说不清楚要什么。你问他需要什么功能，他说“你们看着办吧，反正要解决我的问题”。这种模糊性意味着，你不能依赖“用户故事”来传递需求，因为用户根本没有“故事”，只有“痛点”和“期待”。

4. 团队信任尚在建立中

Scrum 的前提假设之一是高信任度、自组织团队。但创业公司早期团队要么刚组建还在磨合，要么有实习生或兼职参与，要么创始人/CTO 本身还没学会放手。在这种环境下强行推行“自组织”，结果往往是“自流散”。

这四个问题叠加在一起，意味着教科书版敏捷在创业场景里会系统性地失灵。接下来我要拆解的，就是最常见的三个误区。

三、三个最常见的误区，几乎每家创业公司都踩过

1. 把“用户故事格式”当作需求质量

“作为一个 XX 角色，我想要 XX 功能，以便达到 XX 目的”，这个句式在我见过的创业公司里，99% 的情况下只是换了一种方式写“我要做一个按钮”。团队花了 20 分钟讨论用户故事的措辞，但对“这个功能到底验证了什么商业假设”毫无感知。

我在一家做餐饮 SaaS 的团队里做过一个实验：要求产品经理先写一版标准用户故事，然后用一句话回答“如果这个功能上线了，我们怎么知道它成功了？”结果 14 个用户故事里，只有 2 个能给出可衡量的判断标准。剩下的 12 个，都是在描述功能本身。

问题的根因在于：创业公司的问题域还在探索中，你很难写出真正有效的验收标准。 用户故事是好工具，但它适合“已知问题域、探索方案”的场景，而不适合“问题域和方案都在探索中”的创业早期。

2. 把“每日站会”开成进度汇报

我旁听过不下 200 场创业公司的每日站会。超过 60% 的站会模式是：每个人面向 Scrum Master 或 CTO，汇报昨天做了什么、今天打算做什么。CTO 听完后逐一点评甚至分派任务。这不是站会，这是晨会。

站会的本意是发育团队自组织能力：成员之间同步信息、暴露阻碍、主动协作。但当团队规模小到只有 5-8 人，大家就坐在同一张桌子旁时，信息天然就是透明的。这时候站会的增量价值非常有限，更多是心理安慰，“我们团队在敏捷”。

3. 迷信“Sprint 边界不可破坏”

这是我最常听到的一个教条。很多 Scrum Master 会引用 Scrum Guide 里的原话：“Sprint Backlog 一旦确定，不能在 Sprint 中更改。”但他们忽略了两件事：

第一，Scrum Guide 是写给成熟团队和稳定业务环境的指南，不是写给创业公司的生存手册。 在创业公司，客户需求的变化速度远超 Sprint 周期。坚持 Sprint 边界不可破坏，等于对客户说：“你的问题是问题，但我的流程也是问题，你等我排期。”，这在市场上不可接受。

第二，Scrum Guide 本身也说了，如果 Sprint 目标变得过时，Product Owner 可以取消 Sprint。但大多数创业公司根本不敢取消 Sprint，因为那看起来像“管理失败”。

我亲眼见过一个团队硬扛完整个 Sprint，交付了一个已经没人需要的功能，因为客户在一周前调整了业务方向。那次 Sprint 的产出价值为零，但“流程是完美的”。这是典型的流程胜利、业务失败。

四、专业判断逻辑：什么是该留的，什么是该砍的

看到这里你可能想问：既然这也有问题那也踩坑，那到底该怎么做？我的回答是：你需要一个“生存优先”的裁剪原则。

这个原则的核心是一个判断问题：“如果砍掉这项实践，我们获取有效反馈的速度会变慢吗？”

如果答案是“不会变慢，甚至可能变快”，那就毫不犹豫地砍掉。如果“会变慢”，那就保留但尽量简化。下面我用这个逻辑逐项过一遍敏捷常见实践：

这个判断框架不是教条，你可以根据自己的团队规模、行业特点、客户类型做调整。但核心逻辑不变：凡是不能缩短反馈回路的，重新评估它的必要性。

五、实践方案：我们实际保留了哪三个动作，以及怎么做的

基于上面的判断框架，我辅导的团队最终普遍只保留了三个核心动作。下面逐一拆解具体做法和理由。

1. 用“影响地图”替代 Product Backlog

为什么不是用户故事？因为用户故事描述的是“做什么”，影响地图描述的是“为什么做”。 创业公司最大的浪费不是做错了功能，而是做了对的功能却没带来对的结果。

影响地图的格式很简单：

• Why（目标）：我们想要达到什么业务结果？比如“本月客户付费转化率从 12% 提升到 18%”。
• Who（谁）：谁能帮助我们达成这个目标？比如“已经注册但未付费的企业管理员”。
• How（如何）：这些人需要做什么行为改变？比如“在试用期内完成首次团队协作操作”。
• What（做什么）：我们要提供什么功能或内容来促成这种改变？这里才是功能落脚点。

我辅导过的 PingCode 的一个客户团队曾经分享过他们使用影响地图的经验。PingCode 主要服务 100 人以上的中大型研发组织，他们的产品方案天然倾向于支持完整 Scrum 流程。但那家企业客户内部的一个 12 人创新孵化项目，在使用 PingCode 的项目管理模块时，并没有照搬标准迭代规划功能，而是把 PingCode 的“史诗-特性-用户故事”层级结构做了裁减：史诗对应“Why”，特性对应“Who 和 How”，用户故事只写最贴近交付的那一层“What”。这样一来，他们既用了系统提供的结构化能力，又避免了在早期过度展开需求层级。

这个做法给了我启发：工具支持完整流程，不代表你现阶段就要用完整流程。 PingCode 的多级需求管理设计是为了给不同成熟度的团队提供灵活选择，创业团队完全可以只用到“史诗+用户故事”两级，中间跳过特性层，等团队超过 30 人再补回来。

2. 用“阻碍即报 + 看板”替代每日站会

我们实际的做法是：

• 使用物理看板或在线看板（PingCode 自带看板视图），每个任务在“待办-开发中-测试中-已完成”四列中流转。
• 当任何一个任务在同一列停留超过 48 小时，责任人主动在团队群发一条消息：“XX 任务卡在 XX 列，原因是 XX。”
• 收到这条消息后，相关方必须在 4 小时内响应并给出解决方案或重新分配资源。
• 不再有固定的每日站会时间。如果连续三天没有任何人发出“卡住”的信号，团队连一句话都不用说，这说明流程运转顺畅。

这个方案的核心是把“推式同步”变成“拉式同步”：不是每个人每天定时汇报，而是只有在真正遇到阻碍时才主动暴露。对于 8 人以内的团队，信息传递效率更高。统计数据显示，我们辅导的团队在切换后平均每周节省 3.5 小时会议时间，而阻碍被暴露的延迟时间从之前的平均 1.8 天缩短到了 4.6 小时。

3. 用“上线即验收”替代 Sprint 评审

创业公司的 Sprint 评审会上，常见的现象是：团队对着内部人员演示一个功能，大家说“挺好的”，然后散会。这个“评审”几乎没有获取任何有效反馈，因为它把最该在场的人，真实客户，排除在外了。

我们的替代方案：

1. 任何功能一旦达到“可被客户感知”的状态（不必完美，可以只覆盖核心路径），第一时间部署到演示环境。
2. 产品经理或创始人直接约一个客户，给对方一个 15 分钟的操作任务，观察对方怎么做。
3. 记录下客户所有“卡住了”“怎么不能 XXX”“为什么不能 XXX”的瞬间。
4. 这些记录直接进入下一轮迭代的最高优先级。

如果一个功能在 72 小时内没有获得任何客户反馈，它被自动标记为“待验证”，不再投入额外开发资源。

这个节奏之所以可行，是因为创业公司的客户关系通常比大厂更紧密。早期客户愿意跟你一起打磨产品，条件是你能快速响应他们的反馈。 上线即验收把“反馈-改进”的周期从两周压缩到了几天，这在创业早期是巨大的竞争优势。

六、什么时候该“加回来”？引入更多仪式的判断阈值

没有任何一种管理方式是一成不变的。你砍掉了站会、Sprint 规划、故事点估算，不代表它们永远不需要。关键是知道什么时候该把它们捡回来。

以下是我们在多家团队中验证过的几个判断阈值：

1. 团队人数突破 8-10 人

当团队超过这个规模，成员开始分化出明确的前后端分工，甚至需要跨时区协作，信息开始不再是天然透明的。这时候，一个简短的每日同步会议就有了价值。不需要恢复完整站会，可以改为“异步文字站会”：每个人在群或工具里用三句话写清楚“昨天做完的、今天要做的、正在被什么卡住”，发完就算，不用等人齐。

PingCode 的迭代概览页面在这个阶段会变得有用，团队超过 10 人后，每个人不再能靠自己感知到整体进度，一个可视化面板能降低大量沟通成本。

2. 迭代交付成功率连续三次低于 60%

定义：迭代结束时，承诺的待办事项完成比例低于 60%。如果连续三次迭代如此，说明团队的估算能力和承诺能力有系统性问题。这时候引入简单的故事点估算或 T 恤尺码法，不是为了“准确”，而是为了让团队建立对自己交付能力的感知。

注意：引入估算不代表就要开繁琐的规划会。可以用简单的方式，对于每个待办项，开发团队在 30 秒内给出“小/中/大”的判断，记录在任务卡片上。连续几个周期的数据会逐渐帮你建立“一个中号任务大约需要多少天”的体感。

3. 客户投诉中“你们承诺了却没做”的比例超过 20%

这个指标说明团队对外的承诺和对内的执行之间存在严重的信息差。引入 Sprint 目标，哪怕只是一个口头的一句话目标，能帮助团队在面对新需求插入时，有一个明确的判断标准：“这个新需求是帮助我达成这个 Sprint 目标，还是在让我偏离方向？”

4. 产品经理开始用 Excel 手动排期

这是我一个非常实用的判断信号。当你的产品经理开始下意识地打开 Excel 把每个人的时间线排出来，说明当前的流程已经无法给团队提供足够的可视化参照，个人在用自己的方式填补流程缺口。这时候引入一个轻量级的规划工具或启用 PingCode 的迭代规划功能，把排期信息从个人脑子/桌面文档搬到公共视图里，会立竿见影地减少混乱。

七、工具选择：PingCode 等平台在轻量敏捷中的实际用法

关于工具，我想讲一个容易被忽视的点：工具的功能清单不等于你该用的功能清单。

PingCode 是一个完整支持标准 Scrum 流程的平台，覆盖从需求管理到迭代规划、站立会议、进度跟踪、评审回顾的全链路。它主要服务中大型企业和 100 人以上的研发组织，这意味着它的产品设计天然包含了很多创业公司暂时用不到的能力。

但这不意味着创业公司不该用 PingCode。恰恰相反，工具的结构化能力在团队扩展过程中是一种“可升级的基座”，你不需要现在就启用所有功能模块，但你需要一个能在团队从 5 人成长到 50 人时依然能用的系统，而不是半年后被迫再迁移一次。

1. 创业公司如何“裁量使用” PingCode

我建议的用法是分层激活：

• 5-15 人阶段：只用“需求管理 + 看板 + 迭代概览”。把史诗/特性/用户故事三级简化为“目标-任务”两级，用户故事只作为任务的文字描述载体，不做繁琐的验收标准拆解。站会模块暂不启用，改用看板列停留时间触发异步沟通。
• 15-30 人阶段：逐步激活“迭代规划 + 故事点估算（简易模式）+ 进度跟踪”。此时团队开始需要统一的工作节奏和可视化的燃尽数据来感知风险。
• 30 人以上：当团队达到 PingCode 典型客户群体的规模时，标准 Scrum 流程的各模块就基本都能发挥价值了，包括回顾板、评审管理等。

这个做法的好处是：团队不需要学习两次工具。 你在 5 人时期用的 PingCode 看板，到 50 人时期变成了完整的迭代管理面板，底层数据结构一致，历史数据可追溯，没有迁移成本。

2. 与 PingCode 其他子产品的轻度联动

PingCode 还有 Testhub（测试管理）、Wiki（知识库）和 Insight（效能度量）等子产品。创业公司在早期不必全部启用，但有两个点我建议及早行动：

• Wiki（知识库）：从第一天开始记录决策上下文。创业公司最怕的不是做错决定，而是三个月后忘了当初为什么做这个决定。Wiki 不需要结构完美，只要每次做关键决策时花 5 分钟写一句“我们决定做 X，因为客户 Y 反馈了 Z，替代方案是 W，权衡因素是 Q”。这些记录在团队复盘时价值巨大。
• Insight（效能度量）：10 人以下不需要。但当团队超过 20 人，逐步启用交付周期、需求吞吐量等基础指标，能帮你客观判断流程是否需要调整，而不是凭感觉“最近好像慢了”。

八、避坑清单：这些事可能让你前功尽弃

最后我想用几段话列举几个在实际落地中反复出现的坑。这些都是我从辅导失败的案例中提炼出来的，每一条背后都站着一个曾付出代价的团队。

1. 创始人/CEO 嘴上说敏捷，手上不放权

这是我见过最多的失败模式。创始人宣布“我们要搞敏捷”，然后在第二周亲自插一个紧急需求进 Sprint，当众批评开发速度慢，或者在评审会上直接推翻团队的技术决策。

记住：CEO 是创业公司最大的流程破坏者，但这也是 CEO 应该扮演的角色，在需要灵活调整方向时果断介入。解决这个矛盾的方法不是让 CEO 闭嘴，而是公开制度化“CEO 可以随时插入一个需求，但每次插入必须同时指定一个已被承诺的需求为降级”。这样既保留了创始人的决策权，也让团队清楚知道机会成本。

2. 把“轻量”搞成“散漫”

砍掉流程不代表不要流程。我曾经见过一个团队，把敏捷简化到只剩看板，然后看板也不更新了，任务是口头传的、优先级是凭感觉定的、交付节点是模糊的。这不是轻量敏捷，这是无管理。

轻量敏捷的前提是，留下来的少数几个实践必须被严格执行。比如看板上的每个任务必须有明确的责任人、明确的“完成”定义和不超过 48 小时的停留时间。砍掉仪式感，不是砍掉纪律。

3. 数据驱动的幻觉：用粒度换精度

有些团队特别喜欢在早期就埋点、拉报表、计算各种敏捷度量指标。但 5 个人的团队，你根本不需要那么多数据来“看清”状况，你花半小时下去走一圈就知道了。

在创业早期，定性观察远比定量指标重要。 与其花时间分析燃尽图为什么向下弯折，不如去跟那个卡住了的工程师聊五分鐘。等你的团队大到无法靠“走一圈”来感知状态时，再引入度量体系。

4. 工具崇拜：以为买了 PingCode 就敏捷了

我遇到过不止一家公司，以为上一套先进的项目管理工具就完成了敏捷转型。这是把“基础设施”和“文化变革”混为一谈。工具能帮你可视化流程、降低沟通摩擦，但它不能替你面对客户、不能替你决定砍掉哪个功能、不能替你接受“我们做错了”的事实。

PingCode 是一个强大的基础设施，但它服务的终究是使用它的人和组织。工具选好了，最难的部分才刚刚开始。

九、结尾：为生存而敏捷，不是为敏捷而生存

我写这篇文章时反复回想那位跨境支付 SaaS 创始人的问题：“我们到底是来做敏捷的，还是来活下去的？”

三年过去了，他的团队已经发展到 43 人。他们现在用 PingCode 管理着 4 个并行的 Scrum 团队，有规范的迭代规划、故事点估算和回顾会议。但他说，他最感激的是早期那个“砍掉一切”的决定，因为在最脆弱的时候，他们选择了活下去，而不是去符合一本指南的要求。

创业公司的敏捷，应该是一种在混乱中快速找到秩序的能力，而不是一套从外部强行植入的规则。 保留那些让你更快看清方向的动作，砍掉那些让你感觉“流程很专业”但实际在消耗生存资本的仪式。当你活过了早期阶段、团队开始规模化增长时，那些被你暂时放下的实践，可以按需一个一个捡回来，而且这次你知道为什么要捡它了。

如果你正在一家创业公司里摸索敏捷落地，我建议你从下周开始做三件事：

1. 找一个白板或在线看板，把团队当前所有任务放上去。 只看四个列：待办、开发中、测试中、已完成。
2. 取消一次本应发生的会议，把省下来的时间用在跟客户面对面聊产品上。 你可以把这次谈话录下来，回去放给团队听。
3. 在团队群发一句话：“如果一个流程不能帮我们更快验证方向，我们就暂时不需要它。” 让这句话成为你们未来三个月做所有流程决策的试金石。

为生存而敏捷。活下去，然后一切才有的谈。