互联网经验——项目管理
在最近十几年的互联网圈子里，若是把产品比作一个小孩，那产品经理就是他妈，项目经理就是他的班主任。妈没法换，可老师带完这一批还有下一批，这就注定了项目经理永远只能奔跑在项目未结束或正开始的途中。

任何一个互联网项目从构思到落地，到完成，要确认的事项成千上百，项目经理都可谓是职场上的多面手，既要应付得老板，也要手刃得了开发，不仅要衔接好产品，还得关注用户体验设计。处理过程中稍有不慎，项目可能就会整体延期，而锅就一口，你不背谁背...

这次分享的既是项目管理中的一个方法： 构建闭环

何为“闭环”：

百度百科中将“ 闭环 ”同时也定义为“ 反馈控制系统 ”，我认为其中有个特别重要的此—— “反馈”

回到我们实际的工作场景中，无论是主动推动的一件事情，还是简单的一个询问，亦或仅是微信里的一条信息，都会希望对方给予一个反馈，而这就是最简单的闭环了。

总结为三点即为 ”凡事有交代，件件有着落，事事有回音“

项目管理中的闭环

在一些初创公司或者没有流程系统的中小型公司，在项目和工作中，很多信息的获取或同步，都会相对被动。举几个详细的场景：

场景原型：

场景1：

开发的前后台联调，大家一开始各做各的事情，到该联调的时候，总会希望别人来主动发起，或者说自己的部分写完了，就一声不吭继续做其他事情了；

场景2：

产品经理安排好了一个需求评审会，会议结束后，对应需求或者模块人员也落实了，后来却要一再催促开发，才能给出WBS（工作分解结构（Work Breakdown Structure））和工作量评估；而在项目推进的过程中，时常会要求按时反馈才进度，但开发却总是延迟，更甚者直接就忘记了；

场景3：

提出了一个设计需求，安排了具体的负责人，也明确了设计时间，但是到了时间节点的时候，还需要去问设计师，是否已经完成；

场景4：

需求在开发实现过程中，好像还挺顺利的，但一到验收环境，就问题频出，导致上线时间延后，甚至影响以前已开发的功能；

场景5：

当前版本开始测试了，但每天并不知道测试的具体进度，也不知道是否有什么问题，发现的问题也不知道什么时候能解决后上线；

场景6：

老板交代了一件事，比如写总结或分析报告，自己写完了，也发给了老板，但老板可能好多天后才想起来，而且有些还会问，你的报告什么时候能写完发给他？

场景7：

一件老板比较关心的事情，安排自己去处理，事情比较复杂或者比较费时，短时间内给不了结论或者反馈，恰是这种情况，老板因为关心，又来催问，想了解事情的进展。

诸如以上的场景，大家是否都或多或少地经历过？而这些场景，在项目管理过程中，时常会出现。概括起来说，这些场景，都可以归类为 "没有形成较好的闭环和较好的反馈" 。

那么问题来了，我们在辅助、引导和管理一个项目时，哪些是可以形成闭环的呢？这里不去说项目的五大过程管理组，也不去讲PDCA闭环管理，因为这些本身就是很好的闭环， 这里要谈的，更多是聚焦具体团队可以形成的闭环模型。

闭环模型

产品经理：

一个需求的提出，不管落实到功能还是想法，不管是设计还是开发，都需要形成这个 闭环 ：

项目经理有没有落实下去，落实的是谁在做，什么时候做，什么时候做完，什么时候可以验收，验收完，转给测试验证，这个需求最终实现，这就是一个完整的闭环。

里面其实是有一个大闭环和一个小闭环：

小闭环： 需求方提的需求，产品经理是否有落实下去，你确认了；

大闭环： 什么时候做，什么时候做完，什么时候验收，然后到验收完。

模型中标注颜色的部分，是在负责具体需求时，比较容易忽略的。项目过程中，有很多需求方在提出需求后，就基本上不管了，也不专注去验收的。

开发： 接到一个需求任务，从需求的评审开始，到方案设计，编码，联调，自测，转验收，bug解决，需求完善，周知设计或者产品经理验收，才算一个完整的闭环。同样，有不少同学可能只专注于自己的编码和自测，并没有去同步或者及时同步到相关人验收。

设计： 设计的同学接到需求，制作完成，周知到下一个环节的负责人，然后在版本里面验收完效果，才算一个完整的闭环。这点在以往的一些项目中，是很弱的一个环节，经常会在验收版本的时候才发现，版本的实现效果和设计的效果差别很大，很明显就是验收的环境，没有把设计纳入到验收的闭环里面来。

测试： 从需求评审开始，用例设计，版本的测试，bug的回归，版本质量风险的评估、总结，最后到项目报告的反馈，形成完整的闭环。而实际测试的过程中，因为周期往往比较长，或多或少会缺少中间测试环节或测试进度的反馈，也会缺少版本质量风险的评估。

综合以上闭环模型来看，每个团队或多或少都会出现某个环节的遗漏，或者反馈不到位的地方，而这些情况累计起来，对项目的推进，是会有很大的影响的。作为项目经理，不仅仅只是在项目启动阶段，规划阶段做好了，就万事大吉了，而应该是把更多的精力投入在执行和监控阶段。

我们每天可能75%的时间都在沟通，对于项目中的很多事情， 我们坚持“相信团队，但必须核实”的原则。

检查项目具体事项，小团队可能还好，晨会或者发发邮件聊聊天，就都了解清楚了；一旦团队规模大起来，在成员很多的情况下，什么事情都要一一去审查的话，那会累到不行，而且一天下来，基本上没什么收获。审查的时间耗掉太多，基本上也就没留下什么时间去思考和解决项目中可能存在的问题；没有时间去汇总、整合项目的有效信息同步给主要干系人，这样势必会导致一个恶性循环。

所以，作为项目经理，我更认为应让以上各闭环模型都形成真正的闭环，形成良性的闭环，这样不仅可以释放大量的精力，让自己轻松很多，还会事半功倍。

那么在项目管理的过程中，如何更好地让各个环节都形成有效的闭环呢：

1.规范流程

流程是为了效率服务的。通过规范项目开发流程，把大大小小的闭环串联起来，形成项目的大闭环，可以让团队成员清楚地知道，每个团队在哪个阶段需要做什么事情。

下图是我们在项目过程中总结提炼的一个双闭环的验收流程，从多个项目的实际反馈来看，的确有比较好的效果。每个需求完成后，开发在自测期间，涉及到设计资源的验收，就及时周知设计负责人一起验收，可以很好地避免需求转策划验收时，出现大量的设计效果方面的问题。

2.建立规则

光有流程还不够，因为流程并不具备很好的约束力。因此建立规则的目的很简单，就是希望在有限的时间内，获得有效的反馈，让团队互相形成一种约束力。

比如，流程走到需求评审完，该输出WBS任务分解和具体的工作量时，提醒过一次没有按时输出，可以豁免，后面还没有按约定时间输出，就要有相应的惩罚措施了；

同样，比如设计完成时需确定且及时告知下个环节的负责人，提醒过一两次之后，还是没有按时，也需有惩罚；

产品没有按时体验和验收需求或版本的，也要有惩罚措施。

建立很基本的有效反馈机制，更深层次的目的是释放项目经理，不用事无巨细地去问，以此形成积极主动且有效的反馈机制。

但有一个前提，项目经理在定这些规则时，一定是要和团队达成共识，切忌单方面去制定某种规则，要不然，很容易适得其反。

3.用好工具

工具可以帮助我们在管理的过程中，尽可能自动化。

项目经理要尽可能让能自动化的都自动化，让各个环节的闭环在工具中生根发芽，潜移默化，形成有效的自运转，这样才能进一步地释放自己的精力。

例如，TAPD就是一款非常强大的工具，我们可以设定需求管理流程和缺陷管理流程，这可以帮助我们将需求管理和缺陷管理的流转全部自动化，起到事半功倍的效果；可以让项目的整个过程和信息更加透明化；可以让团队成员彼此都清楚知道上下游环节的负责人；还可以起到互相监督的作用。

工具自动化还有另外的优势：不用什么事情都去问一遍，可以很大程度上减少沟通成本。

比如：我们在明确设计完成时，要在TAPD需求单的评论里面，备注好资源输出的路径（svn地址），然后转给具体负责的开发人员，同时，在群里面艾特对应的负责人。

这样等到开发负责人要用这个资源的时候，就不用再来问术负责设计的同学了。如果开发人员和美术人员一对一，那去问一遍倒还好，但实际在项目进程中，往往的1个设计师对多个开发人员，而且在当前快节奏的情况下，都是多个系统并行走的，也对效率有更高的要求。

试想，如果开发过程中，要反复沟通美术资源在哪里，设计师恐怕大部分时间要去应对问答了。而且开发人员时常找不到所需要的资源，也会严重影响开发进度。


4、积极主动

流程，规则，工具，如果说是形成有效闭环和反馈的客观因素， 那么积极主动就是形成闭环的主观因素，是催化剂。

很多时候都是多线程的工作状态，一个人可能会同时处理很多任务，这也涉及到多任务的管理。

因此在很多时候，需要更积极，更主动地反馈，让下个环节的负责人清楚知道当前的情况，以便提前做好预判。

此外，积极主动，还可以确保很多有必要的反馈，尤其是向上管理，比如领导交办可能是一个需要很长时间周期完成的工作，那么中间过程或者中间结论，要及时地进行反馈，占据主动权，避免领导来主动询问。所以，无论是作为项目经理，还是项目成员，都应要积极主动去同步或者获取信息。请主动出击！

细细分析和挖掘上述闭环模型，我们会发现，在跟进、落实每项工作和事情时，我们彼此都不仅仅是完成事情本身，更需要心里装着与此相关的或同事或团队或整个项目的目标；在跟进、落实每件事情时，我们彼此不仅仅是做事情时积极主动，更需要养成“凡事有交代，件件有着落，事事有回音”。 因此，闭环思维强调的不仅仅是责任心，进取心，更强调的是团队间的合作，配合的成熟度还有团队间的信任，同时，还有彼此间的契约精神。
国内互联网公司的产品经理都在做什么?

大厂数据产品民工来回答啦，先说一下我的背景，我是通过0经验自学转行产品经理的，曾经在某互联网大厂做了2年产品经理，都说产品是互联网行业门槛最低的岗位？人人都是产品经理？产品钱多事少好摸鱼？活都是开发干，产出都是产品拿？？？

No，No，No本厂妹今天现身说法

想象中的产品工作

经过详细的数据分析，用户调研需求分析，最终归纳总结n个用户诉求，并在仔细评估价值后产出产品需求，拉通各个业务方和合作方，大家一拍即合，迅速推进

实际中的产品工作

十个需求有八个都是老板拍脑袋要做的，不但要说服自己做，还要做好，想出合理的价值，经过和合作方180轮撕逼，艰难的推进。进度慢了，上线效果不好了，都要被老板质疑“你能力不行”

想象中的产品工作

研发、测试、运营都是你的小弟，作为项目的核心成员，一声令下，大家心往一处想，力往一处使，互相补位，把需求完善的尽善尽美，做的又快又好

实际中的产品工作

项目延期，找产品；功能不好用，找产品；有用户咨询，找产品；出了线上问题，都怪产品。把产品杀了祭天一切问题就可以迎刃而解了

想象中的产品工作

每天做做数据分析，写写文档，喝喝咖啡，催项目成员进度，聊聊微信，完美的一天就过去了

实际中的产品工作

一天八个会，开会十小时，各个业务方轮番撕逼，你有你的排期，我有我的优先级，谁也不服谁，谁也不松口。夜深人静终于可以抹黑写个需求，又要被“灭负’’，只能默默背着电脑回家奋战到黎明

想象中的产品工作

汇报时项目数据表现超出预期，价值明确，老板器重，升职加薪一路升级

实际中的产品工作

一年十个项目，有八个石沉大海，另外两个一堆故障，各种合作方怨声载道，觉得产品的存在就是劳民伤财。侥幸有一个项目出了成果，也是老板指挥的好，开发架构设计的好，运营的策略指定的好。产品？产品一个传话筒，能有什么用？

哈哈，听了上面的这些，如果觉得可以接受，那恭喜，你是真正的产品人，一颗强心脏，就是成为产品最重要的要素。不用紧张，只是跟风自黑，工作中，想象中和实际上提到的场景都会遇到。随着产品能力越来越强，经验越来越丰富，越来越可以驾轻就熟的拉通各方，生活就会越来越向想象中前行啦（知道怎么处理事情处理关系，就不至于夜深人静气的蒙在被窝里哭了）

 除了以上的「跟风自嘲」外对于想转行产品经理的小白我也有几个建议想给到大家，比如从0到1培养对产品的基本认知就是非常重要的~

像我的日常会负责产品三个版本的迭代和优化，经历了产品设计/开发/测试/上线的全流程，每天属于精分状态来回切换：

1.版本1处于上线阶段：线上需求跟进一需求池整理一数据&反馈回归一小版本优化

2.版本2处于开发&测试阶段：排期一跟RD沟通产品细节一文案和埋点梳理

3.版本3处于设计阶段：需求调研—MRD撰写一跟交互沟通产品细节一需求评审

 作为一个老社恐本人，我的工作需要跟n个角色对接，比如跟研发/设计/运营/测试/客服/产品同学沟通需求，刚开始我很不适应也出现过一些社死现象，到现在能够很好地接招和沟通。我发现做好本职工作的同时，80%的工作都在对接，这是我经常面对的2个情况以及我的浅浅思考

RD说这个需求我做不了

1）明确背后真正的意思：真的做不了/能做不想做

2）解读现象的根本原因：技术/排期/时间成本/开发/难度/预期/收益

3）被argue 时快速给出解决方案

4）本质上如何让RD 多做：维护关系/利益共同体

交互说：这个需求我觉得这样设计更好：

1）认可想法怎么回答

2）不认可想法怎么回答

当然不被argue的前提还是要提升自己的产品能力，所以自己还有很多提升空间吧

 不足之处：

1）保持穷尽思维：写 MRD时逻辑要穷尽且互斥，想到最完全的解决方案

2）排定事情优先级：按照对接角色和跟进版本把每周对要做的事情排列出来制作成表格

3）做好项目管理：需求的推动需要多重角色的配合，根据自己的ddl把对接角色的ddl排出，以免自己的事情延期

4）汇报关键节点：定期反馈重要节点的状态，周期长的需求及时反馈中间态以防止想法偏移

其实说了这么多最主要的是想和大家说，不要神化任何一个工作。资本家不是傻子，不会付出远高于你工作价值的工资聘请你来工作。生活也总是有苦有乐的，永远在走上坡路，才是最重要的~

互联网公司里有没有PMO,或者相近的角色？
互联网公司有PMO
在“2014首届中国互联网企业项目管理发展论坛”上：

1、网易杭州研究院项目管理部（PMO）总监曹智清女士

2、京东研发部项目管理办公室总监（PMO）：蔡德辉先生

3、北京联众互动网络股份有限公司管理中心总监（PMO）：陈雄越先生

4、宜信公司技术部总监助理兼项目管理部部门经理（PMO）：顾滢滢女士

5、拓维信息系统股份有限公司PMO部门经理：袁晓慧女士

6、新浪微博项目管理部（PMO）项目管理经理：杜炎先生

7、支付宝项目管理办公室（PMO）项目管理专家：叶东先生

8、汽车之家网项目管理部经理（PMO）：张晓丽女士
他们分别就互联网公司项目管理的发展和PMO的设立、运营与管理以及定位与职责做深入的交流分享。如果你没有参加的话，你可以参加今年5月28-29日在北京召开的“第五届中国项目管理办公室(PMO)发展大会 暨2016年度中国10大优秀PMO总监评选颁奖盛典”，或者参加8月27-28日在北京召开的2016第二届中国互联网企业项目管理发展论坛.

中国互联网公司目前的情形略有不同，更多的采用敏捷型项目管理方式（Kanban/Scrum/XP等），采用的是全功能小团队的方式敏捷开发。运行scrum策略的公司项目经理叫做scrum master也就是敏捷教练，与传统项目经理的职责和工作方式都有不同（详细了解，可以百度）。全功能团队侧重的是更加以用户体验为重的快速开发，端到端优化的可能性极小。
在这样的情况下，PMO存在的目的就不是很大，而且往往因为成本的原因，连scrum master都要复用到多个项目。
网络公司的岗位职责
网络优化岗位职责：
1. 负责集团网络的安全监控和日常管理
2. 保证集团网络安全、稳定网络中出现的问题 ，提出解决方案并组织实施
3. 学习网络新技术，优化和扩展网络功能
4. 完成公司领导交办的其他任务




终端维护岗位职责
1. 接待并处理终端用户报告的计算机及网络故障
2. 解答用户提出的与终端、网络相关的问题
3. 为终端用户计算机操作系统、应用软件和网络通信及其他硬件设备安装、调试提供服务
4. 完成领导交办的其他工作


软件开发项目组长岗位职责：
1. 负责制订软件开发项目的计划，实施整个项目的管理；
2. 参与项目需求分析, 研究项目技术细节，进行系统框架和核心模块的详细设计及规划；
3. 根据新项目开发进度和任务分配，开发相应的软件模块；根据需要及时修改完善；
4. 研究项目技术细节；完成项目初始至终结的全部技术跟踪协调工作
5. 按照项目计划，按时按量保质完成项目编码、文档及测试工作
6. 参与客户沟通、项目需求调研分析并维持良好的客户关系；
7. 解决项目开发过程中一些突发的技术难题，跟踪开发团队的开发进度
8. 完成公司领导交办的其他工作

软件工程岗位职责：
1. 参与项目需求分析, 研究项目技术细节，进行系统框架和核心模块的详细设计；编写相应的技术文档；
2. 根据新项目开发进度和任务分配，开发相应的软件模块；根据需要及时修改、完善软件；
3. 根据公司要求规范，编写相应的技术文档；编制项目文档、记录质量测试结果
4. 研究项目技术细节；完成项目初始至终结的全部技术跟踪协调工作
5. 根据开发进度和任务分解完成软件编码工作，配合测试工程师进行软件测试工作；
6. 参与客户沟通、项目需求调研分析并维持良好的客户关系；编写需求分析报告。
7. 完成公司领导交办的其他工作

网站美工岗位职责：

1、 负责网站网页设计，根据用户要求进行网页的创意设计；

2、 负责网站网页制作，配合公司网站的需要制作网页；

3、 配合网站编辑，在需要的时候协助网站编辑进行页面修改工作，根据设计稿，进行页面切割制作。

4、 完成公司领导交办的其他工作