产品经理怎么跟工程师沟通时间进度问题？

谢邀。

通常，如果你让工程师不必为他所说的话负责任，你就能得到负责任的回答。

坦白说，看到这个问题，也许是我恶意推论了，我总觉得提问者内心深处有一种潜意识，把自己和工程师当成上下游的关系，把工程师对工期的估计当作对自己的承诺。“30天才能给你。”“不行，我15天就要。”这不是沟通，这是对立面的谈判。道已错，追求术有什么用？

工期很难准确估计，这与产品很难准确定义需求一样。我见过一些号称能解决这两大难题的方法或者工具，但是：

(1) 它们本身会带来额外成本，而且往往大得让人难以接受

(2) 更重要的：它们在扯皮时有效，在推进项目时失效

如果工程师给出一个正常的工期预估，那么很有可能不能按期完成。而如果不能按期完成可能会被你找麻烦，那他会给出一个足够充分的时间来保护自己，这很自然。

真正有效的办法，是让彼此间的沟通，永远不会成为日后扯皮时的证据。这样才有利于拿到最真实的信息，方便作为正确的判断。自然，还是无法准确，但互联网本身就充满着不确定性，这正是它魅力之所在；工期的不确定，是这个“大不确定性”中很小很小的一部分，如果这都无法承担，还做毛产品经理呢。

回答过一个类似的问题，原文链接：

===================以下是搬砖过来的，方便懒得点连接的同学======

对于产品经理，想要比较准确的预估项目开发时间，最重要的三个要素是：经验、专业和沟通。

对于预估项目周期，没有什么比经验更准确的了。比如你曾经做过类似的项目，当时用了一个月；这个次做的项目还是同等的规模，同样的质量要求，同一批工程师（至少水平相当），那么这次的项目差不多也要一个月。

为什么这么依赖经验呢？因为项目周期这种事情，除去工程师写代码设计师画图的时间之外，还有很多其他事情会耽误时间：比如大家对需求争来争去的时间、服务器上传速度慢耽误的时间、老板改主意了返工的时间、修改bug需要的时间、工作站死机了没存盘重新做的时间等等等等，这些时间很难用公式来计算，只能说凭借经验来估计。所以你项目做得越多，时间估计的就越准确。

其次我们就会用到专业。虽然说有很多时间是没法靠公式计算的，需要用到经验，但是依然有那么一部分工作时间（而且比例还不小）是可以靠“公式”来计算的。如果你想掌握这个“公式”，就得掌握相应的专业知识。这个专业不是产品经理的专业，而是相关环节的专业。比如你让前端工程师切一个纯的静态页和让他加入js特效花费的时间肯定是不同的，js特效是弹一个浮层出来还是阿贾克斯的拖动时间也是不一样的，你需要明白这些不同的需求在处理起来大概要花多久，有没有可以缩短时间又满足需求的方法（尽管你不需要知道方法的细节）。这对于你计算项目时间也是非常有必要的。

最后才是沟通，如果你前两项都不掌握，沟通是没有基础的：在你眼里工程师漫天要价，在工程师眼里你异想天开。你只有大概知道合理的时间是多少，才能运用沟通技巧，去说服工程师用一个比较合理的时间完成项目。