上一家我们的流程（不一定最优，但是个人感觉还算合理）：

1.产品接到需求--经过分享调研后设计方案（通过产品内部评审）

2.然后基于方案给主要的开发（我们那叫SA）讲解一下需求方案，会涉及到哪些场景。可能有些会和当前的架构存在不匹配的提出来

3.将这需求拆解成N个模块的最小功能点（比如分享商品，支持链接、支持太阳码），让开发评估每个功能点的工时，最后加一个总工时（额外给开发加一些需求理解、技术调研的）

4.最后得出一个需求的工时人天，基于这个人天去匹配资源

没有出现某个场景的信息失真，几乎不会出现很大的偏差

你们评的工时有没有代表意义，如果只是参考，为了过流程，你自己评啊。

如果这个工时，业务用来反馈客户，领导要看结果，那你就不要评了，很简单，不准啊，一个是你不懂开发，另一个是你不知道现在开发人员的工作安排。比如一个项目预计10天，但是开发还要维护别的东西，不能全铺上去，所以最后工时可能估20天。

开发评工时天经地义啊，属于研发负责人正常工作内容，不用给他找理由了。

评工时不需要完整，大概流程，功能结构说下，就评出来了，对他来说也就是一个会的功夫。否则就是能力不行啊。

#产品经理挑战赛# day1

同非技术出身产品，评估工时的目的一般是为了计算产品项目的成本，或者作为项目经理排研发计划的依据。

无论是从哪个目的出发拉评估研发工时，作为产品来说，需要做到位的是将功能需求整理出来，尽量明确到最小的功能单位，方便后续WBS分解（最小工作包）。在工作包分解后再拉会，请项目干系人比如研发负责人、UI负责人等参会评审估算，这种一般会比较准确。

推荐一个三点期望法估算工时：期望工时 = （最乐观时间+最悲观时间+4*最可能时间）/6；这个是项目管理中用到的量化推算方法，比平时拍脑门会相对精确一点。

但是从我个人来说，一般还是建议将估算的工时放8~15%的宽裕度，给研发童鞋一点摸鱼的时间，后面遇到突发性事件，需要赶班时，他们才会比较配合。

#产品经理挑战赛# day4

要快速估算工时，首先需要标准化需求粒度。可以根据实际情况将需求分成ABC三个等级，A等级代表1人日，B等级代表1-3人日，C等级代表3-5人日。不建议粒度过大，最大不超过5人日，如果三个等级你能控制在3人日内就最好了。

然后将估算后需求清单+工时清单找到研发经理快速确认，补充非功能性需求及其工时，比如是否设计第三方组件对接，是否需进行重构，

此外，按照此套方案还可快速报价，一般会按照2万人月去算，当你得出工时，那报价单也基本成型。

综上耗时最短，效果最高。

说下我们公司吧：涉及到外部对接的接口，谁做谁估工时，产品尽量需求拆清晰些，然后给开发讲下大概，也不算耗时吧，反正做的时候也要仔细看需求的，提前了解估完工时，也有助于他们安排时间。

这样开发多估几次，熟练了其实你心里也会有个判断，以防过分虚报

#产品经理挑战赛# day4

1、首先这个估工时，是需求已经确定了吗？如果已经确定了，完全可以交给开发去估计的吧，毕竟一个确定的需求，要经过至少开发leader评审的。

2、如果是需求还未确定，只是给客户一个答复，那特别小的需求就准确一些，复杂的需求就一定要打出提前量来，因为你不知道项目中会因为什么而延期的。那就根据历史需求对应的实际工时来大致估一下，再加上提前量就行了呀呀呀呀～～～

我的意思是你可以关注和了解，时间长了基于经验就可以。如果想提升的话，我认为基于提问场景已经给出了答案，就是应该了解一些基本的计算机知识和技术，你可以更快的了解工时预估。

还有两外一个方法，就是找几个技术询问，以前的大大小小的需求问几个，看看每个需求从开发到上线花费多少时间，然后根据这些来推演现在需要做的功能，评估开发难度以及预估出大概时间，再找相关人员进行讨论进行修正。

如果要准确一点的话，需要让开发参与评估的。只有开发才最了解需要多长时间开发，能评估得更准确一下。这个节点是由你评估，但是没有用什么样的方式评估呀，可以让开发花时间评估一下。就像，评审会是有产品经理开展，也没说能不能邀请运营一起参与讨论呀。

如果不在意准确性的话，就随意了。

你不懂技术，你很难合理评估，这是不可避免的短板。

为什么觉得问开发工时“不是长久之计”呢

开发的任务自己评估，自己负责，很合理啊，而且和你想法一致”多报工时，避免问题“

#产品经理挑战赛# day2

这个是老问题了，我还是那句话专业的事交给专业的人。

我做了 5 年的 java 和 c++，写代码不是拧螺丝，可以计量的，期间的弹性很大，即便在需求及其明确的情况下，依旧可能出现很多问题，包括原来程序设计问题，遗留 bug，表格设计不合理...

所以让不懂技术的人去评估，只能有一个结果，两边关系闹僵。

对于开发而言，产品就是个傻 x，啥都不懂还啥都要管。

对于产品而言，开发就是个二货，天天除了摸鱼啥都不干。

面对这样的问题，不要试图依靠强大的个人执行力去控制一切。

正确的做法是立一个开发负责人，可以是组长、经理、总监，由这个人统一的负责一切开发的评估、进度和管理。

对于产品经理而已，需求即权力，产品的长处是通晓人性，擅长的是权力的把握。没必要把所有的矛盾变成阶级矛盾，应该把这些不必要的矛盾转嫁成其他部门的内部矛盾，力量应该集中在某几个人身上，而不是所有人。

这个也是我头痛的问题，但还好，可以和相关同事交流。

接口有难易之分，具体多久来完成还得开发来评估时间。

让公司提早确定一个开发负责人，这种事肯定需要开发负责人来定的。不要尝试外行管内行。

根据以往的经验，产品：技术花费的时间，大概在1比3—1比4之间，可以用这个作为参考值。

最好找开发负责人+测试负责人评估， 系统的各种交互+测试回归 都需评的， 你不能保证改这个点不影响另一个