传统项目管理VS敏捷项目管理对比

　　传统项目管理通常采用的是瀑布式、部分迭代开发模式，要求在项目建设时，需求足够明确、文档足够规范，迭代过程中需求变更越多、越晚，对项目影响越大，会影响到项目的交付质量。

　　敏捷项目管理作为新兴的项目管理模式，简化了传统项目管理的繁琐流程和文档。以 Scrum 为代表，欢迎需求变更，在客户需求不明确的时候，以在较短的周期内开发出可用的软件为目标，来帮助客户描述自己的需求。迭代过程中的需求变更会加入到项目继续迭代需求池，丰富项目的产品功能。

　　敏捷项目管理VS传统项目管理的相同点

　　敏捷项目管理声称要摆脱繁冗的流程制度文档，但是对于关键的项目文档，比如需求规格说明书等等，也是要求必须具备的。所以，敏捷项目管理的项目流程制度上的管理可以看作是对一套完善的项目管理流程制度的裁剪，只不过这个裁剪的尺度比较大，从而也对敏捷项目团队成员的适应性，自主性提出了较高的要求。

　　具体的敏捷方法在每个迭代周期中都存在立会制度，燃尽图、看板监控、计划发布等，这些和PMBOK中对项目生命周期的五个过程组启动、规划、执行、监控和收尾的定义没有冲突矛盾，实际上敏捷项目管理的这些措施可以看作是PMBOK项目生命期五个过程组执行的微缩版，区别在于敏捷项目管理的迭代周期，时间很短，在去执行过程中裁剪了很多规范正式的项目管理流程制度。

　　敏捷项目管理传统项目管理的区别

　　1、不同的管理方式适用于不同类型的项目，Scrum更适用于未知、不可知或持续变化的项目；

　　2、传统的管理方式有如计划经济体制，Scrum有如市场经济体制，适应变化的能力不同；

　　3、极大地缩短了用户与开发者，预期目标与实施状况，投资与投资回报之间的反馈回路；

　　4、将小型团队转化为自身命运的管理者，团队接受挑战，找寻应对挑战的方法，发挥创意，避开工作障碍，而这一切都无法由中央控制及调度系统预先安排。

　　各个项目管理模式的认识和理解

　　1、PMP：传统型

　　PMP的框架是基于知识点出发的，它的知识框架基本可以覆盖所有的领域，即是其框架是综合和通用的，而不是完全的软件开发项目管理，所以我们经常也会发现在工程领域的PMP框架运用，如：建筑工程类、硬件类、软件开发类等等。

　　传统型的项目管理模式，分为五大阶段，十个领域。

　　五大阶段分别为：启动、规划、执行、监控、收尾

　　十一个过程领域：范围管理、时间管理、质量管理、成本管理，（多快好省），人力资源管理、干系人管理、采购管理等。

　　每个阶段和过程领域都会有一定的概念介绍、输入输出内容、工具，提供给项目人员进行合理运用。

　　在PMP中，项目经理的作用，即是五个阶段的控制者、领导者，同时也是需要对结果负责的。

　　2、SCRUM:

　　谈及敏捷项目管理中的角色时，大多数敏捷方法（特别是Scrum）不包含项目经理。传统项目经理的角色和职责由Scrum团队共同承担，即开发团队（Development Team）、SM（ScrumMaster）和产品负责人（ProductOwner）。

　　Scrum的目标是能够使开发过程能够及时审视，更加透明，并达到持续开发。

　　Scrum 的核心是sprint，每个sprint即为一个迭代，或者一个相似工作的重复周期，为产品或系统产出增量。同一个产品的每个sprint周期是固定的。

　　基于sprint，我们制定product backlog，即待办事项列表，根据产品的不同，我们可以定制不同形式的backlog。核心目标是相同的，即明确目标、检查任务完成及时度，审视过程中存在的问题。

　　SCRUM的敏捷性在于，每一个sprint都是连续性的，在每个sprint的时间窗内，都会有15%的时间来制定sprint计划，并且每相邻的sprint之间没有时间间隔，即开发是连续性的，上一个sprint结束之后立即启动下一个sprint。

基于TAPD腾讯敏捷协作平台

1. 需求调研：根据软件需求文档和定期召开项目公共服务需求研讨会，来实现需求调研和收集
2. 需求孵化：任何人都可以在 TPAD 的“孵化分类”中，提出相关需求
3. 需求规划：产品经理对用户反馈、已实现功能的优化、新功能模块的增加等需求进行抽丝剥茧，设计成为需求
4. 迭代规划：项目经理首先创建一个新的迭代，并设定迭代的目标、开始和结束时间，然后再往迭代里添加本迭代须实现的需求
5. 迭代跟踪：研发过程中使用故事墙以及燃尽图进行迭代进度跟踪
6. 缺陷管理：研发过程中，测试工程师使用缺陷进行缺陷管理，开发工程师完成需求开发后，测试工程师跟进测试
7. 统计分析：项目经理可以将统计报表作为邮件内容，创建定时报告发送给团队成员，方便所有团队成员关注开发质量
8. 知识沉淀：每个团队成员都可以通过文档收集并整理知识条目，对知识库进行补充和反馈，实现团队经验的积累与传承

敏捷开发原则

• 测试驱动开发：测试代码基于业务需求，功能实现代码基于测试代码，一切以实现业务需求为目标
• 结对编程：在讨论和争论中，尽可能保证决定正确
• 代码共享：代码属于团队，而不是个人，谁都可以使用和维护它
• 较少注释：如果代码需要注释才能看懂，就必须重新设计
• 整洁代码：保证代码整洁，可随时适应新需求的开发
• 迭代跟踪：每个迭代都必须关联代码提交日志
• 自动化测试：包括单元测试、功能测试、集成测试
• 随时发布：根据需求最小颗粒度，可随时进行版本发布
• 站立会议：1.你昨天做了什么？2.你今天要做什么？3.你有哪些困难？
• 适应变化：整个开发过程和计划，可适应随时变化的需求

敏捷开发步骤

1. 产品经理根据软件需求文档，在 TAPD 上进行“父级需求”规划。或每个人都可以，在 TAPD “孵化分类”中提出自己的需求，包括“用户故事”、“验收标准”
2. 由项目经理创建一个新的“迭代”，包括“迭代目标”、“开始和结束时间”，并往“迭代”里添加本迭代须实现的“父级需求”
3. 由开发组长（架构师级别），把“父级需求”分解成“子需求”（包括用户故事、验收标准、迭代周期、开始和结束时间），并指定给开发工程师
4. 每天早晨根据“故事墙”、“缺陷”、“报表“，进行“迭代跟踪”和“缺陷管理”、“迭代统计分析”，每天下班前进行“代码评审”
5. 完成一个迭代后，提交到 StarTeam 上，通过编译、自动化测试（单元、集成、功能）后，通知测试小组进行测试
6. 测试工程师维护“缺陷管理”，开发工程师解决“缺陷”，不断往复，直至最终测试通过后，进行发布、部署、监控
7. 相关人员整理开发和使用文档，连同有价值的产物，提交到“TPAD文档”

本文内容可以任意转载，但是需要注明来源【头条@MichaelXu】和来源链接

一、项目启动会 initiating meeting

1、召开时间：启动阶段结束时召开的会议;

2、主要任务：发布项目章程，并任命项目经理，赋予项目经理动用组织资源的权力;

3、注意事项：

(1)会议召开前已经对干系人进行了识别，已经有了干系人登记册与干系人管理策略。此时应当让各方干系人进行认识和会面，让客户方领导表达信息化推动的决心，向项目经理和项目小组成员进行授权，调动员工的积极性，让客户方从上到下达成一种共识，为项目团队日后开展相关的工作扫除障碍。

(2)启动会召开时已经对风险进行了初步规划与识别(风险类别);(3)项目经理要向相关干系人汇报项目计划，但此时的计划是非常粗略的计划，不能用于指导项目执行。用于指导项目执行的项目管理计划需要滚动式规划渐进明细，通过制定项目管理计划过程组才能得到真正的项目管理计划。

二、项目开踢会议 kick-off meeting

1、召开时间：规划阶段结束。

2、会议目的： (1)正式批准综合性项目计划，并在干系人之间达成共识。(2)落实具体项目工作，为进入项目执行阶段做准备。

3、已做事项：开踢会议召开前，通常已经确定了项目的组织结构，并已经对团队成员的角色与职责进行定义。

4、已有文件：此时用于指导项目的项目管理计划已经制定出来，已经有了项目范围说明书、范围基准、各分项管理计划、进度计划、采购计划、风险登记册等文件。因此，在开踢会议中，通常需要对项目的范围、进度、成本、风险应对等事项进行确认，并在干系人之间达成共识。

5、与启动会的区别：PMP考试中项目启动会是initiating meeting，与开踢大会不是一个会，有一次PMP考试就同时出现了initiating meeting与kick-off meeting;当时，前者PMI翻译为项目启动会，后者PMI翻译为开踢大会。

三/四：焦点小组会议&引导式研讨会

1、首先我们回顾二者的定义：

(1)焦点小组会议：是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组会议往往比“一对一"的访谈更热烈。

(2)引导式研讨会：通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一好处是，能够比单项会议更快地发现和解决问题。 引导式研讨会有两种方式：在软件业用“联合应用开发(JAD)"，注重把用户和开发团队集中在一起，来共同改进软件开发过程。在制造行业，则使用“质量功能展开(QFD)"，来帮助确定新产品的关键特征，最终得到功能排序。QFD 从收集客户需求(又称“顾客声音")开始，然后客观地对这些需求进行分类和排序，并为实现这些需求而设置目标。

三/四、焦点小组会议和引导式研讨会区别：(1)二者形式非常相似形式，根本区别就在于参加引导式研讨会的成员具有跨职能的特点，而焦点小组通常是在项目团队所在的职能部门内进行(2)从规模来看，焦点小组会议通常限定在8-12个人，而引导式研讨会则没有这个限制。

五、规划会议与分析

规划会议与分析是风险管理过程召开的第一个会议，也是规划风险管理唯一的一个工具与技术。

PMBOK指南对这个会议是这样描述：项目团队需要举行规划会议，来制定风险管理计划。参会者可包括项目经理、相关项目团队成员和干系人、组织中负责管理风险规划和应对活动的人员，以及其他相关人员。

会议确定实施风险管理活动的总体计划;确定用于风险管理的成本种类和进度活动，并将其分别纳入项目的预算和进度计划中;建立或评审风险应急储备的使用方法;分配风险管理职责;并根据具体项目的需要，来“剪裁"组织中有关风险类别和术语定义等的通用模板，如风险级别、不同风险的概率、对不同目标的影响，以及概率影响矩阵。如果组织中缺乏可供风险管理其他步骤使用的模板，会议也可能要制定这些模板。这些活动的输出将汇总在风险管理计划中。

显然，这个会议虽然叫规划会议，但是却是在风险管理第一个过程里面召开的，顺利完成后，得到了风险管理计划。

六、状态审查会

　

状态审查会是监控风险的最后一个工具与技术。但项目风险管理应该是定期状态审查会中的一项议程。

该议程所占用的会议时间长短取决于已识别的风险及其优先级和应对难度。越经常开展风险管理，风险管理就会变得越容易。经常讨论风险，可以促使人们识别风险和机会。也就是说，项目状态审查会包括但不限于对风险的审查。

状态审查会：从本质上看，是一个全面评估的大会。具体内容包括：项目的详细计划;项目绩效的控制程序和方法;项目进行过程中，面临的风险和不确定性的判别和控制;项目小组的人员的安排;项目小组内部交流和沟通界面的形成;项目进行过程中，报告制度安排;客户关系;分包和承包者关系;与其他机构的关系;会计与核算的方式`内容和结果;项目进行过程中，其他没有言明但重要的事项。

七、投标人会议

投标人会议：(又称投标人大会、承包商会议、供货商会议或投标前会议)：是在投标书或建议书提交之前，在买方和所有潜在卖方之间召开的会议。

1、目的：保证所有潜在卖方对本项采购(包括技术要求和合同要求)都有清楚且一致的理解，保证没有任何投标人会得到特别优待。

2、注意事项：

(1)要把对问题的回答，以修正案的形式纳入采购文件。

(2)买方必须尽力确保每个潜在卖方都能听到任何其他卖方所提出的问题，以及买方所做出的每一个回答。

(3)时刻关注这样的一个问题：让所有的潜在买方得到的信息都是一样的，让所有潜在买方处于同一起跑线上，真正发挥招投标的作用。

八、项目经验总结会

经验总结会：任何项目收尾都要总结经验教训，更新知识库，这些更新将成为组织过程资产(organizational process assets)，供以后的项目参考。 对于经验教训总结我们应当注意：考试经常会问你经验教训总结由谁参与?由谁负责?由谁归档等。

1、经验教训总结，人人需要参加。

2、参与：项目干系人。

3、编写：项目团队(包括项目经理)。

4、负责：项目经理。

5、归档：PMO。

PMO，俗称项目管理办公室，在现代企业管理运营中越来越受到重视，建筑行业、IT行业等都不例外。它在企业中究竟是一个怎样的角色，会受到如此青睐呢？个人根据现实工作经验，发表点看法。

公司经过十几年的发展，一直以来，都是传统做法。做项目都是各产品部门自成一体，各自分别成立自己的一套项目管理模式，实施部夹在中间，既有单独去开发人员直接去实施项目，也有邀实施一起参与一些项目。陆续这样走下来，直到最近统计发现，去年有40多个项目竟然拖到了今年，一直没有什么进展，大家都急着说怎么办？于是乎，成立了一个所谓的“成本中心”即项目管理部来进行统一进行成本控制、项目质量控制。“亡羊补牢，为时不晚”恰好针对此事与有关人员聊了一翻了之后，对公司成立PMO有着重要意义，从以下几点来分析：

1、根据公司组织机构因素，项目统一管理，资源共享

翻开以往的项目记录，能够找到的资料极为少。各阶段文档严重缺乏，导致类似项目在启动时，只能是重新再来，无法借鉴以往项目的任何经验之类的，唯一值得参考的是项目产品本身，但毕竟作用微乎其微。一但项目离职，所有前期项目成果似乎都付诸东流，又是与客户的拖延。

再者，有些项目完成后，有些文档不愿意公开，不愿意共享，也成为了项目中一大障碍。设立PMO，完善公司自身内部机构。起到一个统一管理的作用，对项目的各文档进行监督、管理，使各项目能够充分达到一资源的共享，让项目的启动或者实施更为顺利。

2、提升项目质量

为了不使公司将来再次出现类似所有项目都在拖延或者暂停情况，必须狠抓项目实施质量。项目团队的建设、项目过程的监督、项目过程中的协调都需要一一重视，有了PMO，虽然不能说就有了一切，毕竟每个项目都有不同之处，但管理模式上可以类似，通过PMO的统一管理实施，逐层引导，慢慢建立相关的质量评估机制，让项目顺利走向正轨。

3、降低项目成本

每个团队各自成一体，对各自的成本无法估量，这无疑对项目管理来说是一不良表现，公司整体更加难以把握。项目的无期限拖延也是表现之一，无法保证项目的时间与质量，成本自然随着增加，导致的是公司整体利润各方面下降。有一部门在中间进行监督统一协调，或许会是一种在效的方法。

4、降低项目风险

项目经理的离职、文档的缺失、成本的增加、质量无法保证、项目沟通力度不够等都是导致项目失败

的原因，建立相应的风险评估机制，减少不必要的损失会是公司选择PMO的理由。

5、完善项目体制

要想有好的管理，首先离不开好的制度。身边既然远处不在项目，那管理也是无处不在。对于IT类的项目，管理模式算是在成长中，但是要想获得好的效益，在竞争中存活，公司内部良好的项目管理体制是有效的方法。公司与客户要想双赢，这是必经之路。采集者退散

但是PMO的理论与项目管理的先进理念都来源于国外，在国内算是刚刚兴起膨胀阶段。只有不断地探索才能不断地进步。设立PMO是有必要的，具体还是依中国国情而定。实践才是真正的硬道理。

根据条友们的反馈，老兵经过一周的国内外项目管理系统的研究，找出了三款功能勉强还行、永久免费的、可以下载安装的软件。

项目管理软件主要有以下几个重点：

• 项目节点管理
• 任务配时分配（任务时间管理）
• 项目文档、wiki管理
• 项目反馈管理（request ）或者邮件反馈
• 访问权限与角色管理

图形化方面

• 日历本
• 甘特图
• 项目统计图

但是很多系统都做得特别臃肿，把一些不必要的功能拿了进来，有的甚至把投标等东西都拿进来了。个人觉得没有必要。而必要的东西，比如项目结点管理就很多系统没有。

国外的（一般老外的系统软件相对完善，考虑的比较细致，因为试用范围比较广），国产的好一点的都是要付费的，或者5个人免费，但是要用他们的云端版，最终要被收割数据。或者养熟以后杀熟。

1、onlyoffice

很多人只知道onlyoffice 是用来做在线文档编辑的，其他他的集成版是由项目管理的，而且功能简洁，简单明了。项目结构管理、任务分配、甘特图、日历图等都有。后台管理方面访问权限管理为不同模块元素设置独立的访问权限并创建私有项目。您可以完全控制每个人可以看到的内容以及执行的操作。

老规矩： 关注老兵，私信回复： 19，自动回复安装手册跟下载地址。

2、jitamin （国产的）

我看完界面后，真实心理一凉，但是后面看到更多更垃圾的以后，觉得这款也还算可以，毕竟不要钱，项目、任务、甘特、日历都有，没有太花的东西，除了界面丑了点，其他都是可以的。

私信回复： 19，自动回复安装手册跟下载地址。

3、openProject Redmine

这两款都是项目管理中的老牛了，连IBM都是使用他们。它用日历和甘特图辅助项目及进度可视化显示。同时它又支持多项目管理。支持多项目。但是他们安装起来可复杂了。生手切勿实验！@李永乐老师

新闻、文 档和文件管理

feeds 和邮件通知

依附于项 目的wiki

项目论坛

简单实时 跟踪功能

自定义字 段的问题，时间项，项目和用户

SCM in集成 (SVN, CVS, Git, Mercurial, Bazaar and Darcs)

多个 LDAP认证支持

用户自注 册支持

多语言支 持

多数据库 支持

以上四款软件，私信回复： 19，自动获得跟下载地址。

本来想打个广告的，因为一粒云软件也在做类似产品，但是还没有发布，先放个图让打家看看

在当今极度变化的大环境中，产品团队正面临着一场巨大的变革。为了更好的适应大环境，研发团队都极力做自我调整。

达尔文曾说过“留下来的物种往往不是最强的，确实最先进化的”，从传统的“瀑布式”到“迭代式”，最终再到敏捷型研发团队。无数组织、团队都在进行思考、变革。

研发团队一定要通过无尽的加班，才能交付产品，不能一边享受生活一边交付产品吗？

产品一定要尽善尽美后再推向市场，是否可以通过小的版本快速推向市场？

答案是可以的，是时候来场变革了！

在本系列，我将和你一起探索敏捷项目管理的知识和实践。

---

最终客户价值在销售时交付，不是在计划时交付。

• 敏捷商业目标

1. 持续创新力–满足当前客户的需要；
2. 产品适应性–满足未来客户的需要；
3. 缩短交付进度–满足市场，提高投资回报率（ROI）；
4. 可靠的结果–支持业务增长和盈利能力。

---

持续创新

关起门来造轮子，已经无法适应当今复杂的商业和技术环境。开发产品和新服务都需要新意识。

特别是随着大数据、人工智能、工业互联、5G的发展，编程步入了一个高速发展的时期，从C语言到python，从低级语言到高级语言层出不穷，从成人编程教育到少儿编程的兴起，市场给了我们更大的机遇和挑战。

持续创新能力随着环境的变化显得尤为突出，当大家都在聊4G，5G已经悄然来临，快速占领行业浪尖–这就是持续创新的一种表现，带来的机遇和收益往往是巨大的。

创新思想并不会是模式化的、独裁的环境中产生，一定是在开发的组织、组织成员自我的约束下不断的适应当下的环境中产生。

---

产品适应性和缩短交付进度

产品研发周期越短、产品实施交付能力越快，仍然是项目经理和企业要优先考虑的企业目标。看起来似乎是矛盾的，产品研发周期短意味着缩小研发功能范围。

其实一点也不矛盾，我们有做过市场调查，70%的功能很少使用，频繁使用的功能模块只有20%，意味着我们付出大的代价，无法适应客户的需求，造成极大的浪费。

通过排除用处不大的功能，避免过度研发，减少总体工作量。精益研发的引进，简化开发流程、详尽的文档使其效率更高，将重点放在最有价值、增值的活动上，排除那些合规而无意的的活动上。最后，敏捷项目注重让每个成员都发挥其特长、增设防火墙杜绝无意义的打扰和压力从而提高研发效率。

---

人员和流动适应性

敏捷是一种思想、一种能力。其最终体现在团队成员的意愿上，组建一支适应能力强的团队–成员愿意自我改变、乐意突破极限而不是秉承固有的工作模式。

---

可靠的结果

---

质量是好产品的硬性条件之一，作为研发团队，交付质量可靠的产品，不仅可以鼓舞团队气氛，还可以扩大产品的附加价值。

---

• 敏捷定义

敏捷是一种思想、一种能力--敏捷最精简的定义

---

• 敏捷领导价值观

敏捷《相互依赖声明》中明确的阐述了我们的信仰，即核心价值观和永恒的目的。团队为何存在、要创建什么产品、为谁而而创造以及如何共同工作，这些组成了敏捷项目管理的原则。

一款优秀的产品背后一定有一个优秀的团队，一个优秀的团队一定是由优秀的人员组成，如何吸引留住优秀的人才，是当今企业普遍思考的问题。

最近网络上某某平台，运维人员因公司上级不人道的对待，一怒之下删库与公司同归于尽，事件导致该公司市值缩水几亿以上，对公司和人员、客户、社会造成极大的不良影响。–这就是传统型管理模式

相互依赖声明                                                通过持续为客户创造价值来提高投资回报；通过不断地与客户交互、共享所有权限来交付可靠的结果；预测不确定性，并设法通过迭代、预防、适应来应对不确定性；个体价值是团队价值的源泉、创建个体卓越的环境，实现创造和创新；通过激发成员的使命感和责任感来提高团队的绩效；通过使用根据具体情况而定的策略、流程和做法来提高效率和可靠性。                                                                                                                       

敏捷型领导的价值观念：仆人式领导是一种非常社会化的领导风格。虽然传统的领导力是关于“金字塔顶端”的人积累，囤积和锻炼（通常会堕落为滥用）权力，但仆人式领导是与团队分享权力，识别，优先考虑和满足他人和帮助人们尽可能地发展和表现。

仆人式的几个特性

1. 承诺将自己放到最后；
2. 关注他人的伟大；
3. 充分尊重个体；
4. 用于说出真相；
5. 开放自己的缺点；

• 总结：Scrum Master 采用仆人式领导需要将团队的需求放在首位。仆人式领导者主要关注团队的成长和福祉：首先为他人服务，对于希望在团队成员中发挥最大作用的现代管理者来说，仆人式领导是一个强大的工具。

---

• 敏捷项目管理架构

构想、推测、探索、适应、结束

---

总结

敏捷管理是最新出现的吗？不是，在2000年左右已经出现了。敏捷项目管理通过–做法、价值观、原则、概念架构组合形成了敏捷项目管理，继承了项目管理的丰富遗产，取其精华去其糟粕；敏捷也吸收了丰富的管理、制造、软件研发理论和时间经验（精益产品开发、KanBan等等）融合了最适合激动性和速度的世界观和思想体系。

敏捷项目管理并不是适用于所有人和所有项目，不是万事通的最佳实践。

敏捷是一种思想、一种能力；不要为了敏捷而敏捷。

在上一讲中，我们分享了程序员做项目管理的三个误区。有同学给我留言咨询一个这样的问题："如果我想转岗做项目管理，需要满足什么条件呢？"

其实，想要做项目经理，并没有太多硬性条件的约束，好的项目经理不问出身。在我的团队中，那些非常优秀的项目经理，不仅经历、知识背景各不相同，性格特质也都不一样。实际上，理论、经验、知识背景都是可以后天培养的，而意愿是第一位的，其次就是持续不断的学习和刻意训练。

今天，我们来聊一聊项目管理常识。古人云："会当凌绝顶，一览众山小。"掌握了项目管理的理论常识，就相当于拥有了一幅鸟瞰全局的知识地图。我们用两讲的时间，带你初步领略项目管理的知识体系框架。

项目管理是一门古老的科学，既包含工程技术、管理技术，又与组织行为学息息相关，比如系统科学、行为科学、心理学等，同时还涉及金融、会计等经济学范畴，逐渐发展成为了一门多维度、多层次的综合性交叉学科。

项目管理的历史

1917 年，美国一位名叫亨利•甘特的机械工程师，发明了著名的甘特图，就是一张标明计划与实际完成情况的图表。美国机械工程师协会和管理学会曾经专门设立亨利•甘特金质奖章，并把第一枚授予了已故的甘特，当时他所享有的盛誉可见一斑。时间切换到 1957 年，美国的路易斯维化工厂。他们把检修流程精细分解后，竟然发现，只要缩短最长路线上工序的工期，就能够缩短整个检修的时间。这就是至今项目管理工作者还在应用的"关键路径法"，简称 CPM。

到了 20 世纪 60 年代初，举世瞩目的"阿波罗"登月计划，更是让项目管理方法从此风靡全球。进入90 年代后，项目管理逐步标准化，国际上逐渐形成了三大项目管理的研究体系，分别是欧洲的国际项目管理协会（IPMA）、美国项目管理协会（PMI）和英国的 PRINCE2 体系。我要介绍的十大领域就是出自在国内普及度最高的美国 PMI 标准体系。

什么是项目管理？

要登上月球，光有宏大的想法可远远不够，你还需要让这个想法成为现实的大量资源，以及 一套科学严谨的落地方法。"项目管理就是变理想为现实，化抽象为具体的一门科学和艺术。"这是我听到过的对项目管理最为精辟的总结。

《项目管理知识体系指南》这本大部头可以说是项目管理领域的圣经，它的第一版是由 PMI 组织了200 多名世界各国项目管理专家，历时四年完成的，目前已经演进到第六版， 可以说是集世界项目管理界精英之大成了。

现在，就让我带你去看看这本书中对项目以及项目管理的官方定义。

项目是为创造独特的产品、服务或成果而进行的临时性工作。

项目管理就是将各种知识、技能、工具与技术应用于项目舌动，以满足项目的要求。

具体来讲，项目管理就是指把各种系统、方法和人员结合在一起，在规定的时间、预算和质量目标范围内，完成项目的各项工作，对组织资源进行计划、引导和控制。

由于项目管理的知识体系过于庞大，PMI 把它分为项目管理五大过程组和十大知识领域, 共 49 个子过程。今天，我们先来了解一下项目管理的十大领域。

项目管理的十大知识领域

项目管理的十大领域，将项目管理的工作内容划分为：项目整合管理、项目范围管理、项目时间管理、项目成本管理、项目质量管理、项目资源管理、项目沟通管理、项目相关方管理、项目风险管理和项目采购管理。其中，进度、成本、质量、范围是 4 个核心领域，风险、沟通、采购、资源、相关方管理是 5 个辅助领域和 1 个整体领域。学会了这些过程方法之后，不管你做什么，都可以按照项目管理框架和方法去做。我们来借助一个实际场景，帮助你更好地理解。

比如，你的部门最近有大量新员工入职，同时业务发展涉及越来越多的跨部门合作，领导希望你组织一场跨部门的篮球竞技活动，让大家以最快的速度熟悉起来。接到这个任务以后，如果你熟悉项目管理十大领域，就可以尝试从以下十个角度，快速地进行完整而有效的分析思考。

1. 相关方管理：如何管理相关方？

首先，你要弄明白一件事：在这个活动中，哪些人会是你的相关方？项目发起人对活动的预期效果是什么？比如说增进团队的协作，提升凝聚力等。

除此之外，这个项目是否存在更多的潜在相关方，可以助力到活动的成功举办呢？比如，经过一番了解，你发现 HR 部门最近刚刚成立了团建组，很愿意为活动提供赞助，那么，这时你需要思考，如何拿到这笔赞助？ HR 总监对于活动的诉求又是什么？

最后，分析完相关方方之后，你要思考一下，如何更好地管理相关方的期望和影响？活动过程中的各类决定，都需要谁来拍板？相关方要以什么样的方式参与？

2. 范围管理：做什么？

分析完各方相关方的诉求，就可以进一步来划定项目交付的范围了。在这个过程中，你的主要任务是搞清楚到底要做到哪些事，才能更好地达成各方的期望。

比如，这次篮球赛的预期目标具体是什么？是更关注活动的参与度和投入度、部门之间的合作交流，还是活动的对外影响力？你要确保围绕着预期目标来设计相应的活动方案，然后再进一步确定活动前、活动中、活动后分别要完成的具体工作。

3. 进度管理：花多长时间？

把理想变为现实，你需要一步一步来。进度管理，就是说你要规划好阶段性步骤，同时明确每个里程碑的目标成果和时间安排。

比如，活动的总工期是一个月，那么你可以分为四个阶段来进行：

第一阶段，启动项目并确认概要方案设计；

第二阶段，规划并落实人力和各项资源的投入；

第三阶段，确定具体的活动流程和详细分工，完成活动前的各项准备工作；

第四阶段，做好活动当天现场的统筹和运作。

4. 成本管理：花多大代价？

你要思考一下，活动预算有多少？资金什么时候到位？如何使用？你要去关注整个预算中成本最高的开销是什么，比如是一笔价格不菲的教练费，然后，你要判断这笔投入可能带来的收益，也就是说钱是否用到了刀刃上？总之，你要从全局视角去思考，如何更有效地管理项目的各项投入，以达到更加匹配目标的预期效果。

5. 质量管理：达到什么要求？

从这个角度来说，你需要先确定这次活动圆满成功的标准是什么，是现场参与人数、参与者满意度、管理者的满意度，还是对外传播效果？然后，以终为始，思考一下，你需要引入哪些必要的流程和方法，以保障活动效果的达成。

6. 资源管理：

有多少内部资源？ 你要知道，公司内有哪些核心资源是可以使用的？比如，宣传渠道、设计人员和经费支持等。另外，公司内部有哪些人可以作为支援活动的志愿者呢？公司可以提供活动所需的哪些物品？

7. 采购管理：有多少还要买？

确定了可以使用的公司资源以后，你要接着思考，还有哪些是需要外部采购？有哪些工作需要外部人员支持？如果经费受限，是否可以通过交换资源的方式，来获取更多的外部支持？

8. 沟通管理：如何管理沟通？

从这个角度出发，你需要考虑的是，活动策划团队、执行团队分别通过什么方式来进行项目沟通？与发起人和赞助方的沟通方式和频率是怎样的？你如何保持团队内外项目信息的高效传递，使用什么方式来同步进展？

9. 风险管理：如何应对风险？

你要弄清楚哪些风险可能会妨碍这次篮球赛的成功举办，比如天气因素、场地因素、交通管制、赞助方经费紧张、物料供应延期、公司内外政策变化导致活动被喊停、业务压力大导致兼职志愿者流失等等。你需要提前做好系统性的风险识别，分等级制定应对策略。

10. 整合管理：如何实现整体最优？

整合管理是要告诉你，作为这个活动的大内总管，你该如何去统筹全局，整合并协调各个环节的利益冲突和工作安排，在不断变化的情境下，根据活动的目标"裁剪"出合适的过程、 方法和工具，进行有效管理，从而达到全局的最优效果。

看到这里，你应该会发现，即使只是一场简单的团建活动，想要真正把它做好，其实并不容 易，你需要多方位的思考框架来指导落地实践。

有同学给我留言说，自己同时并行着很多项目，一头雾水，不知道从哪里着手。我刚刚介绍 的这十大领域，就提供了十个有效的思考角度，包含了你能想到的项目运作的方方面面。不管是多难多复杂的项目，所包含的要素无非就是这些，你都可以借鉴我们刚刚使用的框架进行拆解，逐个梳理，快速理清头绪。

总结

我们来回顾下今天的内容。首先，我给你简单介绍了项目管理的发展历程，以及项目管理的官方定义。

接着，借助实际案例，我们对项目管理的十大领域进行了层层拆解。

实际上，项目管理工作的涉及面非常广。关于项目管理的职责定位，不同组织在实践应用的过程中，给出的定义各不相同。根据我多年项目管理实践经验提炼 总结成了 12 个字：保目标，助决策，提效能，促协作。

项目管理是长期工作，不只是单一项目导向下，保证单一项目的成功，更是围绕项目成员的长期合作关系的培养。

本文是系列文章的第五篇：修身篇-如何进行项目管理。也就是下图中红色部分：

本文分3部分：

1. 项目管理的目标；
2. 项目管理的原则；
3. 项目管理的常用方法。

1. 项目管理的目标

项目管理的基线目标：保证项目质量、项目进度。项目质量、项目进度是项目管理的双因子。如果不能保质、按期完成，项目管理就是失败的。

项目管理的高阶目标：与大家建立良好的合作关系，团结一切可以团结的力量，奔向同一个目标。产品经理与业务、技术的合作很多时候是长期的，并且会形成口碑，在一次次项目合作中，和大家建立良好的合作关系，会为以后的项目助力良多。所以，项目管理不只是单一项目导向下，保证单一项目的成功，更是围绕项目成员的长期合作关系的培养。

在菩提的诸多项目合作中，三生有幸，遇到了时刻会站在用户&产品视角上想问题的开发负责人。

我们曾遇到很多不得不的技术项目，比如数据库迁移、系统迁移。这类项目，产品经理不太愿意碰，因为迁移项目一来，就意味长达半年甚至更长的时间不能上商业需求，迁移本身不直接带来商业产出，迁移项目又往往牵一发动全身，非常复杂，容易出错。

此时，优秀的开发负责人会主动帮产品想，在迁移过程中有哪些历史问题可以顺带手解决，哪些新的需求可以快速在迁移中穿插着做。

有的产品遇到迁移，可能真的半年不能动，菩提的产品总会有些惊喜，就是因为有优秀、主动、靠谱的合作伙伴。这样的合作关系建立是因为在一次次项目合作中，建立了很深的信任关系，大家对产品节奏、目标一致。信任关系集腋成裘，这是长期的项目管理范畴。

人靠谱了，事情就不会有太大问题。菩提建议大家做项目管理，尽量往高阶目标走：和大家建立良好的合作关系，团结一切可以团结的力量。

2. 项目管理的原则

1）团结一切可以团结的力量

产品经理需要协同的方方面面太多，靠自己一个人不免还是会百密一疏。如果每个环节的同学能主动上心，自驱推动来完成项目，对产品经理来说不只是省心，也会分解掉很多自己没有注意的点，而且合作非常愉快。通常来说，这样的团队，在需求评审完成后，产品经理马上可以进入下一个需求。

同时，这样的项目团队有凝聚力，有一定的对抗风险的能力，比如资源不足、外部竞争，项目组会自发去解决这些问题。

团结一切可以团结的力量，凝聚人心，自然能干事。这需要大家有共同的目标、共同的利益，同时也要有互相成就、利他的精神。

很多年前，有位大佬讲过，先成就别人，再成就自己。团队管理、项目管理都是如此。一个人可以走的更快，一群人可以走的更远。

2）小步迭代，快速奔跑。

确定的先做，不确定的先放一放。

一方面，业务、开发、设计都能快速动起来，动起来了，产品就可以滚雪球，不断得到用户、市场反馈，进而优化产品。同时，在迭代的过程中去把不确定的问题搞清楚，给自己时间窗口。

不要老想着一口吃成胖子，一上项目就憋大招，不憋大招好像都对不起自己的智商，所以一提需求就是10几个页面。排山倒海之势或许可以吓吓刚入行的同学们，但菩提真心不喜欢这种憋大招的产品经理。

憋大招，一方面往往意味着产品经理抓不住重点，产品从来不以量取胜，以价值取胜；另一方面这种憋大招，往往意味着产品经理欠缺思考深度，做出来的东西往往要返工，返工这事害人害己。

确定的先做，不确定的想清楚了再做。Less is more。

3. 项目管理的常用方法

1）制定详细&责任到人的项目计划

梳理项目流程，并确定每个节点、每个领域的负责人、明确Checklist和时间计划。

菩提之前写过2篇文章，大家可以参考，相信对项目管理、项目流程会有更详细、完整的了解：

1. 重大产品&项目流程长啥样？
2. 需求评审完，产品经理要干的6件事。

2）给自己找个好的技术负责人

好的技术负责人和不好的技术负责人，对项目来说是天壤之别。

好体现在主动、靠谱、沟通能力强、商业判断力强，能满足前3点就很好了，在商业判断上不要有过分的要求。因为主动、靠谱、沟通能力会补足商业判断。如果能遇到4项都有的技术负责人，就谢天谢地吧。

有人会问，技术负责人难道还能挑，不是被指定的吗？风物长宜放眼量，很多东西会动态变化，人和人之间的合作有的是一次性的，有的是半年，有的是1年，有的可能未来某天又江湖再遇了。信任的建立如同集腋成裘。

3）必要情况下，建立项目日会、周会机制

根据项目实际情况来确定项目碰头机制，但不要把会开成形式主义。同时，有了日会、周会、月会，随时有问题，依然要及时解决，别积压，项目管理的问题，往往一环扣一环。

4）必要时，采用逆向管理机制-反串讲

遇到超级大项目的时候，需求实在太复杂，又很多新手，需求讲了一遍又一遍，也不知道大家到底理解了没。怎么办？反串讲，在需求评审完后，让技术同学反串讲需求。

菩提经理过产品经理们写PRD（产品需求说明书）跟写书一样的时光，一期项目内容，动不动就是大几十页，参加项目评审的开发有三四十号人，评审往往要一整天，甚至几天。一场、两场讲完，实在难以判断，大家到底get了多少内容，然后我们就采用了反串讲的方式。

让开发来讲，他们理解的需求有哪些内容，关键点是什么，来过一轮后，效果好很多。

5）项目review不可少

项目review是大家拉平了一个视角看问题的场景，把中间的问题彻底暴露出来，把大家对业务、技术思考不成熟的地方暴露出来，把那些小九九也暴露出来，阳光照进来，下次合作会更好。

还是那句话，产品经理和每位同学的合作不是一次性的，江湖常见才是常态，既然是长期合作关系，大家尽量把问题掰扯清楚。

菩提曾经坚持拉着2个开发(那个项目只有2个开发)做项目review。开发GG们没有经历过这种review，被这仪式感搞的有点懵，觉得小题大做。结果大家还是review了一个大白板，都心甘情愿的领了问题回去。Review完，大家再一起吃一顿火锅，没什么问题一顿火锅解决不了的。

下次项目合作的时候，2个开发GG就是自己人了，产品经理就可以放心多了。

对项目管理的小结

项目管理是长期工作，不只是单一项目导向下，保证单一项目的成功，更是围绕项目成员的长期合作关系的培养。项目管理的目的：保证项目质量、项目进度。

项目管理的原则：团结一切可以团结的力量，小步迭代、快速奔跑。

项目管理的常见方法：

1）制定详细&责任到人的项目计划

2）给自己物色好的技术负责人

3）建立必要的日/周会机制

4）必要的项目逆向管理机制

5）项目review不可少

下1篇开始讨论如何培养产品经理的底层基础能力。

相关阅读

第1篇：认知环境，环境对产品的影响无孔不入。

第2篇：修身篇-产品经理需要的3项核心能力。

第3篇：修身篇-如何培养商业洞察力。

第4篇：修身篇-如何培养产品设计与规划能力。

作者：菩提，西湖渔歌公众号原创首发。微信公众号：西湖渔歌

本文由 @西湖渔歌 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash， 基于CC0协议。

全文共4276字，预计学习时长13分钟

并不是所有问题都有深刻且明确的解答，数据科学界特别如此。

讨论数据科学家应该具备的辅助技能时，项目管理是常常被提及的软技能加分项。但是很少有关于如何将项目管理技能应用于数据科学的专门教程，相关的建议往往也很浅显。

无论任何时候提及这个问题，标准答案总是“只要去阅读已有的项目管理资源”。

笔者曾在一个牵涉几百万美元的公司级项目中担任项目经理，可以告诉你一些经验之谈。项目管理并非制定计划并逐一划去计划表上的事项。亲身参与过数据科学项目就会知道，由于难以预见的情况，计划常常不能如期完成。事情总比想象中耗时更久，种种问题也会不期而至。事实上，Daniel Kahnerman和Amos Tversky创造了“计划错觉”这个词，用以形容人们低估完成任务所需时间的倾向。

项目管理希望解决人类交付的不可靠性。这就是为什么笔者希望给出基于有效项目管理技巧的可行建议，而不是一系列昂贵的工具软件，或者一个讨论CRISP-DM流程每一步用时的粗略大纲。

为什么要使用项目管理工具？

项目管理者用于监督和报告项目进度的工具种类繁多，这些工具看起来似乎只是增加了工作量，使得项目经理的薪酬更加合理，但事实并非如此！使用这些工具，不仅可以维持和高级管理层的沟通，也能帮助项目经理和其他项目参与者记录假设和项目依赖关系。

灵活软件开发宣言提到，应该总是重视人和交流多于过程和工具。相应地，在数据科学项目中，应该重视解决商业问题多于夸夸其谈。尽管你可以论证项目管理工具并非必需，但它们将对系统性地解决和思考问题产生令人惊讶的助益。

正如灵活软件开发宣言所述，这些工具的使用和规范应该视项目规模而定。所以，如果你只是在为丰富简历而进行一个周末即可完成的数据科学项目，就没有必要设计一个花哨的甘特图。但是如果要在搭建项目的过程中时时牢记假设，建立一个RAID日志（包含风险，假设，问题，依赖惯性）可能很有必要。即使在项目结束之后，它也将帮助你在几个月或几年后验证自己的假设。在接下来的阅读过程中，牢记可以，也应当按照需求来选择工具。

数据科学项目管理的工具种类

你的项目管理工具包中有什么？

1. 有条理地思考问题：RAID日志——RAID即风险，假设，问题和依赖关系。提到项目管理工具，第一个想到的可能不是RAID日志，但笔者认为它们是最重要的。无论项目大小，笔者都建议创建一个RAID日志。无论处理什么问题，都需要假设来构想解决方案。在收集数据时，可能会遭遇扰乱计划的风险。在列出所需步骤时，依赖关系有助于安排步骤的执行顺序。将这些内容记录下来，就是全面了解项目而不致对其毫无头绪的关键。

2. 理清待办事项——WBS工作分解结构。这其实就是待办事项清单的时髦说法。数据科学过程框架——比如CRISP-DM，KDD和OSEMN——总结了数据科学项目中的步骤，然而将这些框架应用于具体问题非常重要。比如，在OSEMN框架（获取，清洗，探索，建模和解读）中，需要执行什么样的清洗工作？计划使用的是哪一个模型，如果这个模型无法工作，备选项又是什么？如果是在进行团队合作，WBS甚至能帮助你将任务分配到个人。

3. 规划每个任务或阶段的顺序和时长：甘特图——甘特图结合了RAID日志中的依赖关系和WBS中的任务，有助于计划任务的时间和顺序。它可以相当详细（和WBS上的每个任务相对应），也可以十分简略，仅仅与高级过程相对应。高级甘特图通常被称为“路线图”，它是与高级管理层沟通的最佳方式之一。

RAID日志

创建RAID日志是反映商业问题，并评估数据科学问题能否解决商业问题的方法，它也能帮助保持与其他项目参与者之间的联系以解决问题。

考虑业务问题

笔者建议在了解商业问题后首先记录项目的风险，假设和依赖项，尝试将商业问题转变为数据科学问题，然后考虑如何解决。这自然会导致问题和假设的提出，可以记录这些问题并回顾。

假设

假设通常是一些不言自明的事情，它使人产生一个项目比事实上更加容易的错觉。假设可能关于多个方面，包括：

1. 数据：数据科学家常常在此马失前蹄——特别是考虑到数据清洗通常占数据科学家工作量的80％。可能会对数据做出的假设包括：期望的数据格式，数据有哪些有用的特征，数据是否具有普遍性，某些特征是否能用于代表另一特征等。

2. 模型：所有模型都有各自的假设。例如，K-Means聚类假设聚类内的方差本质上是球形的，并且聚类的大小相同。没有空值是另一个可能的必须条件，这可能要求在WBS中加入一步估算。记录下这些假设和违反假设之处对于确保完全理解模型的利弊十分重要（并在WBS中记录满足假设所需的必要步骤）。

3. 工作流或数据流水线：尽管倾向于不考虑模型部署后的变化，但是如果将来发生变化，那么记录有关工作流的假设就非常重要。例如，最初可能假设地理位置只能分为市或州，但是将来数据流水线可能会更改为获取经纬度，并导致生产模型的调整。

依赖关系

依赖关系可能是数据科学项目遵循的自然顺序，例如在尝试建模之前先完成数据清洗。依赖关系还可以表明某些团队需要交付给其他团队的成果，例如数据工程师向数据分析师或机器学习团队提供的干净数据文件。通过记录依赖关系可以了解某个项目延迟的原因，而不是将其简单归咎于最后一个经手该项目的团队。

风险

风险可能难以区分，并且常常与其他RAID日志项混淆。假设和依赖关系有助于了解风险所在。风险通常是实际问题的征兆（实际上，如果意识到了风险，可以用一个新的问题来代替它）。

问题

仅在项目开始后才需要记录问题。那么为什么要这样做呢？项目管理不仅涉及项目规划，还涉及后续的管理和文档记录。当下看来似乎是在浪费时间，但是像任何好的做法（代码中的* ahem *注释）一样，将来它会带来回报。了解过往项目中遇到的问题（尤其是对于不经常更改数据基础结构的公司），可能有助于防止低估潜在的工作量，准确地估计项目时间轴和效益！

项目参与者之间的联系

最佳做法是让不同参与者定期在RAID日志上签名。如果这看起来过于繁琐，检查所有的新项目或更改就可以使所有参与者了解情况并承担责任。这样IT和商业利益相关者可以轻松确认假设或风险，他们的意见将帮助你保持正确的前进方向。

工作分解结构（WBS）

WBS把项目从主要交付内容分解为越来越小的部分，直至各个任务级别。列出各个子任务有很多好处：

思考您需要做什么

由于对解决实际问题的过度热心，任务可能被低估，导致为其分配的时间不足。或者，更糟糕的是，简单但不可或缺的步骤可能被跳过（检查和估算缺失值！标准化数值特征！一键编码类型变量！），模型结果表明的基本特征转换问题可能被忽略。通过强迫自己将高级数据科学项目的各个阶段分解为一个个子任务，就可以形成标准且可重用的方法。

这一做法最大的优点是，WBS可以在将来的项目中反复重用。又遇到一个可以使用聚类解决的问题？只需找出上一个聚类项目中已经列好了步骤和事项的WBS！

估计每一步的时长

WBS是计算项目所需用时的好办法。每个任务已经列出，添加耗时估算就变得十分简单。与估计高级别任务的时间线（例如，数据清洗需要2天）不同，如果发现一项任务非必需或者违反了模型的假设，这表明该任务不太适合您的数据，并且可以立即确定节省的时间。

由于人们不擅长估算事情需要花费的时间，借鉴历史记录是一个好办法。如果在过去的项目中曾经记录过每个任务的实际耗时，则可以更好地预测未来项目的时间。

识别依赖关系

尽管某些任务之间的依赖关系很明显（如在使用机器学习模型处理特征之前需要先估算空值），但还有其他更微妙的依赖关系。尤其是数据科学过程可以在特征工程和建模步骤中迭代时，仔细考虑任务之间的依赖关系有助于高效地规划模型流水线。

例如，可能想对刚刚经过标准化处理的特征使用线性回归模型，然后再回头看看各种变换如何影响模型结果。因此，尽管两次迭代可能都依赖于线性回归，但可能仅需对第二次迭代应用对数转换。记录任务的顺序和任务间依赖关系有助于创建可重复使用的干净流水线。

甘特图

甘特图是获取WBS并将其直观表示的一种方法。通常，任务沿竖直轴列出，时间沿水平轴延伸，每个水平横条显示一个任务的时间跨度。任务也可以分为工作流组，特别是在项目规模较大且涉及跨组织的多个职能部门的情况下。

确定时间跨度级别

如果是独自完成项目，可以跳过下面这个项目管理工具。但是如果是在团队合作中，笔者认为高级“路线图”非常有用。笔者认为，视觉学习者比人们想象的更多。或者至少，当事情以图片形式呈现能使人们更快地理解。这就是为什么像路线图这样显示项目进展情况的图表（尤其是在长期项目中）可以缓解高级管理层的担忧并保持他们的投资。

牵涉大型组织中多个团队的项目适于在较低的任务级别创建甘特图。不过这种情况下通常会有专门的项目经理负责监督和管理项目。

结论

尽管可能无法避免意外延期，但坚持使用这些工具有助于预见风险，估计任务时长，并保持与其他项目参与者之间的紧密联系。笔者建议在下一个项目中使用这些工具的简单版本，总结如何进行和规划数据科学项目以及如何改进！

在项目正式开始前和项目进行过程中，使用RAID日志来识别假设，依赖关系，风险和问题。在WBS中列出所有必要的任务，并包括预期的开始和结束日期、任务之间的依赖关系，并且根据项目的复杂性和规模决定负责该任务的人员。

甘特图采用WBS并将其绘成图表，以显示每个任务或工作流的预计用时。高级甘特图也称为项目路线图，用于帮助高级管理层了解进度。可以使用精美的软件来应用这些工具，出色的Excel或Google表格也可以解决问题。

留言点赞关注

我们一起分享AI学习与发展的干货

如转载，请后台留言，遵守转载规范

为什么说项目管理是每个人的底层能力？

我是何苦，一名程序员出身的项目经理。我始终认为，项目管理这项技能，可不仅仅是项目经理

才需要掌握的。当代项目管理发展之 快已经超过了我们的想象，美国《财富》杂志就曾经预言，项目

管理将是下一个世纪的首选职业。事实上，项目管理能力，已经成为一项职场人士的必备技能。

为什么要学习项目管理？

通常来讲，程序员精进的道路大概有两条：一条是走个人能力线，成为技术专家；另一条是借助团队能

力往前走，成为技术管理者或业务管理者，只是这条路上的管理岗位是需要时机和坑位的，可遇不可

求。

但是，项目管理则很不同，只要你在一个多人协作的团队，就一定会有项目管理的需求和机 会。蓬勃

兴起的项目管理学习热潮，为程序员开辟出第三条精进之路。

而且，不同于技术管理，这条路线走起来，几乎不需要任何外界依赖因素。一开始你甚至并不需要有组

织的明确授权，你只需要在做好自己的基础上，学会更多的项目管理技能和方法，以项目整体目标为己

任，主动操心和解决项目团队的问题，帮助团队做得更好就可以 了。如果你这么做了，你的 leader 一

定会很开心，你的技术之路也会越走越宽广。

实际上，我身边的很多技术管理者，都非常希望自己团队的程序员能够具备项目管理的 sense 和能

力。在很多大企业中，已经有越来越多的主程开始承担项目管理职责，在他们的绩效考核中，也会明确

写入一定比例的项目管理责任，这种类型的项目负责人已经逐渐成为组织中的中流砥柱。具备项目管理

能力的程序员，无疑会在这个程序员严重同质化的局面下，拥有更多的竞争优势。

除此之外，我认为，项目管理是新一代"进化型"程序员的重要底层能力。

因为说到底，项目管理是一种组织整合能力。在传统的组织模式下，作为程序员，你只需要做好组织中

的"螺丝钉"就好了。但超级个体时代的来临，会让项目管理这种组织能力，逐渐迁移到每一个个体身

上，成为个体底层能力中全新的扩展接口。

优秀的程序员都很擅长与机器和代码打交道，但是，当场景扩展到需要通过团队去拿到项目 结果时，

对技术的高度关注，缺乏专业的方法和工具，以及不擅长沟通协作等，会让程序员遭遇到各种团队问

题，很难发挥各个角色的协同整合作用，以实现真正的闭环。

想要让你的成果真正转化为对用户或客户有价值的产出，这是一个复杂的系统工程。而项目管理的思维

和方法，构建出了一套多人协同的底层操作系统，是你从个体走向团队，必须具备的底层能力升级包。

如果你能比别人更早地意识到这一点，你就已经走在了很多人的前面。

如何有效地学习项目管理？

那么，如果你真的想要学习项目管理，该从哪里开始呢？

项目管理作为一门学科，经过多年发展已经呈现出庞大的知识体系，光国际标准就有三套。 就拿国内

普及度最高的 PMI 标准体系来说，它将项目管理分为十大知识领域和五大过程 组，共有 49 个子过

程，600 多页内容。对于很多初学者来说，实战经验缺乏，书本知识会显得愈发晦涩难懂。

不是所有人都可以很幸运，能在关键成长期遇到师傅的引导。如果你完全依靠自己去摸索， 要么在实

践中撞得"头破血流"，要么迷失在大部头理论的海洋中，无法快速找到真正有效的解决之道。

八年的互联网项目管理实践下来，我越来越觉得，项目管理是科学、艺术的结合体，同时也是一门手

艺。只有经过实践操作的磨砺，你才能真正掌握使用所有框架、方法和工具的正确时机和火候。

我们借用"体机用"的模型来看，"体"是本体，对应于项目管理的知识体系，比如《项目管理知识体

系指南》；"用"是效用，对应于各种纷繁复杂的项目管理实践，比如某某公司的项目管理做法。这些

都是可描述、可传授的，市面上你很容易可以找到相应的资料。

但是，这些内容都无法真正满足实战中多样化的学习需求。项目管理作为一门实践科学，最难掌握的，

其实是"体机用"的这个"机"。这里说的"机"不光指时机，同时还意味着环境和条件，也就是说将

知识技能和具体的"场景"相结合，才能发挥出真正的效用。