共同愿景构建，为什么总变成老板一个人的单口相声

那个会议室里的沉默，我记了两年

两年前的七月，我坐在公司最大的会议室里。投影仪有点糊，空调开得太冷。

CTO站在前面，花了一个半小时讲“我们的技术愿景”。PPT做得很漂亮——有流程图，有架构分层图，还有一张手绘风格的“未来三年路线图”。讲完了，他问：“大家有什么问题？”

没人说话。

不是认同。是“我有一肚子问号，但懒得当出头鸟”的沉默。我旁边坐的是个后端老哥，他悄悄跟我说了句：“我没听懂咱们到底要干啥。”

说实话，那一刻我挺没劲的——那份PPT有一半是我帮忙画的。

这就是大多数“共同愿景构建”的现场：一个人讲，一群人听，所有人鼓掌，然后没有人记住。

'技术团队白板讨论架构草图'

共同愿景，不是“我们一起看了同一份PPT”

最常见的误解是：把“传达”当成了“共建”。

一个东西从上面传下来，你可以叫它“任务”，可以叫它“KPI”，但如果它没有在每个人脑子里长出自己的版本，它就跟“共同”两个字没什么关系。

我后来琢磨这事，发现它跟分布式系统里的“共识”有点像一个意思。

在Raft或者Paxos里面，你要让一堆机器对某个状态达成一致，光靠Leader广播一条日志是不够的——你得让每台机器都确认、都落盘、都能在需要的时候把这个状态复现出来。广播不等于共识。收到消息不等于理解了消息。

共同愿景构建的本质，是一个认知对齐的过程，不是信息下发的过程。

信息下发解决的是“知不知道”。认知对齐解决的是“认不认同”和“能不能用”。

差了这两步，愿景就永远停在墙上的那张海报里。

为什么“说清楚”这么难？

为什么“说清楚”这么难？

说个具体的。

我们后来重新尝试了一次“技术愿景共建”，换了个玩法。没在会议室，找了个小屋子，白板、便利贴、外卖。就八个人。

我上来问了一个问题：“你们各自觉得，咱们技术这块最该被解决的事儿是什么？”

你猜怎么着——八个人说出来的是八个不同的东西。有人说是CI太慢，有人说是代码没人review，有人说是文档烂得没法看，还有人说的是“我不知道我们做这些功能到底图啥”。

这就是“共同愿景”之所以难的第一层原因：大家不是没有判断，而是各自的判断在各自的工位上长出来，然后就没再碰过面。

第二层原因更扎心：很多人对“愿景”这个词有一种生理性的排斥。

它听起来太虚了。你让一个每天写CRUD的工程师去“共建愿景”，他脑子里第一反应可能是：又来了，又要搞形式主义了。

这个排斥是有道理的。因为过去太多“愿景”都是单向输出的——写完就贴在墙上，然后没人再提。

那到底怎么做？

我不打算给你一套模板。说真的，任何能写成模板的“愿景构建方法”，大概率构建不出什么真东西。

但我可以说几个我见过有用的做法。

一个做法值得试试：让每个人先说自己的痛点，而不是先听你的大方向。

顺序很关键。你先说“我们要做中台”，别人心里就自动变成了“我听听你怎么吹”。你反过来先问“你觉得眼下最堵的环节是哪个”，他说出来的东西才是他自己的。

我参与过的一个项目，产品负责人花了一周时间，跟十几个一线工程师挨个聊天，不聊愿景，就聊“你最近干得最烦的一件事”。然后把所有人的痛点整理成一张图，下次开会的时候往桌上一摊——“这是你们说的，咱们认同一下。”

那个会的共识度，比之前所有PPT加起来都高。

另外一点特别关键：把愿景翻译成“我明天干什么”。

愿景是一句话，但你得能让每个人自己算出他要做什么。如果一个愿景落地后，工程师还是不知道自己明天该干什么，那它就是个修辞。

我们后来做的一件事特别土：让每个人写一句“如果这事儿做成了，我下周一早上打开电脑要做的第一件事会变成什么样”。写完之后贴在白板上聚类。花了不到一钟头，但大家对“这东西跟我有什么关系”的理解一下子清楚了很多。

还有一种做法，其实是最反直觉的：允许异议存在，甚至欢迎异议。

最危险的信号从来不是有人反对。最危险的信号是所有人都说“没意见”。

因为“没意见”大概率等于“关我什么事”。

我后来跟那个后端老哥聊，他说：“那天会议室里我其实不同意咱们走的方向。但那个场合，我说了也没用，何必呢。”

这句话我记了很久。共同愿景构建的反面不是分歧，是沉默。

一个类比：它像写代码，不像写宣言

我越来越觉得，做共同愿景这件事，它的气质更像一次代码重构，而不是发一篇技术宣言。

重构是什么？你先把现状搞清楚，找到最疼的地方，然后一步步挪，每一步都跑测试，每一步都能回滚。你做完了，系统还是那个系统，但每个人心里都有一张新的地图。

宣言是什么？一锤子买卖，写完了发出去就完事了。

共同愿景需要的是前一种。它是一个持续推进的过程，不是一份文档的产出。

'技术团队用便利贴做共识工作坊'

误区：以为它是一劳永逸的

说一个我觉得最常被忽略的点。

很多人以为“共同愿景构建”是项目启动阶段干一次就完了的事。就跟开业剪彩似的，剪完就收工。

不是的。它更像是一段持续维护的代码。人会走，需求会变，业务方向一年调两次。你三个月前的那个共识，早就被日常琐事磨没了。

我见过做得比较扎实的团队，他们的做法是每过一个季度，回头问一句：“我们当初一起认同的那个方向，现在还对吗？”

不需要很隆重。一次半小时的讨论，或者就是一个文档里大家随手补充的段落。关键是——让那个共同的心智模型持续有被人“触碰”的机会，而不是被塑封起来挂在墙上。

边界：什么时候它根本不重要

边界：什么时候它根本不重要

最后说一个反过来的事情。

不是所有场景都需要“共同愿景构建”。

如果任务是明确的、短期的、执行路径清晰的——比如“把这个接口性能优化30%”——那你不需要愿景，你需要的是明确的指令和足够的资源。

共同愿景真正发挥作用的场景，是当路径不明确、需要每个人在不同位置做判断的时候。

举个例子。当你在做一个从0到1的产品，需求模糊，方向随时可能变。这种时候，一个共享的“我们到底在解决什么问题”的判断，比任何详细的PRD都管用。因为大家做每个微小决策时，都会在心里问一句：这是否符合我们共同认同的那件事。

反过来，在一个已经很成熟的流水线里，你过度强调“共同愿景”，反而会让人烦躁——大家只想把手头的活干完。

所以，共同愿景构建的适用边界，恰恰在于不确定性。不确定性越大，它越值钱。不确定性越小，它越像噪音。