项目经理工作盘算：把项目当“过日子”干，别当“出任务”搞 看着手里那张厚厚的项目盘算书，真认定有点像在填那张填不满的表格，越填越认定心里堵得慌。项目经理干这行，最忌讳的就是把自己摆在那儿像个冷冰冰的说明书，冷冰冰地讲如何“交付”、如何“里程碑”。咱们干的是项目管理，不是写论文要么拉流程。项目是活的，是充满了突发状况的，就像咱们平时过日子一样，得理直气壮地跟变化扯平。 项目启动阶段，别整那些虚头巴脑的“干群关系”要么“战略对齐”。项目启动就是要把那些原本散落在各部门里的烂摊子收回来，打成一张网，织成一张线。你得先搞清楚，这个项目到底是在算“买卖”，还是在算“成本”。
要是是算买卖，就得拿出一个个具体的数字去碰钉子；要是是算成本，就得拿数据把未来的坑一个个挖出来。 举个例子，刚进项目标时候，我那个团队出于之前接了一个外包项目，把服务器数据给弄丢了，直接害得客户那边断链了。我当时没想忒多，直接让各小组负责人自己背锅，说这是他们执行力不够，推不动。结局第二天客户那边发来了复核报告，发现数据丢了，并且修复工夫拖了三天，害得我们的交付节点直接往后拖了一周。
那三天里，团队内部出于责任扯皮，哪位也不愿动，会议开成一锅粥，半天没个结局。 这就是典型的“项目启动”没干到位，把难题留到了“执行”阶段。真正的启动，是要让所有人明白：我们要在这个项目里做啥，是为了啥，还有最终到底付多少钱。
要是连这个都没搞明白，后面的活干起来肯定是一团乱麻，想省钱都难，出于根本不知道哪块肉该把价砍下来。 再者说，大量人认定项目管理就是做“进度表”。进度表是个死的，项目是活的，故此进度表也得跟着变。
那会儿我就当作只要按时交付就行，目前想想，这简直是大错特错。项目交付不是“按时”动作，而是“按质”交付。
要是交付了，但产品有bug，客户不中意，那这个项目就算白干。
故此，我的盘算里，每一天的进度都不是写在纸上的，而是写在班组的脑子里的，是团队成员在干活时脑子里想出来的“关键点”，而不是到时候再塞给领导查的。 举个真的数据案例，在咱们上次的那个核心模块开发项目中，我让所有人每天下班前填个好办的“当日状态”。
不是那种形式主义的填表，而是每个人根据手头活，把能做的、能改的、能改不完的都一个个列出来。结局发现，原来有 40% 的工作量实际上是卡在等待上下游环节的，出于没人知道这东西在哪。通过这种“状态”的透明化，我们那天发现了一个严重的设计缺陷，害得整体返工率直接降了 15%。比那 15% 的返工，能省下的钱和工夫是没法计算的。
这种“状态”管理，就是防止项目“发福”，让每一项花都看得清清楚楚。 收尾阶段，也别搞啥“大张旗鼓”的告别仪式。项目终止了，人散了，事也完了，你这时候还在那儿煽情，说啥“项目终止了，大家辛苦了”，感觉项目还没终止，显得忒假了。真正的收尾，是“撤出”和“复盘”。人撤了，事撤了，但经验得留下来，就像把饭做好了，留个样子在桌子上，下次有人来了，就知道如何干。 复盘的时候，别光看结局。要把过程摆出来，看自己哪儿做得好，哪儿做得烂，都要找缘由。
有时候不是本事不中，是流程不对，是工具没用对，要么是沟通没到位。
比如我们上次那个需求变更，出于某个文档没更新，害得我们团队在开发里瞎忙活，最终不仅没按时交付，还出于改方案，最终连客户都不要了。
事后回头看，跟方案文档的及时更新差了一分钟，这一分钟错，就全完了。 故此，项目经理的工作，实际上就是个“翻译”和“翻译”的过程。把客户的不清楚需求，翻译成团队的清楚任务；把团队的执行细节，翻译成客户能感知的价值。别总想着用高大上的术语去解释项目，客户要的是实实在在的结局。项目终止前，一定要问问客户：您这个产品，用起来顺不顺？数据准不准？能不能解决难题？要是答不上来，那这个项目，咱们得重新想。 最终，我想说，项目管理不是靠熬通宵堆出来的，是靠每天踏实干活堆出来的。别总想着啥“关键干法”，啥“完美干法”，那些都是借口。真正的管理，就是在混乱中建立秩序，在不确定中找到确定的方向。项目干完了，记得把这份“盘算书”连同你遇到的坑坑洼洼一起打包，留个副本给自己，赶明儿要是人走茶凉，还能看看当初是如何干成的。
这就是项目经理的“家底”，别丢了。