企业管理的108个问题 · 第89问

上一问我们深入挖了项目延期的”元凶”和”治延”策略（第88问），核心结论是：延期不是”不够努力”，是”计划方式出了问题”。

但今天我们要聊的——不是”怎么让项目不延期”，而是一个更基础的问题——“做项目的方法论，到底该选哪一种？”

几乎所有做IT、做软件开发的人——都听说过”敏捷”（Agile）。

Scrum、Kanban、Sprint、Stand-up Meeting——这些词，对程序员来说，就像厨房里的锅碗瓢勺——日常到不能再日常。

但如果你去问一个市场部、HR、财务或者制造团队的人——

“你们在用敏捷吗？”

——大概率收到的回复是：”那是什么？程序员用的？跟我们有什么关系？”

那么问题来了：敏捷——到底是”IT专用方法论”——还是”可以跨越行业的通用管理工具”？

今天我们就来掰开揉碎聊清楚。👇

一、敏捷到底是什么？先别急着”归为IT”

很多人对敏捷的理解是：“不就是两周一个版本、每天站个会、弄个看板吗？”

那你就把敏捷”想小了”。

敏捷的本质，其实是一套”应对不确定性”的管理哲学。

它诞生于软件开发领域——因为软件项目的不确定性太高了——需求随时会变、技术随时会踩坑、用户随时会翻脸。传统的”先什么都计划好，然后按部就班执行”的瀑布式管理——根本玩不转。

所以敏捷的核心思想其实是这四条：

1. 个体和互动 > 流程和工具（先把人搞定，再谈流程）
2. 可工作的成果 > 面面俱到的文档（做出来比写出来重要）
3. 客户合作 > 合同谈判（跟客户一起”摸着石头过河”）
4. 响应变化 > 遵循计划（计划赶不上变化，那就拥抱变化）

——你读一遍这四条——跟”IT”有什么关系？

一点关系都没有。

这四条——放之任何团队、任何岗位、任何行业——都成立。

二、非IT团队用敏捷，能解决什么问题？

我们来看看——不同的非IT团队，如果用”敏捷”的思路，能治什么”病”。

场景一：市场部 / 活动策划团队

传统痛点：

• 做一场大型活动——提前3个月开始策划——所有事都写在”甘特图”上——
• 结果活动中途，老板说：”竞品也搞了活动，咱们加个新环节”
• 策划团队：？？？我们的计划全打乱了

敏捷怎么救？

把”3个月的超大项目”拆成”2周一个的Sprint”：

实操案例： 某互联网公司的市场部，把”年度营销计划”拆成”每2周一个Sprint”——每个Sprint结束时回顾过去两周的投放数据——下个Sprint根据数据调整策略。结果是——ROI提升了30%，因为”反应速度变快了”。

场景二：人力资源团队

传统痛点：

• 做一次全公司的”绩效改革”——从调研到方案到推行——一共花了9个月
• 结果推完发现：员工不买账——很多设计跟实际脱节——但”已经推了，改不了了”
• 再来一次？——没人有这个精力

敏捷怎么救？

“绩效改革”不是”大爆炸式”一次推完——而是”迭代式”：

1. 先选一个部门做试点（不是全公司一起上）
2. 2周后收集反馈——大家觉得哪好用哪不好用
3. 根据反馈修改方案——再试一轮
4. 试得差不多了——再推广到更多部门

结果： 不是”一次做对”——是”边做边调”——最终方案的质量，比”一次性设计”高得多。

场景三：制造 / 生产团队

传统痛点：

• 生产线出了问题——发现是”供应链和仓库”之间的信息没对齐
• 等”跨部门会议”开完——已经过去了3天——生产线已经停了2天

敏捷怎么救？

每日站会——不是程序员的专利。

制造团队每天早上站5~10分钟——每个人说三句话：

1. 昨天完成了什么
2. 今天准备做什么
3. 有什么”堵住我的”问题

——有问题——当场协调——不等”每周例会”。

结果： 信息延迟从”2-3天”缩到”1天以内”——生产线因为”信息不通”导致的停工减少了60%。

三、非IT团队用敏捷的”三个关键调整”

但注意——“照搬IT的Scrum”对非IT团队行不通。

非IT团队用敏捷——要做三个”本地化”调整。

调整一：Sprint周期——“2周”不是硬性规定

IT团队用2周一个Sprint——因为软件版本迭代的节奏就是这么快。

但非IT团队——要根据自己的”交付节奏”来定Sprint周期。

关键原则： Sprint周期的选择——以”你最快能交付一个可评审的成果”为基准——不是”别人用2周，我也用2周”。

调整二：站会——别搞成”汇报大会”

非IT团队最容易犯的错误是——“每日站会变成了进度汇报大会”。

正确的站会应该是：

• 站——真的站着开（不超过15分钟）
• 不报流水账——“我做了什么、做了什么”——没人关心
• 只聊”卡住”的事——“我今天需要谁的支持？”——“什么阻碍了我？”
• 会后跟进——站会上暴露的问题——会后相关负责人单独聊——不要站会本身变成”解决问题的场合”

调整三：回顾（Retrospective）——“最重要的一步”

敏捷真正的”灵魂”——不在”站会”——不在”Sprint”——在回顾。

回顾的目的不是”追责”——是”找到可以改进的地方”。

回顾的经典”三步法”（任何团队通用）：

1. 保持（Keep）： 这个Sprint里，做对了什么？值得继续做？
2. 问题（Problem）： 这个Sprint里，什么让你不爽？什么拖慢了进度？
3. 尝试（Try）： 下个Sprint，我们想尝试改变什么？

关键： 每次回顾结束时——确定1-2个”下个Sprint要改进的具体动作”——不是”我们要更努力”——是”下班后不允许再回消息”或”跨部门协作统一用共享文档”——这种可执行的动作。

四、非IT团队引入敏捷的”三步落地法”

第一步：选一个”痛得最厉害”的团队做试点

不要一开始就跟全公司说：”我们要全面推行敏捷。”

那等于自杀。

选一个”痛点最突出”的团队——最能体现出”敏捷改进效果”的：

• 如果市场部总是”赶不上热点”——选市场部
• 如果HR的绩效改革”推不动”——选HR部门
• 如果供应链”总是断档”——选供应链

选一个试点——先做出效果——再推广。

第二步：用”最轻量”的敏捷工具——不要一上来就上Jira

非IT团队不需要”复杂的敏捷工具”。

最简单的组合就够了：

• 可视化管理： 一面白板 + 三种颜色的便利贴
  • 红：待办（To Do）
  • 黄：进行中（In Progress）
  • 绿：已完成（Done）
• Sprint规划： 每周一早上花30分钟——定本周要完成的”红贴”
• 每日站会： 每天5-10分钟——围着白板站一圈

别怀疑——你就用这三样——效果不比Jira差。 工具只是”辅助”——核心是”人在用”。

第三步：设置”改进反馈周期”——不是”改了就行”——是”改着看””

引入敏捷本身就是一个”敏捷过程”。

每2-4周，回顾一次”敏捷引入本身的效果”：

• 团队感觉敏捷了吗？还是更累了？
• 站会变成了负担——还是真的提高了沟通效率？
• Sprint周期合理吗？太长还是太短？

根据反馈——随时调整——不是”定的规则就不能改”。

这才是”敏捷的精神”本身。

五、敏捷不适合哪些非IT场景？

任何事情都有边界。 敏捷虽然”通用”——但有些场景，它不适合，或者需要”大大地改装”。

敏捷不太适合的场景：

在这些场景里——传统项目管理方法（如瀑布式/关键路径法CPM）可能更合适——或者用”混合式”：核心按瀑布——执行层面按敏捷。

六、最后的话

敏捷不是程序员的”特权”。

它是一种”面对不确定性的管理思路”——任何团队、任何行业——都可以从中受益。

但它也不是”万能药”。

盲目引入Scrum——照搬IT的所有仪式——然后发现”团队更累了、效率更低”——那不是敏捷的错——是”引入方式”的错。

对非IT团队来说——用敏捷最好的方式——是”偷”它的原则：

• 把大事拆小
• 先做出来再看
• 定期回顾、找出改进点
• 别怕改计划

——而不是”原封不动地照搬一切仪式”。

管理工具和方法论——最终都要”为我所用”——而不是”我被工具所用”。

明日预告：第90问 —— 如何做好项目优先级排序？