加入百度时间不长，一直参与百度浏览器 iPhone 版的开发。开发组里每位同事会轮流负责新版本的管理工作，在试用期转正的1个月后，我承担了一次重大更新版本的项目管理工作。
这次重大更新版本从进入开发到 App Store 发布，将近2个月时间。本文是对这段经历的总结，包括管理经验、个人感受、个人思考。
一、管理经验
开发工作需要掌握一些工作技能，比如编程语言、开发框架、设计模式，并在项目排期内高效的输出。项目管理意味着从直接贡献者向一线经理人的转变，需要在工作技能、时间管理和工作理念方面做出改变。
项目管理所需的工作技能大多来自于平时的观察，比如工作邮件和其他项目管理者的工作方式。在分配开发任务时，我给自己分配相对较少的工作，开发工时约为负责直接开发工作的同事的一半，以便有足够的时间和精力执行项目管理的工作。
根据前人经验和自己的想法，我在项目管理中执行的例行工作包括：每日早晨通报、每日站会、项目周报、Code Review。
每个工作日早晨到公司，我会在开发同事的群中给大家发送消息，大致是如下的模版，“今天是开发第x天，有x个story需要进入待测试状态”，“今天是开发第x天，距离开发结束还剩x天”，“今天需要进入待测试状态的story共有x条，其中包含x条昨天需提测story”，“按原计划今天分功能测试结束，大家关注下面三件事情”，再视实际情况提醒大家需关注的事情。投入开发时，没有足够的时间精力关注项目整体状态。我希望为开发者服务，帮助他们处理其他杂乱的事务。
站会是团队的传统，每个工作日下午5:00会在白板前同步项目相关事情，所有项目相关的同事都会参加，包括PM、UE、RD、QA，确保所有同事了解当前项目进展，并商讨部分棘手问题的处理方案。
我在印象笔记中有个叫每日进展的笔记，站会时需要同步的事情都会事先做好记录。作为项目管理者，我会负责站会的主持，首先会同步白板上记录的昨天的问题，然后同步自己笔记中记录的问题。
站会不会像代码一样始终按照约定流程执行，随时会有同事抛出问题。如果该问题为今日重点同步问题，并且剩余的其他问题可以快速同步完，我会说明还剩几件小事，稍后会同步该问题。一般情况下，我会在白板中记录并引导大家同步该问题，自己不会太深入到讨论中，在合适的时机引导大家同步下一个问题。
站会后需要发送沟通纪要及进展邮件，站会邮件不会耗费太多精力，将站会前的记录、站会时的记录和相关问题的同步结果加以整理即可。
项目周报为每周结束后向经理发送的项目状态邮件。一周内发生的事情非常多，写好项目周报是件费力的事情。平时做好的记录对写周报有很大帮助，我会从站会邮件、笔记记录中摘抄内容并加以整理，删除一些不需要关注小问题，将部分相同主题的内容加以归类，按时间顺序加以描述，将一些需重点关注的问题突出展示。
平时能看到项目中存在一些问题，一个便是灰度和发版前夕的 bug 数量大爆发，从开发角度看存在开发质量不高的问题。我在项目管理的过程中想要推行的一个事情便是 Code Review，希望能在开发时便能解决潜在的问题，保证高质量的产出，而不是依赖后期 QA 的测试。我做了一些调研说明 Code Review 的好处和方法，以便说服各位同事参与其中。
Code Review 确实举行了几次，但是现在也已不再进行。第一次 Code Review 的报告人便是自己，我希望自己能做一个好的开始，报告前在白板上画好代码结构图，并准备好代码投影。我把自己编码时的思考与大家分享，并对大家的疑问作出解答，代码中存在的一个低级错误也被同事指出，还有同事还从线程的角度提出修改意见。还有一次是前辈做的 Code Review 分享，抱着学习的态度参加，了解到一些框架的作用和用法，并学到了一些编程技巧，我最近在写代码时也用到了该编程技巧。
执行项目管理时的时间分配不同于开发人员，大多数时候需要将注意力从代码转移到跟进项目状态上。
首先是需要与各种角色的同事沟通，以推进项目往前发展。在项目开发的不同阶段，需要面对的也不一样。项目初期协助 PM 同步需求，与 UX/UE 沟通交互与视觉排期，并督促按时输出。进入开发时关注各开发人员的开发状态，确保各个 story 按时开发完成。督促 QA 抓紧测试，沟通版本状态。
项目管理还有一项重要工作便是任务分配。项目管理的成功来自于各个直接贡献者的成功，需要让每个人各司其职，做其最擅长的事，才能取得最终的成功。我要关注的是大家都在做正确的事情，遇到问题时不会直接投入进去调研，而是转移给相应的负责人。
工作理念的转变是最重要的。开发是我擅长的工作方式，但是项目管理不允许只关注擅长的事情，要相信所有的同事，调动大家的力量来完成项目。
我在此次版本管理中遇到的最大挑战出现在开发阶段末期，并且让我狼狈不堪。一位同事离职，其名下不少 story 处于不可测的状态，结果我承担起了这部分 story 的开发工作。我评估后，在站会与大家保证在下周二站会时开发完成。但是开发压力和繁杂的项目管理，让我焦头烂额。在深入代码逻辑时还要响应其他同事对项目资源的请求、反馈项目状态、整理和分配任务。在此之后的许多项目跟进工作都是由我的经理完成的，当工作需要上级亲自完成，这是一种不好的信号。
项目前期，自我感觉管理的还不错，但是项目末期的时候却总是感觉心里没底，真是只能在挫折中收获经验了。印象深刻的是发灰度和 App Store 发版。发一次灰度，然后需要两三天观察，但是数据总不理想，修改后，再发一次灰度。每发一次灰度都需要几天时间，不断拖延发版的时间，跟PM、QA同步的时候，都不知道同步什么。大部分的沟通都是靠的前辈和经理，最后同步结果是数据正在好转、灰度环境存在限制和对线上的良好预期才得以发版。
二、个人感受
参加工作不久便体验了一把项目管理，非常感谢经理和同事的信任。这次项目管理初体验感受到许多，有让人沮丧的地方，更多的是收获。
在项目初期的时候非常紧张，会感到孤立无援。有一个让我非常感动的事情，我在工位上抓耳挠腮想着给大家分配开发任务，询问了一些同事的看法，然后好几位同事都聚到我工位上，给我意见和建议。也许对旁人而言这不算什么，对我来说却是受到了极大的鼓励，增强了信心。
主持站会也是一件特别的事情，需要在许多人的面前发言。刚开始的时候非常紧张，说话声音发抖，在白板上写字也紧张的弯弯曲曲，但是心里没有退缩的意思。平常注意到站会存在一些问题，经常几个人聚在一起讨论问题，大家的注意力并没有集中在同步项目状态上。在主持站会的时候，我会想一些办法解决这些问题。比如，当大家都到的时候，不会着急马上开始，稍等片刻再宣布站会，将大家注意力都转移到我身上。当有人私下讨论时，会看向讨论者的方向，或者适当加以提醒。特别需要避免的问题是自己在具体问题的讨论中陷入太深。
项目管理需要与许多人打交道，难免会起冲突。与别人沟通时，甚至直接受到恶言相向。这些都是不可避免的，虽然生气，但是会调整好自己情绪，站在别人的角度思考，并就事论事说服别人。
三、个人思考与总结
1、项目管理者的成功来自于团队直接贡献者的成功，需要让他们做最擅长的事，帮助他们成功。
2、冲突来源于对对方的不理解，要从对方的角度思考，消除对方顾虑才能达到自己目的。
3、遇到问题时思考分配任务给合适的人，而不是深入到具体工作内容中。
4、数据很重要，是作决策的依据。比如崩溃率数据直接影响到是否发布新版本。