以下是根据我的工作做的，觉得适用于各行各业的部分归纳等，分篇连载。为免泄露公司机密，仅个人归纳概括，希望对各位工作有借鉴作用：
一、工作流程：
产品规划：产品不是一个功能的堆砌，一个好的产品要有规划，所以负责各版块的产品经理需要对其版块有一个整体的规划，一般来说产品经理需要为其版块准备一个roadmap，把之后几个版本的大致发展方向、思路等等写进去（具体格式参见下集中ppt部分）
产品诞生：需求设想（老板需求、产品经理提的需求、规划等）---产品组内部评审（用市场数据、用户反馈、竞品分析等作为依据，争取同事和上级支持；一般会经过两轮，一轮是跟自己老板、组长、总监等PK，一轮是在整个产品组内提出想法跟其他同学碰撞，确定优先级等等；这轮主要用ppt或者手绘草图等论述即可）---内部PK通过，产品经理输出需求文档（产品的骨架、经脉分布、皮肤组成等等都要涵盖）---交互设计（即产品的基础模样）---交互图发产品组内，大家讨论需不需要继续优化---视觉设计（外面用户看起来的样子）---开发评审（跟开发兄弟们PK，以及投入人力、时间的评估，恩一个产品的诞生经过多次PK）---投入开发---开发完成，进入测试验收---debug（测试同学和产品同学体验开发完成的版本，发现bug，开发同学修复）---回归测试（多次修复以后的最终版本再次投入测试）---测试通过，灰度发布（选择部分用户，小范围发布）---收集灰度情况（如用户反馈，数据等等），作出优化等---如无问题，则全量发布（全体外网用户可体验）---全量后数据及用户反馈跟进，作下一版本新需求准备（回到第一个环节，重复全部流程）
个人认为腾讯产品诞生的流程值得不同行业的朋友借鉴。整个流程有几大好处：
1、产品经理负责制---既民主又集中：套用党的话，产品经理负责制确实发挥了民主又集中的优势。一个需求虽然经过多个流程，但是从第一步到最后，都是由产品经理一人负责，他必须介入其中每一个环节，主导整个需求，可谓集中；同时的确也很民主，首先在需求诞生上，产品经理必须说服上级、同级，而且在这个PK的过程中基本上需求会有很多改动，大家都会指指点点，一定程度上优化了需求；其次在后面的环节中，由于产品经理在公司层级上并不领导设计和开发同学，所以开发和设计同学对需求可以畅所欲言，若一直说服不了他们，他们可以直接就不做这个需求（恩就是这么傲娇）；到最后测试验收阶段，测试同学也能对产品的缺陷提出意见。所以总体来说，也兼顾了民主（当然有时候也还是以贯彻老板意志为主，但的确是少数情况）；
2、专业的人做专业的事：整个流程上每个环节都是最专业的人去负责，确保了当前环节输出的质量；同时流程管理还有一个项目经理，项目经理会协助产品经理去推动产品的进程，排优先级及人力投入等等；
3、产品完成质量较高：由于多个环节把关，所以最后产品的设计、体验及bug情况都会比较高质量。由于本人大学有过创业团队做产品的经验，相比之下，这样流程下的产品质量的确要比创业团队快速做出来的产品质量要高很多；
4、时间效率依然很高：不要以为这样一个过程很漫长，其实时间是十分紧凑的。相比起很多传统企业的拖沓，由于产品经理、项目经理、以及下一个环节同学共同督促，每个环节上的同学都不敢拖沓，每一个人都要为整体进度负责。而且在每个环节的同学投入工作之前都有评审环节，需要评估工作量和排期，这样就有了硬性时间规定，如果超过时间未能完成是要向产品经理以及项目经理解释原因的。因此时间节奏也能控制在科学高效的水平（所以我们常常加班！！！！）
当然弊端也很明显：
1、不便于快速尝试：虽然说腾讯的迭代还是很迅速很密集，但是相比起以前创业时候做产品，还是较慢了点，毕竟互联网拼的就是速度。创业团队能在两三天内完成一个小功能的策划到上线工作，然后马上看用户反馈再优化，而腾讯这样体制下的除了极小的功能外最快也得两周才能走完流程，反应还是不够迅速；
2、不便于集中力量尝试大胆的想法：大胆的创新一般来说绝大部分人是无法接受的，所以在走这个流程的时候很容易被毙掉；
总的来说，腾讯的产品流程适合于打造精品，出产的产品即使不是精品，至少也是合格的产品；但不一定合适做一个大胆的产品。所以一般来说腾讯的产品，大家用起来基本不会有太多疑惑，体验基本流畅，中间也极少出现bug。但很难有给大家眼前一亮，哗的一声，离经叛道却又新奇有趣的感觉。至于对该流程更详细的优缺点和优化分析，敬请关注以后的文章；
二、工作沟通：
1、周知制度：上面所提到的流程，每个流程的成果都需要输出邮件周知，包括：需求预审（与会人员、需求内容、地点时间等）、需求评审纪要（评审结果、排期、人力等）、测试用例（整个产品、功能所有需要测试的点）、测试结果、灰度上线周知（就是告诉大家我这功能要灰度发布了，大家快用用看）、全量周知（产品全面放开啦，外面的用户都可以用啦）；
周知制度有效地让组内同学了解产品进展情况，避免各扫门前雪；而且每个环节都留下了依据，方便出了问题后追踪。
2、评审会：需求评审会，也是PK很厉害的地方，开发、测试、产品同学济济一堂，负责的产品经理先根据需求文档和设计稿来讲述自己的需求，要做成什么样子，然后开发同学等会挑战，细节另表，反正就是诸如臣妾办不到或者这个需要时间研究研究等等。唇枪舌剑十分激烈（当然其实提早跟开发沟通好需求的话，那么会议上就不会有太多PK），但正因为激烈，所以大家都对需求有深入的理解，确保了执行；
3、晨会及周会：晨会是每天产品组内及项目组内的会议，各自汇报其负责工作的进度、昨天工作以及今天工作，和暴露问题，一起想办法解决或争取资源解决。产品组内晨会如：昨天工作重点：1、A板块工作2、B板块工作3、C板块工作；今天工作重点：、A板块工作2、B板块工作3、C板块工作； 如果有问题就说，x板块的y因z原因而如何如何了（描述问题），现在需要如何如何解决（抛出自己大致的想法），如果能迅速确定就晨会上确定，不能迅速确定就会后讨论解决；
周会就是在产品、技术、设计组长、总监等boss面前，每个人讲述一下自己工作一周的进度以及负责板块、功能的情况（诸如数据、用户反馈等）和重要问题的暴露；并讲述下周工作的安排等；
以上的制度可以看出，腾讯很注意团队作战，重视团队内信息的及时互通
4、沟通工具：RTX
详细内容见明天文章：【绝对干货】腾讯工作个人归纳2，包括：rtx沟通注意事项、邮件写法、word文档格式、ppt示例及excel图表类型。
