第三期我们讲的是最后一个须要沟通的主要团队—研发团队。
研发团队沟通后。就代表我们的最后一个沟通任务结束了。那么我们如今開始正式进入了一个项目的生产阶段了，假设说前面准备工作，非常多童鞋没有接触过，那么从今天開始我们讲的内容，我相信大家都不会陌生。那么就让我们来复习一下项目的生命周期。
启动→需求→设计→开发→測试→上线→推广。
我之前讲的都是环绕启动这个阶段的，那么启动阶段在这里要做一个收尾，启动阶段最后一个任务就是启动会。启动会的形式能够多种多样，有些事大家在一起开个会认识一下，有些是大家来个宣誓会，有些是大家在一起聚个餐唱个歌。
情况多种多样，这个要依据所在公司的的风气、习惯来。
启动阶段结束后，我们就要马上投入到需求阶段，在这个阶段的參与者主要为业务方领导、业务方、产品经理、研发经理、架构师以及项目经理，但并非说整个需求阶段必须要全部的人參与进来。那么这些人我们怎么来分别呢。他们主要分三个团队和一个主导。
1、业务团队：业务方领导、业务方。
2、产品团队/翻译团队：产品经理。
3、研发团队：研发经理、架构师。
这里我把产品经理叫做“翻译团队”大家会不会认为有点奇怪？事实上这个产品经理的角色在不同的公司有着截然不同的作用。即便他们做的事儿可能是一样的。
大概互联网公司会分下面几种类型：
1、技术驱动业务团队：产品经理规划公司业务。通过产品经理来驱动业务方和研发团队。
2、业务驱动技术团队：业务方提出需求，产品经理翻译成研发团队easy理解的语言，并交由研发团队实现。
自己的公司属于哪种，就看看你们的产品经理是处于哪种模式下吧。
有点扯远了。话说回来，这三个团队是PM主要须要联系接触的团队，这三方都有着微妙的关系和利益。怎样平衡好。我之前已经提到过一些，这里就不再继续讲了。我想说的是。怎样看待这三个团队。
1、确保老板的利益
说白了，一个项目的成功失败，最直接的影响人并非业务方或者产品经理，而就是老板。一定要搞清楚老板想要什么，老板要达成什么目的。一味的唯命是从。被产品经理和业务方牵着鼻子走，仅仅能让事情朝着不可控的方向发展。所以，搞清了老板的目的，哪怕是出现一些小的错误，老板一定不会在意的。
2、谁地位高。我们以谁为核心去推动
即便是相同的组织架构的两家公司，也会由于成员的组成而造成工作流程的天壤之别。好比A公司的研发团队的领导是公司的元老，在公司极有话语权。那么在这个公司想产出一个产品你肯定要过他这关，即便你全部的工作做得完美。搞不定这个元老，也仅仅会功亏一篑。这里，会不会有童鞋质疑我。“之前你不是说过要走的那些流程，跟你如今说的不一样吗？”是的，确实不一样，前面我是讲一个万金油，应对各种各样的场合，那么做起码不会错。但你看看我的标题？假设都讲那些流程式的东西就没意思了。
3、确保产品经理与业务方交好
业务方和产品经理的关系。在非常多公司都是个问题。假设二者关系闹僵，不管你有再优秀的研发团队。也是无力回天。这个一定是重中之重，怎样处理好二者关系，我们以后再说。
4、与研发团队一起加班
说来说去，最核心的工作事实上就在研发这，而最辛苦的团队当然就是研发团队了，他们常常会没日没夜的加班赶工。这是PM亲近研发团队的最好时机，一定要常常陪研发团队在一起加班，与他们讨论需求、功能。这样你才是一个身体力行的项目经理，而不会被扣上一个“耍嘴皮子的销售”的帽子。
以上就是在PM在需求阶段须要具备的一些意识，下次我会继续讲需求阶段的详细行动。