前言
最近刚刚接手公司的产品部，为了快速提升在团队调整和协作效率，作为一个产品团队管理0经验的萌新，很幸运遇到了《腾讯方法》，在一段时间的内部工作流程优化后，团队的工作效率、部门的协作质量、项目推动都有了提升，特此记录。
这不是一篇具有真知灼见的文章，如果是想找完全正确的真理，现在我会建议你关闭这篇文章，如果只是想看一看一个不太成熟的新管理人的经历，可以继续向下翻阅，并诚挚邀请您给我留下一些小建议。
书概回顾
这本书从初创产品孵化、成熟产品转型、垂死产品复活三个生命周期的产品团队的工作方式进行了案例描述，描述了像腾讯这样的互联网时代王者，在孵化和推出面向移动互联网时代的战略级产品时，会面临哪些问题？这些问题会以何种形式浮现出来？又该如何解决这些问题？
腾讯游戏失败是团队内部对短期利益追逐，无法产出精品大作，距离公司预期距离较大，欲速则不达。团队重构后的核心架构：一个是产品高手， 一个是管理高手，同时，管理高手又是作为外部专家提供支持， 二者没有利益纠葛，只有共同目标。搭配起来 工作， 效率非常高，并且可以互相学习。 他们的思路非常清晰——成功 = 战略 × 团队。并构建不同阶段的战略目标：短期专注于休闲以积累用户、中期强化玩法深度和盈利性、长期定位于细分领域的大作，定位清晰，层次感非常强，彻底全面地满足顾客不同阶段的需求，
团队管理
1.选对人做对事
2.对于产品开发而言，对自己有足够高的要求，才能赢得对手的尊重，赢得话语权
3. “战略重点决定组织结构，战略重点的转移决定着组织结构的调整，组织结构制约着战略重点的实施。” 新架构的思路：扁平结构、化整为零、导入创业文化 ，以保证项目进展透明、权责清晰、提升组织效率。
4.当要变革一个团队时，原有的团队领导者一定会是最大的变革障碍，因为某种意义上，变革意味着对他过去的根本否定
5.做任何决定都要拿绩效和事实说话，才能服众
6.如何激励一个不断失败的团队？持续让它实现小成功，用一个个小成功建立自信心和凝聚力，然后再逐渐向更大的目标和任务 发起挑战，实现更大的成功。
7.领导者必须充分关注和重视对创造绩效的团队成员的管理，管理好他们才是真正的领导力，因为唯有如此，才能实现目标。
8.快速验证，价值驱动，团队自组织。如果团队领导者不去给团队施加压力，他们根本不知道自己有多少能量。
9.如何改变团队成员错误的意识和行为？一是领导者推动改变，二是让用户告诉他们什么是对的，让用户去影响他。
10.天美艺游工作室团队转型七步走Step 1：在对团队面临的问题和解决方案达成共识的基础上， 调动团队成员的精力和决心； Step 2： 制定并分享共同的目标和愿景； Step 3： 确定转型领导团队；Step 4：结果导向，价值驱动； Step 5： 小步快走，自上而下或先外围后中央； Step 6：将成功的实践提炼成机制和制度； Step 7：结合实际不断调整策略。
11.在几个专家的“ 鲶鱼效应” 带动和影响下，解决了团队整体能力不足的问题。
12.团队目标涣散 ，团队成员各怀心思 ，王峰却毫无察觉 ，说明他在领导能力上确有不足之处 。对于一个项目领导者来说 ，首要的一条就是统一团队成员的目标 ，建立共同的愿景和梦想 。让自己的梦想成为团队的梦想 ，让自己的目标成为团队的目标 。要统一团队成员的思想比较难（ 但也要去做 ） ，但统一团队成员的目标还是有各种思路和方法的 。唯有如此 ，才有可能真正开发出成功的产品。
13.真正有效的团队管理要实现 ：1 . 让每一个团队成员具有主人翁精神 ；2 . 让每一位团队成员具有全局视野 ；3 . 让每一位团队成员具有对产品的极致追求 。 简而言之 ， 就是打造具有产品经理精神的团队文化 ， 每一个员工都有站在产品总经理角度思考问题的习惯和行为表现 。
14.通过引入故事墙，将项目信息完全透明和可视化，团队成员每天经过就可以很清楚地看到整个项目的进度，每个任务要实现的 功能， 以及项目的瓶颈和问题。
15.传统瀑布式开发注定要产生大量无用功能的开发，同时传统沟通方式极容易产生误解 与冲突，相互推脱责任， 大量烦琐的需求文档让团队疲于应付，你再有本事又有何用？ 应付了事是普遍心态。方案：以快速开发、快速验证、快速修正的迭代式开发代替瀑布 式 开发，同时以面对面的高效沟通替代传统沟通方式。
16.麻省理工学院媒体实验室研究发现，面对面沟通交流越频繁的团队，创新能力越强。 因此，应该在团队内部建立起一些机制，促进团队成员之间的相互交流、沟通与碰撞，让各种思路与想法畅通地在团队内部流动。
产品方向
1.新产品最大的风险在于“价值假设”和“增长假设”
2.跟随用户就是创新，不要求绝对原创，但一定要比所有的产品都要更好一些，最好地满足用户需求本身就是创新。
3.让产品尽快见到用户，才是真正有效的快速验证。相对而言，用户更愿意对半成品或相对初级的产品发表意见，因为他们会觉得 自己的意见很重要，会觉得你就是找他们来提意见的， 他们的意见能够改变现状……
4.腾讯内部有一句名言：一切 以用户价值为依归。腾讯的绝大多数产品都会被放到公司内部平台供全体成员试用，在整个试用过程中， 产品开发团队会收到很多有独到见地的改进建议。
5.对于产品开发人员来说， 最大的误区就是只从专业角度看产品，只凭自己的喜好做产品。这些都是最低级的错误，但又似乎是 产品经理 的“ 胎记”，是最容易犯的错误。能在多长时间内将自己清空、归零成用户是衡量一个产品经理水平的最重要的标准。
6.产品经理切记：别小看细节， 它最容易大放异彩。 惊喜不在明处，全在细节。不注意不知道，一注意吓一跳， 这才叫惊喜。
7.产品经理切记：你的想法最多只是创意，用户需求才能真正诞生创新。
8.产品六脉神剑之天天兄弟奋斗记：a做到常人难以想象的尝试和重复次数 b激发全链条每一个环节的创造力 c人性 d每次犯错都是一次卖萌的机会 e对屌丝的极致关怀 f暴力拼图法与临时资源替代法
9.如何引导UI设计做出优秀的设计？去给他们大量的参考图
10.如何发现产品的问题？不要去凭空猜想，不要去做无效的研究， 更不要毫无主题和边界地去争论…… 发现产品问题只有一条， 那就是—— 去运行它， 然后观察，然后发现，然后持续改善。
11.新产品开发失败只有两种原因：一是运气不好，二是能力不足。 运气天注定，能力在自己。
12.1 在决定一个出现巨大问题的产品开发项目是否要继续的决策上 ，决策标准绝不是过去投入了多少精力 ，花费了多少人民币 ，而是要真正去找到问题的根源 ，而后再做系统 评估和总结梳理 ，最悲催的莫过于“ 不知道自己是怎么死的” 。
12.2.如果同类产品非常成功，就绝不是产品定位的问题 ，因为竞争产品已经验证过市场了，而一定是产品品质、产品逻辑、产品商业模式等方面出现了问题。
12. 3 . 对于新产品的评价 ，自作多情毫无意义，开发新产品绝不是给自己看自己玩自己评价的，产品品质高低与好坏由用户说了算 。
12.4 . 管理者的职责是打造出一个富有战斗力的团队，快速有效地达成目标，而不是 “努力 ” 但不出任何结果的团队 ，只认 “ 结果 ” ，不认 “ 努力 ” 。
13.在产品开发过程中，千万不要在低优先级的事项上做过多的纠缠，这要通过敏捷的方法实现辨识，让高优先级的事项自动浮现出来，并全力进行解决。
14.要求以更简洁清晰的方式描述需求，按“目标— 策略— 验证标准—用户故事— 界面草图— 流程图— 采集数据” 的模板描述需求， 在形式上结合“ 文字描述+ 流程描述+ 界面图 描述”。
15.在腾讯内部，决策无论大小，都要用数据说话，通过数据模型测算出转型风险，这是腾讯的决策习惯。
跨部门协作
1.所谓跨部门协作，在很大程度上就意味着有很多灰色地带， 这些灰色地带的工作谁做都可以。核心思路：主动推动、不急不躁、勇于吃亏、换位思考
在情绪化状态下，团队成员不会朝着解决问题的方向去思考问题，而是朝着抱怨、 愤恨的方向去想问题。 在这种状态下， 是没有办法解决任何问题的， 这时候最需要的就是让 团队成员的情绪平静下来。但在很多类似的情境下，我们常常发现，很多团队领导者也加入抱怨的队列，这将更难解决问题。团队领导者要时刻意识到自己的选择和行为对整个团队可能产生的影响，要时刻清醒自己的一言一行都可能对团队产生示范效应。 在整个团队处于情绪 化 的 情况下，领导者则必须清醒，朝着解决问题的方向去思考问题。
对于跨部门协作，其实原理很简单：只有考虑别人，别人才会考虑你；只有帮助别人，别人才会帮助你。 关键是谁能先迈出第一步，优秀的团队自然要做到积极主动，先迈出第一步。
2.产品前期尊重每一个角色的观点，美国著名管理学家切斯特· 巴纳德（ Chester I. Barnard） 认为，从具体决策的相对重要性来看，需要优先考虑的是企业高层做出的决策。但从决策的总体重要性来看，具有重大意义的不是企业高层的决定，而是企业内非 高层员工做出的决定。
3.稳定的迭代节奏，大大缩短会议时间，减少不必要的会议，把迭代计划会议从1天变为1小时，从每周一次，改为每两周一次， 每月就为团队节省近100 人/ 日的工作量。
落地应用
团队背景
该公司的研发资源对于产品覆盖来说是相对紧缺的，需求方众多，平衡各个需求方的不同声音和产品的长远发展，一直是产研团队的痛点。
除此以外，也存在一些大公司病，比如工作过度流程化、效率低下、大多数人进入疲软状态，对于缺陷经常出现推诿不敢承担，缺少owner精神等。
刚刚接手这样的团队时，很多朋友说，这不是一个配置非常好的团队，让我慎重选择。过往的工作经历告诉我，在不健全的环境里付出，往往我们能够收获更多，所以我还是决定挑战一下。以下从产品需求规划、研发流程、团队培养维度进行阐述。
产品需求规划
需求来源1：各业务、销售提出的日常性需求
资源消耗：产品每日3h+工作时间沟通，40%开发资源
工作方式：各部门基于个人视角会提出各种优化问题点，产品评估能够修改后，需求方提交工单，产研输出方案，修复问题。
分析及优化：该类需求往往为散点，多为产品表层的体验细节，不是公司的核心目标，但由于产品线多，该类需求会大量消耗产研资源，且无法形成势能，属于事倍功半型的需求。为了减少产品每日的精力过度分散，针对各部门建立定时沟通反馈的机制，非产品线上bug，则统一收集需求，并进行阶段性优先级排序，P0-P3分级处理；若线上bug，直接将需求转开发。后发现该类需求多为P2、P3类需求，即多为重要不紧急、不重要不紧急类型，将该类需求占用资源由40%调整为20%，优先处理对用户覆盖较大的问题、对用户转化影响的问题、核心流程体验不畅的问题。
需求来源2：对核心产品大的版本迭代
资源消耗：40%开发资源
跨部门沟通：之前的团队信奉在
需求来源3:高管层的临时性高优先级需求
资源消耗：10%开发资源；
需求来源4：团队自主发现的产品问题
资源消耗：10%开发资源；
研发流程
工作流程冗长，开发过程点对点沟通
3.开发团队
a 半年计划宣讲
b 产品上线后效果同步到开发【让开发认知事务项产出的商业价值，帮助思维上从执行端到参与端转换，这样有带来一个潜在效果是开发小哥开始主动就产品提升提出建议，在产品团队缺少技术背景时，这无疑是对产品团队的助力】
c bug反馈人直接和开发对接，培养owner精神【在产品和】
