比如需要开发一个什么东西，工程师会说：30天
问为什么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.每个人都希望严格要求别人，但往往严格要求自己是最难的。
