本文首次成型于3年前，以前是作为内部团队经验分享的，如今为了恰饭，摘录其中一部分出来提前放出，大家就当，提前看我未来的第二本书的文章节选吧。
01、标题我也不知道怎么取。
还是从熟悉的业务场景开始，这样大家读起来比较有感觉一些。
场景1
你在公司负责重要项目的业务攻坚，如果搞定这个业务立刻起飞，但是团队面临如下问题……
场景2
你参加一个重要的通道晋升/面试，如果成功了你将薪资翻倍，面试官给你出了如下问题……
场景3
公司现在另起一个重点项目，（这个项目可以给年底发12个月的年终奖），而公司采用多个团队竞争上岗，靠能力答辩PK取得项目主导经营权，在重要的环节中，主考官给你和其他的竞争团队出了如下问题……
有些读者可能急了，“如下问题”到底是什么问题呢？
当前团队一共45个人，过往的业绩表现来看，项目经常性的延期，极大影响了公司在行业里的竞争力，这非常非常让人头痛，请你找出项目延期的原因，并制定解决问题的计划。
此时，你该如何作答？
要解决项目延期，可是一个系统性问题，绝对不是哪一个点，往往是一圈问题导致的，例如：
- 业务需求频繁变更；
- 各进度计划不合理；
- 人力资源分配不合理；
- 团队配合/协作/沟通不充分；
- 团队能力短板；
- 工时预估不准确；
- 团队成员状态不好/有矛盾；
- ……
注意这7个可能出问题的点只是大点，而每个大点，至少还可以拆解成多个小的点。
当我经常面试别人的时候，面试者当然可以通过背的方式应对我的第一轮开放问题。而真正考验一个人的专业能力是基于求职者表述后的追问。
上面7个问题，每个问题，都可以继续追问。
比如说，选中问题1，因为各种各样的原因，你如何处理需求频繁变更？
比如说，选中问题2，你心中各个进度计划合理的情况是怎样运转的？
比如说，选中剩下的……
7选1？选中哪个呢？OMG，也就是说，我可以写7篇3000字的文章，所以每次有人在后台问我，面试XX岗位应该注意什么？我就很崩溃。
任何复杂的问题背后，都是一个框架，这种框架是可以被细分到各个场景之下的，这个就是方法论了。
那随便来一个吧。
如何解决工时预估不准确的问题。
一个团队协作可是，产品/设计/开发/测试/项管/运营多个岗位共同协作的结果。
每个人都可以预估工时，都存在工时不准的情况
鉴于绝大多数人对设计可以指指点点，对测试漠不关心缺乏重视（其实也是不懂），对神秘莫测的开发不知道如何下嘴，那就写开发的吧。
02、开发岗为啥预估时间不准
其实开发岗，可以换成任何岗，答案就是，能力+经验问题。
我所知道的大家曾经遭遇过开发，会说“这个实现不了。”
但是我实际的10多年的工作履历中，还从来没遇见过开发，跟我讲“实现不了”，因为一旦这么讲了，我自然有办法处理，这个处理办法，咱们可以后面的文章里讲。
而实际上，过往和我配合的很多优秀的开发，在拿得准的情况下，会跟我说，“你这个需求，咱们有三种实现方式，分别是blablabla……”
好咯，你说的拿得准，那拿不准的情况呢？
那咱们就看看，开发到底是怎么评估时间的吧。
这里其实就是，需求VS能力
即：产品需求的复杂度VS开发的需求理解+拆解能力
需求理解力不到位，最后做出来的东西，不是开始想要的，然后返工。
拆解能力不到位，并不知道如何把复杂需求拆解成任务。
此处引用一张网图，来说下开发岗，到底是如何评估时间的。
（当我写书的时候，我会升级这张图片，此时就不放出来了，大家意会就好）
听懂产品经理的意思，并且能够合理给出时间，就是开发（综合）能力的体现了。提及一个人的能力的时候，亦或者是任何一个岗位的能力的时候，从来看的不是单一维度。
03、产品岗如何应对开发评估时间
前面讲了，开发如果能够说出三种方案，必然是十拿九稳的，时间预估精准的。
另外一个极端是开发岗支支吾吾，迟迟给不出时间的，那必然是没谱的，这个是可以通过面对面看出来的。如果发现这种情况，你可以直接请团队更专业的人（一般是开发的主管），代替他把关评估时间了。
面对面如果还看不出对方没谱，你这个眼神有待提升了。
刚刚讲了2种极端。
一个是十拿九稳，一个是支支吾吾，那些中间情况呢？
我的既往经验是，再复杂的需求都可以拆解成一个个的子任务，每个子任务都可以由一个开发，或者多个开发协作完成。
产品岗在组织需求评审会的时候，就应该具备，这个需求，会用到哪几个开发职能岗位的能力，前端/客户端，后端，算法，数据库等技术栈。
因此，时间评估，差不多在需求拆解会，或者评审会上差不多就能搞定了。
就算是有些工作无法当场判断时间，散会后的2个小时内，足够给出具体时间安排了。
开发岗给出了具体时间，有经验的产品岗会对时间预估做一个判断，这个就是纯吃技术理解力了。
在你没有底气以及技术理解力，千万不要直接去问给你时间评估的开发，“这个需求这么简单，还要这么长的时间么？”
如果你这么干，必然是破坏双方的信任关系，以及100%会挨怼，“你在教我做事？要不你来？”
下一刻，如果你足够有底气，“特么你起开，你看我怎么10分钟实现你这个说要做2天的需求。”
我相信绝大多数产品，都没有那个能力，“我来教你怎么实现？”
不懂技术没关系，咱们可以有责任心，那就是平日多学习，多请教，理解对方如何实现，技术思维和技术实现是两码事，每个产品都可以有技术思维。
如果你当前技术理解不够，又觉得对方给予的时间评估实在是不太靠谱，可以请他的老大做二次评估，这话总会说吧，“刚刚我们结束了一场需求评审会，他给出的开发时间评估是X天，这个系统我过往做过类似的，我过往的经验是完成这个需求大概是Y天，我觉得这个时间评估差距有些过大了，是不是咱们这边有什么特别的难题需要解决，你是否可以帮忙把个关，毕竟咱们这个需求还挺重要的blablablabla……”
评估小弟的开发实现时间，是对方主管岗的应尽之责。
如果开发的主管岗不看，那就是另外一个话题了，这里不展开。
总体看来，如果你平时善于学习和积累，对技术积累自己的理解力，而且认真负责的话，然后从文中提炼出套路来，是可以做好时间评估的，继而在这个维度上把控好项目进度的。
阶段性完结，未完待续……
文末，项目频繁延期是一个系统问题。
每个点都优化到位了，项目自然就顺利了，如果不顺利自然是有各种各样的原因。
这反应出一个协作团队的战斗力。项目管理是每个产品岗必备基础能力，天天在外面的网站翻什么，被一些吓死人的标题，什么绝招，干货，如果连系统基本功打不好，那些套路根本没鸡毛用。
