从立项到交付：项目管理五阶段的信息收敛与偏差控制

1. 项目管理的本质：从立项到交付的底层逻辑

先说个我自己的经历。前几年接过一个内部系统重构的项目，立项会上大家拍着胸脯说三个月搞定，结果拖到第七个月才勉强交付。复盘的时候发现，问题不在技术难度，也不在人力不足。真正的问题出在从头到尾没人把"这件事到底要交付什么、谁来拍板、什么标准算做完"说清楚。立项书三千字，一半在描述背景，关键的成功标准只有一句"满足业务需求"。这句话在项目里就是一颗定时炸弹——每个人对"满足"的理解都不一样。

这就是项目管理最容易踩的坑：把流程当仪式，把文档当摆设。项目管理的核心不是填多少张表、开多少次会，而是在一件事开始之前就把不确定性挤压到最小，在执行过程中把偏差控制在可接受范围内，在结束的时候让所有人对结果达成一致认知。立项、规划、执行、监控、收尾这五个阶段，本质上是一条信息逐步收敛的链路：一开始信息模糊、目标宽泛，越往后越具体、越可验证。

很多初次接触项目管理的人会误以为这是一套"管理别人"的工具。实际做下来你会发现，项目管理首先是管理自己的预期和判断。一个合格的项目负责人，在立项阶段就要能回答三个问题：这件事值不值得做、能不能做成、做完之后谁来验收。三个问题答不上来，后面所有的甘特图、风险登记册、周报都是自欺欺人。

为什么很多项目明明流程齐全还是失控？因为流程只是骨架，真正跑起来的是判断力。举个例子：同样是"需求变更"，有的团队走个变更单就完了，有的团队会追问变更的原因、影响范围、代价由谁承担。前者是走形式，后者才是管理。流程的意义在于逼你把脑子里的东西写下来、算清楚、留证据，而不是让你假装有条理。

适合读这篇内容的人有三类：第一次独立带项目的执行者，手里可能只有一个模糊的目标和几个配合的同事；带过项目但总是被拖延和扯皮困扰的中层，需要一套可复用的方法；还有做技术出身被推上管理岗的人，习惯了自己解决问题，现在要学会靠流程和沟通推动一群人。这三类人的痛点是共通的：目标不清、协作成本高、收尾难。下面这几章就从立项一直拆到交付，把我踩过的坑和验证过的做法都摊开说。

1.1 五个阶段的信息收敛模型

把项目拆成五个阶段不是行业规定，而是因为它符合人类处理复杂事情的认知节奏。立项阶段解决"要不要做"，规划阶段解决"怎么做"，执行阶段解决"谁来做、做得怎么样"，监控阶段解决"偏了多少、要不要纠"，收尾阶段解决"做完了没有、归谁所有"。每个阶段输出的东西，是下一阶段的输入，缺一环后面就会返工。

我习惯用一个简单的判断标准来衡量某个阶段是否真正完成：如果我明天请假，接手的人能不能只看现有材料就把事情继续推进。立项阶段达不到这个标准，说明目标还没说清；规划阶段达不到，说明任务拆得不够细；执行阶段达不到，说明进度信息没有及时同步。这个标准很土，但特别管用，它逼着你把"我以为大家都懂"变成"写下来谁看都懂"。

信息收敛模型还有一个隐含的好处：它把责任边界划清楚了。立项书是谁签的字，需求变更单是谁批的，验收报告是谁出的，这些东西在顺利的时候没人看，出了争议就是唯一的依据。我见过太多团队凭口头承诺干活，结果交付时对方说"我当时不是这个意思"，双方各执一词，最后只能靠级别高的人拍板，拍板的结果两方都不满意。

1.2 为什么流程齐全还会失控

这个问题值得单独说，因为它几乎是所有项目管理培训里最容易被忽略的部分。流程是通用的，项目是个性的。一套模板套在十个项目上，能跑通三个就不错了。失控往往不在流程本身，而在于流程和项目实际复杂度不匹配：小项目套重流程，团队被文档压垮，精力全耗在填表上；大项目用轻流程，关键风险没被识别，等到爆发已经来不及。

还有一种更隐蔽的失控，叫"流程空转"。会议照开、报告照写、风险登记册照填，但没有人真的用这些信息做决策。周报上写着"进度正常"，实际上核心模块卡了三天没人管。这种项目外表看起来毫无问题，直到交付前两周突然暴雷。判断流程有没有空转，有个简单的观察点：开会的时候有没有人拿着上次的决议逐条对账。如果每次开会都是重新汇报一遍现状，没有人跟进上次说了什么、做了没有，那这个流程基本是空转的。

2. 立项阶段：把"要不要做"这个问题回答透

立项是整个项目里性价比最高的环节。这里花两天时间想清楚，后面能省两个月返工。但实际情况是，大部分立项会开得像动员大会，领导讲愿景，业务方讲痛点，技术方讲难度，最后在一片"加油干"的氛围里散会，最重要的几个问题一个都没落实。

立项要输出的东西其实不多，但每一样都必须硬。第一是目标，必须可验证。"提升用户体验"不是目标，"把下单流程的步骤从五步压缩到三步，页面加载时间控制在两秒内"才是目标。可验证的意思是，项目结束时能拿一个客观标准去对照，而这个标准在立项时就已经征得各方同意。第二是范围，必须明确划出边界。做什么要写清楚，不做什么更要写清楚。很多项目后期的扯皮，根源都在立项时对"不做什么"保持了沉默。

第三是干系人和决策机制。谁是发起人，谁是最终验收人，日常决策谁拍板，出现分歧怎么升级。这几条不写清楚，项目中途一定会陷入"该找谁定"的僵局。我见过一个项目，需求方有三个部门，谁都觉得自己有话语权，结果一个界面改了三版，每版都是不同部门领导的意思，执行的人夹在中间两头受气。第四是资源约束，包括人、钱、时间三条线，哪条线是刚性的必须标出来。很多项目的真实约束是人力，但立项时没人说破，执行时才发现能投入的只有两个半人。

2.1 目标设定的可验证化改造

目标写不清楚，根源在于写目标的人脑子里想的是"方向"而不是"结果"。方向没法验收，结果可以。把方向改造成结果，有个简单的三步法：先写下你希望项目结束后世界变成什么样，再把这句话里的形容词全部删掉换成数字或可观察的行为，最后问一句"这个数字由谁、在什么时候、用什么方式测量"。

举个改造的例子。原始目标："优化客户服务响应速度"。第一步，项目结束后希望客户提问能更快得到答复。第二步，删掉"更快"，换成"首次响应时间从平均四小时降到一小时以内"。第三步，测量方式是客服系统的工单时间戳，由客服主管在项目验收时导出近一个月数据核对。改造之后，目标从一句正确但无用的话，变成了一条可以写进验收报告的硬指标。

注意：目标里出现的每一个数字，都要在立项时确认数据来源存在且可信。我遇到过一次，目标定的是"将故障恢复时间缩短一半"，验收时才发现系统根本没有记录恢复时间的日志，最后只能靠人回忆，验收变成了一场扯皮。

目标的可验证化还有一个隐藏收益：它会自动暴露项目里的分歧。当大家对一个模糊目标点头时，其实每个人脑子里的画面都不一样；一旦要求把数字写下来，分歧立刻浮现。这种分歧在立项阶段暴露是好事，成本最低；拖到执行阶段才暴露，代价可能就是整个方案推倒重来。

2.2 范围边界与"不做什么"清单

范围管理最有效的工具不是工作分解结构，而是一份明确的"不做什么"清单。WBS告诉你做什么，但人的注意力天然会往"还能加什么"上跑，尤其是在项目推进顺利的时候。加需求的人往往没有恶意，他们只是觉得"顺手的事"，但每一次顺手，都在侵蚀项目的时间和人力预算。

"不做什么"清单的写法有讲究，不能只写"本期不做某某功能"，要写清楚为什么不做、什么条件下会做。这样写有两个好处：一是让提出需求的人知道这不是被无视了，而是有明确的时间表；二是未来真的要做的时候，有据可依，不用从头论证。我在一个项目里用过这个办法，清单列了十七条，每条都标注了"本期不做的原因"和"预计进入的版本"，后期需求方再来问，直接把清单发过去，沟通成本降了一大截。

范围边界的另一个关键是变更机制。完全不改需求的项目几乎不存在，问题不在于改不改，而在于改的时候有没有代价意识。变更机制要回答三件事：谁有权提出变更、变更需要谁审批、变更对时间和人力有什么影响。第三点最容易被忽略，但也最重要。没有代价的变更等于没有约束，任何需求方都会倾向于"反正不要钱，那就都加上"。

3. 规划阶段：把大目标拆成可以分头干的小块

立项解决的是方向问题，规划解决的是路径问题。这两者的区别在于：立项说"三个月后要上线一个能支撑五百人同时在线的系统"，规划说"第一个月做数据模型和接口设计，第二个月做核心功能，第三个月做压测和灰度"。方向错了，路径再漂亮也没用；路径不清，方向对也走不到。

规划阶段最核心的动作是分解。分解的目的不是把任务列得越细越好，而是让每个任务都能落到一个明确的责任人和一个明确的完成标准上。任务细到"写代码"这个粒度是没有意义的，因为"写代码"不是一个可验收的单元；细到"完成用户登录接口，包含密码加密、错误提示、超时处理三个子项，接口文档同步更新"才有意义。

分解的另一个作用是暴露依赖。项目里最耗时间的往往不是任务本身，而是任务之间的等待。A等着B的输出，B等着C的确认，C又在等一个外部供应商的回复。这些等待在甘特图上表现为空白，在现实里表现为人力的闲置。规划阶段把依赖关系标出来，就能提前安排并行、提前催办，而不是等到卡住了才发现问题。

3.1 任务分解到什么粒度才算合适

这个问题我被问过很多次。我的经验标准是：一个任务的工作量在半天到三天之间。短于半天，说明分解过细，管理成本超过了任务本身的价值；长于三天，说明分解不够，任务内部的不确定性没有被识别出来，出了问题也很难定位到底卡在哪一步。当然这个标准要随项目调整，两周的短项目和半年的长项目，粒度要求不一样。

除了工作量，还有一个维度是"可独立验收"。一个任务完成之后，应该能拿出一样东西给别人看：一段代码、一份文档、一个设计稿、一次测试记录。拿不出东西的任务，说明完成标准没定义清楚，执行的人只能凭感觉判断"差不多了"。我见过一个项目，任务清单里有一条叫"优化系统性能"，分配下去之后，执行的人折腾了两周，交付时说不清优化了什么、优化了多少，验收的人也没法判断，最后这条任务变成了一个说不清道不明的存在。

分解的过程中，有一类任务特别容易被漏掉：协调类和等待类的任务。比如"等待第三方接口文档""与业务方确认字段定义""组织一次跨部门评审"。这些事不产生代码和文档，但会占用时间，而且经常成为关键路径上的瓶颈。规划时把它们显式列出来，标注预计耗时，能避免很多"进度看起来正常但就是推不动"的情况。

3.2 排期中的缓冲设置与关键路径识别

排期不是把任务时间简单相加。人不是机器，有会议、有请假、有上下文切换的损耗。我的一般做法是在任务估算的基础上加百分之二十到三十的缓冲，但这个缓冲不放在每个任务里，而是集中放在项目末尾或者关键节点之前。放在每个任务里的缓冲会被"帕金森定律"吃掉——反正有缓冲，那就慢慢做，最后缓冲用完了，任务也刚好拖到截止。

关键路径的识别是排期里技术含量最高的部分。所谓关键路径，就是那条决定了项目最短工期的任务链，链上任何一个任务延误，整个项目就延误。识别出来之后，管理策略要区别对待：关键路径上的任务要盯得最紧，资源优先保障，风险优先排查；非关键路径上的任务可以适当放松，它们的延误只要不超过浮动时间，就不影响整体。

提示：关键路径会随着项目推进而变化。原本不在关键路径上的任务，一旦延误超过了浮动时间，就会变成新的关键路径。所以这个识别不是做一次就完事，要在每次进度检查时重新算一遍。

缓冲和关键路径结合起来用，效果最好。具体做法是：先按正常估算排出关键路径，然后把缓冲集中加在关键路径的末端，形成一个"项目缓冲"。执行过程中，任何关键路径上的任务延误，都从项目缓冲里扣。缓冲消耗到一半的时候，触发预警；消耗到三分之二，必须启动应对措施。这个机制的好处是把抽象的"进度紧张"变成了一个可量化的指标，团队看到缓冲快用完了，自然会有紧迫感。

4. 执行阶段：把人、事、信息三条线同时管住

规划做得再漂亮，执行阶段还是会出问题。因为规划面对的是"应该怎样"，执行面对的是"实际怎样"。人会有情绪，会有优先级冲突，会因为一句没说明白的话理解偏差。执行阶段的管理，说到底是在管三样东西：人的状态、事的进展、信息的流动。这三样任何一样断了，项目就会开始漂移。

先说人的状态。项目里的角色大致分三类：决策者、执行者、配合者。决策者要的是清晰的选择题，不是开放式讨论；执行者要的是明确的任务和及时的反馈；配合者要的是知道自己什么时候被需要、需要做什么。很多项目负责人沟通吃力，是因为用错了对象和方式：跟决策者汇报细节，跟执行者讲战略，跟配合者临时抓人。沟通的有效性不取决于你说了多少，取决于对方接收到了什么、能据此做什么。

再说事的进展。执行阶段最忌讳的是"黑盒任务"——分配下去之后杳无音信，直到截止日期才说做不完。解决办法是设置检查点，不是监视，而是同步。检查点的频率跟任务的风险成正比：高风险任务每天同步一次进展和障碍，常规任务每周同步一次。同步的内容不是"做到哪了"，而是"完成了什么、卡在哪、需要什么支持"。前一种问法容易得到模糊回答，后一种问法逼着对方给出具体信息。

最后是信息的流动。项目里的信息有两类：一类是状态信息，谁在做什么、做到什么程度；一类是决策信息，某个问题定了怎么处理、依据是什么。状态信息要广而浅，让所有相关的人都能看到；决策信息要窄而深，只发给需要知道的人，但要留档。混淆这两类信息的后果是：该知道的人不知道，不该打扰的人被大量抄送淹没，最后所有人都不看邮件了。

4.1 例会怎么开才不浪费时间

例会是执行阶段最常用的工具，也是最容易变成形式主义的工具。我见过太多例会，每个人轮流说一遍"我这边进展正常"，然后散会，什么问题都没解决。这种会的根本问题在于它把"汇报"当成了目的，而汇报本身不产生任何价值。

有效的例会应该只做三件事：对齐上周的决议执行情况、暴露当前的阻塞、确定本周的优先级。时间控制在半小时以内，每个人发言不超过三分钟，重点说卡点而不是流水账。主持人要做的不是记录，而是追问："这个卡点需要谁配合？什么时候能给答复？"把模糊的困难逼成具体的行动项。

还有一个细节：例会不要用来做决策。决策需要充分的信息和足够的讨论时间，塞在例会里草率拍板，往往是拍完了才发现关键信息没考虑。例会的产出应该是"哪些问题需要单独开会决策"，而不是决策本身。

4.2 需求变更的代价核算方法

需求变更不可怕，可怕的是变更没有代价。我处理变更的流程是四步：先问原因，再算影响，然后给选项，最后留记录。问原因是为了判断这个变更的必要性和紧急程度，有的变更是业务环境真的变了，有的是提出的人一时兴起，两种情况处理方式完全不同。算影响是核心步骤，要算清楚这个变更会让哪些任务返工、增加多少工时、会不会影响关键路径、会不会推迟交付。

给选项这一步最容易被跳过，但价值最大。不要只给"做"或"不做"两个答案，要给"现在做但推迟其他功能""下个版本做""用简化方案先顶上"这样的多个选项，让提出变更的人自己权衡。人一旦要为自己的选择承担代价，很多不必要的变更会自动消失。最后是留记录，变更单上写清楚改了什么、为什么改、代价是什么、谁批准的。这份记录在项目复盘时是最有价值的材料。

变更类型	典型场景	处理策略	代价评估要点
范围新增	业务方提出新功能	走变更评审，评估是否进入本期	新增工时、是否影响关键路径
需求调整	原有逻辑需修改	评估返工范围，优先保交付	已完成工作的废弃比例
优先级变化	上层要求提前上线某模块	重排关键路径，调整资源	对其他模块的挤压程度
标准提高	性能或体验指标上调	评估技术可行性，给出折中方案	是否需要引入新技术或额外测试

5. 监控阶段：用数据判断项目是在正常跑还是已经偏了

监控不是为了写报告，是为了做判断。判断的依据不能是感觉，得是数据。但数据也不能太多，太多就看不过来了。我的经验是盯住三类指标：进度偏差、范围蔓延、质量趋势。

进度偏差看的是实际完成和计划完成的差距。这里有个容易犯的错误：用"工作量完成百分比"来衡量进度。这个指标看起来很直观，其实很不靠谱，因为人对百分比的估计极不准确，做到百分之九十的功能可能还需要百分之五十的时间。更靠谱的做法是用"可交付物"来计数：计划这周完成五个功能点，实际完成了几个，完成的那几个是不是真的达到了验收标准。

范围蔓延看的是需求数量的变化趋势。立项时定了二十个功能点，执行到一半变成三十个，这就是典型的蔓延。蔓延不一定都是坏事，但如果蔓延的速度超过了进度的速度，项目一定延期。监控范围蔓延的方法很简单，每周统计一次需求清单的数量和变更记录，画个趋势图，一眼就能看出来。

质量趋势看的是缺陷发现和修复的情况。缺陷数量本身不重要，重要的是趋势：如果缺陷发现数在交付前还在上升，说明质量还没收敛，不能贸然上线；如果缺陷修复速度跟不上发现速度，说明团队已经超负荷，需要减范围或者加人。

5.1 进度数据的采集与真实性校验

监控失效最常见的原因不是没有数据，而是数据不真实。执行的人出于各种原因倾向于报喜不报忧，"基本完成""快好了""就差一点"是最危险的三种表述，它们掩盖了真实的困难。要拿到真实数据，靠的不是追问，而是改变提问方式。

不要问"这个任务完成多少了"，要问"这个任务还剩哪些具体的事没做"。前者得到一个百分比，后者得到一个清单，清单是没法含糊的。也不要问"有没有问题"，要问"如果要延期，最可能卡在哪"。前一种问法暗示"没问题最好"，后一种问法允许对方说出真实的担忧。

注意：如果团队长期报喜不报忧，不要只怪团队。先检查一下历史上报忧的人有没有被善待。如果第一个说"做不完"的人被当众批评，后面所有人都会学会沉默。数据真实性的问题，根源往往在管理氛围。

5.2 偏差出现后的纠偏决策框架

发现偏差之后，第一反应不应该是加人或者加班。加人有学习成本，新人上手期间反而拖慢进度；加班有边际递减，连续加班两周之后效率会明显下降。纠偏有四个选项，按优先级排列：砍范围、调顺序、加资源、延时间。

砍范围是第一优先，因为它的代价最小，只影响功能多少，不影响交付时间。调顺序是把非关键路径上的任务往后挪，先保关键路径。加资源要谨慎，只适合任务本身可以并行拆分的情况。延时间是最后手段，因为它的代价是外部承诺的失信，一旦用了，后续所有项目的时间估算都会被质疑。

选择哪个选项，取决于约束条件。如果时间是刚性的，就只能砍范围；如果范围是刚性的，就只能延时间；如果两者都刚性，那就只能加资源，同时接受质量风险。这个取舍必须由决策者来做，项目负责人可以提供选项和代价分析，但不能替决策者承担取舍的责任。

6. 交付与收尾：让项目真正结束而不是慢慢消失

很多项目没有"结束"，只有"不了了之"。功能上线了，文档没写，知识没传递，人员撤走了，留下一堆没人敢动的代码和一堆没人说得清的决策。这种项目的隐性成本极高，因为下一个接手的人要从头理解一遍，遇到问题找不到人问，想改又怕改坏。

收尾阶段要做的事，核心是把项目从"一群人的临时协作"转化为"组织的长期资产"。资产包括三类：可运行的成果、可查阅的文档、可继承的知识。成果要验证，文档要归档，知识要传递。这三件事在项目顺利时显得多余，在项目出问题时是唯一的救命稻草。

验收是收尾的第一个动作，也是最容易走过场的动作。走过场的验收就是签个字，认真的验收是逐条对照立项时的目标，确认每一条都达到了，达不到的写清楚原因和后续安排。验收不是挑刺，是给项目画一个明确的句号，让所有人知道这件事到此为止，后续的问题属于维护范畴，不属于项目范畴。

6.1 验收标准的落地检查清单

验收最容易出问题的地方是标准模糊。立项时写"系统运行稳定"，验收时怎么判断稳定？所以要有一份可执行的检查清单，把模糊的标准翻译成具体的检查项。清单的每一项都要能回答三个问题：检查什么、怎么检查、什么结果算通过。

检查维度	检查项示例	通过标准	检查方式
功能完整性	立项范围内的功能点是否全部可用	全部功能点通过测试用例	逐项执行测试用例
性能指标	核心操作的响应时间	在约定并发下不超过约定阈值	压测工具记录数据
文档完备性	操作手册、接口文档、部署说明	内容完整，无关键步骤缺失	由未参与项目的人试读复现
数据准确性	迁移或计算结果与预期一致	抽样核对无偏差	随机抽取样本比对
遗留问题	未解决问题是否登记	有明确责任人和处理计划	查阅问题清单

这份清单的价值在于它把验收从"感觉行不行"变成了"逐项打勾"。我经历过一次验收，双方对"系统是否可用"争论了两天，最后发现争论的根源是没人定义什么叫可用。有了清单，争论就变成了对具体条目的核对，效率完全不同。

6.2 知识传递的实操方法

知识传递最没用的形式是"文档写了放在共享盘里"。写了没人看，看了看不懂，看懂了找不到人问，这三道坎每一道都能让文档变成摆设。有效的知识传递要有三个要素：结构化的材料、有互动的讲解、可验证的复现。

结构化的材料不是把所有信息堆在一起，而是按接手人的使用场景组织。接手人最需要知道的是：这个系统怎么跑起来、出了问题先看哪里、哪些地方看着能改其实不能改。按这三条组织材料，比按模块罗列代码结构有用得多。

有互动的讲解是指至少有一次面对面的交接，接手人可以提问，交付方可以补充材料里没写到的隐性知识。隐性知识往往是项目里最珍贵的部分，比如某个参数为什么设成这个值、某个模块为什么不能动、某个看起来多余的判断其实在防一个历史问题。这些东西写不进文档，只能靠讲。

可验证的复现是最后一道保险：让接手人独立完成一次部署或者一次常见问题的处理，交付方在旁边看，不做提示。能独立完成，说明传递到位；卡住了，说明还有知识缺口。这个方法我在几个项目里用过，每次都能发现文档里漏掉的东西，比如一个环境变量的配置、一个依赖的安装顺序。

7. 常见问题与排查技巧实录

项目管理的很多问题是有共性的，重复出现，反复踩坑。下面这几个是我遇到频率最高、也最值得提前预防的。

问题一：项目开始时一切顺利，中期突然失控。这种失控通常不是突然发生的，而是早期的小偏差被忽略了。排查思路是回看过去四周的进度数据，找出第一次出现偏差的时间点，看当时为什么没被处理。十有八九是因为当时的偏差看起来"不严重"，或者处理它需要跟人起冲突，于是被搁置了。

问题二：需求方和开发方对同一个功能的理解不一致。这种不一致在文字描述阶段几乎无法发现，要到做出来才暴露。排查思路是提前做原型或者用具体的例子来确认理解，不要停留在抽象的描述上。一个可点击的草图胜过三千字的需求文档。

问题三：关键人员被抽走或者离职。这是项目最大的风险之一，预防方法是避免任何模块只有一个懂。具体做法是核心模块至少两个人参与，一个人主做，一个人做代码评审和文档核对。成本不高，但能避免单点故障。

问题四：汇报时一切正常，交付时集中暴雷。这说明监控机制失效了。排查思路是检查汇报的内容是不是"完成了什么"而不是"做到哪了"，以及有没有人真的拿着汇报去核对实际产出。一个简单的验证方法是随机抽查几个"已完成"的任务，看看产出物是不是真的达到了验收标准。

问题现象	可能原因	排查动作	预防措施
中期突然失控	早期小偏差被忽略	回看四周进度数据找拐点	每周核对偏差，小偏差即时处理
理解不一致	需求描述过于抽象	用原型或案例确认理解	关键需求做原型评审
关键人员缺失	知识集中在单人	梳理每个模块的知情人	核心模块双人参与
交付前集中暴雷	监控数据失真	抽查已完成任务的产出	汇报语改为"完成了什么"
会议冗长无产出	例会当汇报会开	检查是否有决议跟进	例会只对账、只暴露卡点

我个人在这些问题里踩得最深的是第二个。早期做项目的时候，我总觉得需求写清楚就行了，文字描述足够准确，没必要画原型。结果做出来的东西和对方想的差了十万八千里，返工的代价比做原型的时间大得多。后来我养成了一个习惯：凡是涉及界面或者流程的需求，一律先画个粗糙的草图，让对方指着图说"这里不对""那里要改"，改草图花十分钟，改代码要花十天。

还有一个心得是关于记录的。项目过程中会产生大量的决策，这些决策当时都有充分的理由，但过了一个月就没人记得为什么这么定了。我的做法是维护一份决策日志，每做一个重要决策就记一条：时间、决策内容、依据、参与人。这份日志在复盘和交接时价值极大，能省掉大量"当初为什么这么设计"的争论。

最后分享一个判断项目健康度的小技巧：看团队在例会上有没有人主动说"我这边有问题"。如果每次开会都是一片祥和，没人提问题，这个项目大概率有问题但被藏起来了。敢说问题的团队，问题反而少；不敢说问题的团队，问题都在水下。