这事儿让项目经理是真头大，原本以为一周就能搞定的活儿，开发那边给扔回来一句最长功能得40天×2人，折算成工作日就是5周。这落差感就跟冷水泼头似的，一下子就把项目经理给浇懵了。 其实不会写代码也能把工期算准，主要靠经验积累。刚转岗的PM经常被说“不懂代码就要被开发坑”，但你真让他把Java、Web、H5、Android、iOS这些全学会再上岗，黄花菜都凉透了。诀窍就是多干活，脑子就会练出那种“工期感觉”，看到需求就能大概说出区间。 光有感觉不行，还得加上数学辅助。那个PMP或者软考里学的三点估算特别管用：乐观值O、最可能值M、悲观值P。把这三个数一算出来，期望值和标准差就出来了，再对照正态分布图，马上就能看出80%的概率落在哪个区间。 要是技术团队意见不统一咋办？用发牌法快速收敛。把功能拆得细一点，每人写个工时写在纸条上发过去。汇总以后一看众数和离散度，既民主又高效，比瞎拍脑袋强太多了。 功能复杂、涉及新技术、需要跨系统联调的地方肯定要多费点工夫；核心成员请假或离职导致位置空着也是隐患；还有那些没人懂的新技术学起来费劲得很。把这三层原因扒开了看清楚才能对症下药。 客户要是非要3周上线？也有办法把“不可能”变成“可落地”。加人可以快速扩容但别忘算融合成本，新人到岗到能干活平均得两周时间；加时间的话996肯定不行情绪会出问题；少内容砍功能也不是偷工减料而是止损。 把评估差距当成体检报告而不是判决书就对了。用经验加三点估算再加发牌法把数字算准，再加人加时间减内容这三板斧一用，就能把计划拉回正轨。这次差点炸锅的迭代正好是检验团队弹性和沟通效率的练兵场。