---

0. 前言

想起上次做完管理相关的演讲之后，有人问我，你是否在管理方面犯过错呢？

我说，有啊，比如我之前一直想着怎么让程序员干活干快点，但我后来才发现，问题不是出在程序员「不够努力」上，而是有更加深层的原因。

我最近的思考主题就是：公司无法快速交付客户需求的根本原因。

---

1. 定制化

我们公司的业务是 SaaS，针对不同的客户给出定制化的方案和交付内容。

定制化对于「获取客户的销售环节」而言，是个加分项，因为客户会认为，我想做的你都能帮我搞定，你可以满足我的诉求。

但是定制化的弊端也很明显，为了实现定制化，就要求从 BA 到 Dev 到 QA 都能明确的搞清楚这个客户需要定制的内容是什么。

BA 需要写需求文档，Dev 根据需求去做配置，QA 去测配置。

小到一个字段的 friendly name，大到这个客户的网站有哪些 user role，所有的细节都要经过不同部门，不同人员的确认和合作，才能最终交付。

这个模式在每个环节的人员都知道自己在干什么的时候，是可以勉强运行的。

但是一旦来了很多经验不足的新人，就会出现超级多的沟通问题，最终导致项目上线后一堆 bug，进入了救火模式。

比如我最近在忙的一个项目，就是因为新人不知道两个表格里面的 Id 必须保持一致，写了个错的 script，QA 也没测出来，直到我接手之后才发现这个不对。

我对于「如何做好定制化」这个问题的思考经历了好几个阶段。

阶段 1：在模糊的需求下完成任务 - 复制粘贴 + 踩坑

BA 的需求经常就只有一句话，比如加一个字段。

但是作为程序员，拿到这个需求后我还要追问很多细节，比如：这个字段是 filter 吗？是所有 tab 里面都要有这个 filter 吗？需要在 XYZ 里面显示吗？显示的顺序是什么？

同时，还必须有人去根据这些讨论结果来更新需求文档，否则 QA 又会问一堆类似的问题。

有些偏技术的需求，BA 更是完全不懂，我刚来的时候，每当遇到问题，资历老的程序员就会告诉我，你去看一下最近上线的那个客户是怎么配的，然后把那个当做例子就好了。

这种做法的弊端在于：假如我参考的例子是错的，那我也会配错，下一个人继续按照我的错误配置去配……直到某天，这个问题在生产环境被发现了，然后所有被影响的客户都要一个个去修。

阶段 2：分享知识

后来我踩了一些坑，对业务逻辑更熟悉之后，我能保证自己在做事的时候可以考虑周全了。

但是其他团队成员可能没有相关的知识，他们还是会配错，假如审核的人也不知道这个坑，问题还是会继续存在。

当时我很热衷写文档，做知识共享，就是希望能够把一些经验传递给别人。

但这种做法的弊端在于：系统过于复杂，能定制化的配置过多，新人往往根本无法理解、消化这么多的内容，最终还是会采用「复制粘贴」的方式完成任务。

---

2. 定制化的瓶颈

有很长一段时间，我都把希望寄托在「培训程序员」上，我不断地去分享知识，去做审核，告诉他们为什么配置 A 和 B 要这样做而不是那样做，我还会告诉他们我是怎么去做测试来保证任务的质量的。

但是这个方法的效果不好，一旦我培训好的人离职了，我又要继续培训新人，这会占用我大量的时间。

可是如果我不做培训，那问题就会暴露在生产环境中，我的团队就要一直救火。

我到底要怎么做才能提升团队的效率和质量？

问题到底出在哪里？

首先，我们的系统很复杂，有老系统和新系统，有数据库各种表格之间的联系，还有不同的网站版本。

每个客户的配置都不同，就意味着所有人都要了解所有客户的配置和一些隐藏的背景知识才能上手。

假如客户 A 有个新需求，程序员做完了以后，测试提了个跟需求 A 无关的 confirmation bug，由于没有人知道客户 A 的项目究竟「应该是什么样」的（最初的需求文档肯定找不到了，而且跟现在的项目实现也不一样了），大家就只能拍脑袋做决定。

定制化的痛点在于：我们过度依赖「人脑的记忆力」，我们期待所有人都了解所有细节，但这是不可能做到的。

只要中间有一个断层，问题就会不断扩大，而且问题会反复出现。

我能做什么？

那么我能做什么来改变这个痛苦的、原地绕圈子的现状呢？

---

3. 标准化

最近，我似乎找到了答案，就是去推行标准化。

一个产品的标准配置究竟是怎样的？一项新功能究竟应该支持多大程度的定制化？

这些问题，似乎没有人去深究，也没有人给出答案。

我厌倦了告诉新人「你去看一下上一个客户是怎么做的，就跟它做的一样就好了」。

我想要有一份标准化的文档，可以告诉新人，这个功能的默认配置就是这样的，你只需要跟 BA 确认这三个点就可以了。

标准化的文档还可以避免 QA 提出一大堆 confirmation bug，这个 logo 的大小到底应该怎么样，这个 dashboard 应该有几个图，这个图的标题应该是什么，等等……

从产品经理的角度来看，做了一个新功能并不代表做完了，只有新功能触达用户群，并且能收集到关于这个功能的反馈，才能形成有效的迭代闭环。

我们公司的瓶颈在于，做了的新功能，没法快速 rollout 到每个客户。

因为没有标准化的文档，BA 不知道怎么去提需求，Dev 就用模糊的需求和过往的经验来做，QA 也许根本没有测到「应该测的内容」。

Product Kick-off Meeting

标准化不是我一个人能够完成的，产品的默认配置到底应该是怎样的，有多少内容是可定制的，应该由产品部门来决定。

于是我跟产品部门进行沟通，说从现在开始，不管我们要推什么新功能，都要开个 kick-off meeting，把这个功能的默认配置和 BA 提需求的格式确定下来，不然我们 rollout 的速度肯定快不起来，也无法保证功能上线后的效果。

这件事算是「我给自己揽了个活」，也是一次「从 0 到 1」的突破。

第一次 Kick-off meeting 开了一个多小时，产品、程序、测试各说各的，完全不在一个维度，也没有讲清楚需求文档应该写什么。

我在会议上努力去理解每个人发言的重点，会后又花了一个小时来写标准化文档和需求文档的模版，发给产品那边确认，确认完了再放进我们的文档库里面，作为最终版本。

标准化的好处

有了这个文档，我们做 automation tool 的时候就可以在 UI 上做减法，只允许用户修改「可修改的配置」，一些默认的设置根本不用暴露给用户。

另外，每当大家针对一些细节产生疑问和分歧的时候，我就可以拿出这个文档，找到当时我们做的决定，来说服别人——「这就是标准」。

假如我们要改标准，也会有一套完整的流程，不是拍脑袋想改就改。

这个新功能的需求模版也受到了各个团队的好评，他们只需要按照模版，填写 3 - 5 项内容即可，不需要反复跟其他团队确认一大堆无关紧要的细节。

标准化就是在做减法，减少每个人需要记住的内容，让所有人可以轻装上阵，关注真正需要关注的事情，去做有价值的事，而不是把大量的时间都花在沟通、确认、讨论、口口相传、原地绕圈上。

---

4. 标准化的难点

说实话，标准化这件事，公司里面虽然偶尔有人提，但是几乎没有人做出实质性的行动……

毕竟「定制化」是我们的销售卖点，「标准化」对内部流程简化有好处，但很多人都倾向于「不做标准化的决定」或者「不讲清楚标准，让大家自己悟」。

为什么我们一直没有标准？为什么没有人去推标准化呢？

我想，也许是因为做这种决定牵扯的利益方太多，需要自上而下对齐目标，花时间去做沟通工作、召开会议，产出清晰的文档，让大家都愿意去用这个文档……

总之，这可能是件吃力不讨好的事情。

从另一个角度来说，「标准化」也会从根本上改变团队的做事方式。

做标准化，是有风险和责任的。

不做标准化，大不了就是大家多花点时间沟通，交付速度和以前一样慢，出了问题再去修就好了。

不做=维持现状，做了=承担风险。

但是，做好了=让所有参与其中的人都能获益。这对我来说，就是一种足够强大的动力。

我不在乎自己是不是「有责任」去做这件事，我只在乎做了这件事是否真的有好处，以及不做这件事是否也能达到同样的结果。

既然「让程序员多努力和知识分享」都无法达到我的目的，我就要换个角度来解决团队效率低的问题。

我解决问题的视角，从自己的团队内部转移到了前期的计划和与其他部门的对接这个环节，发现「需求不清」是表象，「不知道怎么写需求」是症状，「不了解我们的产品应该提供什么，能做哪些定制化」才是根本原因。

解决这个问题，就必须先说清楚我们的产品标准是什么。

我没有想要一步完成整个产品的标准化，毕竟这个太难了，十几年的产品+几十个客户。

但至少我可以从新功能的推行开始，做出一点点改变，通过行动让大家看到标准化的好处，能够接受这个「新鲜事物」。

在第一场 Kick-off 会议开的一团糟（老板的评价是：Awful meeting）之后，我还是坚持把自己想做的事情做完了（写文档+发会议纪要）；这个月的公司会议中，产品部门还特别把我写的文档和需求模版放进了 PPT 里面，现在已经有五六个客户的新功能的 rollout 需求都是用我的模版来提的（耶！）。

所以目前看来，虽然过程很曲折，结果还是很不错的~

---

5. 结语

欢迎分享你对这个话题的看法，周末愉快~