📚 课程目录第2章现状评估与诊断

2、现状评估与诊断：识别痛点、收集数据、使用SWOT分析、绘制价值流图

做过程改进，最怕什么？

最怕一上来就拍脑袋：「我觉得这里慢，改这里！」

我见过太多团队，花了几十万买工具、搞培训，结果三个月后一切照旧。为什么？因为根本没搞清楚「病根」在哪。

这一章，咱们就聊聊怎么给过程做一次「全身体检」。不靠感觉，靠数据。

痛点分两种：显性痛点和隐性痛点。

显性的好办——用户投诉、项目延期、Bug 率飙升，谁都看得见。隐性的才要命：团队士气低、跨部门扯皮、重复劳动多，这些往往被当成「常态」。

我的经验： 别只盯着「最痛」的地方。有时候一个不起眼的小摩擦，恰恰是瓶颈的源头。我曾经帮一个团队排查，发现他们每天花 40 分钟手动合并代码——改完这个，整个交付周期缩短了 15%。

怎么找痛点？我建议从三个维度入手：

避坑： 我曾经见过一个团队，把「审批流程慢」列为头号痛点，结果一查，真正的原因是需求文档写得不清不楚，审批人根本不敢点通过。痛点找不准，后面全白干。

痛点找到了，下一步就是量化。说白了，你得用数据证明「这里确实有问题」。

我个人习惯把数据分成三类：

嗯，这里要注意：数据不是越多越好。我见过有人拉了一张 50 行的 Excel 表，结果谁都不想看。你想想看，真正能推动决策的，往往就那么 3-5 个核心指标。

  核心原则： 先采集，再筛选。宁可多采一个月，也别漏掉关键数据。我习惯先拉一个「数据采集清单」，跟团队确认后再动手。

数据有了，接下来得做战略层面的判断。SWOT 分析是个老工具，但用好了真能救命。

说白了，就是四个格子：

我建议做 SWOT 时拉上不同角色的人一起。开发、测试、运维、产品，各说各的视角。有一次我们做 SWOT，运维说「部署太慢」，开发说「部署太频繁」——你看，同一个问题，不同岗位看到的完全不一样。

小技巧： 做完 SWOT 后，把 S 和 O 组合起来形成「增长策略」，把 W 和 T 组合起来形成「防御策略」。别只列出来就完事。

这是我最喜欢的一步。价值流图（Value Stream Mapping）能把整个交付过程画成一张图，哪里快、哪里慢、哪里在等，一目了然。

画图其实不难，分四步走：

下面这张图，就是一个典型的交付价值流：

你看，这张图一画出来，问题就藏不住了。等待时间占了总前置时间的一半以上。说白了，团队真正干活只用了 7 天，但整个交付花了 13.5 天——那 6.5 天全在等。

  关键洞察： 价值流图的核心不是画得漂亮，而是找到「等待」和「返工」。我见过最夸张的一个项目，活动比只有 12%——也就是说，88% 的时间都在等。改完等待时间，交付速度直接翻倍。

数据也收了，SWOT 也做了，图也画了。最后一步，是把这些碎片拼起来，形成一个完整的诊断报告。

我习惯用一张表来汇总：

避坑： 我曾经见过一个团队，诊断报告写了 30 页，但没人知道下一步该干嘛。记住：诊断的目的是「行动」，不是「展示」。每一条发现，都必须对应一个可执行的动作。