2025-11-04

前言

陆续分享过几篇自己的思考，希望引起大家对软技能的重视，感谢大家一直以来的支持。

• 如何写好一篇文档? 🔥 1.0w 👍 261 ⭐️ 422
• i 人研发沟通指北: 沟通中的道与术 🔥 7.6k 👍 349 ⭐️ 398
• 基建团队的自我修养 🔥 4.5k 👍 243 ⭐️ 164

相信大家或多或少都写过一些规划，规划也是成为 Owner 的必备技能之一。最近一直在跟团队里的同学对一些规划，发现了一些共性的问题，总结下来，希望对大家能有所帮助，也欢迎各位同学在评论区讨论。👉 👉 👉 文章比较长，建议先⭐️收藏再阅读哦！古人云，凡事预则立，不预则废。技术规划，是进阶路上必不可少的一环。那一个好的规划需要完成哪些事情呢？先下结论

• 判断事情是否值得做 (要做对的事情，好钢用在刀刃上)
• 判断事情该如何做 (要把事情做对)
• 简洁而清晰地展现推导逻辑 (向外争取资源，酒香也怕巷子深，大家都是聪明但很忙的人)

不少同学在写规划的时候只关注了第二点，但其实另外两点也非常重要，缺一不可。第一点是前提，前提错了，后续的工作全都会白给，碌碌而无为；第三点是点睛，只有其他人也理解了，才能争取到资源，后续协作才能顺利开展。Talk is cheap. 先抛一些近几年自己写过的一些规划，可以大概瞄一眼。

做好一个规划并不容易，规划绝对不是简单的 2=1+1，规划的底层逻辑是找到做正确之事的正确方法。规划需要投入大量时间深度思考，如果不花时间去仔细思考需求背后的本质，那就只会疲于应付你不想支持的需求。

为什么要写规划？

• 避免疲于应对各类需求，总被业务推着走
• 让协作方更好的了解到全景和收益，协作更加顺畅
• 更容易做好优先级管理，避免按下葫芦浮起瓢
• 有效避免返工问题，提高工作效率

短期可能会有效率更低的错觉——上手就干，会让人看起来很勤奋，战术上的勤奋很容易掩盖战略上的懒惰，更具体一点说，"做对的事情"带来的影响通常需要长期来看，短期内是不易察觉的。举个例子，如果一个项目在 Q1 做完，Q3 返工重做，那从全年来看，Q1 的产出就是无效产出。

• 锻炼/体现一个人的系统思考能力

抽象一点讲，写规划非常锻炼一个人系统思考能力。功利一点讲，晋升的材料中，规划一定是必不可少的部分，也是最能体现一个人成长的部分，一份清晰明了的规划，直接就会在评委那里获得非常不错的印象分，加上优秀的执行力，轻松获取双强支持。

规划梳理 SOP

暂时无法在飞书文档外展示此内容在真正开始讲细节之前，我想先分享一张路径图(右图)，这张图有很多种理解方式，代入到规划场景

• 左上代表了 MVP 的关键路径
• 左下代表了关键重难点的突破
• 右上代表了缺乏主线，随机乱撞
• 右下代表了深陷牛角尖，无法自拔

理规划的时候，经常看看自己当下处于图中的哪个位置，会有非常有用，当卡住的时候，尝试往后退一步，往往都会有新的发现。

规划六要素

这六要素是我自己写规划的一些经验，并不是教科书式的定义。六要素的顺序需要是一个完整而清晰的叙事逻辑，后一节承接前一节，避免逻辑上的跳脱造成读者理解困难。如果顺序弄反了，比如把思路放在目标前面，就会很容易让人摸不着北，虽然能理解要这么做，但却不知道为什么要这么做。读者都是聪明但很忙的人，所以要尽量避免读者自己推理。个人推荐的顺序 —— 先抛出一个好的问题，来论证解决这个问题的价值，然后表达整体目标来提纲挈领，再说明目前遇到的关键痛点/难点，然后提出核心解决问题的思路，最后给出方案全景，这时候顺带提出方案的成熟度模型，最后再进行拆解落地路径。这个顺序也可以调整，事实上，我自己也调整过很多次，但一定要考虑逻辑的合理性，要符合大部分读者的思维习惯。

价值论证

问题定义如果对问题没有足够深刻的认识，那就是不可能做出一个具有建设性&前瞻性的规划，最多算是一个执行方案甚至 TodoList，难称“规划”。在写规划的时候第一节一般都是背景，但是会发现很多人都是一两句话就略过了，跟别人讨论的时候，更是一句话"大家都懂"，连讲都不讲了。事实上，大家大概率都不知道你在说什么。我将这个标题定为价值论证，而不是常见的"背景"，就是想提高大家对这方面的重视程度，就算你在写规划的时候使用了"背景"一词，也希望能记住这一节其实是价值论证。请重视、重视再重视对于价值论证(即背景)的阐述，这是带动读者"入局"的关键，是你后续方案站得住脚的关键，也是拉长周期看提升效率的关键。提出一个好问题比解决问题更重要写规划之前，通常都会有个相对模糊的目标，大概要解决哪些问题。一个典型的错误就是把当下的问题流水账式地一列，然后随便写个目标，就开始写解决方案了。对问题定义的深入研究，正是透过现象看本质的过程。定义问题时要控制住去解决问题的冲动，试图去探究和理解表层问题背后其他深层次的原因，过早开始着手解决问题，就会深陷技术细节而忽略对问题本身的挖掘。如果你常常略过了这一节，那只有一种可能，本质上你还是在执行，执行一个来自他人的任务，而不是在自己主导规划一件事。这就是为什么有些规划会给人视角高度不够、没有上个台阶考虑问题等感觉，因为纯执行视角下的问题想上高度是很难的。饱和式(120%)认清现状

为什么要看到那么多？就是给自己一个上台阶的机会，因为有很多问题的根因都是同一个，但不放在一起看很难觉察到。这样有不少问题很可能捎带手就解决了，长期来看，效率可以被大幅提高，你也可以避免疲于应对各类突发需求，给自己留出更多的思考时间，正向循环。

一旦我们看清了结构和行为之间的关系，我们便能开始了解系统如何运作，为什么会出现一些问题，以及如何让系统转向符合人们预期的行为模式。—— 《系统之美:决策者的系统思考》

什么才算"问题定义清楚了"？

• 每一个问题都可以简明、准确地说出问题是什么，原因是什么，影响范围是什么。

一个常见的现象是，当有人提问 xx 问题是什么意思的时候，作者又去拉了另外的同学来解释，这就是典型的没有理解清楚，如果连问题都解释不清楚，那怎么可能很好地解决这个问题呢？无论这个规划最终是否由自己亲自落地，问题背景都需要做到熟稔于心。但这一部分不一定非要体现到文档里，不然会让文档显得非常冗余。

• 后续遇到相关/相似需求，应该"预判到了"占大多数。

如果你经常说"当初没有考虑到这种情况"，显然很难得到别人的认同。最好的回答永远都是，"当初考虑过这个问题。"

• 如果已经做完了，看看当时的技术选型是否合理，能否低成本的支持上。
• 如果还没有做，那回顾一下当时的优先级判断是否合理。

一旦出现应该解决而没解决的问题，那要多问问自己当时为什么没有考虑到，大概率是认清现状时没有覆盖到，是因为当时找人聊的少了，还是考虑的时间短了，这不是追责，而是为了下一次做得更好。数据分析本来应该是问题定义的一部分，比较重要，所以单拎一节。大部分研发同学的数理逻辑基础都是比较强的，但我依然建议每个人都应该系统地学习一下数据分析的知识。在写规划的时候，比较忌讳"不言而喻"，这很具有迷惑性，在实践的时候发现前提条件错了，很容易导致事倍功半。不依赖任何数据做出的决定往往都是想当然。想区分哪些是想当然，哪些是事实，数据分析是一个非常好的方法，非常建议尝试着多做一些定量的分析。

• 对于稳定的数据，考虑其合理性，是否有优化空间。
• 对于不稳定的数据，先分析不稳定因素，这部分往往会对结论造成重大影响。
• 数据分析结论可能是反直觉的，需要多方交叉验证。
• 数据分析时需要划分不同的维度进行观测，划分维度的根本目的是管理误差。
• 数据也有可能会说谎。 (后文会展开)

解构&提炼问题给你 2000 字的机会，让你讲明白一个问题，那大概率是可以的。但我们往往面对的是数十个问题，我们不可能通过几万字来讲清楚每一个问题。"以小见大"是提炼问题时常用的手段，无数的小问题抽象成核心大问题，通过典型的小问题来解释大问题，再将大问题分解成可被解决的小问题，这样问题也就得到解构，价值也就论证清楚了，同时解决方案也就在眼前。注意不要拆分过多问题，因为大多数人一次最多只能记住四件事，说多了，就记不住了。当问题足够凝练时，针对每一类问题，抛出一两个简单但深刻的例子，这样才能够让读者易于理解到底要解决什么问题。但需要注意的是，并不是每一个问题都值得现在或自己去解决的。

很多复杂问题是更高维度简单问题的投影，比如说打篮球动作变形、速度慢、配合差是很多时候体力不行；写程序烂、bug 多、时间长是抽象分解问题做的不好；还有比如海军说的“很多管理问题都是假象，本质是能力问题”。而解决这些本质问题需要更大代价和决心的。—— 张一鸣

价值论证过程，也是目标逐渐清晰的过程。花了那么大篇幅来讲如何写好价值论证这一要素，就是希望能够引起重视，再次强调，提出一个好问题比解决问题更重要。

关于价值论证更多的描述，推荐阅读技术价值论证 V0.3

核心目标

目标定义在开始梳理规划之前，通常都会有一个模糊的目标，一般都是直接奔着问题去的。当你 120% 的认清了所有现状之后，大概率可以被提炼成一个更加宏观但清晰，且具备可落地性的目标。想清楚什么是手段，什么是目标！这是一个特别容易犯的错误，它很容易会将你的规划甚至团队带入深渊。比如当下最火的 AI，用 AI 是手段，做好业务才是目标，很常见的错误就是把用 AI 当作目标，最后做了一堆华而不实、没有什么实际用处的聊天机器人。关于目标，虽然看起来只有短短的一句话，一定值得你慎之又慎的去思考和提炼。目标是读者读完文章后最需要被记住的事情，这是对项目认知直观引导。在制定目标时，有一个很有用的SMART原则可以参考(参见右图)，这里不具体展开，后文基本上也会涵盖这里面的内容，有兴趣的同学可以单独去查阅相关资料。暂时无法在飞书文档外展示此内容说明一点，我自己的习惯并不是严格按照 SMART原则来提炼目标，比如

• 我更习惯把指标定义放到具体落地的方案里来检验目标的达成，而不是定为目标本身，这样不同阶段可以使用不同的指标。
• 我还会把时限放到后面的里程碑里，这样会更加的全面而清晰。

但总的来说，这个原则里提到的五个维度是我认为在整个规划里都必须涵盖的。有些同学会试图把目标定成一个大而全的事情来体现自己的技术视野，但实际上往往只会起到反作用。什么都想做，就只会什么都做不好。把事情直接抽象成一个过于通用的方案，只会导致目标和落地，一个天上一个地下，目标是航母，实际一看是个自行车，只会给人一种非常务虚、不知道到底要做什么的感觉。相反，恰到好处的抓大放小，才是真正体现一个人水平的地方。大而全 ≠ 视角高没有任何一个团队的人力是无限的，大到公司也是一样的，我们必须要舍弃该舍的东西，这才是更成熟、现实的做法。对于该不该做、该做哪些一定要有充分的判断和依据，一定不会做的事情就没必要写上去，聚焦真正有价值的事情上，只有核心问题才值得被拔高或泛化。目标对于后续规划的影响是非常巨大的，一旦目标制定完成，请始终记好你的目标，并不断检查是否会达成目标。不然方案可能做的天花乱坠，实际一看，与目标完全不相关。在这里也列一些之前自己实际规划做过的一些目标供大家参考:

• 钟馗

构建现代、统一、高效的综合治理分析与应用体系，激发高效交付

• 技术债治理

构建技术债综合治理体系，帮助业务战略性地规划、跟踪以及偿还债务，促进项目长线健康发展。

• Code Review

为 RD 构建一个积极、透明、规范的现代代码评审协作环境，提升代码评审质效，促进工程师文化 & 知识共享。

• 影响面分析

构建统一的变更风险可视化体系，帮助业务更好、更快地落地垂类场景分析能力，提高 RD 的消费体验。目标拆解我自己的习惯会是在解决思路那儿一并完成拆解和解释，当然也有不少人习惯在目标下面直接进行简要的拆解和解释，位置不重要，重要的是目标是需要可拆解&被拆解的，而拆解一定不是 2=1+1。目标拆解时，《金字塔原理》介绍了一种非常不错的方法——MECE分析法，不重复、不遗漏，我个人更喜欢用一个数学上的概念来表述这件事情——正交，无论怎么叫，说的都是同一个事情。

举个直观的例子，对人的划分，可以分为男人、女人，也可以根据工种划分研发、产品、设计等等，但是不能分成男人、研发，这样的划分会给后续带来很多麻烦，非常容易遗漏。

通常可以沿着维度的划分再进一步细化，一般分解到第三层时，基本整个解决方案也就明晰了。

• 我自己最常用的拆分维度——架构维度(分层)、流程维度(分节点)。

这两种维度几乎可以解决绝大多数技术规划，且很容易做到正交的拆分。

• 越靠近原始目标(顶层)的概念，越需要足够清晰、简单、无歧义。

这个无歧义一定不是自己觉得无歧义，如果你在和别人讨论的时候，发现别人很自然的理解错了，那别尝试解释，产生了歧义是客观事实，跟你之后解不解释没关系，这个人误解了，其他读者一样会误解。我推荐的方式是，一旦发现直接避免使用这个概念，至少越抽象的地方，越不应该使用，因为这些概念往往都是纲领性质的，它会给读者带来灾难性的误解。

举个简单的例子，你能分得清中台和平台么？问一问旁边的人，看看他的理解和你一样么？

• 注意"抓大放小"，把精力放到主要问题上

有些问题虽然被定义出来，但可能并不值得当下去解决，解决之前，一定需要考虑必要性，投入产出比(ROI)到底值不值。

在复杂事物的发展过程中，有许多的矛盾存在，其中必有一种是主要的矛盾，由于它的存在和发展规定或影响着其他矛盾的存在和发展。—— 《毛泽东选集: 矛盾论》

关键挑战

这里需要考虑的是在可能产生卡点的重难点问题，对应图中黄框部分，这部分很可能会对整个方案产生质的影响，值得深入考虑 & 可行性验证。

考虑是否真的值得解决这个难题通常需要考虑这个问题的重要程度，是否真的对全流程产生质的影响，解决问题的成本是否过于高了，是否存在别的路径。我自己常用的判断问题值不值得解决就是画一个右边的坐标系，判断事情落在了什么位置。

• 越靠近右侧，越应该高优解决，哪怕成本比较高

(往往是，明年做只会比今年成本更高)

• 越靠近左上，越应该避免投入过多人力。

暂时无法在飞书文档外展示此内容难题 ≠ 要攻克有些事值得做，难也要做；但难的事情，未必就值得做，二者并不是充分必要条件。公司鼓励，做难而正确的事情，一定不要忘记这个事情首先得是正确的事情，不然就是自嗨。写完之后，要再次检查一下如果这些挑战能够突破，对达成核心目标是否有重大影响。

核心思路

对于读者而言，思路是整个规划的精髓，是通篇读下来最有收获的地方。思路也是一份规划是否具有前瞻性的关键。好的思路经得住时间的检验，虽然具体落地方案可能会随业务发展而变化，但核心思路不应该轻易改变，不然很难在一个领域做深做透。无论长短规划，思路都需要清晰、简明，越是长期的规划，越需要简单、深刻的思路，这些思路不能是正确的废话，一定需要折射出背后有更深层次的思考，换句话说，更像是一种洞见。

以我自己所在团队举例子，我们是负责客户端代码准入的基础设施建设的。2020年起步的时候，核心思路就是要「基建 vs 业务问题」转为「基建+业务 vs 问题」"和"建设分析体系——标准化、体系化、生态化"这两个思路一直沿用至今。2022 年开始做代码数据服务，具备实时分析代码调用、依赖关系的能力，提出"代码即服务"的思路也是一直沿用至今，刚好跟最近 AI 的火热撞个正着，顺其自然的能够给 AI 提供更高质量的上下文。2023 年抖音的准入规范规模逐渐庞大，遂提出 "Coaching, NOT Blocking"的理念，有效治理了准入生态，同时也改观了业务 RD 对于准入的认识，也是保持至今。不可否认，我们的技术方案迭代了很多轮，但这些思路贯穿了从最初两个人单打独斗到现在成建制的团队的过程，被保留了下来，经受住了时间的考验。👉 感兴趣可以阅读 钟馗白皮书丨综合质量分析与治理体系

这一关，最难在于"打开思路"。很容易钻进某一个牛角尖出不来，我的经验还是前文提到的，要不断检查自己思维在路径图中所处的位置。这个阶段，一定要多跟其他同学讨论，深入讨论，好的思路都是深入探讨出来的。

• 思路不是总结，别期望一次把所有的细节都想清楚。
• 思路不是主观判断的扩写，而是大胆假设，小心论证。
• 搞清楚自己到底是如何下的判断也很重要。
• 遇事不决，及时往后退一步，再重新想，不行就再退一步。
• 思路也可能会失灵，必要时重新建构整体思路。
• 一旦出现思路上的调整，一定要及时拉各方重新讨论&对齐。
• 尝试证伪自己的假设。 (后文会有更详细的解释)
• 自己的认知和事实通常都是有差距的。
• 习惯性多问为什么，是不是真的就这样、为什么会这样。
• 推翻自己的思路固然令人不爽，但总比做完再推翻来的好。
• 优先正向解决问题，而不是缓解问题。 (后文有更详细的解释)
• 不要因为走得太远，而忘记为什么出发。
• 未必要直接解决所有的问题

案例如果你打算修的是高铁，那么肯定是不可能直达你家楼下的，分距离以合适的方式和方法来解决对应的问题往往是更好的选择，避免想着一个方案直接解决所有的问题，而导致项目难产。

写完之后，要再次检查一下如果按照思路执行，能否达成核心目标。

方案全景

到了这一步，通常就到了大家最擅长的一步了。我最推荐的还是画好一张全景图(通常是架构图或流程图)，公司内也有很多讲怎么画好架构图的文章。当然也有同学可能并不赞同这种图，觉得一眼看过去并不知所云，我依然推荐的原因如下内在原因 (for 作者)

• 透过架构图，来梳理自己对于方案的描述逻辑
  • 帮助自己梳理思路，防止遗漏要点
  • 确保内容不会偏题，抓得住重点
  • 抽象地看框架，事情也更容易理顺

外在原因 (for 读者)

• 人对图的接受程度要远大于大段文字
  • 图可以帮助读者快速理清各元素之间的关系，对于关系的形象描述有着天然的优势
• 图的理解粒度，可粗可细
  • 粗，可以统观整体设计，让读者有个宏观的认识 (自顶向下)
  • 细，当读者读完后续方案细节后，反观图即会有更为清晰的认识，下次再讨论时，能够快速回忆起具体的内容
• 提升文档的专业度和权威性
  • 懂，可以快速通过架构图来看其中的门道
  • 不懂，从某种程度上至少让人愿意相信这是经过深思熟虑的

这是最主要的原因，读者无需一开始就仔细地理解整图，对整体系统能有个大体认识即可。

全景图不止横向、纵向两种维度，还可以有面积大小、颜色深度、边框线条等等。不用讲究用上每一个维度，但必要时可以增加维度而提高图的信息密度。但也不要刻意用上每个维度，不然很容易陷入，这个图怎么表示都不对的陷阱。全景图之后，就是方案细节的描述了，但如果是长期规划，并不建议在这一节讲每块讲的过于详细，而是推荐另起一篇文档，来拆分一期、二期，这样这篇规划就可以足够干练。写完之后，要再次检查一下如果方案落地，能否达成核心目标。

落地路径 (里程碑)

拆解落地路径不是 2=1+1。举个例子，当我们设计一个非常完美的流程时，往往不会一个节点做完美之后再去做下一个节点，而是通常会选择先进行全流程的打通，这样能够快速看到效果，并摸清楚每个节点大概存在哪些问题，以给下一步动作提供指导性意见，这就是平时我们所说的 MVP，通过最小的功能集来快速达成产品，以尽早进入用户反馈阶段，很多东西想着和用着是完全不同的两种感受(这可能也是为什么产品都很喜欢改方案吧，苦笑)。MVP 是一个已经被广泛验证接受的一种模式。本质上，这也是避免人力盲目投入的一种风险控制策略。

再复习一下

在复杂事物的发展过程中，有许多的矛盾存在，其中必有一种是主要的矛盾，由于它的存在和发展规定或影响着其他矛盾的存在和发展。—— 《毛泽东选集: 矛盾论》

案例如果你打算从北京大钟寺工区前往上海新江湾工区，第一阶段需要考虑的是坐飞机还是坐高铁，来解决城市之间的通行问题，而不是先考虑是"打车去机场/高铁站、还是坐地铁"去这种城市内的通行问题。思考一下，在实际实践的项目中，你是否有过先考虑了"怎么打车去机场"，结果后来定的"坐高铁"的尴尬情况。

我们往往需要针对需求实现的不同阶段来设立里程碑，这样便于一步一个脚印的落地，而避免憋大招，设立里程碑最重要的是确定阶段性目标以及阶段性需求范围，在实践过程中，非常容易出现越做需求越大，导致项目不断延期，这就是需求范围有问题，需要明确做到什么程度，是达到了对应阶段的目标。完成路径拆解之后，一定要再次确认，能否达成每个里程碑的目标，完成所有的里程碑之后，能够达成最终目标，这个确认几乎花不了多少时间，在于非常容易遗忘，从而导致做完的项目发现目标完全达不成。至于落地路径的展示形式了，我自己喜欢用飞书画板，分层分模块的表达，这样更加清晰直观一些。暂时无法在飞书文档外展示此内容写完之后，要再次检查一下每个里程碑之于核心目标的意义，是否真的达成了核心目标。

[可选] 成熟度模型

众所周知六要素可以有七个（笑脸。

成熟度模型是方案全景的一个补充，它可以以另外一种形式来描述，可以更直观地评估不同发展阶段下达到系统的预期，让复杂系统的迭代路径以一种结构化的形式展示出来，知道当前在哪，要去哪，怎么走，非常也便于我们更纯粹地窥见理想状态下的系统的样貌。关于成熟度模型，更多的可以参考 基建成熟度模型草案

常见误区

❌ 规划必须事无巨细地把方案的所有细节想清楚✅ 规划是一种预判，而不是总结，只需要针对关键点进行可行性验证即可。❌ 规划要留大块时间一口气写完✅ 很多规划，尤其是偏长期的规划，是需要很多灵感的，灵感这个东西，不是靠憋能憋出来的，有时候放松一下，反而会灵光乍现。❌ 写规划的时间，可能就已经上手实现完了✅ 忽略了对"要做对的事情"的谨慎判断，拉长周期看，很容易反复做同一件事情，看似很忙，其实没什么有效产出。❌ 规划好了，就应该事事顺利✅ 并不是，有意外才是一种常态，规划只是尽可能降低灾难性卡点(导致整个方案不可行)的概率，但一定还是会有意外，比如最常见的复杂度要比预想中高、某个基础设施没有想象中那么好用等等，要尽可能给意外留出容错空间。

举个极端的例子，再好的产品规划，也架不住特朗普突然要封停 TikTok。

实用技巧

先由少到多，再由繁至简

这个技巧还是一位大学老师教给我的，当你觉得一篇文章干货满满，大概率都是作者有意规避了一些冗词赘句。通常来讲，我们不太可能一次性写出一篇高度凝练、各部分内容笔墨都恰到好处的规划，那就不妨先顺着思路能写多少写多少，先有了内容，再去刻意地提炼&精简内容，这样可以有效避免刚开始想的时候还想过几个边界case，而真正写的时候却忘记了。

连问三次为什么

这是多年作为基建与业务打交道的经验，后来在读书的时候看到，丰田汽车公司有一个五问法，被广泛应用于丰田的生产系统中。核心本质是一样的，次数并不关键，要通过多次问为什么来找到本质问题。我们几乎不可能通过一次为什么来找到本质问题，所以强迫自己，多问几次为什么，甚至给自己计个数，通常会得到不一样的思考。

如果当初调查用户需要什么，他们会告诉你要一匹更快的马，而不是汽车。 —— 亨利·福特

主动证伪自己的假设

在梳理规划的时候必然会夹杂很多自己的主观判断，这本身也是一件正常的事情，规划不是总结，本身也需要预判。但这里有可能出现底层逻辑的谬误从而导致整个方案雪崩。规划很容易变成基于自己的某个判断的扩写，于是写规划的过程，就变成了到处找证据证明自己的观点正确的过程，于是特别容易形成验证性偏差，因为人总是倾向于选择相信自己愿意相信的事情。这样的规划风险是非常大的，因为规划的根基不是源于客观而全面的事实，而是基于自己的某个判断。主动尝试证伪自己的假设，会让自己很容易发现这些反面证据，习惯性多问是不是真的就这样、有没有可能不是这样、到底为什么会这样。要考虑不确定因素以及是否存在盲点，虽然这些常常与自己的判断可能不符，会让人感到不爽(事实上，很多问题的答案就是反直觉的)。另外一点就是多关注因果关系的走向，要区分开到底是因果关系还是相关关系，典型的就是尿布和啤酒放一起卖的例子。当你怀疑因果关系走向时，请进行反方向验证思考。尝试证伪的目的是为了揭示未知信息，而不是已知信息，而这恰恰是走在“做正确事情”这条道路上最重要的保障措施。一旦判断出现问题，大胆承认并尽快调整方案，哪怕是在规划梳理完成之后，否则成本只会越积越多直至爆雷。不知道大家有没有看过《神探狄仁杰》系列，我认为剧中狄仁杰最厉害的点就是可以毫无心理负担地推翻自己之前的判断。

数据可能会说谎

你的想法决定看到什么，数据也是一样的，同样也会产生严重的问题。这里单独提出来，是想强调不要觉得数据就是客观事实，数据很可能会说谎。逻辑其实是一样的，一旦有了一些判断，是很容易影响自己对数据的解释的。我们基于数据说话，通常有个前提，过去的数据可以在一定程度上预测未来。但事实上，这个前提未必正确。

案例某 App 发了个新版本，然后用户活跃时长看起来上涨了，于是加大投入，发现并没有带来更多日活。归因的时候才发现，原来是当时的那个版本只是因为暑假到了，中小学生们有更多的时间玩手机了，几乎所有娱乐 App 活跃时长都涨了。

所以在分析数据的时候，要通过不同视角下的数据进行交叉验证，同时，尝试针对数据进行不同维度的拆分，来确保自己得到结论足够 solid。 最遗憾的是，这个事情通常只能自己做，因为你不可能指望别人在看你规划的时候发现数据分析上的盲区，因为不亲自分析，很难发现端倪。

问题缓解陷阱

处理问题之前，先判断清楚是在缓解问题，还是解决问题。不得不说有很多问题或许没有办法从根本上解决，但缓解问题应该是谨慎评估后主动选择，而非因为快思考下的惯性使然。问题缓解方案通常很容易被想到，并且看起来成本也比较低，这就很容易形成一个陷阱，误使我们的大脑使用快思考的系统1(节能的本能驱使)来导致我们无意识地选择这样的方案。这样的方案往往治标不治本，拉长周期来看，很容易出现返工的情况。

案例一个任务的执行成功率只有80%，产物经常因为执行失败而无法获得。处理方案:建立自动重试机制将成功率提升至90%建立定时触发机制，将整体的进一步提升至95%。

看起来很合理，短时间内问题也似乎得到了"解决"，但事实上这是一个典型的缓解问题的策略。这里举这个例子并不代表不能这么做，而是说，如果这么做，一定是经过谨慎评估后做出的选择。因为这样的方案往往意味着在后续的迭代过程中还会出现更多的不稳定因素，整个系统变得按下葫芦浮起瓢，累计到任务原本的成功率逐步降低到50-60%，重试机制的收益变得越来越小，这时不得不重新开始，从正面解决稳定性问题，也就出现了返工的现象。除此之外，这个方案看起来成本很低，但还要考虑重试雪崩效应等等，所以实际上真正妥善的重试也没有想象中成本那么低。值得说明的是，这种现象通常都比较隐晦，很容易事后发现"当时没想到这层"，这里也给出两个我认为比较有效的应对策略。

• 优先正面处理问题，而非打补丁式处理
• 在方案设计之初，就做出宏观定性的判断，是要解决问题，还是要暂时性的缓解问题

从中短期项目开始

有些同学没有写过规划，甚至觉得写规划是方向 Owner 才该做的事情。规划是方向 Owner 必不可缺的技能，逻辑往往是先具备了成为方向 Owner 的素质，才成为 Owner，一定不是成为了 Owner，再去练习对应的素质。同时也不要觉得只有长期项目/方向才需要进行规划，中短期项目也是需要规划的，从事情角度上讲，应该先想清楚，再行动。中短期项目往往整个周期比较可控，相对较短，比较好判断规划的正确性和问题。从逻辑上讲，如果一个短期项目都做不好规划，如何就觉得可以做好长期规划呢？

多与他人深度讨论

人都是有限理性的，我一直相信再聪明的人也很难凭借一己之力考虑的十分周全的，要相信群体智慧。所以多与他人讨论，深入讨论，是一件非常必要的事情。通常我建议你找至少 2 个人来聊项目的规划，认清现状阶段要找至少 5 个人聊他们的需求。

有限理性意味着，人们会基于其掌握的信息制定理性的决策，但是由于人们掌握的信息通常是有限的、不完整的，尤其是对于系统中相隔较远或不熟悉的部分，由此导致他们的决策往往并非整体最优。—— 《系统之美: 决策者的系统思考》

我从来没有遇见过想要找人沟通思路的时候，对方不愿意的，同样的，我也非常乐于跟别人讨论他们的方案。那么为什么还是有很多人不太愿意(至少我感受是这样的)去找别人讨论呢？很显然，主要因素就是自己。下面列举了几个很常见的心理:

• 与别人沟通，可能会被 Challenge，觉得被冒犯不舒服。

如果你是抱着"售卖自己方案"的心态，当别人提出意见时，就自然会转换成对抗状态，来疯狂解释自己为什么要这么做。个人推荐的是找别人对方案的时候，是抱着"我想和你一起探讨出一个更好的方案"，这样别人提出意见时就不会觉得被冒犯了，相反，还会因为更深入的讨论而感觉满足。

• 沟通很费时间，觉得效率很低

首先，很少有人会因为你想要和他讨论方案而觉得你在浪费他的时间，除非你什么都没做，静等着对方给结论。那么自己是否值得花这个时间呢？需要想清楚一件事，就是如果前期没有花足够的时间讨论清楚，只会导致后续更大的麻烦，甚至导致规划半途而废，所以一定不要认为沟通是在浪费时间。与他人讨论最重要的目的是发现未知信息。所以讨论期间，我非常建议你避免过多解释，当你进入一种解释的状态时，对方往往会迫于"面子"而不再与你更深入的讨论，及时发现自己的这种状态，多听、多看、少说，让对方尽情发表他的看法，代入对方的视角，考虑他为什么会这么想，与自己的推导逻辑差异是什么，这个差异会有什么影响，这样你才能得到更有用的信息。反思一下，如果你发现一个概念、一个思路需要你花很大的篇幅才能让对方理解，那这一块的事情一定是没有提炼到位的，还是不够简洁直观。对方不理解，一定是自己的问题，而不是对方的问题，对方能与你一起来到这家公司共事，那对方一定是个聪明人。

临门一脚，写好文档

规划的最终落地形式大概率是一篇文档，从完成草稿到真正形成一篇好的规划，只差最后10%，前面那么长时间都花了，千万不要吝啬在最后这一步上投入时间，这是向外争取资源最重要的一步，不要功亏一篑，让金子埋进沙子。

• 自顶向下结构化的行文，可以更容易让人接受

很多人习惯会从下往上的思考问题，然后给出结论，这种方式适合自己思考和讲故事，但不适合高效的传递信息。读者都是聪明但很忙的人，大部分情况下都是对文档进行跳读。自顶向下的行文，很方便进行跳读。

• 思考逻辑 ≠ 行文逻辑
• 避免偏离核心目标
• 多用图表达，一图胜千言
• 文档 ≠ TXT

关于这方面推荐我之前写的一篇文章 如何写好一篇文档？ 这里就不过多赘述。

结语

验证一个规划是否是一个好规划是很难的，前期只能通过读者的反馈来反映，更多的是需要时间来验证，但规划好了也并不一定能执行的很好，受到各种外部因素的干扰。常常复盘一下自己的规划是上一轮的延续，还是推翻上一轮重来，好的规划，是应该具备前瞻性和延续性的，如果是频频推翻，那一定不是一个好的规划。规划是一个人系统思考能力的体现，所以也不太可能通过一篇文章就真正有非常大的提升，本质上还需要多学习别人写规划的思路、多想、多讨论、多写。首先提升对规划这件事的重视程度，不要用战术上的勤奋去掩盖战略上的懒惰，再重新理解一下规划的底层逻辑 —— 找到做正确之事的正确方法，最后就是要不断地检查是否偏离了核心目标。写到这里，万字有余了，希望这篇文章对你能有帮助，欢迎点赞、收藏、转发，你的支持是我继续写下去的动力。

推荐阅读

• 《系统之美: 决策者的系统思考》

非常推荐大家都去读的一本书，真正的剖析系统思考的过程是怎样的，如何进行系统思考。

• 《事实: 用数据思考，避免情绪化决策》
• 《麦肯锡结构化战略思维: 如何想清楚、说明白、做到位》
• 《金字塔原理》