关于项目管理:如何优雅做好项目管理

导言

我的项目自身无好坏之分，项目管理有做好与做坏之别。在互联网大厂的体制下，想要做坏一个我的项目很难（能够通过换人、追加资源等形式打消危险），想要做好一个我的项目不容易，须要团队及 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，个别会有三个出发点。

1、借人成事，拿后果：对我的项目交付要求极为刻薄，项目风险高、工夫紧、工作重、压力大，这时候个别会抉择能力强、抗压好的技术同学负责 PM，以确保拿到后果

2、借事修人，锤炼人：我的项目难度中等，危险可控，从组织锤炼人的角度比方锤炼合作能力、架构能力等等，能够安顿负责 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 交付类我的项目都是采纳这种模型。

$$
图片起源：https://www.wendangwang.com/doc/b901e3c258faf493da109ebec47d22dc22821c9f/3
$$

瀑布模型的劣势：分工清晰，阶段目标十分明确，有助于晋升阶段效率；其次因为在晚期可能明确我的项目的范畴和详情，在开发阶段也能无效组织和调配资源，两头过程变数小，交付预期明确。

瀑布模型的劣势：各阶段须要清晰、详尽的文档，在开发中也须要撰写大量的文档，这个过程减少大量工夫，也极大的减少了工作量；其次我的项目前期展现成绩给客户减少我的项目不满足冀望的危险，常有交付性能不是客户冀望的状况产生；再次需要变更，因为要波及各阶段，变更老本十分高。

实用场景：软件需要十分明确且不会频繁变动的我的项目，比方外包类我的项目，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 标准化决策 & 评估模型，是一种通用决策办法。做任何工作都应该从 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 来说想要把危险从危转折，就须要防患未然，定义危险解决准则让团队提前达成共识，能够思考从这三方面建设标准

1、意识建设，明确危险全员有责全员解决，大家一荣俱荣一损俱损的团队意识。

2、建设危险疾速上报解决机制，激励大家积极主动上报危险，积极主动第一工夫采取措施。

3、明确责任到人，明确奖罚规范、对不上报造成失误的要罚，对打消危险有补救措施的给予激励。

工具举荐

对于技术 PM 来说，须要心力、脑力、膂力同时在线，不仅要被动承当、随时补位，还要踊跃乐观、时刻放弃苏醒的头脑，做问题的终结者。除了要把握项目管理、软件开发模型的实践外，还须要在集体治理及项目管理过程中把握几款工具，便于集体和我的项目提效。

工夫治理

工夫治理的外围是精力治理，每个人的精力都是无限的，要把本人的精力用在重要的事件上，这样产出才是高效的，作为我的项目核心的 PM，我的项目的大小变动都会汇聚到我的项目 PM 这边来，能够通过紧急重要四象限来治理所有事项，并依照事项所在象限，调配工夫精力来做。

具体各个象限占用工夫，大家能够依据本人状况调整，外围准则是把精力放在重要的事件（当下 or 将来），即与指标达成严密相干，精力调配咱们倡议依照以下比例来调配。

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

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

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

4. 不重要也不紧急（5%）临时可有可无的需要，技术 PM 须要深刻理解业务背景，再联合当下业务现状，做出本人正当的判断。比方一些不重要的需要，能够和业务沟通此类需要是否能够推延到下个迭代做，或者当下应用最低的老本来做。

工作合成构造（WBS）

在任何我的项目中，工作合成都是重中之重。这个过程决定我的项目的胜利水平、资源应用状况、危险等。在软件我的项目中，罕用形式是依据功能模块来做工作合成，把模块拆分成工作，再把工作拆解成具体的一项工作，安顿到每个人的日常工作上来，这样一个过程就是工作合成构造（简称 WBS）。在软件我的项目中除了用功能模块来拆分外，还能够依照部门、职能、地区、施行过程等来拆解。具体项目管理过程中，要多尝试几种合成形式，而后找到资源、老本、效率的最佳平衡点。

要害门路法（CPM）

一个我的项目拆分成工作后，工作与工作之间有前后依赖关系，工作有轻重缓急（权重），执行工作的人员也有能力差异，如何可能最优化做好排期安顿，这时能够用要害门路法（CPM）来进行最长门路的拆解，要害门路是通过确定最长的依存流动范畴并测量从头到尾实现这些流动所需的工夫来一种办法。如下所示，尝试找一下下图的最短门路。

PM 指北

作为技术开发人员，做 PM 时首先是转化本人的思维模型，其次要做好角色转换。无论之前集体如许胜利，从做项目经理开始就要开始做从一个人胜利走向一个团队胜利转型，从关注集体的事件到关注团队事件、人、资源、流程机制等。

明确 PM 职责就是通过周密的打算，治理好我的项目中的人、事、物，达成指标后，把握实践、工具、办法再通过屡次实际，总结，就不能做到预 (项) 事(目)不 (管) 慌(理)。项目管理也不是只付出而没有收益的角色，通过项目管理实际至多能够晋升这 5 方面的能力。

1. 沟通表达能力：技术 PM 是最理解我的项目业务的人，是问题征询的接口人，PM 会面临 PD 问进度、测试问逻辑、研发挑战架构等等，能无效清晰的表达出来让他人了解至关重要。

2. 组织协调能力：遇到问题须要决策，技术 PM 组织协调者，圈人、建场子、做打算。在波及多工种、多任务的工作中兼顾跟进落实。

3. 技术架构能力：技术 PM 也是一把代码好手，不仅我的项目要管得好，架构体系也要理的清，如果团队内没有架构师角色，我被动担起来。

4. 危险辨认能力：项目管理过程会波及 PRD 破绽、技术方案设计破绽、资源抽调、人员变动、提测品质差等危险，技术 PM 要联合我的项目的驱动因素，时刻放弃对危险的敏感度，做的早发现早解决，将项目风险降到最低。

5. 影响力、抗压能力、系统分析能力等也将有不同水平的晋升。

作者 | 光照

点击立刻收费试用云产品 开启云上实际之旅！

原文链接

本文为阿里云原创内容，未经容许不得转载。