目录
读后感—PMBOK第六版 目录
项目定义
定义:项目是为创造独特的产品、服务或成果而进行的临时性工作。
项目的特征具备以下三点:
独特性:独一无二,无法简单重复过去的做法。
临时性:项目有明确的起点和终点,其可交付成果可能在项目终止后依然存在,“临时性”并不意味着项目的持续时间很短。
不确定性:项目在不断应对变化,风险如影随形,只能渐进明细。
开展项目是为了通过可交付成果达成目标,可交付成果指的是在某一过程、阶段或项目完成时,必须产出的任何独特并可核实的产品、成果或服务能力。可交付成果可能是有形的,也可能是无形的。
例:为某家二级医院的智慧服务板块,研发一套门诊分诊排队叫号系统的项目。在这个过程中,其独特性、临时性以及不确定性体现在哪些方面呢?又有哪些有形的产出和无形的产出呢?
独特性:医院有着个性化的需求,关于分诊规则、排队逻辑以及叫号方式等,都需充分考虑,以确保能够完美契合医院的业务流程,进而提升服务效率。
临时性:该软件的开发通常具有明确的项目周期,涵盖需求分析、设计、开发、测试、部署等各个阶段。团队需要依据项目的推进情况及需求,临时性地调配人力、物力以及财力等资源。
不确定性:门诊业务科室众多,且就医人员情况复杂,导致流程复杂且多变,需求难以完全确切把握,且在软件开发过程中可能会遭遇技术难题,比如遇到医保在同省一个城市能正常使用,而在另一个城市却无法使用的情况。
有形产出:一个能够直观看到并使用的产品。
无形产出:对服务流程的优化,患者等待时间的减少,医护人员工作效率的提高,以及患者对医院信任度和忠诚度的增强。
项目分类
项目除了上述的创造商业价值还有驱动组织进行变更。
项目驱动变更
项目驱动组织进行变更。从商业角度来看,项目旨在推动组织从一个状态转到另一个状态,从而达成特定目标(见图 1)。在项目开始之前,通常将此时的组织描述为“当前状态”。项目驱动变更是为了获得期望的结果,即“将来状态”。
有些项目可能会创造一个过渡状态,即由多个步骤组成的连续区间,以过渡到将来状态。通过成功完成项目,组织可以实现将来状态并达成特定目标。
图-1 组织通过项目进行状态转换
项目创造商业价值
PMI 将商业价值定义为从商业运作中获得的可量化净效益。效益可以是有形的、无形的或两者兼有之。在商业分析中,商业价值被视为回报,即以某种投入换取时间、资金、货物或无形的回报。
项目生命周期
项目生命周期与产品的生命周期相互独立,后者可能由项目产生。相对于产品的生命周期通常项目生命周期短的多,产品周期指一个产品从概念、交付、成长到衰退的整个演变过程的一些列阶段(见图2)。
图-2 产品与项目生命周期
项目生命周期可以是预测型或适应型。项目生命周期内通常有一个或多个阶段与产品、服务或成果的开发相关,这些阶段称为开发生命周期。开发生命周期可以是预测型、迭代型、增量型、适应型或混合型的模式:
1.预测型生命周期:在生命周期的早期阶段确定项目范围、时间和成本。对任何范围的变更都要进行仔细管理。预测型生命周期也称为瀑布型生命周期(见图 3)。
特点:计划严密、可控性强,对项目进度、成本、质量都有详细的计划,为项目投资评估和精细管理奠定了基础。
图-3 预测型生命周期/瀑布型生命周期
预测型生命周期对变更却并不友好,尤其是项目后期,变更代价太大,几乎让人无法接受。累计投入线代表项目累计的成本,也代表变更的代价。变更提出得越晚,代价越大(见图4)。
图-4 预测生命周期与资源投入
例:开发一款门诊分诊排队叫号软件,软件的初始版本开发司内采用 需求调研、资源验证、代码开发、软件测试、实施安装,在这个过程像瀑布一样,从上而下一级一级的“流”下来。如果项目涉及的软件功能复杂,实施后在客户试用阶段可能导致直接重新开发。
2.迭代型生命周期:项目范围通常于项目生命周期的早期确定,但时间及成本估算将随着项目团队对产品理解的不断深入而定期修改。迭代方法是通过一系列重复的循环活动来开发产品,而增量方法是渐进地增加产品的功能。
如:软件开发按照版本发布,每一个版本内部就是一个小的瀑布开发,经历“需求分析—设计—开发—测试—发布”周期,下一个迭代在此基础上重复这些步骤,对软件进行优化升级,发布新的版本(见图 5)。
图-5 软件迭代开发
例:完成门诊分诊排队叫号软件的现场实施后,对于客户提出的新需求,按照需求调研、资源验证、代码开发、软件测试、实施安装的流程进行处理,若再次试用时客户又有新需求浮现,还是按照这一顺序来操作。
3.增量型生命周期:通过在预定的时间区间内渐进增加产品功能的一系列迭代来产出可交付成果。只有在最后一次迭代之后,可交付成果具有了必要和足够的能力,才能被视为完整的。
团队先交付一部分成果,之后每个阶段再交付一部分成果。生产产品就像搭积木一样,一块一块搭起来(见图6)。
图-6 软件增量开发
例:在开发一款门诊分诊排队叫号软件时,其涵盖了门诊科室、药房、医技科室、急诊科室等多个方面。由于客户因领导检查的原因,要求的开发周期非常短,若进行全量开发则无法按时完成。因此,在这种情况下,我们选择将优先级最高的门诊科室部分先行完成开发并上线使用,待检查结束后,再持续推进并完成所有的开发工作。
4.适应型生命周期(敏捷型):适应型生命周期也称敏捷型生命周期,是指在面对需求易变的场景时,项目团队固定迭代周期和资源,并获得相关方的持续参与。敏捷周期比一般的迭代周期更短,对变更的响应速度更快(见图7)。
图-7 软件敏捷开发
例:在开发一款门诊分诊排队叫号软件时,软件具备签到、呼叫、显示等功能。在和客户沟通后,首先进行签到功能的开发,签到功能开发完成后,邀请客户进行体验,对于客户提出的需求及时讨论并确认,快速地重新进行开发。
5.混合型生命周期:是预测型生命周期和适应型生命周期的组合。充分了解或有确定需求的项目要素遵循预测型开发生命周期,而仍在发展中的要素遵循适应型开发生命周期。
例:在开发一款门诊分诊排队叫号软件时,前期需求调研时运用敏捷开发,通过绘制原型图来形成客户可能操作体验的最小可用产品(MVP),并在此基础上进行沟通从而确认需求。在确认需求进入开发阶段后,则采用瀑布型开发,开发过程中客户不参与其中,最后进行现场实施,客户试用。
预测型、迭代型、增量型、敏捷型生命周期的对比(见图8)。
图-8 各种生命周期对比
生命周期与适用场景
针对不同的项目场景,我们应该采取不同的生命周期(开发方法)。1996年,拉尔夫·斯泰西(Ralph D.Stacey)提出了一个方法——Stacey矩阵(见图9),帮助我们判断我们所做的项目应该采取哪种开发方法。
图-9 Stacey矩阵
1区:需求明确,技术(解决方案)也确定,这类项目就是简单的项目,比如注册一家新公司。针对这类项目,团队最好提前把计划做到位,预测型生命周期最适合。
2区:技术很确定,需求却不明确。例如,我们为客户开发一个信息系统,不需要采用新的技术,但系统应包含哪些功能,客户总是说不清楚。这类项目就是复杂项目中的烧脑型项目!
关于这类项目,我建议采取混合型的开发模式。例如,我们在开发产品原型时用敏捷方法,在确认需求并验证方案后,在正式开发时用瀑布开发方法。当然,我们也可以逐块构建,采用增量交付的方法,降低项目被彻底推翻重来的风险。
3区:需求很明确,技术却不确定,这类项目属于复杂项目中的棘手型项目。例如,“无人驾驶”的需求是明确的,但技术仍未成熟。
关于这类项目,我建议采用混合型的开发方法。例如,针对软件部分,团队可采用敏捷开发;针对硬件部分,团队可采用迭代开发。
4区:需求不明确,解决方案也不明确,这属于混乱状态的项目。这种项目失败的概率很高,所以不要碰!
5区:需求还在挖掘,技术也需探索,这属于混沌状态的项目,最好采用敏捷开发,因为敏捷开发适应性强、灵活机动,可以拥抱变化。\
项目是否适合采用敏捷开发,我们可以用敏捷适用性评估雷达图来帮助我们进行决策(见图10)。
图-10 敏捷适用性评估雷达
该雷达图中包含“项目、团队、文化”三大扇区。每个扇区又包含三项评估指标:项目中有变更、关键性和交付指标,团队中有团队规模、经验和联系程度指标,文化中有支持、信任和决策指标。每个指标1 - 10分,团队小伙伴们根据自己对项目的认识填写由这9个指标构成的问卷。1 - 3分是敏捷区,4 - 8分是混合区,9~10分是瀑布区。
项目阶段与阶段关口
项目阶段是一组具有逻辑关系的项目活动的集合,通常以一个或多个可交付成果的完成为结束。
划分项目阶段的关键目的在于将长期的项目目标分解为阶段性目标,将其划分为多个阶段不仅有利于更有效地掌控项目管理(诸如团队规划与控制等方面),而且还提供了评估项目绩效的契机,并能在后续阶段采取必要的纠正或预防措施。
这就如同玩游戏一般,玩游戏需要一关一关地突破,每一关的末尾都存在着一个颇具挑战性的“大 boss”。唯有战胜它,才能顺利进入下一关,若是失败则只能重新开始。
项目阶段是依据什么来划分的,以及被划分为几个阶段,在不同的行业、不同类型的项目中,其侧重点通常存在差异。在每个阶段结束并即将进入下一个阶段时,还必须满足一些特定的条件,我们将这些条件称为阶段关口。在不同的组织、行业或工作类型中,阶段关口可能会被称为阶段审查、阶段门、关键决策点、阶段入口或阶段出口等。
阶段关口通常在项目阶段结束时进行,会将项目的绩效和进度与项目和业务文件进行比较,然后基于此比较结果做出相应的决策(比如继续或终止的决定)。
工程建设项目阶段和阶段关口
依据实践经验,工程建设项目可分为“可行性研究—计划与设计—施工—交付使用”四个阶段(见图11),阶段与阶段之间有必须经过的阶段关口。例如,项目必须通过立项审批,才能从可行性研究阶段进入设计阶段;只有甲乙双方签署了主承包合同,才标志着项目进入了施工阶段;项目竣工后,只有验收通过才能进入使用阶段。这样划分项目阶段已经上升到了行业规范和法律层面的高度。
图-11 工程建设项目阶段和阶段关口
根据不同阶段所用的资源不同,像房屋装修这样的小项目可分为结构施工、水电改造、粉刷等阶段。这样划分是为了避免工序之间的相互干扰和冲突,也可以更方便地针对不同的资源进行分包管理。阶段关口就是每个工序完成后验收甚至结算费用的时间点。
软件产品研发项目一般可以划分为“需求分析—方案设计—软件编码—软件测试—部署上线—运维与维护—项目收尾”这七个阶段,如此划分有助于对质量和风险进行有效管控。倘若发起人在产品开发进程中察觉到该项目无法达成其最初的要求,那么就需要提前终止项目。对发起人而言,及时采取止损措施也是一项极为重要的管理抉择。
项目和运营的联系与区别
项目:公司产品研发、为客户交付服务、管理变革等项目团队的工作。
运营:运营是一项持续、重复且流程化的工作,其核心在于确保产品、服务的稳定生产和顺畅运作。通过高效利用最优资源,致力于满足客户的多样化需求,从而确保业务运作的持久高效。例如:门诊分诊排队叫号软件的运营工作,不断关注系统性能、数据安全、用户体验等方面,以确保软件能够为医院和患者提供稳定、高效的服务。
围绕项目,企业可以分为甲方、乙方两类(见图12),无论是甲方还是乙方,企业里的经营管理活动其实只有两种(见图13)。
图-12 项目甲方和乙方
图-13 项目与运营
项目和运营有什么不同
项目 | 运营 |
---|---|
独一无二 | 重复多次 |
有始有终 | 持续不断 |
革命性(只有一次成功的机会) | 渐进性(逐步改进) |
责权不均衡 | 责权均衡 |
临时性组织 | 稳定性组织 |
效果导向 | 效率导向 |
不确定性(风险) | 确定性(风险) |
针对性计划 | 标准化流程 |
例如,在门诊分诊排队软件中,项目工作主要是软件的从无到有的开发过程,涉及需求分析、设计、编码、测试、部署上线等阶段。而运营工作则侧重于软件上线后的持续运作和优化,负责监控软件的运行状态,确保系统的稳定性和安全性,定期收集用户反馈,针对问题进行修复和优化,提升用户体验。
一般的企业会把负责项目的人和负责运营的人分开,即由项目经理负责项目,由职能主管负责运营。
项目经理 | 职能主管 |
---|---|
“帅才” | “将才” |
“通才” | “专才” |
“目标管理” | “过程管理” |
“整合的方法” | “分析的方法” |
“责大权小” | “责权对等” |
“计划、组织、协调、指导” | “技术、流程、标准、规范” |