产品经理怎么跟工程师沟通时间进度问题？
程序员文章站
2022-05-02 16:19:14
...
比如需要开发一个什么东西，工程师会说：30天
问为什么30天 会告诉你工作量很大。
怎么判断是否真的需要30天？如果自己（不专业）觉得不需要 怎么跟工程师沟通？
通常，如果你让工程师不必为他所说的话负责任，你就能得到负责任的回答。
坦白说，看到这个问题，也许是我恶意推论了，我总觉得提问者内心深处有一种潜意识，把自己和工程师当成上下游的关系，把工程师对工期的估计当作对自己的承诺。“30天才能给你。”“不行，我15天就要。”这不是沟通，这是对立面的谈判。道已错，追求术有什么用？
工期很难准确估计，这与产品很难准确定义需求一样。我见过一些号称能解决这两大难题的方法或者工具，但是：
(1) 它们本身会带来额外成本，而且往往大得让人难以接受
(2) 更重要的：它们在扯皮时有效，在推进项目时失效
如果工程师给出一个正常的工期预估，那么很有可能不能按期完成。而如果不能按期完成可能会被你找麻烦，那他会给出一个足够充分的时间来保护自己，这很自然。
真正有效的办法，是让彼此间的沟通，永远不会成为日后扯皮时的证据。这样才有利于拿到最真实的信息，方便作为正确的判断。自然，还是无法准确，但互联网本身就充满着不确定性，这正是它魅力之所在；工期的不确定，是这个“大不确定性”中很小很小的一部分，如果这都无法承担，还做毛产品经理呢。 回答过一个类似的问题，原文链接：产品经理怎样合理的预估项目开发时间？
===================以下是搬砖过来的，方便懒得点连接的同学======
对于产品经理，想要比较准确的预估项目开发时间，最重要的三个要素是：经验、专业和沟通。
对于预估项目周期，没有什么比经验更准确的了。比如你曾经做过类似的项目，当时用了一个月；这个次做的项目还是同等的规模，同样的质量要求，同一批工程师（至少水平相当），那么这次的项目差不多也要一个月。
为什么这么依赖经验呢？因为项目周期这种事情，除去工程师写代码设计师画图的时间之外，还有很多其他事情会耽误时间：比如大家对需求争来争去的时间、服务器上传速度慢耽误的时间、老板改主意了返工的时间、修改bug需要的时间、工作站死机了没存盘重新做的时间等等等等，这些时间很难用公式来计算，只能说凭借经验来估计。所以你项目做得越多，时间估计的就越准确。
其次我们就会用到专业。虽然说有很多时间是没法靠公式计算的，需要用到经验，但是依然有那么一部分工作时间（而且比例还不小）是可以靠“公式”来计算的。如果你想掌握这个“公式”，就得掌握相应的专业知识。这个专业不是产品经理的专业，而是相关环节的专业。比如你让前端工程师切一个纯的静态页和让他加入js特效花费的时间肯定是不同的，js特效是弹一个浮层出来还是阿贾克斯的拖动时间也是不一样的，你需要明白这些不同的需求在处理起来大概要花多久，有没有可以缩短时间又满足需求的方法（尽管你不需要知道方法的细节）。这对于你计算项目时间也是非常有必要的。
最后才是沟通，如果你前两项都不掌握，沟通是没有基础的：在你眼里工程师漫天要价，在工程师眼里你异想天开。你只有大概知道合理的时间是多少，才能运用沟通技巧，去说服工程师用一个比较合理的时间完成项目。 比较激进的程序员，欲求展现实力地乐观估计出的时间，基本上是要乘以3，才是最后真正能上线的时间。
有经验些的程序员会估出一个比较稳妥的时间，以应对如果开发中遇到棘手技术问题和添改需求的情况，也能加下班能解决。以避免延期对士气的严重打击。
所以工期估算跟开发者的性格与经验相关，不能一概而论，这需要与开发团队长期合作的默契来辨别。
早期评估出的工时，就跟有的人拍着胸脯说：“这是最最终版需求，绝不再改”，一样
的不靠谱。
唯一可以确定的是，一定要每天沟通进度，至少每隔一周重新评估一次余下的工作量，修正进度计划或更改上线时间。
磨嘴皮是最大的时间小偷，要想珍惜时间，最有用的就是早定需求尽快开工，code wins arguments， 项目时间的管理精髓在于天天沟通和持续评估.
一个产品项目，标准的流程大致是要经历市场调研分析、需求分析设计、技术分析设计、编码开发、测试、验收上线、运维等过程。按照CMMI的研发流程，对应就是立项阶段、需求阶段、设计阶段、编码阶段、测试阶段和发布阶段等6大阶段。
其中：
立项和需求阶段，主要是产品经理的工作；
设计阶段分为两方面，一方面是产品UI设计，这主要是UI设计师和产品经理的工作，另一方面是技术设计，这主要是技术人员的工作（架构师或项目经理或直接的开发者）；
编码阶段，主要是技术人员的工作；
测试阶段，主要是测试人员的工作；
验收发布阶段，主要是产品经理的工作。
以上6个阶段，每个阶段都有项目组成员的工作分工。当然，产品经理和项目经理是贯穿整个项目流程的（有些公司的有些项目，项目经理和产品经理是同一个角色）。
虽然互联网产品讲究的是短平快和快速迭代，工期周期都相对较短，但整体项目也需要经历以上阶段。
【分析】
产品经理在做产品项目时，工期评估通常分两类：
1. 第一类是已有时间期限，只能按时间倒推法评估。例如根据市场或运营反馈一个紧急产品需求，需要两个星期内上线，产品项目目标很明确，总共只有两星期时间，包括需求分析、定义和设计，再到技术设计、编码开发，最后测试验收并发布上线。那么在已有时间期限内，项目组成员其实也没什么别的选择，只能按期完成。在这种情况下，产品经理要做的就是权衡每个阶段的时间比，同时与项目组成员多沟通，大家都面临时间紧迫、任务量大的现状，只能加班加点，按期完成目标，谁都不能拖后腿（这是项目时间很明确且无法改变的情况下，也就是是领导的死命令，项目组成员必须按期完成的情况。如果还有得改，产品经理应为项目组成员争取合理的时间和资源）。
2. 第二类是没有死命令，可以根据正常研发流程来评估项目工期及各阶段的工作时间。在这种情况下，每个阶段的对应成员都要给自己对应阶段的工作来评估合理的时间（当然，这是在需求已定稿的前提下来评估的）。而产品经理要做的也是合理的评估各阶段的时间比，以及项目工期总协调。在这种情况下，每个成员都要对自己评估的工作时间要负责，且要在自己评估的时间内完成自己的工作，如果某个阶段有延期，就会发生连锁反应，有可能就会让整个项目延期，而这个一般是不允许发生的。在整个过程中，产品经理和项目经理要把监测和把控整个项目进度。
【方法】
无论是以上哪类情况，产品经理都要对技术人员评估的时间要信任（不仅是技术人员，其实是各成员的评估时间）。而产品经理要做的就是搜集所有成员的评估时间，与预期设定的项目工期做一个对比。如果符合预期，这是最佳效果，就按各评估时间推进即可；如果不符合预期（通常都是不符合预期的），那就权衡各阶段的时间比，同时再协调。产品经理要做到这个，一个是要基于以往的项目经验，另一个就是要看具体的项目情况。
及时沟通，是推进项目进展的必要也是最基本的要素，这不仅仅是要求产品经理这样做，项目组成员都要这样做。
项目中，不怕出现意外情况或突发情况，怕就怕有问题自己捂着，等到别人发现时才沟通。别人不问你，自己打死也不说的这种人，无论是产品狗还是程序猿，都是不合格的，更别提什么扯皮了，还是自己好好反思去吧。 首先，请信任你的工程师。其次，要对这个项目有明确的时间预期。
一切成功合作都建立在彼此信任的基础上。建立起这种信任，研发信任你，需求是靠谱的有效的，你相信研发，会为了项目努力工作，如果没有这个前提，合作注定不会愉快。
pm在提需求时，是需要问问自己可以接受的时间底线是什么的，为什么是这个时候？然后，带着你的需求去沟通。这时，有时是会需要一些说服的技巧：描述出这个项目的蓝图、预期，以及要求时间点原因，如果有彼此第一点的前提，并且在不是很过分的前提下，或许也不成太大问题。
沟通时请务必说清楚需求，让大家理解一致。其次，如果真是一个大的项目，例如30天的项目，请叫上项目所有成员，一起分拆。把这个大的项目拆分成一个个小的需求点（用户故事），每一个小的需求点，需要做哪些工作，每项工作需要多久，每天完成哪些任务，列个表，做个项目进度墙，大家按进度行事，会靠谱许多。
最后，pm请在实际项目中慢慢积累经验。有技术背景的pm会好些。如果没有，请多和研发沟通，这个项目，需要完成哪些步骤，每项步骤大致需要多久时间。如果有出乎意料的长或是短，问问原因。如此积累，会更靠谱！ 要么，去学习，让自己成为“懂”的人，再来评估；
要么，相信程序员；
要么，把评估30天的程序员开了，换个评估15天的程序员，如果完不成，后果你来负。 我们用的Scrum，没错就是大家都吵吵嚷嚷的Scrum，甚至还有人骂这玩意儿。答完后发现有点不符合Po的原题，凑合看吧。
=======================================================================
我们现在做的也还不好，不过有几点可能能给大家参考。
1、业务上达成一致
这里的的达成一致时指的就最后要交付的东西达成一致，产品要做成什么样子，需要哪些资源。就是不断的互相讨论，但仅仅是业务层面的，给出用户使用场景，但尽量别去扣技术细节。
2、结论上信任团队
充分信任你的团队，也让团队充分信任你。
让专业的人做专业的事儿，东西只要没做出来就是个未知的，对于未知事物的估计，研发人员自身的技能、经验、职业素养都很重要。但是有一点 了解到团队人员怎么去估算时间，比一位的去扣人家自己估算的是否合理要有用的多。首先信任大家给你估算的时间。
3、过程中不断优化
一次就达到很好的估算时间，基本不现实。了解他们的估算方式后，就可以先开始几个周期完全信任大家的预估时间，然后做记录，让大家看到自己的效率是提升还是降低了，想干事儿的不会磨洋工的，不想干事儿的早点负分滚粗。 相信我，工程师说要30天完成
通常实际需要的是60天
所以，lz不要疑心别人故意偷懒，还是多想想30天没完成怎么办吧 不想做产品经理的构架师不是好程序员……
以这句话开始回答的目的在于，现在社会早已进入了全面分工时代，那些依靠一己之力完成中型以上项目/产品已不可能，同时具备多种技能的人员（产品+构架 or 构架+开发 or 开发+测试）从比例上来说对大部分公司来说都是奢望。
在各种工作量估算方法中，无论是“土的不能再土”的经验估算，还是在CMMI中的FPA，在组织适用的条件下都是好的估算方法。但是之所以在大多数中小型公司会出现楼主这样的问题，个人认为有一下几个原因：
1、缺少统一的估算方法/标准：如果组织确认用经验来估算，那么工作量的准确程度取决于估算人的能力、工作态度（可能还有心情）；因此我个人是建议在组织中推行相对客观的FPA方法，但是这一方法需要得到组织的认可，也有相应的成本代价；
2、缺乏有效的监督/反思机制：在很多组织中，是不会去反思项目为什么会延期，分析原因并加以改进，日常项目研发监控也不能很好的落实。长此以往，项目延期会成为习惯；
3、缺乏对承诺的尊重：如同个人信用一般，很多人只把计划当做计划，而不是将计划当做承诺；诚然这样的要求似乎有点高，但是多次的延期，必然造成他人对你的不信任。
PS.每个人都希望严格要求别人，但往往严格要求自己是最难的。
问为什么30天 会告诉你工作量很大。
怎么判断是否真的需要30天？如果自己（不专业）觉得不需要 怎么跟工程师沟通？
回复内容：
谢邀。通常，如果你让工程师不必为他所说的话负责任，你就能得到负责任的回答。
坦白说，看到这个问题，也许是我恶意推论了，我总觉得提问者内心深处有一种潜意识，把自己和工程师当成上下游的关系，把工程师对工期的估计当作对自己的承诺。“30天才能给你。”“不行，我15天就要。”这不是沟通，这是对立面的谈判。道已错，追求术有什么用？
工期很难准确估计，这与产品很难准确定义需求一样。我见过一些号称能解决这两大难题的方法或者工具，但是：
(1) 它们本身会带来额外成本，而且往往大得让人难以接受
(2) 更重要的：它们在扯皮时有效，在推进项目时失效
如果工程师给出一个正常的工期预估，那么很有可能不能按期完成。而如果不能按期完成可能会被你找麻烦，那他会给出一个足够充分的时间来保护自己，这很自然。
真正有效的办法，是让彼此间的沟通，永远不会成为日后扯皮时的证据。这样才有利于拿到最真实的信息，方便作为正确的判断。自然，还是无法准确，但互联网本身就充满着不确定性，这正是它魅力之所在；工期的不确定，是这个“大不确定性”中很小很小的一部分，如果这都无法承担，还做毛产品经理呢。 回答过一个类似的问题，原文链接：产品经理怎样合理的预估项目开发时间？
===================以下是搬砖过来的，方便懒得点连接的同学======
对于产品经理，想要比较准确的预估项目开发时间，最重要的三个要素是：经验、专业和沟通。
对于预估项目周期，没有什么比经验更准确的了。比如你曾经做过类似的项目，当时用了一个月；这个次做的项目还是同等的规模，同样的质量要求，同一批工程师（至少水平相当），那么这次的项目差不多也要一个月。
为什么这么依赖经验呢？因为项目周期这种事情，除去工程师写代码设计师画图的时间之外，还有很多其他事情会耽误时间：比如大家对需求争来争去的时间、服务器上传速度慢耽误的时间、老板改主意了返工的时间、修改bug需要的时间、工作站死机了没存盘重新做的时间等等等等，这些时间很难用公式来计算，只能说凭借经验来估计。所以你项目做得越多，时间估计的就越准确。
其次我们就会用到专业。虽然说有很多时间是没法靠公式计算的，需要用到经验，但是依然有那么一部分工作时间（而且比例还不小）是可以靠“公式”来计算的。如果你想掌握这个“公式”，就得掌握相应的专业知识。这个专业不是产品经理的专业，而是相关环节的专业。比如你让前端工程师切一个纯的静态页和让他加入js特效花费的时间肯定是不同的，js特效是弹一个浮层出来还是阿贾克斯的拖动时间也是不一样的，你需要明白这些不同的需求在处理起来大概要花多久，有没有可以缩短时间又满足需求的方法（尽管你不需要知道方法的细节）。这对于你计算项目时间也是非常有必要的。
最后才是沟通，如果你前两项都不掌握，沟通是没有基础的：在你眼里工程师漫天要价，在工程师眼里你异想天开。你只有大概知道合理的时间是多少，才能运用沟通技巧，去说服工程师用一个比较合理的时间完成项目。 比较激进的程序员，欲求展现实力地乐观估计出的时间，基本上是要乘以3，才是最后真正能上线的时间。
有经验些的程序员会估出一个比较稳妥的时间，以应对如果开发中遇到棘手技术问题和添改需求的情况，也能加下班能解决。以避免延期对士气的严重打击。
所以工期估算跟开发者的性格与经验相关，不能一概而论，这需要与开发团队长期合作的默契来辨别。
早期评估出的工时，就跟有的人拍着胸脯说：“这是最最终版需求，绝不再改”，一样
的不靠谱。
唯一可以确定的是，一定要每天沟通进度，至少每隔一周重新评估一次余下的工作量，修正进度计划或更改上线时间。
磨嘴皮是最大的时间小偷，要想珍惜时间，最有用的就是早定需求尽快开工，code wins arguments， 项目时间的管理精髓在于天天沟通和持续评估.
- 将大任务拆分成小任务分别评估。
- 组织几个工程师同时评估，取平均值。
- 最后的时间留出 1/3 余量，应该就比较安全了。
一个产品项目，标准的流程大致是要经历市场调研分析、需求分析设计、技术分析设计、编码开发、测试、验收上线、运维等过程。按照CMMI的研发流程，对应就是立项阶段、需求阶段、设计阶段、编码阶段、测试阶段和发布阶段等6大阶段。
其中：
立项和需求阶段，主要是产品经理的工作；
设计阶段分为两方面，一方面是产品UI设计，这主要是UI设计师和产品经理的工作，另一方面是技术设计，这主要是技术人员的工作（架构师或项目经理或直接的开发者）；
编码阶段，主要是技术人员的工作；
测试阶段，主要是测试人员的工作；
验收发布阶段，主要是产品经理的工作。
以上6个阶段，每个阶段都有项目组成员的工作分工。当然，产品经理和项目经理是贯穿整个项目流程的（有些公司的有些项目，项目经理和产品经理是同一个角色）。
虽然互联网产品讲究的是短平快和快速迭代，工期周期都相对较短，但整体项目也需要经历以上阶段。
【分析】
产品经理在做产品项目时，工期评估通常分两类：
1. 第一类是已有时间期限，只能按时间倒推法评估。例如根据市场或运营反馈一个紧急产品需求，需要两个星期内上线，产品项目目标很明确，总共只有两星期时间，包括需求分析、定义和设计，再到技术设计、编码开发，最后测试验收并发布上线。那么在已有时间期限内，项目组成员其实也没什么别的选择，只能按期完成。在这种情况下，产品经理要做的就是权衡每个阶段的时间比，同时与项目组成员多沟通，大家都面临时间紧迫、任务量大的现状，只能加班加点，按期完成目标，谁都不能拖后腿（这是项目时间很明确且无法改变的情况下，也就是是领导的死命令，项目组成员必须按期完成的情况。如果还有得改，产品经理应为项目组成员争取合理的时间和资源）。
2. 第二类是没有死命令，可以根据正常研发流程来评估项目工期及各阶段的工作时间。在这种情况下，每个阶段的对应成员都要给自己对应阶段的工作来评估合理的时间（当然，这是在需求已定稿的前提下来评估的）。而产品经理要做的也是合理的评估各阶段的时间比，以及项目工期总协调。在这种情况下，每个成员都要对自己评估的工作时间要负责，且要在自己评估的时间内完成自己的工作，如果某个阶段有延期，就会发生连锁反应，有可能就会让整个项目延期，而这个一般是不允许发生的。在整个过程中，产品经理和项目经理要把监测和把控整个项目进度。
【方法】
无论是以上哪类情况，产品经理都要对技术人员评估的时间要信任（不仅是技术人员，其实是各成员的评估时间）。而产品经理要做的就是搜集所有成员的评估时间，与预期设定的项目工期做一个对比。如果符合预期，这是最佳效果，就按各评估时间推进即可；如果不符合预期（通常都是不符合预期的），那就权衡各阶段的时间比，同时再协调。产品经理要做到这个，一个是要基于以往的项目经验，另一个就是要看具体的项目情况。
及时沟通，是推进项目进展的必要也是最基本的要素，这不仅仅是要求产品经理这样做，项目组成员都要这样做。
项目中，不怕出现意外情况或突发情况，怕就怕有问题自己捂着，等到别人发现时才沟通。别人不问你，自己打死也不说的这种人，无论是产品狗还是程序猿，都是不合格的，更别提什么扯皮了，还是自己好好反思去吧。 首先，请信任你的工程师。其次，要对这个项目有明确的时间预期。
一切成功合作都建立在彼此信任的基础上。建立起这种信任，研发信任你，需求是靠谱的有效的，你相信研发，会为了项目努力工作，如果没有这个前提，合作注定不会愉快。
pm在提需求时，是需要问问自己可以接受的时间底线是什么的，为什么是这个时候？然后，带着你的需求去沟通。这时，有时是会需要一些说服的技巧：描述出这个项目的蓝图、预期，以及要求时间点原因，如果有彼此第一点的前提，并且在不是很过分的前提下，或许也不成太大问题。
沟通时请务必说清楚需求，让大家理解一致。其次，如果真是一个大的项目，例如30天的项目，请叫上项目所有成员，一起分拆。把这个大的项目拆分成一个个小的需求点（用户故事），每一个小的需求点，需要做哪些工作，每项工作需要多久，每天完成哪些任务，列个表，做个项目进度墙，大家按进度行事，会靠谱许多。
最后，pm请在实际项目中慢慢积累经验。有技术背景的pm会好些。如果没有，请多和研发沟通，这个项目，需要完成哪些步骤，每项步骤大致需要多久时间。如果有出乎意料的长或是短，问问原因。如此积累，会更靠谱！ 要么，去学习，让自己成为“懂”的人，再来评估；
要么，相信程序员；
要么，把评估30天的程序员开了，换个评估15天的程序员，如果完不成，后果你来负。 我们用的Scrum，没错就是大家都吵吵嚷嚷的Scrum，甚至还有人骂这玩意儿。答完后发现有点不符合Po的原题，凑合看吧。
=======================================================================
我们现在做的也还不好，不过有几点可能能给大家参考。
1、业务上达成一致
这里的的达成一致时指的就最后要交付的东西达成一致，产品要做成什么样子，需要哪些资源。就是不断的互相讨论，但仅仅是业务层面的，给出用户使用场景，但尽量别去扣技术细节。
2、结论上信任团队
充分信任你的团队，也让团队充分信任你。
让专业的人做专业的事儿，东西只要没做出来就是个未知的，对于未知事物的估计，研发人员自身的技能、经验、职业素养都很重要。但是有一点 了解到团队人员怎么去估算时间，比一位的去扣人家自己估算的是否合理要有用的多。首先信任大家给你估算的时间。
3、过程中不断优化
一次就达到很好的估算时间，基本不现实。了解他们的估算方式后，就可以先开始几个周期完全信任大家的预估时间，然后做记录，让大家看到自己的效率是提升还是降低了，想干事儿的不会磨洋工的，不想干事儿的早点负分滚粗。 相信我，工程师说要30天完成
通常实际需要的是60天
所以，lz不要疑心别人故意偷懒，还是多想想30天没完成怎么办吧 不想做产品经理的构架师不是好程序员……
以这句话开始回答的目的在于，现在社会早已进入了全面分工时代，那些依靠一己之力完成中型以上项目/产品已不可能，同时具备多种技能的人员（产品+构架 or 构架+开发 or 开发+测试）从比例上来说对大部分公司来说都是奢望。
在各种工作量估算方法中，无论是“土的不能再土”的经验估算，还是在CMMI中的FPA，在组织适用的条件下都是好的估算方法。但是之所以在大多数中小型公司会出现楼主这样的问题，个人认为有一下几个原因：
1、缺少统一的估算方法/标准：如果组织确认用经验来估算，那么工作量的准确程度取决于估算人的能力、工作态度（可能还有心情）；因此我个人是建议在组织中推行相对客观的FPA方法，但是这一方法需要得到组织的认可，也有相应的成本代价；
2、缺乏有效的监督/反思机制：在很多组织中，是不会去反思项目为什么会延期，分析原因并加以改进，日常项目研发监控也不能很好的落实。长此以往，项目延期会成为习惯；
3、缺乏对承诺的尊重：如同个人信用一般，很多人只把计划当做计划，而不是将计划当做承诺；诚然这样的要求似乎有点高，但是多次的延期，必然造成他人对你的不信任。
PS.每个人都希望严格要求别人，但往往严格要求自己是最难的。
推荐阅读