|
研发保证按照需求和时间点完成开发任务，并且尽量少出BUG项目管理者联盟
UI设计师力求页面效果不仅满足PM的功能需求，也符合运营的预期调性项目管理者联盟
不仅如此，在每天的晨会(站会，10分钟)和每周的例会(1个小时)里，大家会抛开自己的分工，一起加入产品的讨论。虽然经常会有不靠谱的建议，但这才像一个团队。项目管理者联盟文章
但这个模式也有缺点，就是只适合5-20人的小团队。如果人数增加到30人，就肯定行不通了。原因是：项目管理者联盟
首先，一个老大直线管理这么多人的成本和难度很高，沟通和信息互通也不会那么通畅。如果老大和员工之间再增设一个层级，变成金字塔式架构，就更复杂了。talent.mypm.net
其次，如果是30人的团队，那么产品和运营的人数也会增多，比如各5个，这就意味着产品和运营分别成立了二级团队。独立的小团队变成大团队，又会出现上文中所说的目标不统一，各自为战的情况。pmp.mypm.net
所以，如果可以拆分成小团队，或者本是小团队的公司，可以尝试上述的方案。一旦团队规模变大，就不再适用了，这也是业内都很羡慕团队「小而美」的原因吧。项目管理者联盟
当然，大团队也不是无解，可以通过扁平化的团队架构，来缓解产品和运营配合不好的问题。比如一个总监同时管理产品和运营团队，这两个团队分别有1个经理级中层，再各带一个小团队。这样的三层团队设置，从层级上来讲是可以接受的，承担30人的团队也是没问题的。项目管理者联盟
3.谁更有话语权项目管理者联盟
说起产品和运营的关系，就不得不说话语权的问题。这两者一定会存在强势和弱势的关系，不可能有一碗水端平的状态，只是强弱差或大或小而已。当然，谁都希望能主导项目，但是有时候并非是自己能左右的。项目管理者联盟
决定一个团队是产品驱动还是运营驱动，有两个因素：项目管理培训
团队基因。团队基因主要是创始人团队带来的，所以基本等同于创始人基因。从一个公司，到一个小团队，这个规律都适用。项目管理者联盟
所以，要看一个团队是什么角色来驱动，主要看老大。如果老大是PM出身，公司很有可能是产品驱动;如果是技术出身，那么运营的角色一定是很弱势，不被重视。因为技术人员一般不重视也不懂运营，两个角色实在是离得太远。项目管理者联盟
产品属性。通俗的说，就是看是什么产品了，不同类型的产品就是适合不同的团队架构，也决定了角色之间的话语权。项目管理者联盟
一个工具型产品，肯定是产品驱动的，比如天气、笔记、拍照类app，即使渠道的作用很大，但也不会成为驱动方;一个O2O产品，肯定是运营驱动，比如团购、到家类app。bbs.mypm.net
所以，如果要看一个团队里哪个角色更有话语权，哪个角色是主导地位，就从上面两个因素中就可以看出。service.mypm.net
4.该怎么配合www.mypm.net
团队架构就说到这，那么产品和运营应该怎么配合，才是合理的，是可以发挥双方合力的。我认为，分为产品上线前和上线后两个阶段。当然，可能没有这样纯粹的阶段，但有这样的状态。service.mypm.net
上线前：bbs.mypm.net
第一步：产品的功能规划以及发展方向，都是老板的决策。在决策完成之后，应该告知团队全员，项目的背景、方向和规划，让大家充分了解信息，对于后续执行的过程是有帮助的。项目管理培训
第二步：之后执行环节的规划，就是产品和运营协同工作的开始。比如，受众人群、功能特点、版本节奏、运营规划等，应该双方一起参与讨论，得出一个大概的框架和计划。项目管理者联盟
第三步：按照框架计划，大家开始分头行动。产品去画原型，定功能细节;运营做准备内容、流量渠道和核心用户，以及策划上线后的爆点。在这个阶段，产品和运营可以暂时分离开，不必有频繁的协作。但由于有了前两步的铺垫，在分头行动的过程中，双方也了解对方的计划和进展，所以信息是互通的。项目管理者联盟
第四步：上线前的准备阶段，之前分头行动的产品和运营的双方，就要再次回到一起，交出之前的作业。也就是大家为产品上线所做的准备，进展、遇到问题和后续计划是什么，拿出来互通和讨论。问题都解决后，就可以上线了。club.mypm.net
上线后：项目管理者联盟文章
进入到产品正式运转阶段，产品和运营再次结合在一起协同工作。在这个阶段需要高频次的沟通，以及互相推动彼此的工作。项目管理者联盟
|
