导言

项目本身无好坏之分，项目管理有做好与做坏之别。在互联网大厂的体制下，想要做坏一个项目很难（可以通过换人、追加资源等方式消除风险），想要做好一个项目不容易，需要团队及PM付出大量心血和精力。在这些做好的项目中，我们也观察到很多PM做的疲惫不堪，甚至厌倦做项目管理工作，更有甚者一度对项目管理工作对技术人员的价值产生怀疑，所以，对于技术PM来说“优雅”做好项目管理至关重要。

想要优雅做好项目管理，掌握项目管理的思维、理论、工具和方法至关重要。

集团生态涉及100+BU，有成熟业务诸如淘宝、天猫，也有创新业务达摩院、阿里体育；有纯线上互联网业务阿里妈妈，有线下业务银泰百货，也有线上与线下结合盒马业务；有大量toC的电商营销业务，也有toB的服务平台业务，比如千牛、客如云、阿里云等。每种业务因为其定位、面对的客户、所处发展阶段，面临市场竞争、团队规模等不同，这就导致了不可能有一套规章制度适用所有业务，淘宝的电商项目管理模式，并不适合灵犀互娱的工作室模式，这也是PMO团队与业务结合才能大方光彩根本所在。但没不是每个BU都能有自己的PMO团队，而项目管理工作，又会贯穿业务的整个发展过程，为了顺利推进业务发展，团队中部分技术同学就有PM管理职责，也是担任PM同学的一种培养。技术人员想要做好项目管理不容易，即需要具备PMO相关管理理论和工具，也需要转化自己的做事思维模型，还会面临发展方向选择是锤炼技术能力、提升影响力还是转行做专职PMO或者产品。

基本概念

什么是项目、项目管理？

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

管理（ Management ）通过实施计划、组织、领导、协调、控制等职能来协调他人的活动，使别人同自己一起实现既定目标的活动过程。

项目管理（Project Management） 在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望的过程。

从项目的基本概况可以看出，每个项目是具备三种基本特征即独特性、临时性、目的性。而项目管理就是在有限资源（时间+成本）的情况，运用专门的知识、技能、工具和方法解决独特性，达到目的性的过程，而主导这一切的就是项目经理（即PM）。

项目经理( Project Manager )是项目团队的领导者，首要职责是在 预算范围 内 按时 优质地领导项目小组完成全部项目工作内容，并使 客户满意 。为此项目经理必须在一系列的项目计划、组织和控制活动中做好领导工作，从而实现 项目目标 。

从本质上来说，技术同学做PM都是在承担项目经理的职责，对初次做项目管理的同学来说除了要接受师兄的言传身教外，还需要自身掌握项目管理的理论、工具和方法。

项目管理制度在公司中的作用？

在业务发展过程中项目管理如此重要，以至于在互联网公司治理过程中采用了实虚线管理制度，实线为直属汇报关系，虚线为业务线，通过这种管理方式有效打破部门墙，快速组织内部资源。

项目可以划分为两类，这两类项目对PM管理技能要求也会有差异，当我们作为项目PM时，首先要清晰知晓项目的分类，并以此来建立相关的项目管理制度和规范。

一类产品项目（或者叫业务项目），经历从小到大需要不断持续迭代，典型特征就是规模小、持续型，互联网项目大部分都是这种类型。作为这类项目的PM，需要业务发展壮大过程中不断演化系统，因此会需要承担比较重架构职责，同时还要围绕团队效能不断调整研发流程，这类项目对PM的技术能力、架构能力、团队管理要求比较高。

另外一类为战役项目，基本为一次性需要大投入高产出，典型特征为规模大、阶段型，历年双十一大促项目基本上为此类项目。作为这类项目的PM，需要全局了解，明确职责，定义上下游规范，同时还要围绕团队效能不断调整研发流程，这类项目对PM的沟通能力、协作能力、影响力要求比较高。因为涉及人员众多，常见的是由PMO团队来统一管理。

在技术团队中选择这两类项目的PM，一般会有三个出发点。

3、识人用人，培养人：难度低，风险不大的项目，对于一些新人、判断不准、需要进一步摸清能力边界的技术人员，用来安排担任PM，通过担任PM过程中，进一步观察识别考察。

技术团队的PM的选定大部分基于以上原则，作为PM同学在接手项目时不妨做考虑考虑，选定自己的背景，以便于针对性的提升应对。 



对于很多初次做PM的或者做过PM后仍然很痛苦，或者是掌握项目管理的流程、工具但在使用过程中仍不能明白其精髓的技术人员，很有可能是项目管理的思维模型尚未建立。当你走上PM岗位时，术是工具、方法、理论，道是做事的思维模型，所以一定要让自己思维模型做一次升级转化。

转化思维模型

大部分技术PM一开始从开发者转过来，无形中会有一种思维定势。即要做好交给自己的事情，执行到位是，常见的情况是在项目功能模块划分时，往往选择难度最大的功能模块来开发，一方面是担心人别人做不好，影响项目的进展，高风险内容放在自己手里最放心，另一方面也担心团队其他同学有意见，怕团队中其他人觉得自己作为PM没有起到核心作用。这种情况是比较典型的点状思维、线性思维模式，没有从整体项目角度来思考项目目标、项目风险、任务分配，其实这种方式才是项目管理中的大忌，增加项目风险的同时，会让PM精力分配极为不合理，导致各方面工作做不好。因此，作为PM是要先做好三种思维模型的升级转换。

1、目标导向、计划先行：作为项目PM首先要明确项目目标，充分考虑项目风险后，制定详尽计划，并能推导出目标结果来，实际执行过程中紧盯目标按照计划执行，与目标无关的事情再容易也不要做，与目标关系不大又不得不得事情，少精力做或者让别人做，谨记项目管理是预期性管理，不是超期性管理。

2、以始为终、积极应对：项目的目的就是为了“结束”，开始一个项目的目的是为了Close这个项目，进入一个项目的目的是为了退出这个项目。对于项目过程中碰到已知或未知的困难，站在终点去思考，一定会完成，所有困难时达成目标必然的过程，保持积极心态应对，不抱怨。

3、团队协作、通过他人拿结果：作为PM时已经不是一个人在战斗，是一个团队，而PM是这个团队的领导者，首先要让团队成员彼此看见、消除误解，再次明确分工、职责边界、协作协议，团队团队成员、共同努力才能一起拿结果，不要最后是个人成功了，项目却失败了。



从开发到PM，是类似于从演员到导演的转化，也是从战术思维到战略思维的升级过程，这一步是里，一定要做好。才能坦然面对项目管理过程的各种问题，比如别人埋怨、各种突发的风险等。

项目管理核心概念

项目管理概念出现于20世纪中叶，20世纪60年代成立项目管理协会PMI（Project Management Institute，PMI）。PMI一直致力于项目管理领域的研究工作，并制定了行业标准，由PMI组织编写的《项目管理知识体系PMBOK指南》已经成为项目管理领域最权威教科书。在项目经理认证方面，PMI推出的项目管理资格认证PMP(Project Management Professional)，感兴趣的同学可以考一个。 《项目管理知识体系PMBOK指南》最新版已经到第7版，在内容上并没有延续以前的五大过程和十大知识领域的结构，而是将五大过程组变成了十二项原则，十大知识领域变成了八大绩效域，虽然结构变化挺大，但相关领域知识内容变化不大。第七版更加强调VUCA（乌卡时代）和在不确定性中如何敏捷相关的内容，更加强调绩效领域的相互作用关系，但缺乏绩效领域的逻辑关系，感兴趣的同学可以了解下。《PMBOK指南》第六版的内容有比较强的逻辑性，适合体系化的分享，一样可以应用于现在的项目，所以本次分享还是以第六版的内容为主，

项目过程周期全景（五大过程）

实际工作中，我们参与的项目基本经历以下过程，大家基本也是按照下面流程过程进行工作排期，覆盖整个项目周期，这只是项目管理过程中要经历的工作，过程中涉及的相关理论和工具是不知道的，所以这也是我们很多项目拷贝一个别人做的项目语雀文档，就可以做项目管理的原因，关键动作补缺位，也不会出大错，但做完后总是感觉不得法。在这个过程中看不到沟通管理、也看不多人力资源管理（圈人），能做好但做不优雅。



PM指南中定义一个项目五大过程，项目从开始到结束主要经历，启动、规划、执行、监控、收尾，在这五大过程组中涉及到整合管理、干系人管理、进度管理、成本管理、质量管理、沟通管理、人力资源管理、采购管理、风险管理10大领域知识。



五大过程中，每一个过程都有些关键动作要执行，结合实际项目经验，为了便于记忆我把里面过程、核心动作了总结。整个项目过程中三字诀来说。

过程一：定目标，核心涉及三个动作，圈资源，明确项目的各类资源情况，比如前端、服务端、产品具体参与人员，能参与的程度，全部精力还是一半都要明确清楚，外部依赖资源等等；定规范，完成项目团队的组建，定义团队开会制度、日报周报、风险上报，产品需求变更流程制度规范等；确需求，明确项目背景，完成需求范围的确认，需求方案评审等等。

过程二：抓过程，核心涉及三个动作，做排期，做好项目人员任务分配、里程碑、项目详细排期，关键路径拆解等；进评审，完成交互/UI评审、技术方案评审、测试评审，评审的动作也要做到排期内，切勿出现等到评审完成后再确定排期的事；识风险，实际研发过程管理、进度跟踪、把控，发现识别解决风险等等。

过程三：达结果，核心涉及三个动作，保交付，确保项目如期上线交付；做好项目复盘总结项目过程中的得与失，如果再来一遍那些部分会坚持做好，那些部分会放弃，一定要做好复盘总结，这才是团队成长的关键，归好档，项目prd文档、设计文档、架构方案文档、邮件等等资料都要做好总结沉淀，以备后面同学学习。

十大领域知识

在项目过程阶段会涉及到十大领域知识，每个阶段重点涉及哪方面的知识可以查阅《PMBOK指南》，每项领域知识内都有详细介绍。

正如我们所知，项目管理并不局限于软件行业，针对软件行业，整合管理、干系人管理、进度管理、风险管理、沟通管理是特别重要的领域知识，需要重点掌握，针对这些重点领域知识，结合项目实际管(碰)理(到)经(的)验(坑)，后面会做一些更细致的分享。 



为什么要学习项目管理理论？

作为技术人，主要工作是开发，又不想走到管理岗位，还有些社恐，有必要学习项目管理知识么？或者觉得自己做的项目挺好的，虽然不懂什么项目管理理论，但项目都按时发布上线了，还有必要学习项目管理知识？有这样以为的技术PM可能不少，主要还是有些内容没有看清楚

当前世界发展越来越快，变化也越来越大，因为信息的互联互通也让这个世界变的更加复杂乌卡（VUCA）时代，《PMBOK》第七版的变化也是为了更好应对这个世界发展而出来的。再次，今天商业运营基本规则还是，运用公司体制将各种资源、系统、方法、人员结合在一起，在规定的时间、预算和项目目标范围内完成项目的各项工作，快速、高效完成价值创造，赢得商机，对于具体实施的人来说这离不开完备的理论支撑。最后从项目上来说，新软件的开发、新建筑的创造、一次家庭出游等都可以看做是一个项目，需要用心经营才能做好，而更关键的是每个人的一生也可以看做是一个项目，具备临时性、独特性、目的性的特征，需要做好人生规划（计划），并坚定不移的经历、学习、提升（执行），才能得到自己想要的生活（项目目标）。所以无论是当前时代、商业运营还是个人发展角度来说，都需要掌握项目管理相关的知识。

项目管理的理论体系可以应用到各类行业，比如建筑工程、通信、电子、化工、金融等各行各业。为了在互联网产品中更好掌握应用项目管理的技能，还需要知晓掌握软件软件生命周期，软件开发流程。根据不同的项目特性，选择不同的开发模型。

软件开发模型

软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。

-摘抄自百度百科

瀑布模型

瀑布模型是较早出现的标准软件开发模型，于1970年W·Royce提出。该模型给出了固定的顺序，将生存期活动从上一个阶段向下一个阶段逐级过渡，如同流水下泻，最终得到所开发的软件产品。这是一个非常经典的模型，即使在互联网盛行的今天也没有完全消亡，比如说Scrum每一个迭代内，都可以看做是一个小的瀑布模型。还有一些常见的外包项目、2B交付类项目都是采用这种模型。 



图片来源

瀑布模型的优势：分工清晰，阶段目的非常明确，有助于提升阶段效率；其次因为在早期能够明确项目的范围和概况，在开发阶段也能有效组织和调配资源，中间过程变数小，交付预期明确。

瀑布模型的劣势：各阶段需要清晰、详尽的文档，在开发中也需要撰写大量的文档，这个过程增加大量时间，也极大的增加了工作量；其次项目后期展示成果给客户增加项目不满足期望的风险，常有交付功能不是客户期望的情况产生；再次需求变更，因为要涉及各阶段，变更成本非常高。

适用场景：软件需求十分明确且不会频繁变化的项目，比如外包类项目，2B类项目。

迭代模型

迭代模型出现时间也比较早，早期被称之为“分段模型（stagewise model）”。从一定程度来说每次迭代开发都是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程，也可以说是小型的瀑布式项目组合。这种分割的好处也显而易见，就是阶段目标可检验。 



图片来源： https://www.cnblogs.com/liuqiuyue/p/10662488.html 

迭代模型的优势：每个迭代阶段都可验证，成功降低项目交付风险；其次灵活性高，新的需求变更可以下个迭代中解决，成功弥补了瀑布模式不能需求快速变更的短板。

迭代模型的劣势：最终交付物可能无法预期，先期规划和后期交付可能会差别巨大；其次迭代模型需要开发、业务团队高频高效的沟通，为了保障沟通质量，需要在沟通前做好充分的准备。但现实情况是多数情况下沟通时间不能保证，沟通效率不能保证。

适用场景：需求不明确、创新性和需要抢占市场的项目，比较适合2C项目

增量模型

增量模型又称演化模型、渐进模型，增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件，运用增量模型的软件开发过程是递增式的过程。相对于瀑布模型而言，采用增量模型进行开发，开发人员不需要一次性地把整个软件产品提交给用户，而是可以分批次进行，而每次开过过程又可以作为一次迭代开发。增量模型对软件设计要求非常高，整个体系架构需要具备开放性与稳定性，能够顺利的不断集成各种增量组件。 



图片来源： https://blog.csdn.net/qq_38262266/ article / details/ 86585435 

增量模型的优势：可以分批次地提交软件产品，使用户可以及时了解软件项目的进展，相比迭代的优势是增量模型的交付是全局可用，不会是只是让用户体验一个迭代内的功能；其次在软件设计中以组件为单位进行开发，能够降低了软件耦合开发的风险。

增量模型的劣势：要求待开发的软件系统可以被模块化，如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。互联网项目中，需求会拆分成模块进行迭代，因此模块拆分不合理也会造成效率问题。

适用场景：需求非常明确，可模块化开发的项目，适合客户端类项目开发。

模型对比

除了上述三种经典模型外，还有螺旋模型，演化模型、模型模型等，其他模型基本是这三种模型上的强化或调整，从事软件开发核心掌握着三种模型即可，我们用一张图对比三种模型的差异。



如果软件从一开始定义到最后产出交付的相同度定义为可预测性，那么瀑布模型方式是最好的，迭代模型是最差的。如果从软件使用目的出发按照更接近客户真实场景定义为适应性，那么瀑布模型是最差的，而迭代模型是最好的。

以上三种模型在传统软件交付市场都有很好的实现场景，在很多互联网项目上也证明了其价值。B/S模式(互联网项目)和C/S模式(软件项目)相比一个重要特征是，发布即用户可见，这种快速的用户可见模式和传动的软件交付后等待用户更新相比，带来了很多新的挑战，比如出现问题后快速修复能力，新功能快速验证的能力等等，这些挑战最终指向了如何在不确定性中建立快速适配变化的软件研发模式。而传统的软件模型是为了达到最终交付目标建立的流程模式，强调详尽的文档、严格的流程机制、完备的工具能力、周祥的计划，而所有这些动作都会让时间变长，不适合快速变化的B/S模式项目，因此，为了适应快速变化的B/S模式项目一种新的方法应运而生。

敏捷方法

敏捷方法是一种从20世纪90开始出现的一种新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力，更强调开发团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。进入21世纪随着互联网的大流行，敏捷开发的概念开始广泛的流行，敏捷方法通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力非常适合互联网行业的发展。

敏捷方法并不是全新的理论体系，敏捷方法基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称，可理解为在原有软件开发方法基础上整合——取其精华，去其糟粕，是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法中有很多落地实践，比如常见的Scrum、XP极限编程、精益、看板、水晶、DSDM动态系统开发、FDD功能驱动开发等等。 



极限编程

极限编程（ExtremeProgramming，简称XP）是一种轻量级的、灵巧的软件开发方法，强调可适应性以及面临的困难，主要目标是降低因需求变更而带来的成本问题。在具体工程中会把复杂的开发过程分解为一个个相对比较简单的小周期，在每一个周期里面，项目人员和客户都可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，而且可以根据实际情况及时地调整。

极限编程以沟通、简单、反馈、勇气和尊重为价值标准，以13种方法指导的开发框架。 



图片来源： https://zhuanlan.zhihu.com/p/511512621 

极限编程模式对开发和测试团队要求非常高，团队中的人员水平必须具备非常高的水平这个模型才能运转成功，比如测试驱动开发TDD，先写测试代码、再写程序代码进行测试，再比如结对编程，2名开发人员用一个键盘、一台显示器、写一段代码，这在大部分公司几乎不可能存在。因为这种方式质量提升多少不可见，效率倒是可见的降低了，至少从表面看是这样的。

极限编程的优势是具备非常好的工程实践能力。TDD、结对编程不适合自己的项目，但不影响持续集成、重构、简单设计等的实践方法在项目中落地。

Scrum

Scrum是迭代式增量软件开发过程，Scrum包含了一系列实践和预定义角色的过程骨架，通过实践3个角色（Scrum Master，Product Owner，Team）、3个工件（Product Backlog，Increment，燃尽图），5个活动（Sprint，Sprint planning meeting，Daily standup meeting，Sprint review，Retrospective meeting），再加5大价值观（专注、勇气、公开、承诺、尊重）来指导软件开发的一种机制，在Scrum实践中Scrum Master类似项目PM角色。 



图片来源： https://blog.csdn.net/baidu_35805755/ article /details/123345576 

Scrum是一种机制、一种框架而非解决策略，是建立在使用它的人的集体智慧之上的，实现了经验主义的科学方法，这种机制非常不适合频繁变化的团队，因为好不容易建立的团队信任很容易因为人员的变动而缺失。

对比

极限编程和Scrum这两种机制虽然都属于敏捷方法范畴，但在实践中也有不少差异。比如，迭代长度不同，极限编程的迭代长度1-2周，Scrum的长度在2-4周；再比如迭代过程中是否可以修改需求，极限编程过程中是可以允许需求变动的，如插入需求，则要考虑用另外等时间的需求将其替换，而Scrum一般是不允许这么做的；再比如在迭代中是否严格按照优先级来，极限编程务必要遵守的，而Scrum可以很灵活，可以不按优先级来做，最后一点差异在研发过程中是否严格按照工程方法，来保障进度或者质量，极限编程有严格工程实践约束，必须严格遵守，而Scrum来说不是那么严格，用开发者自觉保障。

造成极限编程和Scrum的差异的根本原因是，极限编程更注重通过强有力的工程约束来保障进度和质量，即以工程约束为核心，而Scrum更强调人的作用和价值，是以人为核心，强调建立自组织模式。在实际工作中，作为PM时最好是从管理上使用Scrum（团队自组织），而在工程实践中创建适合自己团队XP。

掌握项目管理知识及软件开发模型后，顺利完成中小型项目的交付问题不大。但想要到借助团队能力优雅的做好，就要在关键节点下功夫。

项目管理领域重点知识

目标设定

目标的价值在于聚焦能量和引发行动。项目目标做的好（科学合理）能够给人以鼓励，催人奋进和向上，能够把团队内限的资源和精力用在最有意义的事情上，清晰的目标是也动力产生的源泉，它会不停地激励我们把它变成现实。不好的项目目标会变成了团队沉重的负担，项目目标设定至关重要。

初次做项目PM的时候，很容易把项目目标设定为某某日期按时上线或者无故障发布等等。按时上线是非常重要的一环，但这里面缺乏对质量的要求，对性能的要求，也无法提现团队人员的成长等等。设定目标时，不要从单一维度出发我们要从多维度出发，设定目标要具备SMART原则，即目标具体、可衡量、可实现。如下例所示，右侧项目的目标设定明显要好于左侧。



6W2H思考法：也叫八何分析法、6W2H标准化决策&评价模型，是一种通用决策方法。做任何工作都应该从6W2H来思考，这有助于我们的思路的条理化，杜绝盲目性。大到业务思考、业务决策、技术架构设计等，小到一个类的定义，一张表结构的设计，都可以使用该方法。

那么技术人员做项目管理，可以从哪几个方向设定项目目标呢，这里给出一个图，供参考。 



对出初级PM来说可以从如上几个方向设定项目目标，在每个项目上灵活运用。比如你初次接手一个项目，这个项目是创新方向的尝试，产品需要从0-1，团队也是新组建的需要磨合。这时候的目标可以这样设定。

业务目标：通过完成XXXX等核心功能建设，配合市场完成新产品行业发声。

技术目标：完成XX系统从0-1的建设，核心XX接口rt达到50ms。

团队目标：建设团队研发流程体系，实现按双周发布机制；通过团队大练兵打造一支狼性团队。

目标的设定，一定要根据项目实际情况进行，这就需要PM充分了解项目的背景、公司的诉求、市场情况，做出针对性的目标，而上述这些信息的获取，除了要自己去学习为，还需要和项目的干系人做好充分沟通，了解他们对项目的诉求，制定的项目目标，才能让各方满意。

干系人管理

干系人即项目相关人员，在项目管理过程中，我们打交道最多的相关人员有如下



在实际项目管理中，不能忽略下面的这些项目关系人的诉求，所以项目目标制定时，一定要充分和各方干系人做好沟通管理。 



大家可以尝试把关系人放到下面不同方格内，针对不同关系人的难点做关键动作。 



A方格：项目发起人、业务负责人 B方格：技术负责人、中台服务提供方 C方格：PD、UED、DEV、QA

D方格：财采等

做好干系人管理明确他们的诉求后，那么就知道AB方格干系人的目标一定要作为项目核心目标来定义，并与他们做好充分沟通确认，C的目标作为重要支撑目标来定义。

进一步可以思考下，周报、晨会的目标对象是哪方干系人？他们核心关注点事什么，思考清楚才能写好项目周报，开好每个晨会。

沟通管理

信息的传递会因为表达、介质、编码、情绪等影响产生丢失，这就是沟通的原罪，你内心有100%想说的，到真正行动时可能只有20%的部分。沟通的本质不是你说没说、说了多少，而是在沟通的对象理解了多少。沟通不是一次性的需要多次反复确认。 



沟通是一种建立沟通关系的双向过程，通过沟通我们可以在不借助实力和权威的前提下，导致想法和行为的改变，项目管理上的沟通是指有效沟通，想要做到有效沟通，需要建立团队的沟通机制和善用工具。可以在团队中建立这样的沟通原则，并成为团队内明确下来。

1. 丑话说在前面，先定义规则机制要求，奖罚说清楚 2. 让沟通在一个频道上，统一团队术语 3. 让“承诺”变的神圣、有效，不失信于他人 4. 让各环节的交付标准变的明确，利他就是利己

5. 提倡换位思考，让合作变的愉快

做到有效沟通还要善于利用Email、电话等工具，不同工具要用在适当的场景内才能产生价值。EMail，用于重大事项同步周知；电话/视频会议，日常管理或者关键内容汇报；钉钉，有问题及时沟通；文档中心，项目文档协作、沉淀。

在项目管理过程中PM是沟通的中心，PM几乎要花50%的时间用在沟通上，工作中50%的障碍也是在沟通中产生的，为什么会这样，因为PM在沟通过程中会碰到前后端专业有GAP缺乏共同语言、业务产品各方目标不一致、团队成员职责不清问题推诿、项目进度不透明等沟通障碍。针对这些沟通障碍，可以针对不同的干系人，制定不同的沟通策略，对项目的业务方和领导及时做好汇报和请示，对你的合作伙伴（中间件、依赖方）做好合作和谈判，明确大家的目标，对产品经理就要做好引导和确认，对项目组成员要做好协商。唯有此PM才能做到 外圆内方，财源滚滚(一位PMO同学的分享，非常有道理)。 



风险管理

风险种类

在项目管理过程中可能会出现各种风险，比如需求评审有遗漏、需求有变更、工作拆分有遗漏、需求理解不充分、测试环境不稳定、人员经验不足、团队积极性不高、质量较差等等问题。下面有个项目管理过程中可能出现的风险，作为项目PM可以照章比对。



（来源一位PMO同学非常全面的整理）

风险的识别和应对

项目管理过程中风险无处不在，有些风险无关紧要，有些风险会严重影响目标达成。PM不是孙悟空没有火眼金睛，无法识别所有项目风险，但PM可以掌握风险识别的方法并应用，确保尽量识别出特别严重的风险，进行处理。

方法一：找专家来判断，可以请教有经验的同事、专家请他们把把脉。 方法二：组织头脑风暴，有更多视角的输入，便于发现风险死角。 方法三：组织专题会议，集思广益，深度探讨，便于发现隐藏风险。

方法四：数据分析，养成看报表、看数习惯，发现异常波动及时跟进处理，把风险扼杀在摇篮里。

对于风险的识别，PM要充分调用团队的力量。

风险是任何项目中不期望出现的但又无法避免的，面对风险，我们可以用规避、降低、转移、接受风险这几种方式进行处理。对于PM来说想要把风险从危转机，就需要未雨绸缪，定义风险处理原则让团队提前达成共识，可以考虑从这三方面建立规范

3、明确责任到人，明确奖罚标准、对不上报造成失误的要罚，对消除风险有补救措施的给予鼓励。

工具推荐

对于技术PM来说，需要心力、脑力、体力同时在线，不仅要主动承担、随时补位，还要积极乐观、时刻保持清醒的头脑，做问题的终结者。除了要掌握项目管理、软件开发模型的理论外，还需要在个人管理及项目管理过程中掌握几款工具，便于个人和项目提效。

时间管理

时间管理的核心是精力管理，每个人的精力都是有限的，要把自己的精力用在重要的事情上，这样产出才是高效的，作为项目中心的PM，项目的大小变化都会汇聚到项目PM这边来，可以通过紧急重要四象限来管理所有事项，并按照事项所在象限，分配时间精力来做。 



具体各个象限占用时间，大家可以根据自己情况调整，核心原则是把精力放在重要的事情（当下or未来），即与目标达成紧密相关，精力分配我们建议按照以下比例来分配。

1. 重要且紧急（45%）严重阻塞项目进度的事情，例如技术方案设计、具体任务拆解、后端接口定义、核心主链路开发，阻塞测试的BUG等，这些问题不解决，干系方不能正常推进工作，必须优先解决。

2. 重要不紧急（35%）不阻塞项目进度，但未来可能有影响的事项。例如某非核心链路功能（消息发送之类的），可适当延后一段时间，但需要有一个明确的时间点，需要follow整体项目排期，随着项目推进，该类事项很可能上升成重要且紧急。

3. 紧急不重要（15%）例如一些客户反馈的线上问题，并可以安排团队其他同学来跟进解决，在工作间隙要多关注。

4. 不重要也不紧急（5%）暂时可有可无的需求，技术PM需要深入了解业务背景，再结合当下业务现状，做出自己合理的判断。比如一些不重要的需求，可以和业务沟通此类需求是否可以推迟到下个迭代做，或者当下使用最低的成本来做。

工作分解结构（WBS）

在任何项目中，工作分解都是

重中之重。这个过程决定项目的成功程度、资源使用情况、风险等。在软件项目中，常用方式是根据功能模块来做工作分解，把模块拆分成任务，再把任务拆解成具体的一项工作，安排到每个人的日常工作上来，这样一个过程就是工作分解结构（简称WBS）。在软件项目中除了用功能模块来拆分外，还可以按照部门、职能、地域、实施过程等来拆解。具体项目管理过程中，要多尝试几种分解方式，然后找到资源、成本、效率的最佳平衡点。 



关键路径法（CPM）

一个项目拆分成任务后，任务与任务之间有前后依赖关系，任务有轻重缓急（权重），执行任务的人员也有能力差异，如何能够最优化做好排期安排，这时可以用关键路径法（CPM）来进行最长路径的拆解，关键路径是通过确定最长的依存活动范围并测量从头到尾完成这些活动所需的时间来一种方法。如下所示，尝试找一下下图的最短路径。



PM指北

作为技术开发人员，做PM时首先是转化自己的思维模型，其次要做好角色转换。无论之前个人多么成功，从做项目经理开始就要开始做从一个人成功走向一个团队成功转型，从关注个人的事情到关注团队事情、人、资源、流程机制等。

明白PM职责就是通过周密的计划，管理好项目中的人、事、物，达成目标后，掌握理论、工具、方法再通过多次实践，总结，就不能做到预(项)事(目)不(管)慌(理)。项目管理也不是只付出而没有收益的角色，通过项目管理实践至少可以提升这5方面的能力。

5. 影响力、抗压能力、系统分析能力等也将有不同程度的提升。