夜雨聆风
使用Excel制定项目计划,一个经过实战验证的协同制定法
开发团队的小王说上周定的项目计划，第一个里程碑可能要延期。我问他为什么，他说当时看计划的时候就觉得时间不够，但没好意思说。
这已经不是第一次了。项目经理排计划，开发团队看一眼，心里翻个白眼，嘴上说”没问题”，然后第一个里程碑就延期。这到底是谁的问题？
01· 计划为什么总是不准？
做项目管理十年，我见过太多项目死在”计划不准”上。表面上看是延期，是开发团队不靠谱，是项目经理判断失误。但说到底，根本原因就一个：这份计划，从一开始就没有被”相信”过。
项目经理根据经验排计划，开发工程师拿到手一看，心里清楚这时间根本不够。但碍于面子，或者觉得说了也没用，就默默接受了。结果就是计划归计划，实际归实际，两条轨道各跑各的。
说白了，计划不是用来”管住”开发人员的工具，而是帮助整个团队看清楚：我们接下来要做什么、要花多少时间、风险在哪里。
要解决这个问题，核心是一个转变：让”知道怎么做”的人来估时，让”懂得全局”的人来审核，让”负责结果”的人来确认。
这就是协同制定计划的本质。
02· 为什么选择腾讯文档？
昨天和团队讨论用什么工具，有人说用Excel，有人说用Project。我说，工具本身不重要，但工具要服务于协作流程。
选择腾讯文档（在线表格）的理由很实际：
第一，国内团队不用翻墙，微信直接打开，零门槛。开发人员不用装软件，不用记密码，点开链接就能用。
第二，多人实时编辑，开发人员可以同时填写自己负责的模块。不用等别人填完，不用来回发文件，效率高。
第三，权限可控，可以设置谁可以编辑、谁只能查看。项目经理搭骨架，开发填时间，架构师审核，各司其职。
第四，支持评论和@提醒，沟通记录留存在表格里。有问题直接@，不用专门拉会议，异步沟通不打断工作流。
第五，修改历史可追溯，避免”我没改过”的扯皮。谁改了哪一列，什么时候改的，清清楚楚。
当然，飞书表格、石墨文档同理，关键是在线、可协作、有历史记录这三点。
03· 协同制定计划的五个步骤
第一步：项目经理搭骨架，不填时间
项目经理根据需求文档，将软件功能拆解为一级模块和二级任务，填入表格第一列。
这一步项目经理来做，是因为项目经理最清楚产品全貌和优先级。但注意：只拆结构，不填时间。
时间估算是开发的事。项目经理替开发估时，就像厨师替食客点菜——你觉得好吃，人家不一定喜欢。
第二步：开发人员自主估时
将文档链接发给所有开发工程师，每人认领自己负责的任务行，填写”乐观工时”、”正常工时”、”悲观工时”三列。
这种三点估算法（PERT）能有效暴露不确定性。开发人员心里清楚，这个任务如果一切顺利要几天，正常情况要几天，万一出问题要几天。
同时鼓励在备注列写明假设条件和风险点，比如”依赖第三方接口文档，若文档未到位需额外增加2天”。
第三步：架构师技术审核
架构师通读全表，重点关注两件事：技术可行性和依赖关系。
某个任务的估时是否符合实际复杂度？A任务没完成，B任务能否并行开始？架构师往往能发现那些”被遗忘的工作量”——比如没人估进去的数据库设计时间、第三方SDK集成调试、跨模块联调的缓冲期。
架构师可以直接在表格里用评论功能提出质疑，开发人员异步回应，不需要专门拉会议。
第四步：三方碰头会议（1~2小时）
这是整个流程最关键的一步。开发、架构师、项目经理在同一屏幕前，逐模块过一遍。
会议目标不是批评谁的估时，而是达成共识：这个任务我们都认可它大概需要多长时间。
有争议的地方当场讨论。开发说这个功能要5天，架构师说3天就够了，项目经理问为什么有差异。讨论清楚，最终确认一个”承诺工时”写入表格。
第五步：锁定计划，输出甘特图
会议结束后，PM根据确认工时和任务依赖关系，排出正式的甘特图，明确每个里程碑节点。
此时表格进入”只读“状态，非正式变更不得修改。后续若有变更，走正式变更流程，重新评估影响。
04· 计划表格应该长什么样？
一张好用的项目计划表，字段不用多，但每一列都要有明确用途：
功能模块和开发任务由项目经理填写，搭好骨架；负责人明确到具体工程师；乐观/正常/悲观工时由开发填写；承诺工时由三方会议后确认写入；前置依赖由架构师标注；风险备注由开发和架构师共同维护；状态列由开发实时更新，分为未开始、进行中、已完成、阻塞四种。
有一个小技巧：在”承诺工时”旁边加一列”PERT加权工时”，用公式自动计算（乐观 + 4×正常 + 悲观）÷ 6，作为参考值。帮助三方讨论时有数据依据，而不是全靠感觉拍。
05· 三个角色，各司其职
项目经理：搭骨架、推流程、控节奏。不替开发估时，但要确保计划完整、无遗漏模块。说白了，项目经理是”搭台子”的，不是”唱戏”的。
开发工程师：估时间、说风险、认任务。在表格里的估时就是对团队的承诺，要认真对待。估得准，后续被压时间的概率越低；估不准，最后加班的是自己。
架构师：把关技术合理性和依赖关系。架构师往往能发现那些”被遗忘的工作量”——比如没人估进去的数据库设计时间、第三方SDK集成调试、以及跨模块联调的缓冲期。这些漏估项，最后都会变成延期的”锅”。
06· 执行中的几个常见坑
坑一：开发不填，或敷衍填写
解法是项目经理提前说明这次估时的重要性，并告知这不是”绩效考核”，而是帮助团队争取合理工期。估时越准，后续被压时间的概率越低。
坑二：会议变成质疑大会
项目经理主持时要定好基调——这次讨论的目标是达成共识，不是追责。对于明显过短的估时，可以问”你估这个时间时，假设了哪些前提？”而不是直接质疑。
坑三：计划确定后频繁变更
每一次计划变更，都要同步评估对其他任务和整体工期的影响，并在表格里留下变更记录和原因，形成变更管控意识。
坑四：只有开始，没有跟踪
计划表同时作为进度跟踪表使用，每周更新状态列，PM每周做一次快照对比，及时发现偏差并预警。
07· 一份被团队”认领”的计划
太多”精美”的甘特图——颜色漂亮、逻辑清晰，贴在会议室墙上，然后一个月后就没人看了。
真正有用的计划，不一定好看，但一定是团队每个人都参与制定过的。
当开发工程师亲手填下那个工时数字，他对那个数字就有了一份责任感；当架构师逐行审核并确认，他对整个方案就多了一份承诺；当三方坐在一起讨论出最终数字，这份计划就不再是PM的文件，而是整个团队的契约。
这，才是计划能被执行的根本原因。
写在最后
项目计划怎么定才算数？不是项目经理一个人拍脑袋排出来的，也不是开发团队被动接受的。
而是开发、架构、管理三方一起”谈”出来、”确认”出来的。这个过程可能有点麻烦，可能要开几次会，可能要反复讨论。
但比起计划不准导致的延期、返工、团队士气低落，这点麻烦是值得的。
搞定就是稳定，摆平就是水平。一份被团队”认领”的计划，才是真正能落地的计划。
END
往期推荐
扫描二维码
获取更多精彩
pmthink.cn
