.png)
首页>-
第一种：
总结经验，建立基准，比如通常一个页面的开发时间是多少，一个接口开发时间是多少，拿一些页面或者接口的时间做基准，来询问开发新开发的比基准那个难度增加了多少，来衡量这次的时间准确度。
-
第二种：
寻找外部技术专家，或者组织内部招聘技术经理角色。
-
第三种：
如果WBS是自下而上的评估，每个功能开发的最大单位控制在2天内，如果超过2天要接着拆分。不要让开发留太多buffer（浑水摸鱼）
-
第四种：
时间拍死法（破釜沉舟法），比如定好最后上线时间，可以召集全员（产品、UI、开发、测试），讨论上线产品范围，倒排所有时间，让各方互相商讨（撕逼），开发的关注点不再是项目经理你行你上，而是产品什么时候出原型。如何迭代，每个迭代版本做什么，能充分平衡各方利益。
-
第五种：
标准的扑克牌法，开发一起评估每个任务需要多少时间，然后各自讲出理由，来达成统一意见，但有些小团队1岗1人，比如1个后端1个前端1个移动端就不好使用这种方法了。
-
第六种：
收buffer法（砍价法），人都是有拖延症，喜欢给自己留buffer，报上来的时间砍掉一半，就和买商品讲价一样，如果没人反对，那可能这里面确实水分很大，如果反抗意见强烈在放一点buffer，逐渐找到平衡点。
-
第七种：
画像法，充分了解你的团队每个人的性格和做事风格，有些人不留buffer，有些人习惯留buffer，根据不同的人来平衡排期。
优培东方送你一张活动持续时间估算表：
项目名称： 准备日期：
| WBS编号 | 活 动 | 工作小时数 | 持续时间估算 |
粤公安备案 44010602008731号