随着团队的发展壮大，越来越多的同学开始担当项目负责人的角色。那么，如何才能成为一个合格的项目负责人呢？

根据自身多年工作经验的积累，我对项目负责人需要完成的工作如下：

1. 做好通报工作：信息同步
2. 做好协调工作：资源协调
3. 做好管理工作：稳步落地
4. 责任义务权利：权责分清

一、做好通报工作：信息同步

想要成为一个合格的项目负责人，首先需要履行的职责是：向自己的上级、团队、相关合作团队以及关注项目进展的人，及时同步项目的动态。

为什么要做信息同步？

首先，从风险角度来看，信息公开，可以帮助降低项目落地的时候失败的风险。

信息公开，不同角色的人会通过不同的视角来看，目前项目的状态会有什么样的问题。比如：一个项目立项之初，如果事先沟通得不充分，可能会发生：排期预估乐观、人力资源申请存在不到位、技术方案考虑不周等。通过信息公开，不同角色的人可以看到项目状态，如果遇到一些风险，可以主动提出，在事发之前就做好准备工作，可以大大降低事情落地的风险。

其次，方便其它有依赖或有交集项目上同步信息。

比如是一个产品功能的开发项目，一般一个产品要新增加一个功能，会同时有产品、市场、运营等同事同步自己的工作，比如：3-8日要发布一个功能，那么运营同学可能会提前预约3-10号的发布会，来专门推广这个功能。如果项目一旦出现延期、质量问题、功能缩减等，那么需要其他成员同步调整自己的计划，避免因为信息不同步，导致乌龙。

做基础服务的项目，也可能会同步有业务方进行依赖，比如：新增一个Feature或者修复一个Bug，可能都会对业务方有影响，如果需要对方调整，则信息同步是很好的方式的一个提醒。

再次，里程碑事件是最好的“证据”。

团队协作里面，很难免会遇到“扯皮”的事情发生，不管是因为职业素养问题，还是因为某个人“记错了”，我们尽量去避免这类问题的发生。那么，信息同步就是一个很好的方式。不要扯皮，看邮件。

再再次，让你的上级“知道”。

是不是经常听说：你做了很牛逼的事情，结果老大不知道，还以为你一天无所事事，最终郁闷地错失了升级加薪的机会？换个角度考虑，你的老大可能同时跟进N个项目，对很多项目的细节并不清晰，老大如何知道你做得牛逼？

当然，这是从我们自己的角度来看这个事情。让老大知道项目进展，可以帮助你获取他的更高层级的协助。比如：我们会在通报里面，描述工作的计划和方案，有的时候这个计划和方案在老大看来，有更好的解决方案（比如：通过资源解决问题，某某团队已经做过了，我们直接拿过来用；或者，某个方案有更好的方式），那么这个时候，他会从资源、“过来人”的角色来帮助我们更好实现项目落地。这也是让老大知道的意义。

综上，作为一个项目负责人，如何信息通报做得不够好，那么我们认为这个负责人是不合格的。

什么情况需要通报？

一般情况下，我们会有几种场景下做通报：

1. 项目进展，达到某个里程碑阶段
2. 项目进度，出现变化（故障、异常）
3. 项目的一些结论性质的内容
4. 定期的项目进展通报

1、项目里程碑通报

常见的里程碑事件，有：项目立项、方案沟通与评审、阶段性的进度通报、项目提测、项目部署、项目结束等。

通报的内容以“项目达成某个点”为主，比如：

【立项】**项目立项通报、【上线】**项目部署完成/小流量部署完成。

一般情况下，有些里程碑事件可以省略，比如：某些封闭项目、大家都知道的立项环节等。

2、项目进展出现变化通报

常见的有：项目延期、需求变更、方案或资源变更等。在我们项目中，经常出现周期上的变更（延期）。偶尔会出现人力资源的调整，比如之前由于某某离职、晋升等造成变化。

比如：【变更】**项目成员变更通报

3、项目的一些结论性质的内容

项目的进行过程中，经常会有小范围的沟通、讨论，往往这些沟通和讨论都会达成一些共识和下一步的计划。那么，这种情况也需要进行通报，比如：会议纪要。一般这类通报包含以下几方面内容：

1. 参与人（都谁参与了）
2. 时间（什么时间讨论的）
3. 主题，讨论了什么问题
4. 结论，达成了什么结论
5. 后续计划，接下来怎么安排的（由谁什么时间、负责完成什么事情）

4、定期的项目进展通报

这个比较好理解了，比如：项目周报、日报、季报等。定期的给出项目的进展、下一步计划、遇到的问题或需求的资源等。

同步方式

常见的情况下，我们使用：邮件（最常见）、即时通信工具（微信）、WIKI（Slack、Confluence等）、Tower(TB）等。这里我们仅讨论：邮件和即时通信工具（也可以用Slack代替）。

一些重要的结论，后续可查的，走邮件；比如：沟通纪要、双方的结论等；

一些及时性强的、临时的，走即时通信。

二者的区别在与：是否需要保留记录，是否及时。其实二者并不冲突，可以同时使用（即：既发了邮件，也发消息）

使用邮件

一般，标题能够突出结论或者主题，比如：

  【纪要】**沟通纪要

  【评审】**项目技术方案评审邀请

标题直接与主题相关，方便接受邮件的同事快速判断这封邮件是否需要看下去。

邮件内容，一般三段式：

1. 结论先行（方便阅读邮件的人第一时间Get到点，至于过程看不看，根据结论判断）
2. 补充描述（比如：结论是怎么得出的；
   1. 结论的产生很多是跟背景相关的（也可以叫：场景），缺乏场景的情况下讨论结论是没有意义的
   2. 除了故障是怎么分析、怎么得出的）
3. 下一步计划（接下来怎么办，比如：如果是故障，则接下来安排怎么排查和处理，给出时间点和责任人；如果是结论通报，要么省略，要么可以说一下：反思的过程）

上面的结构可以满足大部分发邮件的需要了。

使用微信（其他通信一样）

微信的内容随意性比较大，需要遵守的是：一句话说明白。结论先行、补充描述即可。

同步对象

你的邮件、内容发给谁，你可得想好了。

原则上讲：你的内容希望谁看到，那么发给谁。另外一种定义是：项目相干方，及与项目相关的人。

这里，常见的候选人是：

1. 你的上级（导师、项目的直属负责人）
2. 执行项目的团队
3. 你的业务方（谁的工作依赖你的项目）
4. 某些特别的人（自已意会）

总结

综上，能够合理地做好项目通报，是项目负责人的基本能力。（当然，技术能力才是基本能力…）

二、做好协调工作：资源协调

项目往往会出现：人员变更、依赖工具、有时间限制，当任意一个因素出现瓶颈的时候，就需要来做资源协调了。

项目管理四因素

在一个项目中，我们考量：时间、成本、功能、质量四因素，几乎任意一个项目都可以由这四个因素来描述。

这里面，成本包含了：人、某些资源、工具、场地等。

这四者的关系可以总结为：

时间=功能*质量/成本。

图示：对角线为互斥：此消彼长；相邻为互助，相互促进。

那么，所谓协调，就是在这个四个里面做取舍。

处理功能

所谓功能，也可以理解为需求。

处理好需求（我们经常叫：控制好需求），是顺利落地项目的第一步。道理很简单，功能越少，难度越小。一般来讲，我们会根据时间来卡功能，敏捷里面也叫：TimeBoxing。在某些场景下，我们会直接进入研发，看看在某个TB下，我们尽可能地多地实现功能，实现多少算多少。

正常情况下，都是通过时间窗来卡功能的，因为一般上线的日子提前订了，那么这个时候就看能做多少了。当然也有根据功能来计划发布时间的，这个完全根据实际的情况来定。

处理功能，需要有优先级的概念，尽量将功能拉平成为一个线性维度的数据，而不是一个矩阵（二维关系）或者网状（多维关系）的数据。线性维度的数据更好地进行分析。

什么是矩阵数据、多维度数据？

我们在制定需求时，如果需求之间没有依赖关系，相互独立的，那么会认为需求的信息是线性的。在某些情况下会出现：A需求依赖B需求的情况，那么这个时候需求的信息就不是线性的了，这种情况下，如果依赖的情况比较复杂，甚至会出现：A依赖B、B依赖C、C依赖A的环形依赖情况，那么这种需求就属于整理得不好的。在经常的情况下，我们会将多维需求拉平成为线性需求，方便我们进行管理和开发。

最常见的情况是：我们将简单依赖通过合并、拆解等方法，彻底解开关系依赖，实现线性数据。这也能够解决常见的场景。

如果需求本身数量也多，情况比较复杂，那么这个时候就需要一轮结构化处理了（后面有机会专门来聊这个话题）

总之，需求这里一定要可控，在自己能够处理的范围来处理。

遵守时间

时间也即周期，我们完成一件事情所需要的时间。在很多情况下，我们拿到一个需求，会进行排期（计划时间，什么时间完成、什么时候进入测试、什么时候发布）。

在指定时间的情况下，就不说了。

在需要给时间的情况下，比如：这么多功能、你的团队需要多久能做完，潜台词是：功能确定、人员确定（成本）、质量保证下线，那么需要多长时间。这种情况下，一般我们会进行功能、人来进行任务划分，划分后，根据经验来给出时间。最常见的，就是：排期。

排期

排期一般分两种情况：阶段性周期（里程碑）和任务计划。

“完成技术调研需要1-2周”属于阶段性周期，而“用户登录API开发需要16h“属于任务计划，二者的区别是：

1. 周期长短不同，阶段性周期粒度长一些，计划的粒度会小一些
2. 阶段性的周期可以是一个范围，不确定的；计划就需要确切的值

了解一个项目的周期，我们先了解一下：PDCA（戴明环）

对于项目，项目的周期为：

对于项目而言，我们经常接触的是：Plan和Do的环节，Check和Analysis的环节很少想到，很多情况下，我们发布的项目后续都由运维接手了，然后便开展了下一个版本。其实，C和A的事情我们都做了，只是很少会把它单独拎出来而已。

比如，系统上线后，进入运维状态，那么这个过程就进入了长期的Check状态，当出现Bug时，就会进入Analysis了，接下来修复bug的场景就是下一个版本了。

管理成本

一个项目，可以投入一个人来做，也可以投入十个人来做；可以自己团队花很久来研发，也可以买现成的商业方案。这些都是成本。做项目就没有不付出成本的，只有成本的高低之分。我们最常见的是人力不足时，向其他团队”借人“的场景，这个情况也比较简单和常见。

如何选用第三方方案

还有一种情况，对于很多技术出身的人才来说，就有些困难：使用别人现成的方案。之所以说这种情况比较困难，主要在于：

1. 有些是能自己写就自己写，不想去理解别人的技术思路，不想去学习；
2. 有些是能用别人的就用别人的，总觉得别人写的就是最好的（某个NPM的故事）

就这里而言，这个没有什么固定的答案。一句话：因实际情况而异。

当然，实际选择的时候，我会关注：

1. 我们的团队是否有能力自研（或者为了提升自研能力）
2. 选用的组件是否是公司的发展方向（如果是，优先，甚至是必须）
3. 现在什么比较富裕，什么比较匮乏（比如：钱比较多，用现成比重大些；人比较多，自研比重大写）

总之，谁负责谁决策，无论做哪种选择，都需要足够的勇气承担风险。

多跟老大要资源

在一般情况下，老大会帮助自己来提前调度资源（老大不就是干这个事的么），但是在某些情况下（比如：难度超过预期、老大对项目细节并不熟悉等），老大给的资源跟实际的需求有出入，那么作为项目负责人有必要也有责任向老大申请资源。

控制质量

互联网经常有一句话叫：要时间不要质量。在保障核心功能正常使用的情况下，减少非核心功能的测试时间，来追求发布上的快。（不知道现在腾讯帮助中心的检索的bug修复了没）

这里，质量一定要分级，分级的原则是以影响面来衡量，而不是修复难度。

为什么要分级

在时间、资源充裕的情况下，是不需要分级的。测试做个一年半载再上线也是可以的。然而现实是，老板永远催着你赶紧上线，我们的资源也不是可以无节制消耗的。那么要找到：既能保证质量达到一定的要求，并且在有限的时间和成本下完成，就需要一个平衡的折中方案。质量分级是一个常见的方式。

有些人认为，在有限的能力下完成牛逼的事情，更能凸显自己的能力。这个话讲得没错，但是合理的利用资源，也是一种能力。（想了解为什么？以后有机会讲职业发展的时候，再详细展开）

质量分级

一般来讲，我们根据Bug的影响面作为标准来定义等级（切记：不是修复难度，而是影响面）。这里的影响面从两个层面看：

1. 业务影响：比如显示金额出错，数据并没有发生变化，可能是一个笔误导致的，修改起来很容易，但是对于用户来讲，可能会觉得自己的钱丢了或者赚了，转而产生客诉或者其它负面影响，虽然修改起来容易，但是带给客服、用户、外界对公司的印象会大打折扣
2. 系统稳定性影响：比如写数据写失败、写错误、隐藏的bug等，触发概率大且一旦触发会造成系统不可用或者数据损坏，那么这个也会比较严重

根据上面两种情况，我们定义：

等级没有绝对的边界，根据实际情况来调整，但是就是一个原则：以Bug的影响面为准。

总之，做好协调工作，可以让工作更有效率。

三、做好管理工作：稳步落地

项目的执行过程，我们的敌人：风险。我们接下来所有的事情，几乎都是讨论怎么对付它。

过程管理你一定不陌生，定期的进度review、各种的站会例会，几乎充斥到我们工作的每个环节。如果想让项目顺利落地，即便项目中出现风险，也可以降低本来应有的损失，那么我们需要学习一些基本的知识：

1. 目标管理（SMART）
2. 时间管理（重要紧急四象限、《高效能人事的七个习惯》）
3. 结构化思维

以及一些常见的敏捷实践：scrum、极限编程、TDD。

什么是执行力，我的理解是：把不确定的事情确定下来，把计划的事情落实下来，就是执行力。

先说说，一些基本知识

目标导向

目标导向可以理解为是一种价值观，事情的优先程度永远与是否与目标有关而相关。这里就要说四个概念：

目标：要解决的问题或者要实现的目标。比如：降低数据库压力、增加公司营业额。目标是应该有明确的指标，这个指标是很好衡量的。

方法：也叫手段、方案，从现状到目标实现的过程或者办法。

现状：目前的所处的状态

背景：这个范围很宽泛，主要交代了前因后果，以及一些隐藏的限制条件

了解完这些概念之后，那么就需要明确规则了：

现状、背景、目标是常量，方法是变量。

意思是：如果执行的过程中实现得不顺利，那么说明方法需要调整了，而不是调整目标。这也是目标导向最重要的概念。

目标管理

我们在制定目标的时候，会遵循SMART原则，那么什么是SMART？

Specific：具体的、确定的，可衡量的

Motivating：有激励的，有挑战的

Attainable：是可以实现的

Responsible：有责任的，这里指的是有责任人

Time-related：有时间限制的

（这个真的版本太多，我找了很久，组装了一个合理的）

一般，我们安排任务都会出现：某某负责**事情，实现**指标，某日子前完成。

时间管理

我们必须承认一点：人的精力有限、时间有限，如何在有限的时间内做价值更大的事情，是时间管理解决的问题。

时间上面，有几个原则：

1. 要事优先（什么是要事）
2. 积极主动（多思考怎么办，少思考为什么）

对于事情，我们都可以分为以上四类。上面四类里面，肯定是优先做：重要紧急的事情，不做不重要不紧急的事情；那么重要不紧急和紧急不重要先做哪个？

这里有几个参考的方法，根据自己情况来定：

番茄工作法：

1. 以每25分钟为一个番茄钟，5分钟为一个休息时间
2. 一个番茄钟只干一件事，谁来打扰都不行
3. 休息的5分钟用来上厕所、喝水、散步
4. 每天回顾与总结
5. 内部的中断：接受、记录并继续；外部的中断：2分钟内能完成就做，完成不了重新安排（当然是要分情况的）

以上便是需要准备的基础知识。那么接下来，我们开始“稳步落地”。

1、好的计划，是成功的开始

计划是典型的重要不紧急的事情（大多数场景下），计划越精确越好，但不是越细越好，一定要有合适的粒度。

比如，拿排期来说，那么根据项目的大小，一般4周以内的项目，计划的记录在1-3天比较合适；如果项目超过4周，那么粒度在0.5-1周比较合适。

在拿项目设计方案来说，如果是大型的系统架构设计，那么划分出子系统的定位和子系统之间的关系即可（参考：系统之美）。

除此之外，好的计划也是有“预案”的，预案主要描述了：一旦发生某些变化，就执行什么动作。

所以好的计划是：

1. 精确的描述
2. 合适的粒度
3. 不可控因素的预案

计划需要多去联系和尝试，根据不同的情况，慢慢总结其中的细节和联系。

SCRUM中的计划会，就是来跟大家同步计划的（记住：这里是同步计划，不是制定计划，也就是说：会议上我们来分配工作的，不是来讨论怎么做计划的）

2、定期的跟进进度

我们在做敏捷实践的时候，经常会进行：SCRUM的四个会，这个四个会中有两个就是与进度有关的，这两个会分别是：

每日立会（没错，是“立”不是“例”，表示站立的意思）和定期review。

每日立会：团队内进行沟通进度的会议，长度不超过15分钟为宜。会议每个成员讲：

1. 昨天的工作进度
2. 今天的工作计划
3. 我遇到了什么问题，什么会妨碍我的工作，需要什么样的支持

这里需要注意的是：会议上不分析出现问题的原因，也不追责，仅以发现问题为主。如果遇到出现的问题，单独计划讨论、会议来进行。

定期Review：一般在某一个小的里程碑的时候进行的，有的时候也会在每周进行（因为一些任务就是按周来计划的）。会议中一般讨论这个时间范围内的整体进展，以及遇到的问题和反思，长度15-60分钟为佳。

3、处理阻碍进度的绊脚石

项目中遇到了问题怎么办，那么这个时候我们需要在：资源、质量、功能上做文章了。

比如，某个任务花费的时间比预期的长，那么要保证按时上线，要么加人解决，要么放弃一些功能的测试了，或者砍掉某些需求。这些都是我们解决问题的思路。

在通过某些思路解决问题的时候，具体的方法因人而异了，比如：如何跟老大要人；如何跟平衡方案和资源分配，都是需要慢慢凭经验改进的事情。

另外，处理问题需要准确、快速（这是两个词，准确和快速类似重要和紧急一样，两个维度来描述事务，是不是出现了很多次），越准确越快速肯定是最好的，不准确又慢也是有问题的。在时间允许的情况下，优先保证准确；那么如果时间紧迫怎么办？这里就有冒险和求稳两种做法了：快速决策和跳过问题。

问题越早解决，带来的代价越小。（忘记是谁说的了，原话可能也不是这样，但意思差不多）

4、项目要复盘（也就是：Review）

Scrum里面的回顾会（Retrospective Meeting）。这个会议时间可以长一些，当然提前准备工作也是要做的。

1. 这次项目里面，哪些是做得好的、哪些是不好的（可以提前收集一些材料，比如：邮件、纪要、WIKI等）
2. 下次如何能做得更好，以及可以安排哪些新的挑战进来（什么是挑战？）

这个会议可以轻松一些，主要是总结。有的时候，我会准备一些小零食来帮助大家放松。

总之，好的执行可以帮助项目

其它的一些过程管理

高效的会议

如果想要会议很高效，那么有以下建议可以参考：

1. 提前准备，提前收集各种声音，挺多数人的意见，跟少数人商量，自己做结论（出自：百度圣经）
2. 会议要有明确的目标，是为了达成一致，还是为了同步结论
3. 有限的人数，减少产生不相干的话题和无意义的争论
4. 会议要以结论结束
5. 正常情况下，会议15分钟左右即可（一些特殊的会议除外，比如：分享、培训、脑暴等）
6. 会议结束后，对于一些结论，需要有会议纪要（这就是一个里程碑，方便大家后续以此为基础进行推进）

一些好的经验

1. 事情赶早不赶晚（我在百度的时候，我的导师教我的，受用匪浅）
2. 学会说“不”，对于没有明确目的的要求，可以说“不”，既是对自己负责，也是对对方负责
3. 对事不对人，事情该怎么样就怎么样

四、责任义务权利：权责分清

有权利就有义务，有义务就有责任，这里几乎是可以划等号的。在我经历的不同团队里，这里是经常发生纠纷的地方：

1. 边界与范围：哪些是该负责人负责
2. 责任链模型
3. 团队成员的边界
4. 如何看待冲突
5. 如何做决策

边界与范围

你需要做决策，并且需要为此负责

我经常遇到的一种情况是，负责人担心做出决策事后害怕担责，往往会寻求团队外部的合作人、自己内部成员来决策，造成一种“我没有选择”的假象，最终经常会演变成：彼此甩锅。

那么，我们认为：无论决策由谁来做出，凡是与团队有关的决策造成不好的结果，项目负责人一定是第一责任人。

讲到责任，就必须得讲一个东西叫：责任链。

责任链，是一种责任的认定方式。一般情况下，责任的追踪方式有两种：从上到下的金字塔责任链 和 从头到尾的队列责任链。

金字塔责任链

当一个项目出现问题时，那么第一责任人就是这个项目的负责人，无论决策是谁做出，也无论客观因素如何。但是在这个团队内部，再次拆分责任的时候，就根据具体的原因来拆分了。而对于这个团队的上游（或者上级），在他的外部也需要承担失败的责任。这也是百度旗下任何的问题（不管李彦宏是否知情），大家骂的都是李彦宏的主要逻辑。

金字塔责任链主要适用于有明确上下级关系的场景下。

队列责任链

推动-协作者模型主要适用于平级或者跨团队间的场景。当一件事由专门的推动者负责推进时，就会由推动者来负责项目的推动工作，也承担着项目推进的责任。

因此，在责任上面，当需要某个人或者团队去执行落地某个任务时，充分的授权便是最为基本的条件之一。

团队成员的边界

我记得我们之前的KPI里面，个人绩效分为两部分：团队绩效+个人绩效。有的时候，团队绩效的比重占到了70%，个人仅占到了30%。这里的含义是：团队成就个人。这也与当今社会中的价值观一致。（比如：NBA总决赛的MVP大部分是从胜者的球队中选出的，金球奖的得奖人也是需要有团队的大赛成绩的）

因此有一句话：团队牛逼了，团队成员差不了；团队失败了，团队成员好不了。因此，当团队陷入某些困境中时，这样的原则要求团队成员思考如何帮助团队走出困境，而不是想好自己怎么不受影响，能够全身而退。倘若团队成员各自为战，团队翻盘的机会也就不大了。

不要害怕冲突，但要控制冲突的边界

冲突的发生有多重因素，但大多数都是彼此对于方案的不一致。冲突可以有效帮助彼此思考，方案考虑因素更多，但是冲突一定要满足：

1. 就事论事，对事不对人，切勿将话题转移到人的身上
2. 意见表达充分之后，给对方说话的“权利”
3. 冲突的目的是结论，切勿无限制扩散

和和气气会慢慢降低大家对项目的严肃程度，适当的冲突帮助彼此监督，考虑问题更加完善。

另外，在别人产生冲突的时候，自己当裁判，而不是“和事佬”。当裁判并不是看谁说对了或者声音大，而是看谁越界了（谁超出了事的范畴），对于越界的人及时制止或者直接终止冲突，这是“裁判”的作用。

因此，不要害怕冲突，而要善用冲突。

如何做决策

老百度有一句话叫：听多数人的意见，跟少数人商量，自己做决策。

首先，做好调研工作（看看别人怎么做）

调研就是看业内同样的问题都有哪些解决的方案，看看别人的方案主要可以发现：

1. 各自的场景有何异同
2. 核心的逻辑和算法是怎么做的
3. 最终的实现有何取舍（场景、目的不同，导致实现不同）

最终，都可以得出一个：基本的技术论调。

其次，听听大家怎么说（我们的现状和场景）

听听大家说，了解大家的诉求（也就是：需求）和方法（调用方式）。区分清楚哪些是需求，哪些是建议很重要。

需求：我希望你的项目能够实现什么功能，解决什么问题；

方法：你的这个项目可以通过什么技术实现；你的项目可以如何落地。

通过了解大家诉求，来了解我们的现状和场景。

再次，找到关键瓶颈点（成本关键点、技术关键点、周期关键点）

找到关键瓶颈点的原因是：如何做取舍。一个项目顺利的情况下，资源到位、时间到位、技术满足，那么项目仅仅是落地的问题。然而，在一些场景下，会发生：人不够用、时间紧、功能多等。这个时候往往就就是要做取舍了。

那么了解自己当前的瓶颈点，找到瓶颈点的确认关系，那么取舍的事情会相对比较容易。

最后，得出结论

已经做了比较充分的熟悉了，接下来结论也相对容易多了（也清晰了）。有了上面的流程，换个人得出的结论也基本接近。ba

附录

参考文章

1. 成本和质量是常量，范围和时间是变量 http://blog.csdn.net/thinkinchaos/article/details/1303105
2. 项目管理核心三要素 http://www.360doc.com/content/16/0411/22/4186849_549847818.shtml
3. 敏捷迭代开发 Time Boxing http://blog.csdn.net/jiyiqini/article/details/51303235
4. 结构化思维 http://wiki.mbalib.com/wiki/%E7%BB%93%E6%9E%84%E5%8C%96%E6%80%9D%E7%BB%B4
5. PDCA戴明环 https://baike.baidu.com/item/PDCA%E5%BE%AA%E7%8E%AF/5091521?fr=aladdin&fromid=3716836&fromtitle=PDCA
6. Bug的严重等级和优先级 http://blog.csdn.net/rabbit100/article/details/50980952
7. 什么是bug等级和严重程度 https://zhidao.baidu.com/question/466544098.html
8. 如何定义bug严重程度 https://www.zhihu.com/question/20280073
9. scrum 百度百科 https://baike.baidu.com/item/Scrum/1698901?fr=aladdin
10. SMART https://en.wikipedia.org/wiki/SMART_criteria
11. 结构化思维 百度百科https://baike.baidu.com/item/%E7%BB%93%E6%9E%84%E5%8C%96%E6%80%9D%E7%BB%B4/1482961?fr=aladdin
12. 极限编程 https://baike.baidu.com/item/%E6%9E%81%E9%99%90%E7%BC%96%E7%A8%8B/4690591?fr=aladdin
13. 《高效能人士的七个习惯》 https://book.douban.com/subject/5325618/
14. 《金字塔思维》https://book.douban.com/subject/1020644/
15. 《OKR》https://book.douban.com/subject/27084312/
16. 番茄工作法 https://www.jianshu.com/p/7d026e18c46d
17. 《搞定》（英文：Get Things Done）https://book.douban.com/subject/4849382/
18. 《系统之美》https://book.douban.com/subject/11528220/
19. SCRUM的四个会议 http://blog.163.com/linfeng_0212/blog/static/622213820151034538512/