二、开发过程
　　与上面1～7相对应相对应，现在我们开始讨论第2个部分：开发过程。开发过程是我们的产品从概念变成真正可贩卖的工业品中必不可少的神奇一步，是多种不同分工、不同专业背景的同学在一起协同工作的过程，很重要。后面会以如下的一个目录方式逐步讲解这里的细节：
　　1)项目的概念
　　2)项目组
　　#1 人(资源)
　　#2 流程(人和人之间如何协同)
　　3)PM在开发过程各个阶段中的作用
　　#1 需求阶段(需求方全体确认需求)
　　#2 开发阶段(开发团队集中开发阶段)
　　#3 测试阶段(质量检查的阶段)
　　#4 发布阶段(内测、灰度、正式发布等逐级发布阶段)
　　#5 发布后的阶段(效果跟踪的阶段)
　　下面会根据这样一个目录进行说明：
　　1)项目的概念
　　项目的概念相对简单，可以理解为一个话题或者主题，很多人为了同一个目标、同一个主题、同样的利益和愿景聚拢在一起形成了项目组。这一点和公司等任何组织的形成类似。
　　2)项目组
　　#1 人(资源)
　　项目组里有不同的人，一般来说，一个处于开发循环中的核心项目组包括了这样的一些人：产品经理、视觉设计人员、交互设计人员、开发人员(前端开发、后台开发)、测试人员、项目经理等。
　　所谓的开发循环中的核心项目组是指一个形成一个产品所需要的少(标准)的人力配置结构，当然一个更宽泛意义上的项目组还包括了很多很多其他角色：运营、渠道、运维等等等等;
　　这些角色在开发循环中(显然，不在循环中的时候某些角色还有自己的独立于项目组之外的工作)的主要职责是：
　　a. 视觉设计人员(视觉设计，你看到的几乎每一个优美的图案)
　　b. 交互设计人员(交互设计，你在使用产品过程中哪些举动可以获得反馈以及以什么形式获得什么样的反馈)
　　c. 开发人员(前端开发同学的成果是你拿到的终安装包、后端开发同学的成果则是在服务器端的逻辑，离你看起来很远，但实际上息息相关)
　　d. 测试人员(写过程序的同学都清楚，开发过程中难免会有各种各样的问题，有些很容易看出来，但有些要通过一定的测试手段和方式才能找出)
　　e. 项目经理(成熟稳健的项目经理对一个团队来说非常重要，人力资源在项目中的保证和调配、确保项目中涉及的各流程的顺利运行，以及处理好项目组内成员及其分别的外部支援团队与项目组之间的关系，这些是项目经理工作的内容，所以你看到了与项目经理良好的互动和项目配合对PM的工作会有很大的帮助)
　　##题外话一下，项目经理的英文 Program Manager，产品经理的英文 Product Manager，所以你看到两者如果英文缩写的话会很像，因此不同的公司都会想办法在英文名上对这两者进行区分，在腾讯，公司制度上项目经理缩写为PM，而产品经理缩写为PDM，但实际上不论是在行业内还是在公司内，大家还是总是喜欢叫产品经理为PM。所以以下我会继续这样写。
　　#2 流程
　　互联网产品的一个典型的项目组内环形开发流程是这样的：
　　需求的撰写和定稿--》交互设计和视觉设计--》开发--》测试--》发布--》新的需求的撰写和定稿……
　　##所以你看到了，需求阶段是整个环形开发的起点，因此当你综合考虑PM的职责和他在开发流程中这样特殊的位置时，会明白他是很不容易的，有很多事情需要他来处理和承担责任(背黑锅而受到指责什么的……所以新手特别是毕业生产品经理是很艰难的，类比导演专业一毕业带摄制组出去拍摄，艰难程度可想而知，因此对于新手，在你从业的前半年到一年的时间是需要准备好随时接受来自项目组内外的压力，这里冷暖自知了，后第3部分心得体会和大家分享一点点)
　　那个循环开发流程只是说项目组内需要一同经历的流程，也是说为了协调大家各种角色的时间、更好的进行协同工作所需要的循环流程，但实际上项目组内的部分同学，除了这个流程以外，在这里的项目组里每天每周都还有无数其他的流程要走。与项目相关的，比如PM在自己的组内有需求评审的流程、比如交互设计师和视觉设计师分别在自己的视觉/交互组内都有各自的评审流程;
　　3)PM在开发过程中各个环节中的作用
　　#1 需求阶段
　　#1.1 加工从各个需求渠道过来的需求、撰写需求的部分不说了，上面已经讲到了
　　#1.2 带着写好的需求文档经过需求评审的流程，并根据评审的建议或意见进行修改，直到达成一个绝大多数人都能够认可的需求;
　　#1.3 和交互设计师深入交流，不要只说你要什么效果，而要全面的讲讲为什么要这样做，你达成一个什么样的目的，这样可以更好的借助交互设计师的专业知识，可以提供给你和他更开放的思路一起想出可能原先想都想不到的更好的实现方案。
　　## 题外话一下，如果你所在的公司和部门在你所在的项目中提供了专职的专业交互设计师，那么建议在写需求文档的时候可以使用一些低保真的原型工具(低保真!)，而不是Axure因为这样会限制你和交互设计师、以及在需求评审阶段的每一个人的思维，这不是你想要的效果，所以，试试低保真的原型图吧
　　#1.4 和视觉设计师深入交流，不要说你想到哪里用什么颜色，同样，尽量说说你想到达到什么样的效果，至于配色什么的交给视觉设计师吧
　　以上1.1～1.4的部分才是一个完整的需求方确定需求的部分。
　　#2 开发阶段
　　#2.1在问题出现时权衡取舍、做出决策
　　开发过程中，随时会遇到概念设计阶段想不到的新状况，比如开发同学开发过程中发现有的地方不好处理、或者有的地方有两种以上的实现方案但是都有优缺点、或者某些地方要是真按照需求文档那样写会有一些潜在的风险，而以上的任何一种情况出现，都需要你，一个一线PM根据自己的经验和感觉、根据产品方向和核心价值进行权衡取舍后给出直接明确的答案：做或者不做、选A方案或是B方案、哪些损失是值得的。
　　#2.2 保证资源及时到位
　　#2.2.1 及时与某些项目资源输出方沟通
　　保证资源的到位是项目经理的职责，但实际上产品经理也要深入的参与其中。比如设计资源的到位情况，项目经理会保证在一个时间段内这个设计人力可以的属于这个项目组，但是在设计师动手之前你需要与之充分沟通，确保设计师与你向着相同的方向在努力;而当设计师输出设计资源以后，还要根据设计资源的质量(也是能否满足需要、是否契合PM希望达到的视觉气质等等)反复与设计师沟通，这个过程可长可短，而项目组后续的很多工作都有可能卡在这里，所以PM在这里也有责任保证资源的保质保量及时的输出。(##题外话，所以如何保质保量及时也是一个问题，这里涉及到“信任”和“妥协”，在第3部分心得分享的模块，会做进一步说明)
　　#2.2.2在项目过程中随时与项目资源输出放沟通
　　既然如上所说，开发过程中随时都会有新的问题，都会有项目内外部各级的同事领导体验反馈出问题，那么相应到，很多资源上的新需求，也是在项目过程中随时产生的，当有此类场景出线时，及时与相应的资源输出方(一般是交互和设计)进行快速有效的沟通非常必要。
　　#2.2.3 及时审核确认
　　每天项目都会有新的进展，每天都会有一些功能点完成、一些修复优化的点开发好，因此及时的审核确认也是PM工作的一部分，否则等到了测试阶段或者上线前的阶段再发现一些重大问题(或是与需求文档不一致的地方，你会发现这种事情时有发生)会造成很大的修复成本，时间、人力、项目组的信心、PM被信任的指数等等等等都有可能受到不同程度的伤害，因此这也是一个很重要的部分。
　　#2.3下一个循环也在同步的进行
　　移动互联网市场正在日新月异的迅猛变化，当前行业里雄厚的资本、杰出的人力资源都在以极快的速度向这个领域内聚集，因此腾讯MIG去年常说的一句话是“快比什么都重要”，所以具体到腾讯的模式下你会发现以两周或者三周为周期的项目组开发周期非常的普遍(记得一年多以前还有2个月多一个周期，那个时候PM还有喘口气的时间，这是题外话了)，因此作为一个PM，在一个正在进行中的项目周期中，你除了要做到上面的#2.2.1~2.2.3之外，还在同时为下一个项目周期做好准备，开始进行需求的撰写、评审以及其他的需求方流程。
　　#3 测试阶段
　　一般来说，在前期开发过程中，PM会进行高频率的产品自测，也是上面的#2.2.3所描述的部分，而到了真正的专业测试阶段，PM介入的比较少了，专业的测试人员测试出问题后大部分情况会直接反馈给开发同学，只有当有很多很多问题开发同学做不完需要PM排优先级的时候、或者是有些优化点优先级低但是可能意义非凡时，需要PM来做一些时间和效率上的取舍。(关于质量与效率等问题，在第3部分心得体会那里也会有提及)
　　#4 发布阶段
　　一般情况下，在经过了专业测试之后的产品差不多可以发布了，以后的过程可能不同的公司/部门都会有所不同，但大致上还是比较相似的：
　　#4.1找一小撮玩家进行测试
　　可以找公司内的同事，也可以招募一些公司外部的玩家用户测试，这一阶段的目的是找出专业测试也没有发现的重大问题(比如安卓平台上由于机型和系统的严重碎片化，很容易发生程序在某个特定机型上出一点小状况的事情)以及听听用户对某一个新feature是否会有比较大的正向或是负面的反应;
　　#4.2 灰度发布
　　还是基于万一出现问题时控制受众范围的考虑，一般我们会采用灰度发布的策略(当然这个策略的制定也是PM工作的一部分)，灰度策略制订时一般考虑两部分受众：新增用户、老版本用户。新增用户如何处理、什么比例;老版本用户如何处理、什么比例，这些问题一般通过PM的经验结合这款产品的用户规模、所在生命周期的某一特定阶段而制定。
　　#4.3全量发布
　　灰度发到是全量了，也有不经过灰度发布直接全量的情况。
　　#4.4其他
　　当然，以上#4.1～4.3才不会是我们工作的全部，还有很多很多的事情需要你来做，比如提前一周左右输出发布计划给所有相关部门和人员、发布前的各种各样的资料准备、发布前和各宣传相关的渠道的交流(微博、软文、、)、发布前准备好客服公告、新版本发布时安装包里帮助文件的更新、发布后信息知会给所有相关部门和人员等等等等。
　　#5 发布后的阶段
　　#5.1 效果跟踪
　　可以通过很多渠道直接或间接的获得用户反馈，比如论坛、微博、Q群、帮助社区、新闻(腾讯的产品不论好坏一般都会有或多或少的行业评论)、甚至家人、朋友、同事、领导等等等等。
　　#5.2 数据分析
　　毕竟只有血淋淋的数字才能直观的证明一项新功能/改动的正确性和效果，因此版本发布后的数据分析也是必不可少的工作。数据分析这里至少将包括规模数据的分析、和各主要特性的分析两大部分，当然用户及市场反馈的部分也是一个重要的可选项。
　　以上1)～3)整体上概要性的描述了开发环节中PM的主要作用，而实际工作中一般要处理的事情会更多一些。