在做产品的这段时间里，听到最多的词不是交互、架构、设计这种逼格很高，吓死人的词，而是——时间。

　　时间是一种看不见摸不着的东西，但是我们都能感觉到他的流逝与不可逆。去推进、去监督、去设立时间节点、听起来似乎应该是项目经理该做的事情，可事实上，大部分公司都会把这一份职责也加之产品经理身上。产品经理也有理由去承担下这部分的工作，因为在整个产品产出过程中，产品经理应是最懂产品每一个细节的人。

　　每一次产品开发都是一次时间紧任务重的挑战

　　老板总是很任性的，要求你在很多短时间里就将产品设计并制作出来。通常工期都会比较紧张，或者说这是为老板之人的一种战略也不一定。。就是工期紧，好让下面的人有紧迫感?好吧，完全是一种一项，对猜测不负责的。

　　时间是把抵在脑袋上的枪

　　上线时间，洋气一点叫deadline。再洋气一点叫“带的来恩”。

　　OK，当无数个会议结束后，需求已经确定!这时候我们会得到，一个比较明确的上线时间或者模糊的预测上线时间。

　　明确的就是领导确定下来的，一般不能改变，且不在我们能控制范围之内。这通常与公司战略、拉融资、等等因素相关。也包括老板的心情!

　　还有一种叫预测上线时间，此类时间的主动权放在了我们自己或者项目经理手中。但我们该如何去预测一个产品的上线时间呢?一般有经验的产品经理会根据以往的经验来进行预测。但如果你和我一样是菜鸟怎么办?那就扔鞋或者掷筛子吧~~哈哈 开玩笑。这个当然还是有方法可循的。

　　在做过两个产品小功能模块后，让我知道了在产品产出过程中沟通的重要性。

　　人与人在信息流传递上，是很容易出现差错的。就像我们小时候玩的游戏，由第一个人说一个词传到第十个人的耳朵里可能就变成了另外一个词。

　　你也许会说，你可以去找他们的负责人啊，进行一对一的沟通不需要中间的传话筒;OK，这样是可能会降低出错的概率。但你并没有考虑进，这个人一天的“时间”里会接受多少这样的信息传达。也许一不小心你的需求就会在他的任务清单里变成了，重要但不紧急的项目了。

　　沟通先行

　　那么在预估他人时间的之前。我们可以先搞定自己的“时间”。

　　首先我们需要将此次产品的需求了解透彻，最好能够整理出一份文档，里面包含一些产品背景，解决了什么问题，如何解决等文字说明，要实现哪些功能。你可以叫他MRD BRD PRD什么的，其实这些都是形式，重要的是你是不是可以让自己和其他人明白，你们接下来要做的事情。

　　在去找他人沟通之前，你需要给自己一个时间节点，这时可以适当的“逼迫”自己，设定较为短的时间可以让自己尽快投入到产品的设计中去。其实包括我在内，大部分同学都是一群拖延症重度患者啦。你们懂的。

　　谈话的形式最好是找到负责人，进行一对一或者少数人的交谈，和他们讲明白这个产品可以实现哪些功能，大概会有多少个页面等，是在原版的基础上进行迭代，还是开发新产品等等开发前期需要知道的前提。

　　如果你的谈话对象是UI，最好在谈话之前到网上找一些竞争对手或者目标效仿网站一并发给设计，再去谈的话就可以更加轻松了。这时UI一般会根据平时自己做页面的情况与这次设计的复杂程度，给出一个大概的时间。

　　如果你的谈话对象是技术，你也可以去把竞争对手的网站发给他，告诉他们竞争对手上的哪些功能也是我们需要的，问一问有没有技术难点，询问一下他们手头上是否有其他并行工作，是否是全身投入到这个产品中来，当然如果你是个懂技术的PM的话，那真是极好了，可以直接跟他们说，需要什么样的技术架构来实现。当然他们也会给你一个时间~

　　与测试的沟通可能就相对简单一些了，可以先去了解一下同城他们做测试的一个流程，并询问他们常规测试一般时间。

　　压缩与预留

　　OK，现在几方阵营的时间已经交到你的手上了。那是不是就可以相加得出时间了呢?其实还早。还需要一部压缩与预留。

　　压缩时间是尽量去压缩每个环节上面的时间，根据你对这个团队或者个人能力的认知，来压缩他们的时间，尽量做到前紧后松，这是最理想的状态。要压缩多少时间，就要看你的感觉与协调能力了。

　　预留时间则是要给产品的deadline一个缓冲的时间，不知道大家知不知道墨菲定律，如果事情有变坏的可能，不管这种可能性有多小，它总会发生。产品开发也是一样，所以我们需要给哪些，不可预知的事情一个缓冲的时间，通常如果做预测时间对外公布的时间，都会与真正心理预期的上线时间有所不同。

　　尾巴——节奏感

　　从对时间的把控，可以看出PM的节奏感。无论是快速迭代，还是传统的开发，节奏感都非常重要。可以说，过快的开发会让用户忙于更新而不能去熟悉产品，而过慢的开发进度又会被变化莫测的市场所淘汰。

　　其实这很像划龙舟，如果大家的力气都在一个时间一起爆发，那力量肯定是不容小觑的，但如果有哪个人的节奏错了。别人做完动作，他还没有开始，那不仅会拖慢速度，严重的更会让自己的团队丧失资格。

　　所以通常我们都会在龙舟上看到一个慷慨激昂喊号子的年轻人，而在产品开发的过程中，这个人就是产品经理。

　　那~下次我们要不要一起喊产品号子!