构建之法阅读笔记03

阅读内容
《构建之法》第二版 第7章～第9章（MSF、需求分析、项目经理）

核心概念摘要
MSF（Microsoft Solution Framework）提出了一套以"交付价值"为中心的软件工程方法论。它的核心理念包括：推动信息共享与沟通、为共同远景工作、充分授权与信任、各司其职且对项目共同负责、重视商业价值、保持敏捷并预见变化、保持质量。MSF 不指定特定的技术栈或工具链，而是提供一个原则性框架，让团队根据自身情况裁剪。

需求分析一章指出：软件开发中最昂贵的错误不是代码写错了，而是做出了没人需要的东西。需求不是用户嘴上说的那几句话，而是用户真正需要但未必能清晰表达的东西。获取需求的方法包括：用户访谈、场景分析、原型法、竞品分析等。书中特别强调利益相关者分析——一个功能改动的受益方和受损方必须被清晰地识别并纳入评估，否则交付后必定出现"你的解决方案成了我的问题"的冲突。

项目经理（PM）的角色不是"传话筒"或者"催进度的监工"，而是连接用户、开发团队和管理层的双向翻译器。好的 PM 既要能听懂用户想解决什么业务问题，也要能把这个意图翻译成开发人员能执行的明确任务，同时还要向管理层解释这个功能为什么值得现在做。

个人感受
1、我过去是怎么做的

我之前对"需求"的理解非常浅层，基本就是用户说什么我就做什么。用户说"这个地方加个导出按钮"，我就二话不说去加一个导出按钮。用户说"列表页应该能筛选日期"，我就埋头去写日期筛选。写完交付之后，用户又说"不对，我说的导出是导出 PDF，不是 Excel"，或者"筛选之后还要能批量操作筛选结果"。然后我又改，一来一回折腾好几次。我从来没有追问过"你为什么要导出？导出之后你会拿这份数据去干什么？"——我觉得那是用户的业务，不关我的事，我只要把功能做出来就行。

至于 PM 的角色，在小组项目里基本就是组长兼任。组长的主要工作从来不是做需求分析或管理利益相关者，而是"催进度"——"你做完了没有？"、"明天要交了今晚能出来吗？"。需求文档就是一份简单的功能列表，写在腾讯文档里，没有优先级排序，没有场景描述，没有"这个功能不做会怎样"的分析。

2、结合书中所讲，说明为什么这样不好

书中明确指出，用户描述的是方案（"加一个导出按钮"），而需求分析要挖掘的是背后的问题（"我需要定期把系统里的数据拿出来做月度报表，目前每次都要复制粘贴特别麻烦"）。如果我停留在用户提供的方案层面，我永远只能做出一个又一个孤立的按钮，而看不到真正的需求全貌——用户可能真正需要的根本不是导出功能，而是一个能自动生成月度报表并推送邮件的内置模块。

更深层的问题在于：没有利益相关者分析的需求决策，本质上是在用一个利益群体的损失去换取另一个群体的便利。比如"简化审批流"这个需求，对申请人来说是便利，但对风控部门来说可能是灾难。如果需求分析阶段没有把风控部门叫到桌上讨论，上线之后的反弹和热修复就是完全可以预见的代价。

关于 PM 的误区，书中讲得很透彻：PM 的核心能力不是 push 进度，而是拆解模糊问题为可执行任务和管理多方的期待值。催进度的前提是大家对于"做到哪算做完"有一致的理解——而这个理解恰恰来自 PM 写的清晰需求说明。没有这个前提，催得越紧代码写得越烂，最后返工成本越高。

3、解决办法

需求挖掘三问法：每次接到用户的功能请求时，强制自己问三个问题再开始写代码——（1）你用它来解决什么业务问题？（2）目前没这个功能时你是怎么做的？（3）这个功能做出来后，什么样算好用、什么样算不好用？把这三个问题的答案写在需求说明的第一段，作为后续所有设计决策的锚点。
利益相关者矩阵：任何涉及流程变更或权限调整的需求，在进入开发前必须至少过一遍利益相关者分析——谁受益、谁受损、谁有权力否决。用一个简单的二维矩阵画出来：横轴是影响程度，纵轴是决策权。矩阵里只要有"高影响+零决策权+受损"的格子，就说明需求沟通还没有覆盖到位，不能进入开发。
需求优先级用 RICE 打分：不再用"我觉得这个重要"来排优先，而是给每个需求按 RICE（Reach 覆盖面 × Impact 影响度 × Confidence 信心度 ÷ Effort 工作量）打分。得分高的先做，得分的计算过程保留在需求文档里，事后复盘时可以看到当时的判断是否准确。