一、为什么架构师要谈问卷
很多人觉得，问卷调查是产品经理或 HR 的事，跟架构师没关系。架构师的职责是画架构图、定技术选型、评审方案、把控风险。问卷这种东西，听起来太"软"了。
但我越来越觉得，架构师最核心的能力不是设计，而是判断。而判断的质量，取决于信息质量。
你做的每一个架构决策，背后都隐含着一堆假设：
- 假设团队现在的开发环境是统一的
- 假设 CI 已经能自动构建了
- 假设代码分支模型是清晰的
- 假设交付物是有版本管理的
- 假设大家对痛点有共识
这些假设，有多少是你亲自验证过的？
如果没有验证，那你的架构方案就是建立在流沙上的。看起来很美，落地时处处碰壁。而问卷调查，是成本最低的验证手段之一。
这就是我想说的第一件事：问卷不是收集数据的工具，是校准判断的工具。
二、架构师最容易犯的错误：用"我以为"代替"实际是"
我见过太多架构师，包括我自己，犯同一个错误：
坐在自己的工位上，用推理代替观察。
"嵌入式团队应该都是用 Linux 交叉编译的吧？"
"CI 这种东西，现在应该都有了。"
"Git 分支模型，大家应该都懂 Git Flow 吧？"
这些"应该"，每一条都可能是错的。
更危险的是，你越是资深，越容易犯这个错误。 因为你过去的经验让你形成了很多"默认认知"，而这些认知在你熟悉的环境里是对的，换一个团队、换一个技术栈，就未必成立。
架构师的位置越高，离一线越远，信息失真越严重。你听到的往往是二手、三手信息，是经过层层过滤和美化后的版本。
问卷的价值，就是让你重新接触到未经修饰的一线事实。
三、一个真实的结构性困境
我想讲一个具体的处境，因为它比抽象的道理更能说明问题。
我们软件部 13 个人，12 个是嵌入式，只有我一个非嵌入式。我负责 Web 和 Java/Python 服务，同时要推整个部门的技术体系统一。
这个结构意味着三件事：
第一，我对嵌入式的了解，天然是二手的。 我懂 Web、懂服务端、懂容器化，但嵌入式交叉编译、Qt 工具链、烧录调试这些，我是外行。我用 Web 的经验去套嵌入式，很可能不切实际。
第二，我是少数派。 12 对 1，靠职权推不动。我不能说"我是负责人，你们照做"，那样只会激起抵触。我必须靠共识、靠盟友、靠试点。
第三，我的规划方向是清楚的，但路径不清楚。 统一环境、规范 Git、建 CI/CD、统一 Docker、可复现交付------这五条我很有把握。但先做哪条、从哪个团队切入、用什么理由推，我不确定。
这时候，问卷就不是"可选项"，而是"必选项"。
因为我没有资格拍脑袋。我对嵌入式的每一个判断，都需要数据来校准；我推的每一条规范，都需要共识来支撑。
方向我来定，路径让团队选。这是我作为少数派架构师的基本策略。
四、问卷的四个真实作用
1. 校准认知：你以为的，和实际的可能差很远
问卷最直接的作用，是让你发现"我以为"和"实际是"之间的差距。
举个真实的例子。有一次我们推统一构建流程，我预判嵌入式团队最大的痛点是交叉编译环境。结果问卷收上来，排第一的痛点是"交付物管理混乱，客户要旧版本找不到"。
这个偏差价值极大。如果我按自己的预判去做，第一件事是搞交叉编译容器化，投入大、周期长、见效慢。但实际最痛的是制品归档，这件事投入小、见效快、收益直接。
问卷让你把有限的资源，投到真正的痛点上，而不是你以为的痛点上。
2. 建立共识：让问题从"你的判断"变成"大家的共识"
架构师推规范，最大的阻力往往不是技术，而是"凭什么"。
你说是问题，团队说"现在也能跑"。你说要改，团队说"没必要"。
但如果问卷收上来，12 个人里有 10 个都选了同一个痛点，这件事的性质就变了。它不再是你一个人的判断，而是团队自己的共识。
你后面推规范时，可以理直气壮地说："这不是我要改，是大家一起反映的问题。"
问卷把"我要你改"变成了"我们一起改"。 这一个字的差别，决定了落地的阻力大小。
3. 发现盟友：谁是支持者，谁是观望者，谁是阻力
问卷不只是看选项分布，更要看人。
- 谁在问卷里表达了强烈的痛点？------这是潜在的盟友，因为他有改变的动力。
- 谁选了"现在这样也能跑，没必要改"？------这是潜在的阻力，需要提前沟通。
- 谁愿意参与试点、评审规范？------这是你可以依靠的关键人。
架构师不可能一个人推动所有事。你需要找到愿意一起干的人，而问卷是识别这些人的低成本方式。
问卷是一张人际地图，告诉你谁是同路人。
4. 争取资源：用数据说话，比用感觉说话有力得多
架构师要推一件事，经常需要向上争取资源：统一镜像仓库、CI Runner、交叉编译基础镜像、专职人力。
你怎么说服上级？
"我觉得需要。"------太弱。
"团队反映需要。"------有点弱。
"问卷显示，80% 的人认为环境不统一是最大障碍，60% 的人每周至少遇到一次构建不可复现的问题。"------有力。
数据不能替你做决策，但能让你的决策更有说服力。 在组织里，一个有理有据的提案，比一个"我觉得"的提案，通过率高得多。
五、问卷不是万能的：它的边界在哪里
说了这么多问卷的好处，也要说清楚它的边界。
第一，问卷不能替代一对一沟通。
问卷是广覆盖的，但它是浅的。它告诉你"有多少人选了什么"，但没法告诉你"为什么"。
数字背后是活生生的人。12 个人选同一个选项，可能各有各的原因。有些人是因为真的痛，有些人是因为随大流，有些人是因为理解偏差。
问卷是面，访谈是点。 问卷给你广度，访谈给你深度。只有广度，你会知道问题在哪；只有深度，你才知道怎么解。
第二，问卷不能替代你自己的判断。
问卷是输入，不是答案。
你不能问卷说什么就做什么。问卷反映的是"大家感知到的问题"，但感知不等于真相。有时候大家觉得是问题的地方，其实是表象，根因在别处。
架构师的价值，恰恰在于从一堆感知中，识别出真正的根因，并给出系统性的解法。
第三，问卷不能替代行动。
问卷做得再漂亮，分析得再透彻，如果不落地，就是浪费大家的时间。
而且，问卷本身会消耗团队的信任额度。 你发一次问卷，大家认真填了，结果没下文，下次你再发，就没人理你了。
所以，发问卷之前，先想清楚：我拿到数据后，要做什么？ 如果没想清楚，就别发。
六、问卷与访谈的组合拳
既然问卷不能替代访谈，那两者应该怎么配合？
我的答案是：问卷是面，访谈是点，两个都要做，顺序不能反。
为什么顺序不能反？ 如果先访谈再发问卷，你会带着访谈里的个别观点去设计问卷，容易有偏见。先发问卷，拿到整体分布，再挑典型的人深聊，信息才完整。
两者的分工是这样的：
| 问卷 | 一对一访谈 | |
|---|---|---|
| 覆盖范围 | 全员（13 人） | 3--5 人 |
| 目的 | 摸底、校准、找共识 | 挖根因、找盟友、定试点 |
| 题型 | 单选为主，结构统一 | 开放为主，追问为主 |
| 时长 | 5--8 分钟 | 20--30 分钟 |
| 产出 | 分布数据、优先级排序 | 原话、顾虑、关键人、试点 |
| 时机 | 先发 | 问卷收完后 |
访谈至少覆盖 3--5 人。 不要多，但要聊透。
为什么是 3--5 人？因为 13 个人的团队，3--5 个样本已经能覆盖主要的角色和项目类型。再多，边际收益递减；再少，可能漏掉关键视角。
访谈的核心不是"你选 A 还是 B"，而是"你能跟我讲讲上次发生这件事是什么情况吗"。
访谈不是问卷的口头版，它是问卷的追问版。 问卷问"是不是"，访谈问"为什么""什么时候""后来呢"。
七、一对一访谈提纲（8--10 题，开放为主）
用途：问卷收完后，选 3--5 位嵌入式同事做一对一访谈。每人 20--30 分钟。
原则：多听少说，不争论技术细节，重点记录原话和态度。
1. 你手上现在主要在做哪几个项目？哪个占你精力最多？
追问：这个项目现在处于什么阶段？交付压力大吗？
目的：了解他的工作重心，判断他是否有精力参与改进。
2. 你平时从改完代码到交付，中间大概要经过哪些步骤？
追问：哪一步最花时间？哪一步最容易出错？上次出错是什么时候？
目的：拿到真实流程，而不是他以为的流程。重点听"手工环节"。
3. 你现在的交叉编译环境是怎么搭起来的？
追问：如果换一台新电脑，你能自己搭起来吗？要多久？有没有文档？
目的：判断环境是否可复现，是否依赖个人经验。
4. 你觉得现在工作里最烦、最浪费时间的是什么？
追问：能举个最近的例子吗？这件事多久发生一次？
目的：这题最关键。不要给选项，让他自己说。记录原话。
5. 如果只能改一件事，你最想改什么？为什么是这件？
追问：如果这件事改了，你的工作会有什么变化？
目的：直接暴露他的第一优先级，也是判断他是否愿意参与改进的信号。
6. 你有没有遇到过"在我机器上能编译，换台机器就不行"的情况？
追问：后来怎么解决的？花了多久？
目的：验证可复现构建是不是真痛点。
7. 交付物（固件、库、镜像）现在怎么管理？客户要旧版本时能找到吗？
追问：有没有版本对不上、找不到旧版本的情况？
目的：验证制品归档需求是否真实。
8. 如果公司推一套统一的构建/交付流程，你最担心什么？
追问：你觉得哪些东西是嵌入式必须自己定、不能被统一的？
目的：提前识别阻力，划定"不强制统一"的边界。
9. 如果要做这件事，你觉得团队里谁比较有经验、适合一起参与？你自己愿意参与吗？
追问：从哪个项目开始试比较合适？
目的：直接找盟友、找试点。这题是访谈的核心产出之一。
10. 你觉得团队当前优先级最高的事情是什么？
追问：是交付进度、代码质量、流程统一，还是别的？
目的：判断你的规范和团队关注点是否一致。如果不一致，先对齐关注点。
八、访谈之后怎么用
访谈结束，当天整理，重点产出四样东西：
1. 共识痛点清单
3--5 个人里，超过一半提到的痛点，就是共识痛点。这是你推规范的合法切入点。
2. 盟友名单
明确谁愿意参与试点、谁愿意评审规范。优先跟进 1--2 个嵌入式骨干。
3. 边界清单
把"嵌入式必须自己定、不能被统一的"整理出来。这些不写进强制规范，只做文档化和可复现要求。
4. 试点项目
从访谈里推荐的项目中，选一个项目不大、负责人配合、技术栈相对标准的，先跑通。
九、一份好问卷的设计原则
最后，说说设计问卷的几个原则。这些是我做了几版之后总结的。
原则一：题目的结构要一致。
要么全是单选题，要么每题明确标注题型。不要一会儿单选、一会儿多选、一会儿填空、一会儿量表。 结构不一致，不仅受访者困惑，AI 和统计工具也容易识别错误。
原则二：题型要匹配目的。
- 想摸底现状 → 单选题
- 想收集痛点 → 单选题 + 开放题
- 想排优先级 → 单选题（最多选 3 项，但平台不支持就单选最主要的）
- 想找人 → 单选题 + 填空
不要为了多选而多选。 单选往往比多选更能反映真实优先级。当一个人只能选一个时，他选的是"最重要的"，而不是"都沾一点的"。
原则三：问题要具体，不要抽象。
"你觉得开发环境好吗？"------太抽象，答案没意义。
"新同事搭建交叉编译环境一般要多久？"------具体，能拿到可比较的数据。
原则四：不要问"该不该"，要问"是不是"。
"你觉得该不该统一构建流程？"------这题会引发立场之争。
"你现在构建流程是手动还是自动？"------这题只问事实。
先拿事实，再谈观点。 事实没有争议，观点才有。
原则五：问卷要短，但要覆盖关键维度。
太长没人填，太短没信息。我的经验是：20 题左右，5--8 分钟能填完，覆盖所有关键维度。
每一题都要能对应到你后续的一个决策。如果一题的答案你根本不会用，那就删掉。
十、结语：问卷是架构师的"侦察兵"
打仗之前，要派侦察兵。
侦察兵不决定战略，但决定了你战略能否落地。他告诉你敌人在哪、地形如何、哪里好走、哪里是陷阱。
问卷就是架构师的侦察兵。
它不替你做决策，但它让你在决策之前，先看清战场。
而访谈，是侦察兵回来之后的审讯。侦察兵告诉你哪里有敌人，审讯告诉你敌人有多少、装备如何、士气怎样。
只有侦察，你会知道问题在哪；只有审讯，你会知道怎么打。
我常想，架构师和普通工程师的区别，到底在哪里？
普通工程师想的是"这个功能怎么实现"。
架构师想的是"这个系统怎么演进"。
而演进的前提，是你得先知道现在在哪里。
问卷和访谈，就是那个告诉你"现在在哪里"的组合工具。
它们不酷，不高级，不像微服务、云原生、AI 那样有技术含量。但它们是所有架构决策的起点。
没有侦察的将军，不配谈战略。
没有摸底的架构师，不配谈演进。
这是我做完这份问卷、聊完这几个人之后，最大的体会。