小米信息部PMO leader陈静：给互联网人的项目管理第一课

陈静，现任小米集团信息部PMO leader，拥有600人规模部门PMO从0到1建设经验，10年软件、互联网行业项目管理从业经验。曾任职高德地图、世纪好未来等企业，已通过 PMP、ACP认证（敏捷）；熟悉瀑布及敏捷项目管理方法。擅长PMO组建、部门数字化运营规划及实施、跨部门沟通及协调组织。

以下内容为问答专场活动笔记整理，欢迎阅读转发。

我们来看一下今天要讲的内容吧：

1. 整体的项目管理的基本概念和方法论

2. 项目管理相关的职位大概有哪些
   

3. 怎么样快速的上手一个互联网的项目
   

4. 项目管理中，一些常用的管理模板和工具的使用
   

项目管理的概念

项目管理实际上是在有限资源的约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效的管理，也就是从项目立项到结项的全过程。

最重要的是以下几个点：计划、组织、指挥、协调、控制和评价，最后的目的是达到整体项目的目标和交付。

项目的分类：大概有以下几种，信息项目地管理、工程项目管理、投资项目管理

其实项目管理的范畴是多种多样的，生活中的很多事情都可以当做项目来管。今天是互联网人的课，所以我们讲信息项目地管理，其中主要会讲软件研发类的项目管理，它也是交付类项目的一种。

其实软件研发类的项目管理一共有两种大的类型框架，正所谓没有套路不成方圆，基本上我们的项目管理其实是有一套方法论的，接下来我们对方法论进行简介。

第一个套路PMBOK

PMBOK，我相信很多人都听过PMP这个证书。基本上，互联网行业或者是其他行业都是一样的，项目经理的从业者特别喜欢考一个证，就是PMP，这个是PMI（美国的项目管理协会）的证书，那么国内其实有高级集成的项目经理。软考其实也是有的，但是PMP证书的通用性比较强

PMBOK是比较权威的一套框架，它的第一版是由PMI组织了200多名的项目管理专家，历经四年完成。现在的最新版本是第六版，这个知识体系就构成了PMP考试的整体的基础。

说到PMBOK不得不提一下他的理论框架，它的框架其实很复杂。考过PMP的同学，一定知道这个书易读性不太好。它基本上包括五大过程组和十大知识领域，涵盖了项目管理的方方面面，国内软考的框架和PMBOK基本上相同，会有一定的个性化的部分，但是基本上的理念都是相通的。大家不用深究，如果要考PMP的话，网上会有很多的资料。今天我们就了解下框架就好了。

Pmbok的五大过程组。第一个就是启动的过程组，它主要用来设定整体的项目目标，项目要做什么；第二个是规划的过程组，设定整体的工作路线要怎么做；第三个执行过程组，就是干活儿；第四个监控的过程组主要用来测量项目绩效，整体干得怎么样；最后会有纠偏的一个工作，整个收尾的过程主要就是归档、总结和回顾。

这五大过程组基本上就是项目经理五个比较大的阶段，接下来会讲十个的知识领域。

十大知识领域

它基本上涵盖了项目管理的各个方面：第一个是整合的管理、第二个是范围相关的管理，然后是时间的管理、成本相关、质量相关、人力资源相关、沟通管理、风险、采购和干系人的管理。

国内的很多公司，在项目管理上还是参照PMBOK的框架和方法论的。但是实际上落地的每个公司都会不一样。所以在PMBOK里面也会说以上的过程和方法，大家视具体的情况，裁剪使用。

如果没有接触过PMBOK和项目管理的人员，听到了以上的两页会觉得，这个体系好大好复杂，都不知道怎么用。其实，Pmbok这本书里面也没有指导具体的项目实施到底应该怎么来做。

基本上互联网公司里面产品型的项目，套用PMBOK这种大的框架相对会比较少，因为互联网都是偏快速迭代的产品。但是有一些大的像比如说国企类、TOB、银行、传统的软件行业用PMBOK这套理论都会相对较多，接下来我给大家看一个实际的例子。

这是一张真实的工作截图。那么这张图片大家可以看到，上面会有工作的内容、占用的资源、整个工作拆的周期、工作量、右边这部分是整个项目的甘特图。

那么项目经理在进行项目整个进度控制上，主要依赖的就是这样一份表格。这个表格的制作其实就是基于PMBOK的理论上来进行资源和工作任务的划分和分配。上边的甘特图，我们可以直观的看到整个任务所占的周期、任务间的依赖以及它完成的情况。特别是很多大的工程类的项目里，我们可以看到很多甘特图贴在墙上。

今天的PMBOK，我们不会展开来讲，大家了解有这样一套知识体系和框架就可以了，如果想深入了解的话，其实就是搜关键字，PMBOK五大过程组和十大知识领域，其实大家能在网上看到非常详尽的资料。PMBOK就不详细来讲了，接下来我们会详细来讲一下敏捷。

第二个套路敏捷

敏捷其实是最近五六年，比较流行的一种方法论。

现在互联网公司都在讲敏捷或者往敏捷转型，我们今天主要介绍敏捷中的Scrum，其实敏捷包含很多方法论和方法。

Scrum也是国外比较流行，在国内应用最多的一个方法体系。实际上它包含了一系列的实践和预定于角色的过程，它也是一种流程、计划和模式，用于有效地开发软件。每次的冲刺，我们叫做Sprint，他大概是一个15到30天的周期。开发团队就会做一个软件的增量，每个sprint要实现的特性的就来自产品的backlog，随后我会讲解所有的名词。

其实敏捷里面比较重要的点，第一个就是时间和我们定了Sprint的周期之后，到期即发布。第二个就是说在整个sprint周期内，我们的需求是会被冻结的，就是需求列表是不允许随便更改的。但是实际上Sprint的周期非常短，大概一到两周之内。我们会把这个需求锁定，所以就避免了这种随时改需求，随时插需求，最后导致项目延期交付的这个问题。

这些都是基本概念，第一个如果讲到scream的话，你首先要了解三种角色。

第一个角色Po。产品的负责人，Product Owner就是维护整个产品需求列表的人，他代表了整个产品的价值，需求的导向。他们主要就是做需求优先级的排布、每个是需求不是都要选择、最后是给高层的整理和汇报以及对产品的验收，实际上他通常都是产品经理或者是产品相关的人员来担任的。在Scrum里我们叫PO。

第二个角色就是Scrum Master。我相信很多人都听过，敏捷教练。它就类似于敏捷中的项目经理，但是Scrum Master和传统意义中的项目经理有很大的区别。传统软件中，特别是比较大型的工程类软件中的项目经理，他实际上是一个强控制和分配任务的角色。但是在敏捷中更多的是一种教练或者是指导类型，他为整个的过程负责，他负责保障整个团队按Scrum运行，排出所有的困难，帮助更好的交付。所以他实际上很少去直接去指派任务。（让A干什么，让B干什么）

第三种角色就是开发的团队Team。PO和Scrum Master基本上都是一个人，那么team是由多个人组成的，Scrum 推荐的小团队，大约是五到九个人为一个Team比较好。Team的组成，大概是哪些人呢？其实都ok，比如说有开发、测试、或者是其他的人员，Team中的分界职责不是非常明显，也就是说测试也可以做一些产品或者文档类相关的工作，开发也可以去做一些测试的工作，如果你开发运维先做完的话，也可以帮其他的开发做一些工作，最终的目标是为了整Sprint的交付。所以，在Team中他们会有结对编程，还会有一些开发测试的角色互换都是可能的。我见过的团队里面，也有很多是全栈工程师，就是什么都可以做。

讲完了三种角色之后，我们讲三个工件。

第一个叫产品列表，英文是Product Backlog。它实际上就是你产品整体的高层需求。

在Scrum敏捷里有很多单独的需求，是用用户故事来写的——userstory。但是国内的很多企业，应用敏捷的时候，大家都觉得用story写需求有点别扭，它类似于从用户角度说：我作为一个什么，我希望实现什么，已达到什么样的效果。他的需求都是以这样的方式来写的，常常也会写卡片，有很多人非常不适应。所以国内的很多企业，都把它写成了需求列表的方式。产品列表也叫作Product Backlog，就是由PO来负责维护，他会跟高层、用户及各种各样的人去沟通，来维护整个产品的导向和方向。

第二个就叫做Sprint Backlog，它也叫Backlog，但是它只适用于Sprint，就是我们一个冲刺或者叫一个交付周期、一个迭代其实都可以。假设我们现在的一个迭代是三周，三周一交付，那么在这个Sprint中，我们应该交付哪些需求，哪些特性，就是由Sprint Backlog来决定的，基本上它也是在一个Sprint开始之前，由PO和Product Master整个团队定下来的，它要完成这个任务的清单。

第三个工件就是最后可交付的软件了。这个就不展开来讲，就是你Sprint完成之后，那么会有一个演示的过程，那就演示你这次Sprint到底完成了什么，有产品和PO来进行验收，最后可能会有上线等等这些后续的一些处理，但是要注意的是，不一定Sprint完成了就一定要上线，他只是完成一个要交付的产品。

接下来讲五个活动

第一个Sprint，其实是一个时间周期。通常在两周到一个月之间，实际上，这个只是经验值。一周的也OK，但是最长的我们建议不要超过一个月。定完Sprint之后，就尽量不要更改。

第二个计划会议，那么在每个Sprint之初由PO来讲解整个的需求，就是我们刚才讲到的，有一个工件叫Sprint Backlog，那你要在这个Sprint开始前，完成需求任务清单，由PO进行讲解，然后由开发团队进行估算。通常在敏捷中，用的是估点，就是对这个userstory进行标识点数，用于标识它的工作量和难度。开完这个会议的话，你大概要完成的工作和你的工作量就出来了。

第三个每日站会，站会是敏捷中比较标志性的。这个活动，其实是团队中每个成员站着开会。通常时间比较短，基本上在15分钟内就会结束。团队每个成员都要发言，发言集中在三个问题：第一个，你昨天做了什么；第二个，今天准备做什么；第三个，有没有碰到什么困难或者是问题。这个会议主要进行整个团队信息的沟通，所以通常不会很长，才会采用站立的方式。如果在沟通中发现了有些问题，需要下来详细沟通的话，那么在会议结束后可以继续进行沟通，一般在站立会议的时候不会进行特别详细的需求，细节的沟通，特别是只有两个人相关，与他人无关一般不会占用大家的时间，这个每天都需要在固定的时间开。

第四个评审会，实际上，就是在Sprint结束之前，团队已经开发和测试完成了，这个时候就要给PO演示和展示你可交付的软件，你完成的到底是什么样子的，然后PO来进行验收。

第五个回顾会议，是在Sprint最后结束的时候，召开的一个会议，而且通常时间会相对较长。那么他主要就是说整个团队坐在一起，说一下整个Sprint的情况，视他完成的程度而进行自我反思和持续改进，看看有没有什么做的比较好的点，有什么做到的不好的点，碰到了什么问题，以后有什么优化的方向，基本上是都会开这个会议。

基本上这些概念讲完了之后，大家会对你有一个简单的了解，我们现在看几张图片。

最左上角的是看版，这就是我们实际工作中，因为敏捷的团队所做的一个看板，上面贴了很多便利贴，就是一些工作的卡片，上面写了backlog，一些需求，还写了一些task，就是具体的工作任务，大家可以看到有红色或者是橘色不同颜色的卡片，他标识的不同的工作任务，有的是技术卡片，有的是bug卡片。也就是说，团队中的技术，相关的人员实际上都可以往上贴task，那么他整个的看板会摆在比较显眼的地方，大家每天都会站在前面开站会，可以看到右边有一张照片是team的成员站在看板前面开站会，他们在进行沟通，如果对当前的问题有疑问的话，他们就会直接移动黑板上面的卡片。

在这张PPT的左下角，有一张燃尽图。实际上敏捷中我们也需要看整个的进度和工作量。刚才大家还记得甘特图吗，其实在敏捷中也可以用，但是我们通常使用燃尽图或者燃起图，他俩基本上是一致的，只是一个是烧完了，一个是烧起来。那么就是说，你对卡片进行估点之后会有总点数。每天完成多少会有团队或者Scrum Master进行更新，我们就可以看到任务的完成情况。如果是燃尽图的话，这个数字一直会往下掉，到最后变成零，就证明所有的任务都已经完成了；燃起图，也就是说每天晚上累加，达到了你峰值的100%之后，任务也就完成了。

他是一个方便看进度和任务完成度的一个统计。

右下角就是我们整个的backlog了，他是分模块的。但是backlog整个的形式是由PO来控制的。

在敏捷上，我们要求的很重要的一点就是可视化，一定要做出来板子，如果是异地的团队的话，可以使用电子版，但是通常如果你初次转型敏捷的话，我们都建议使用物理看板。建议集中办公就是团队的坐在一起，这样沟通会比较顺畅。

讲了好大一堆理念，那如果我想在我的团队中实施Scrum，应该怎么做呢？这里给出了一个简单的路线图。

首先，你要确定你整个的团队（就是实施敏捷的试点团队），要确定你的PO（就是产品经理）的角色，然后要组建你的team，有几个工程师大概需要做什么，还要有一个Scrum Master的角色，它是可以兼职的。

选定了团队了之后，那么就由PO来维护整个的产品的backlog，决定你整个产品的需求，优先级方向完成的阶段、目标和价值。整个清单列出来之后，我们就可以定一个Sprint的周期，比如说三周，定完Sprint的周期之后，就可以选择Sprint的backlog，就是完成一些什么东西。

之后你就可以开刚才说的那几个会议了。第一个，我们开冲刺的计划会议，确定本次Sprint该完成哪些backlog，团队都确认OK，之后我们就把卡片写出来，然后贴到看板中，贴到to do list或者哪一列都OK。之后我们就开始开发和测试，在进行循环。中间，每日开站会沟通所有的问题，Scrum Master要确保所有的问题得到及时和妥善的处理。

然后，在过程中我们来观察整个看板的任务完成情况，观察燃尽图或者燃起图的情况和任务都完成。看看有没有Miss或者其他的困难，有没有增加额外的技术卡片。在这个中间Screm Master和PO都要尽量保持第一个需求的稳定性，第二个团队的稳定性。其他的问题都及时得到了解决和处理，保证整个Sprint有序的进展。当开发和测试完成之后，我们就可以进行功能演示的会议了，有必要对整个的软件进行验收，来决定是否上线或者是投入市场等等后续决策。

最后可以进行整个Sprint回顾会议了，来看你整个过程中发生了一些什么事情，好的方面，坏的方面，这个其实形式不限的，比如我们以前画过鱼骨图，或者是开过那个头脑风暴的会议，其实都可以穿插进去，还有一些分享等等，都可以在回顾会中来做。

以上基本就是一个简单的Scrum实施的步骤

关于敏捷和Scrum，那我们今天就讲这些，大家可以下去再消化一下，其实敏捷是个很大的话题，相关的问题，大家也可以去网上找一下资料。其实我刚才说的是团队级的敏捷。其实还有更大的叫组织级的敏捷，比如说100人，200人，500人，其实有另外一套方法论，那个比敏捷会新一点，有好奇的小伙伴可以去搜一下。

接下来，我们会简单介绍一下。软件研发类项目管理的职位大概有哪些。

其实，关于项目相关的岗位有很多，这里我截取了几个，大致是分为三个方向：

第一个方向是项目专员和项目经理。

或者叫项目沟通员，项目主管，项目协调，项目总控，其实代表的是一个意思，那他们主要就是做具体项目地管理，按时保质地达成目标和交付。

第二个方向是PMO。

跟项目经理和Scrum Master有些区别，他更多的是看高层次的规范体系的建设，会存在一些比较重大的项目级的管理和整体的审核，控制，做更多的这方面高层次的工作。PMO是这个职位的名称，同时也是个部门的名称，项目管理办公室的名称

第三个Scrum Master。

敏捷的项目经理或者敏捷的项目管理，也叫做敏捷教练，他实际上和前面的都会有部分重合，更偏向于敏捷项目地实施。和项目经理一样，一个Scrum Master，其实也可以带多个敏捷项。这里要提醒的是，这些职位并不是完全割裂的，他有可能混合，而且可以是专职，也可以是兼职。比如说你在一个公司做PMO，同时你会担任两个团队的Scrum Master。如果你有这方面特长的话，这样其实也是OK的。

关于项目管理的职位，就介绍到这。不展开来讲，其实后面还有很多，比如说项目管理专家等，都是一些上升的路线，但具体相关的职位，其实都会分布在这几个方向之内：项目专员，项目经理，高级项目经理，PMO资深专家，会有这样一条上升的路线。

职位简介过后，接下来我们讲一下，互联网项目应该怎么去管

社区的同学大多都是从事互联网行业的，那么互联网行业项目也有蛮多种，如果我们用PMBOK来管理的话，第一个它周期性比较长，第二个文档和体系的痕迹非常非常的重，其实比较难实施或者直接落地。那么接下来我讲一下比较简易的办法。

如果你不是专职的项目经理也没有关系，实际上在互联网公司，有很多种项目管理的方式，也有很多是由开发类的和产品经理来负责整体的项目管控。那么我认为人人都应该有一些项目管理的思想，这会帮助你更好的完成工作。

其实控制全部项目的过程是项目经理的角色，只看结果其实是老板。那么程序员，他大部分的只会盯着具体那块的细节。那么怎么管好整个的过程呢？我提供了以下的路线，第一分类；第二分集；第三对项目进行分解。

我想把它分为两个类型：

第一个是产品型，第二个是项目型，大家可以问一下自己属于哪个类型的项目。

产品型就是它没有完成日期，它只有迭代版本的上线日期，但是没有整个产品的结束日期，比如说大家天天刷的抖音，什么时候这个项目结束了，其实大家是不知道的。它通常用迭代或者是敏捷开发的方式，以一个版本的发布上限为阶段性的分界线。他通常的一个版本的周期比较短，几天啊，几周都有可能。

项目类型，它很多是瀑布或者是迭代开发的形式，基本上是以验收、交付、客户签字、回款、项目结项作为整体的分界线，看的是一次性的，而且周期比较长。几个月到几年都是有可能的。我们常见的一些国企，银行类或者大的TOB软件类，ERP类都属于这一类别。比如说500万的合同，一年半完成，那么整个客户签字确认验收，然后三个月的维护期之后，这个项目就已经结束了。然后项目组的人员打散，重新分配。接下一个项目可能就是民生银行，接着中国银行，然后招商银行，还是不停的一个一个项目，它具有的就是一次性。

如果你是产品型的话，就比较适用于整个迭代的类型的开发；如果是项目型的，就要注重整个项目过程，文档和知识体系的控制和梳理，着重点是不一样的，接下来的我会着重来讲产品型的，因为互联网的很多项目大多属于这个类型。

分类之后，要对项目进行分级，就是优先级。一定要有优先级！

因为在互联网的工作中，肯定会存在多个项目，多任务并行的情况，当你确定了优先级之后，就可以确定对这个项目整体的资源投入和监管的力度，这也决定了你做事情的顺序。

请大家在拿到项目之后，首先问自己几个问题：第一个我这个项目在整个公司的战略中处于什么样的优先级范围；第二个在整个部门中处于什么样的优先级；第三个在我手头自己的任务和工作中，它的优先级是怎么的。

我给出的事例，当然每个公司都不一样，用P0,P1,P2，A,B,C都可以。那么这里的分类事例分类是这样的：P0就是非常的紧急，P1就是紧急，P2就是一般。那么高优先级的项目可以抢占或者是独占资源，低优先级的项目或者是任务，要向高优先级的让路。我们建议一个公司或者是一个产品线，对需求或者项目进行排序的时候，用统一的优先级排序方式。当然每个公司都不一样，如果大家不知道怎么定优先级的话，我给大家一些简单的参考的指标。

指标已经写在PPT，大约是由以上这些，比如说业务的紧迫程度，业务的影响范围，业务的价值，合规和合法，隐私性，管理层关注，也就是说是不是boss需求，是不是公司的形象需求，还有整个的使用人群，你涉及用户面的大小，技术上面低复杂度和必要性，以及整个项目地成本和投入是多大，这些的范围，就决定了你这个项目优先级的高低。

那么优先级确定了之后，就是分解到某一个项目了，我要真正做一个项目的时候，大概有哪些点呢？这里我提供了三个关键点：第一个就是做项目计划，并且确认你项目中的关键里程碑；第二个就是关键里程碑，配套的产出物是什么；第三个就是你所有任务间的依赖。

里程碑

它实际上是项目中的重大事件，它是一个时间点。通常我们在里程碑会check一个可交付成果的完成，他其实具有非常大的意义。那么，你在项目做计划的时候能规划出了里程碑的节点。那么你就知道在每个节点需要验收什么。然后，围绕每一个里程碑安排工作。这样会比较有节奏感，同时如果你的项目周期稍长，设置里程碑之后，会把整个进度的压力分散开来。我们会发现在工作过程中，比如说是三个月项目周期。那么大家很多人会把工作挪到最后两三周才完成，导致拼命的加班和赶工。这会导致延限和质量的风险。而且里程碑的到达率其实也是项目经理考核的依据。

我们在做项目计划的时候，项目经理主要check的点实际上也就是关键的里程碑。那么你到里程碑check相应的点已经完成了之后，会提高你对后面整个延期情况，质量和进度的控制感。

比如说一个项目周期，三个月有五个关键的里程碑，每个里程碑都按质保量，及时地交付了，那么就认为整个项目的交付期是可控的，后面的风险会比较小，如果五个里程碑前四个都严重延期，那么最后的deadline交付成果肯定不会非常好，但是如果三个月的项目不设置里程碑的话，我们就很难去直观的感受到整体的风险的严重程度。

标准产出物

讲完了里程碑，我们来看一下里程碑的配套的产出物，PPT里面写了很多个产出物，这个就是比较完善和标准的产出物了，那么项目经理主要检查的就是这些点。

比如说我们项目计划的会有一些配置和质量管理的计划；需求的时候会有需求说明书和评审的报告功能；功能开发会有概要设计、数据库设计、详设；测试会有用力、计划等等。那么配合我们所有里程碑就检查这些文档和产出是否完成以及工作的完成情况。那么我们就对这一块儿的工作有了比较系统和直观的了解，并且可以记录在案。但是实际上来讲，有的同学肯定会说，我一个项目要写这么多的文档吗，光写文档的就已经够了，或者是我的项目组只有两，三个开发。写这么多文档会不太适用于我整体的情况。这个没有关系，就是所有项目管理过程都是裁剪使用的，在这里给大家展示了一份比较全面滴产出物。那么实际上在你在项目应用过程中，大家可以按需来挑选使用就可以了。

适用于一个互联网项目的简单项目计划。

对照这个图片来看一下。

1、第一列是整个的阶段，实际上就是说，你这个整个项目涉及了哪些阶段，我们可以认为每个阶段的结束，都是一个关键的里程碑的点。在这个例子中，我写了需求设计，数据准备，研发测试和上线这么多个点。

2、第二列是组别。也就是说你涉及到的组别，开发，产品，业务或者是其他的和你整个组织的架构是有关系的。就是说你用的人员需要沟通的范围大约是哪些。

3、任务的编号，会有任务的周期几月几号至几月几号，这样方便你整体的项目排期，如果你手头有一个人承担多个项目的话，整个这个排期是非常重要的，那么就可以从这中间看出来你所有资源的占用情况，特别是你项目是非独占资源。比如在很多公司的设计UI和测试组，他都是公用的资源。那么当你用到这些资源的时候，那么我们有整个的排期之后，你就可以看到他资源的繁忙程度啊，空闲时间段和并行的程度，你可以就估算一下整个资源的风险。

4、产出描述，这部分其实就是配合前面的阶段，也就是配合里程碑要检查的产出物。

5、责任人，有的人喜欢写很多，比如说我就是两个产品经理，或者就是开发就四个人。在这里，我建议大家有且只有一个主要的责任人，其他的都是参与者。我们来check整个的任务的时候，只要找这个责任人就可以了。

6、工期的估算，就是你自己的任务，大约要花多长时间。

关键：任务依赖

也就是说任务间有没有关系，我们在这个表中可以看到，小瑞要开始页面设计之前，他要依赖于小熊出整个的原型图，他依赖产品经理出原型图。那么他的任务依赖就是一号任务，如果小熊没有按期把原型图交付的话，那么页面设计就会影响，页面设计影响之后，那么开发和测试都会延后，那么项目就有delay的风险。

那整张表我们可以告诉你这些比较关键的信息：第一个是你这个项目所有关键的阶段，就是左边彩色，需求设计，研发，测试等等相关的阶段；第二个，是你所有涉及的部门。你要跟这些老大或者是他们具体的人员进行品牌的沟通，大家用到几个组，有些项目非常的复杂，跨业务线啊，跨BU，甚至跨外包公司，这种的外部合作其实都有。我把这个写出来有利于你简单明了的掌握所有的关系。然后他会告诉你：整体的任务的周期和整体的工作量是多少，用来评估你项目地优先级和难易程度，比如说我这个项目用到300人天，和一个用到15人天的项目。他在你的列表中的优先级肯定是不一样。

它这里面列出了你所有要检查的产出物。比如说我整个这个项目需要产出这么几个东西，第一个要原型图，PRD需求相关的，然后会有所有的设计图，开发会有一些数据库表和整体的设计的文档。测试会有测试用例。然后上线会有一些物料的运营和物料的准备。

最后，会告诉你所有任务的依赖关系，检查任务的依赖关系，已确定你整个项目整体的进度情况。

这里需要特别注意的是，当整体的项目排期计划做完之后，一定要注意及时更新，不是说做完了就OK了，就放那里，不用管了，一定要注意及时更新。同时当你发生了变更和更新之后，一定要及时知会整个的团队和所有的干系人。

怎么来知会？其实你工作中常用的方式都可以，比如说公司内部的这个iM的交流群，邮件组，开会，任何方式都可以选用。但是一定要，及时更新和知会。

在上线过程中，其实有很多很多的坑。我推荐大家在上线的时候，做一个checklist检查表。这个确实每个公司每个产品线都不太一样，我给出了一份事例，是一个APP相关的。

那么主要回答几个问题，第一个是你所有的工作都完成了吗，所有的bug都结完了吗，有没有遗留问题，是怎么解决的，所有上线的运营的物料，数据准备好了吗，各种服务，各种切换，各种开关，各种管理员，各种设置是不是都做好了。相关人员都通知了么？有没有什么问题？靠自己的脑子容易疏漏。这就需要你做一个checklist。

首先checklist会有项目名称和上线日期，然后会有相关的组别，和具体的任务。

那么所有跟上线在这个周期内相关的任务都可以写进来，具体写一些什么，要根据你整个项目地实际情况来定。

在这里再敲一次黑板，每一项任务必须有且仅有一位负责人。在必要的时候，可以签字确认，当然也可以采用电子签或者是邮件，微信沟通也好。

那么有了上线检查表之后，经过几次的迭代，一个产品线的整体的风格和工作任务稳定之后，我们能拿到一个比较完善的检查表，每次走一遍的话，大家会发现这个会比较高的，提高你整个上线的效率，团队中形成了共识，大家会自动自觉地完成相关的任务，减少出错的几率，如果有人调岗或者离职呢，也能方便地进行交接。

实际上项目管理是有非常多的工具，在这里简单给大家推荐几个。

如果你是项目类型的。比较重，比较大，涉及人员比较多，周期比较长的话，那我们推荐用PC版的。就是图片上面两个。

如果你是Windows的话，那我们就推荐用Project，就是可以画出比较完美的人物图和甘特图。如果你是苹果电脑呢，可以用ominiplan，他俩的功能是差不多的。

如果你是产品迭代类型的项目，小步快跑，或者团队没有那么多，周期没有那么长的话，那我们就在用比较简洁的工具，那下面有三个是网页版的。

其实还有更多的工具，每个都各有千秋，但是整体的理念和展现形式都差不多，大家可以根据自己的习惯来使用。这些的工具都会有任务拆解，燃起图的提供和统计。电子看板，其他的协统知识库和文档的存放，这些功能都会有，基本上都是和敏捷相关的，卡片也都是拖拽式的，非常的灵活和简单易用，界面也很简洁。

包括我刚才讲到的项目，计划和check的呢，其实大家都可以做到工具中，当然了，如果你使用Excel表也是没有问题的。

大家在项目管理其实不要拘泥于工具或者是形式，工具和形式其实都只是工具，最重要的是项目管理的思想。那么就是我刚才提到一点，整个项目你是围着交付的，整体的目的，按时保质的完成任务和交付期是项目经理最大的目标。然后才是沟通，成本节约，整体规划等等其他的技能。

分享完毕

以下是嘉宾互动问答环节

1. 产品管理和项目管理有什么不同？

问题描述：在实际工作中，产品管理和项目管理到底有什么不同呢？边界怎么区分？

答：第一个就是它整体的生命周期是不一样的，产品的管理主要是需求，计划和发布。他整个强调的是做什么。产品一般都没有结束的时间，但是项目管理的主要是过程和任务的管理，侧重的是如何实现这些需求，项目一般都是临时性的，一次性的，他是有结项的时间的。而产品是一个长生命周期的过程。

第二个是关注点不一样，产品经理的侧重点是向外，他比较关注用户市场，市场机会和整体的竞争格局，用户的需求和用户沟通，解决的呢，是做什么，卖给谁，赚谁的钱的问题。但是呢，项目经理的侧重点是朝内的，他更多的关注资源，进度啊，资源的调配效率。整个它解决的是如何用有限的资源在限定的时间内，按照质量把东西做出来，并且交付。

第三点，实际上他是交付物的不同，那整个产品经理交付的是整个产品的结果，是最终给用户的一个产品，他比较关注整个产品的成本，质量和体验。以及产品通过运营之后所转化的一个收益的情况。但是，项目经理交付的，他是管理成果，最终的交付可能是管理层的工作报告，他更关注的是团队的士气，效能，成本以及企业整体的生产效率的提升。

2. 如何界定产品经理在项目管理中的责任范围

问题描述：产品经理作为一个项目的主要负责人，在项目管理过程中必然与项目经理有工作职责重叠的部分，大家在实际工作中一般是如何处理这种责任范围的重合的？

答：我觉得这个，你需要先确定一下你所在的公司和组织的形式

第一个你所在的组织和公司是不是项目制，他有没有专职的项目经理，如果有专职的项目经理，那么产品经理的工作会相对简单，他主要负责产品和需求相关的工作，更多的就对需求方，老板、用户和市场运营结果负责就好了，如果没有专职的项目经理，没有人承担项目经理职责。那么除去产品相关的工作啊，产品经理可能还需要承担一部分，项目整体的进度排期，资源协调和报告等等相关的管理工作了。

那么他具体的工作的范围包括以下几点，你第一个就是你清晰的表达整体产品的需求的问题，没有歧义，把整个blog整理好。第二个对需求清单的整个条目进行归纳，确保整个开发团队所有执行的工作有效的进展，Bug遗留问题的处理。确保整体需求的可见，清晰，透明，并且告诉团队下一步大概应该做什么，把优先级排好，这样团队能够很明显的知道你应该做什么。确保你所有的开发团队中的人员对需求有一致性的理解，这个非常的重要。

大部分的问题其实都是沟通问题，最后在负责产品交付的时候，进行验收和所有遗留问题的解释和处理。在进行整个的产品开发的过程中，你不仅可能需要考虑未来产品的规划，还特别应该关注当前整体产品的进度，通过沟通，监控，协调，保证当前的功能正常的上线。

3. 多团队协作的项目管理应该怎么做？

问题描述：最近项目里需要多个团队合作开发，各团队基于需求以自身便利出发，对产品架构设计不利，请教各位大大，怎样去做这类项目的管理？

答：这个其实不同的公司的文化和不同的人的处理方式会不一样，但是呢，推荐几种处理的方式：

第一个是有一个好的心态，那么你一定要认识到，工作中肯定会存在一些争论，矛盾和冲突的。不同的人思考处理问题的方式都不一样，希望大家能够通过换位思考，梳理问题产生的根源，确保整个大局的前提下能处理好之间的冲突，就是一定不要产生冲突和争吵。

第二点，一定要注意职责的划分，很多情况下的矛盾的其实都是资源协调，抢资源和职责划分不清楚。有些任务一定有且仅有一位负责人，这样的任务划分界限比较清楚了之后，大家都会围绕自己的工作重点来。如果团队项目中出现了难以界定的工作出现的时候，应该及时组织会议或者是沟通，确保事事都有人管，有专人负责。那么项目经理的习惯实际上是这样的，一旦出现了边界模糊的问题，直接抓一个会。任务12345全部都列出来，谁负责哪项任务大家协商或者是指派，负责大概的范围，抽时间把列表填好，这个问题就能够得到解决。

第三点，一定要立字据，必要的时候可以签字确认。那么其实跨团队沟通，特别是对一些其他的业务部门的，或者是外部的公司合作，比如说你找一些外部的供应商，找一些外部的供应公司。立字据和签合同是很重要的一点。如果存在过往中存在扯皮，推诿啊等等的事情的情况下，一定要留下记录，已防被查。必要的时候签字确认。然后一定要做到统一目标，在一个项目开始的时候，我们会抓整个项目，就是你排期计划开始和需求OK之后，一定要找整个team，确保所有人的理解都一致。

如果在沟通过程中确实使用了所有的方法都无效的时候，及时上升，就是找你的领导。找人协调，或者会找更高的领导来帮你协调和处理整体的问题，如果涉及到金钱啊，隐私，法务，财务等等的话，一定要准备好相关的物料，找相关的投入，比如说内审内控，你们公司的税务和法务来具体一起帮忙把关，而不要全部的问题都自己扛。

本文完

点击“阅读原文”看今日话题

有哪些产品是你感觉页面虽丑但是功能却异常强大？