标签：style blog http ar os sp strong on 数据
分工是社会化职能细分的一个趋势，别小看这个分工的作用。对于大部分团队来说，如何分工是管理者们需要着力考虑的问题。分工合理，可能会起到1+1>2的效果；反之，则有可能成为发展的阻碍。当然这是一个管理学问题，在这里不做讨论。
有许多朋友曾经问过我，你们究竟是如何分工的？你日常都做哪些事情？我一般回答：XX功能是我负责的，每个产品经理都有对应的功能需要去跟进。实际上，每个产品经理除了职能不同，大部分没有太明显的区分界线。整个产品团队中有两种角色：
● 产品策划
● 产品运营
简单地说，前者负责功能实现，后者负责运营和推广。作为一名产品策划，我的日常工作主要是撰写需求文档、跟进功能逻辑的实现，尽可能多地考虑功能的产品体验；而产品运营同事不仅负责日常运营，还需要针对这些功能点进行推广，侧重数据表现。两种角色的立足点不同，看待问题的方式也有所不同。两边常常会有一些不同的建议，有利于产品快速发展，但也有包容与折中的时候。有时候，产品体验并非只需要考虑用户体验，还需要关注商业价值，因此常需要找到一个平衡点。
从时间点上来看，产品策划和产品运营都贯穿整个项目周期。但前期策划需要付出更多精力去确认功能点，而在发布产品前后，则是产品运营的重头戏。 除了角色上的细分，还需要考虑在同种角色内的分工。为什么那么关注分工呢？因为每个功能点的实现难易度不同，每个人的经验和能力不同，每个人分担到的任务和精力不同，所以不能一概而论。
要想任务均衡，必须选择最佳的分工方案。不仅如此，每个产品经理的风格都不同，有些人特别适合做对外合作沟通，有些人特别适合和开发工程师打交道，有些人特别了解交互设计，有些人特别擅长处理逻辑复杂的功能，有些人则特别有创意……但无一例外，对于产品经理来说，这些能力都需要具备。虽然按照短板效应来看，产品经理应该关注自己的短板，但我认为，在分工时优先需要考虑的则是最长的那块板——即每个人的特点和优势。不过，无论是哪个产品经理，都少不得一个能力：执行力。
整个项目的推进是需要执行力支撑的。大部分时候，团队越大，沟通成本就越高，所以产品经理要全力去执行，推动功能实现。 但是在执行的过程中，难免会出现一些问题。比如产品经理之间分工不明确造成类似“哈丁公地悲剧1”的博弈，谁都不愿意去主导某个公共模块的梳理。比
哈丁公地悲剧：公地悲剧（Tragedy of the commons ）是一种涉及个人利益与公共利益、对资源分配有所冲突的社会陷阱。1968年，加勒特·哈丁（Garret Hardin）在期刊《科学》中将这个概念加以发表、延伸。
将这个理论运用在这里，想表达的意思是如果产品经理缺乏全局视角，常常造成一些公共模块不受关注，引起项目的危机。
如在执行有些功能点的时候，由于缺乏对于其他人工作的关注，造成功能冲突，结果需要推倒重来。所以产品经理之间不仅需要相互做好沟通和分工，甚至在整个开发项目上都需要有一个全局视角，不能因为我的需求影响了你的需求，或为了实现我的功能而引起你的功能无法达到最佳效果。所以，产品经理在负责自己的“一亩三分田”时，需要尽量确认一些公共模块上的功能交集，及时找相关产品经理确认对应的方案，提前达成一致，这样会大大降低后续问题的出现几率和试错的成本。
大部分时候，产品经理的分工都是经过深思熟虑的。常见的方法是按照模块进行划分，但有时候功能复杂就需要合作进行。合作的方法就是大家在QQ 群里吼一声，然后当面去沟通。这是一种比较高效的方法。
不过，多人分工也有一种隐患——产品经理对于自己的模块了如指掌，但该模块对于其他产品经理来说就是一个“黑匣子”。每个人都需要掌握自己负责的模块的整个逻辑，很难有精力去关注其他人的一些产品逻辑。如果沟通不密切，很容易出现对于别人的产品功能不了解的情况。所以在分工之上，还需要有更高级别的产品经理去关注全局，考虑每个功能的体验。
同时，产品经理需要有极强的积极性，培养自己对于需求的思考习惯，尽快发现需求本质及需要提前准备的资源，与其他产品经理常常互通信息，一起制定最佳的计划和方案。不仅如此，产品经理在考虑自己的功能模块时，需要有全局观，思考这个功能对于整个产品的影响，并及时通过技术人员了解技术方案上的一些细节，及时了解相关的技术方案是否需要其他同事的支援，时刻与产品经理沟通，相关的功能是否有类似的方案可以借鉴，避免重复开发——重复开发不仅影响代码质量，而且损耗资源。
对于大团队来说，每个人的信息一致是至关重要的。产品经理作为功能的负责人，更应该保持信息渠道的通畅，及时与其他产品经理沟通，有必要时向上级汇报，并请求提供帮助。
在腾讯团队中，沟通的即时性和保持信息的一致性做得很不错，项目经理会第一时间发布项目的相关信息；对于重大的功能，产品经理则会发出邮件，每周按计划进行滚动，随时同步进展；开发相关人员则会定义某个时间为例会时间，随时沟通开发进展，及时暴露项目开发过程中的问题和遇到的难点；产品经理可以考虑加入对应的开发工程师例会，可以有效地了解开发进展，并能保持与开发工程师的沟通，快速地解决问题。
想要更好地沟通信息，还有一个好办法。平时在公司，因为工作时间需要专心工作，因此有时候无法找到时间及时了解一些信息，那就考虑和其他产品经理或者开发工程师们一起吃午饭吧。他们不仅很欢迎你加入，还会向你透露很多有价值的信息。一起吃午餐不仅可以培养革命友谊，还是相互了解的好机会。了解每个工程师、产品经理的性格和风格，有助于后续的沟通和合作；同时，利用轻松愉快的用餐时间，我会请教其他产品经理一些问题，他们都会各抒己见，这对个人的学习有非常大的帮助。
无论是小团队，还是亿级团队，沟通都是协同工作的关键因素。沟通可以让信息渠道畅通，有利于每个人都能得到最新的信息，可以同时推动项目前进；积极良好的沟通也可以增强每个人的战斗力，让工作变得有人情味，而不是冷冰冰的任务，每个人都能从中获得成就感。
不仅如此，上下级的沟通交流也可以非常有效地增强团队战斗力。在腾讯，每个人都可以直呼对方的英文ID，即便是老板也不例外。同时，假设你有紧急事务，可以发邮件、发QQ 消息、打电话给上级领导，都会尽快得到回复，不会太官僚化。这一习惯扫清了团队协作的一些障碍，让人印象深刻。
原文地址：http://www.itmmd.com/201412/236.html
标签：style blog http ar os sp strong on 数据
原文地址：http://www.cnblogs.com/cto-gougou/p/4172238.html
