不写文档,我就变快了吗?

龙龙老师，今年是我做产品的第二年，团队为了提速，从去年开始拥抱AI，这一年来我写的文档越来越少，可速度好像没有提升的很明显，但肉眼可见的是混乱程度在加剧，几句话一个需求，产研看起来很默契，可把周围其他线的同事搞懵了，尤其是测试，基本上都在瞎测，还有遇到大需求想要回溯时，没有沉淀全靠猜。这几个月下来，我感觉自己好像不太能拥抱AI，不知道怎么提速，我不会要被淘汰了吧？

这是后台收到的一条留言，我看到它时，停留了好几分钟。

我以为自己能很快回复这位朋友，可好几次打好的回复，最后都被我删了。

我卡住了，这个问题没那么简单。

回答得不好，不但缓解不了他的焦虑，反而可能把事情说得更乱。

思来想去，我觉得这问题没有绝对的标准答案，还是试着分享下我的看法。

说到底，我真正想回答的是另一个问题。

不写文档，速度就真的变快了吗？

# Chapter 1

提速是所有团队都会遇到的问题，跟领域、行业、品类都无关。

软件开发需要提速，烧烤出餐需要提速，制造生产也需要提速。

写文档要提速，出稿子要提速，质量测试也要提速。

为什么非得提速？

把自己想象成老板就清楚了。

我要更快地验证市场，我要更快地看到收入增长。

那怎么做呢？

想办法更快地开发迭代，更快地做出新品，更快地获取客户反馈。

大家总说，天下武功，唯快不破。

放到商业里，这句话也成立。

快做快试，多错多试，循环往复。

而这条快速路上的所有角色，都会被带动着一起提速，绝无幸免。

我们都不想让自己成为那个最慢的环节。

我这么讲，个体的焦虑是不是会适当缓和一些呢？

因为提速焦虑本来就是常态，它并不罕见，不是现在才有，也不只存在于某个行业。

所以先别急着怀疑自己。

你遇到的不是会不会被淘汰的问题，而是所有人都在经历的提速焦虑。

只不过，以现在的视角看，我们正处于一个显著被动提速的阶段。

大家伙也无处可逃，我同样无法置身事外，这是趋势。

既然逃不过、躲不过，那就只能面对。

只要敢面对，问题基本上就不会太大。

记住上面这点。

反正就是别怕，兵来将挡，水来土掩。

接下来，就看看如何安全地提速。

# Chapter 2

提速要看「人」。

准确点说，要看这件事会不会影响别人，有没有协作成员。

我还是从开发过程中写文档这件事切入，会更容易理解一些。

文档是给人看的。

当一件事情不存在协作、不影响别人，也不需要交接时，那就怎么快怎么来，能不写就不写。

我经手过好几款产品的交付，其中有一部分仍在服务阶段，这些产品的迭代都由我一个人负责。

起初遇到大需求时，我也尝试过用文字记录自己的所思所想，但没坚持多久就放弃了。

大厂那套规范化管理适合团队合作，不太适合单兵作战。

对我来说，文档就会明显成为提速的枷锁。

赤裸地讲，时间都花在了把文档写得像模像样上，其实意义极其有限。

后来我做了两件事，把文档这一环节从工作流里踢了出去。

第一，有文档，但文档不是我写的。

做需求时，AI 是写手，它写它读，我出脑子，文档服务于它。

我把一大半时间放在问题和目标的表达上，交互和技术方案反而聊得更少。

比起后者的优雅丝滑，我更在意前面的问题有没有识别准确。

问题识别准确后，一般交付结果也不会有太大的偏差。

久而久之，工作的重心就逐步偏向识别问题。

这才是产品最该做的事。

不过有一说一，不管是谁写的文档，只有在被使用时才有价值。

绝大部分需求文档，都可以说是一次性的。

需求做完了，它的使命也就结束了。

AI 写的文档，我至今重新打开的概率不会超过 1%。

我更愿意看代码。

这就是我做的第二件事。

第二，对我来说，代码仓库就是最好用的文档。

代码是产品最直接的表达形态，它呈现的是最客观的逻辑。

做过产品的同学应该都知道，需求文档表达的是思考逻辑和预期方案，实际落地时很难做到百分百还原。

也就是说，通过文档看背景可以，看最终效果不行，多少会有偏差。

所以，需要排查问题或者回看历史时，我会直接选择看代码。

我的很多对外文档，比如常见问题、更新日志、用户教程，都是通过读代码生成的，简单高效。

所以，如果只看一个人，不写文档，速度确实有可能变快。

总的来说，一个人的提速是简单的。

理清楚什么是重中之重，把精力投入进去，再删掉其余不重要的环节。

可一旦中间出现了“别人”，事情的复杂度就会显著显著再显著提升。

# Chapter 3

人一多，不可避免地就会遇到协作问题。

而协作里要不要写文档，又是一个老生常谈的话题。

不过在讨论团队应该怎么做之前，我想先把镜头收回来，看看我们自己。

问题到底出在文档，还是出在我们对文档的认识上？

我直接给出几个从个人身上诊断的方法。

一，是否分得清工作的主次。

产品日常工作里写文档是常态。

可以大胆地说，大部分产品经理都曾通过文档来彰显工作量和价值，职业越早期，写得越多。

这是中性的观点。

一万小时定律没错，现在多写一些，以后才能少写一些。

但也不能动不动就写文档，要先想清楚写文档在工作中的主次。

为什么我非得写这个文档？

这个文档究竟写给谁看？

除了文档，还有没有更轻的表达方式？

我有没有更重要的事情要做？

产品要解决问题，文档只是解决方法之一。

吼一嗓子能解决的事，就别非得上文档。

我在职业头两年经常写文档，大大小小的事情都需要文档记录。

改个布局的小细节要写，接入支付的大特性也要写，只要流转到开发节点，就必须有文档来做载体，没有就不做。

甚至到后来，产品输出的文档数量跟开发写的代码行数一样，变成了隐形的考核标准。

文档变成了形式主义的具体表现。

不能说完全没有收获吧，只能说如果腾出更多时间，应该能做更多产品真正该做的事情。

二，抛开剂量谈药效就是扯淡。

写文档也一样，如果简单说写文档浪费时间，这实在是太片面了。

我个人非常认可文档的价值。

好记性不如烂笔头，何况我们的文档还会直接影响上下游。

可如果觉得写文档影响速度，那就先看看，日常工作里究竟有多少时间花在了写文档上。

再看看这些文档里，又有多少是真正被人使用的，多少是价值甚微的。

如果排查下来，时间花得多，文档价值又很小，那就要么改变自己，要么改变环境。

反过来，如果文档并没有占用多少时间，也确实有人在使用，那就得问问自己，是不是单纯在抗拒写文档。

这其实就是下一个问题了。

三，嫌写文档影响进度，有没有一种可能，是我们不会写。

别急着对号入座，这句话说的也包括我自己。

实话说，写文档是产品众多事项里最舒服惬意的一件事，没有之一。

在我看来，文档就像是一个空白的舞台。

我要自己设计开场落幕，自己设计服装、道具，自己布置场景。

我在舞台上只有一个使命，把故事讲清楚。

用我的肢体，用我的语言，让观众充分理解我的故事。

我在舞台上也只有一个对手，就是我自己。

我要如何又快又好地把观点演绎出来呢？

至少目标足够具体：把故事讲清楚。

这实在是一件值得高兴的事情（居然有目标！）。

所以我说怎么想都想不到，居然有产品会不愿意写文档。

哈哈收一收收一收，脑洞一不小心就打开了。

我其实想表达的是，写文档并没有大家想的那么让人生厌。

换一个角度去看这件事，可能就会有全新的体会。

当你享受写、又经常写时，质量和速度都会有明显提升。

这就跟我开车一样。

我不喜欢开车，很大一部分原因就是车技差，难道我因此就不再开车了吗？

不会的。

熟能生巧，我会继续开，直到车技变好。

文档也是一个道理。

如果我们写得太少、写得不够好，速度太慢拖累了节奏，那就继续磨、继续写。

所以，站在个人角度看文档和速度的关系，无非就是三个问题。

第一，能不能分清楚写文档和其他工作的主次。

第二，日常工作里，写文档到底占了多少时间。

第三，我们对写文档究竟是什么态度。

前两个问题，是在判断文档有没有真的拖慢我们。

最后一个问题，是在判断我们对文档的抵触，究竟来自它没有价值，还是来自自己不喜欢写、不会写。

想清楚这几个基本问题，或许对我们都有帮助。

# Chapter 4

再回到团队上。

如果只看一个人，前面的答案是明确的：能省就省，怎么快怎么来。

可放到团队里，不写文档，速度就一定会变快吗？

未必。

我先说我的主要观点，速度不是靠简单做减法就能提上去的。

这件事没有绝对的万金油，适合自己的才是最好的。

上一章已经把我对文档的态度讲得很清楚了。

事情不是非黑即白，需要“因地制宜”。

不需要文档就不要硬写，需要写文档的就不要凑合。

我经历过啥需求都用文档，也经历过啥需求都靠一张嘴，还经历过相对理想的混合状态。

文档驱动型的管理，优势在于清晰、可控。

劣势也很明显，流程极易阻塞在出文档的节点上，可以说是动不动就卡住了，身会累。

口头驱动型的管理，优势当然是灵活、快速。

劣势也很直接，就是混乱。提需求简单，但做需求全靠想象，对齐、遗忘、再对齐、再遗忘，心会累。

混合型的管理，看起来像是把两家的好处都占了，实际上最难。

因为混合难在一个度。

什么时候写，写到什么程度，谁来写，谁说了算。

这个度控得好，阖家欢乐。

控得糟，容易扯皮，身心俱疲。

情况看似不太乐观，好像不管怎么做，提速都会带来副作用。

那倒也不至于。

下面是我的一些策略。

一，与其看不如做。

如果团队自己也拿不准哪种方式更合适，最简单的方法就是先跑起来。

文档驱动、口头驱动、混合驱动，都可以试一试。

不需要很长时间，跑个 2—4 周，基本就能看到问题。

试完了不要只看产品是不是少写了，还要看开发问得少没少，测试猜得少没少，团队返工少没少。

最后拿结果说话。

二，文档友好协作。

如果确认问题的确出在产品文档太重，那就先让产品少写一点。

注意，是少写，不是不写。

关键需求、关键规则、关键节点，还是要由产品写清楚。

非关键问题就用更轻量的方式记录，发条飞书消息，丢张截图，甚至当面吼一嗓子都可以。

不要让一份完整文档，成为所有人开始工作的前置条件。

把该写的写清楚，把没必要的拿掉，产品才不会一直卡在写文档这件事上。

三，全员转型产品。

产品少写了，接下来的问题就是谁来写。

总不能产品不写，其他人也不写。

这样不是提速，只是把问题藏起来了。

所以第三步，不只是让更多人来写文档，而是让更多人拥有产品意识。

换句话说，全员转型产品。

这里的“产品”不是职位，而是两种东西：Ownership 和产品 Sense。

Ownership 看重视程度，产品 Sense 看判断水平。

当这两种意识足够强时，团队成员就不会只盯着自己手里的任务，也会主动站到产品视角上思考问题。

这里说的判断，不是完成自己岗位职责范围内的判断，而是产品判断。

团队成员不只从自己的岗位看问题，也能站在用户、业务和整个产品的角度，判断一件事该不该做、应该做到什么程度、不同选择会带来什么影响。

当这种产品判断足够成熟，很多问题就不必再等产品拍板，成员自己就能往下推进。

这不是去产品化，更不是大家一窝蜂地去抢产品的工作。

团队要培养的，也不只是多几个人会写文档，而是让判断能力和责任意识分布到更多人身上。

产品要做的，不是把所有判断都抓在手里，而是把判断权适当地分出去，再给足边界和支持。

产品不再是团队里唯一的信息出口，而是协作的组织者。

四，目标驱动迭代。

当团队里越来越多人具备 Ownership 和产品 Sense，才有条件继续走到下一步。

再往后走，连谁该写文档、写多少文档，都不需要提前规定。

用目标而非任务来推动产品迭代，差别就在于想象空间。

目标不是模糊，更不是让大家各做各的。

目标是把问题、边界和结果讲清楚，至于具体怎么实现，可以给每个板块留下足够的空间。

有人觉得写一页文档最快，那就写。

有人觉得画张图、发段消息就够了，那也可以。

每个板块的人根据自己的目标和协作对象，判断要不要用文档、由谁来写、写到什么程度。

只要不影响别人，最后也能对结果负责，就不用追求所有人的动作整齐划一。

走到这里，文档不再是统一要求，而是一种协作工具。

需要就用，不需要就别硬上。

这几条也不见得就一定有效。

毕竟团队是由人构成的，而人是最复杂多变的因素。

我们一方面要尊重团队成员的多样性，另一方面也要在多样性中寻找稳定性，这本身就不是一件容易的事情。

但至少有一点是明确的。

文档只是表象，背后是人怎么判断、信息怎么流动、责任怎么分配。

只删除文档，解决不了这些问题。

# End

我确确实实没想到，一个关于文档的话题，自己能写这么多。

罗里吧嗦写了很多细节，也算给自己做个记录。

回到开头那位朋友。

你看到测试在瞎测，看到大需求无法回溯，说明你已经意识到团队的提速出了问题。

这跟你会不会拥抱 AI 没有直接关系，更不代表你要被淘汰。

文档当然可以少写，也可以交给 AI 写。

所以，不写文档，速度就变快了吗？

对一个人来说，有可能。

对一群人来说，未必。

说到底，一个人的快很简单，一群人的快很难。

团队提效，绝不是删掉文档就算结束。

速度不是删出来的，是整套协作一起调整出来的。

文 / Chris