项目经理怎么评估工时？

又到了每个迭代一次的工作量评估环节了，大侠看着要开发的功能点心里暗自想：这点功能估计也就十来天的活儿，妥妥的3周可以上线。

没过多久，开发经理就把工时评估表发过来了，大侠看到评估的工作量，瞬间有点懵了，这差距有点大呀。

开发经理评估的时间最长的工期要40天，2个人开发，也就是说最长需要20天开发完成，去掉周六日，那就需要4周才开发完成，加上测试时间那不得5周才能上线！！！

这个时间和3周差的有点多了啊！！

面对这种情况怎么办呢？大侠有点懵了～～

不是从技术转岗的项目经理们，听到的最多的一句话就是：有时间也要学点技术，否则开发人员会坑你的。所以有的项目经理就吭哧吭哧的去学习编程，可是哪有那么容易啊。

如果项目经理要是真的学，那不得需要学习架构、Java、web、H5、android、ios···这么学下来，黄花菜都凉了吧。

那对于不懂技术的项目经理怎么评估工时呢？

其实就两个字：经验。

当经历过很多个项目后，就会慢慢的有感觉了，能够感知到完成一个功能大概需要多长时间了。

如果想要获得一个具体时间，除了需要经验外，考过软考或者PMP的同学都知道，还可以通过“三点估算”的方式知道。

“三点估算”的三个要素：最悲观值O（Optimistic），最可能值M（Most Likely），最乐观值P（Pessimistic）。

然后通过计算期望值

计算标准差

通过正态分布可以知道项目在某个范围内完成的概率了。

那有人就会问了，三个要素最悲观值O（Optimistic），最可能值M（Most Likely），最乐观值P（Pessimistic）怎么获得呢？

可以通过技术人员反馈、经验判断来获得。

这不是又回去了吗？技术人员反馈的差值大，经验又没有怎么办呢？

如果是这种情况的话，那么出纸牌的方式或许对你有用。

在评估时间的时候，不单独采用某个人评估的时间，而是召集大家在会上统一决定。

在评估一个功能的工时的时候，每个人员出牌，表示自己评估的完成时间，这样就很能看出大家对于这个功能的开发工期了。

评估时间是有差距的，如果差的特别多那么就需要问一下具体原因了。

1、功能方面：

是否因为某个功能的逻辑比较复杂，或者某个功能涉及到了比较难攻克的技术。

2、人员方面：

是否有人离职，或者请假呢，因为人员缺口而存在的偏差呢？

3、技术方面：

是否因为是新技术没有相关人员有经验，或者新技术的学习成本比较大呢？

要干的活儿，无法在预期的时间内完成怎么办呢？总结下来只有这几种方式：加人、加时间、少内容。

1、加人：

协调其他人员、临时招聘、找外包。如果加人的话要加快进度，因为人员进来之后不能马上开始工作，他们首先要熟悉一下整体情况后才能开展工作。

2、加时间：

加班、延期。要么就需要开发人员进入加班状态，不管是996，或者9107都是有可能完成的，不过项目经理要安抚好团队人员的情绪，疲劳之后会带来很多的情绪。延期的话，如果真的可以说服客户，延长工作时间也是很美好的。

3、少内容：

减少功能，降低逻辑。对于一些复杂的内容，如果时间不允许，可以先做到0-1，而不要追求0-完美，但是前提要和客户沟通好需求内容，否则做完了又要挨批。