作为技术的项目管理

作为方法论的项目管理

2015 年的某一天晚上, 大概十点钟左右, 我刚准备去睡觉, 突然接到公司产品总监的的电话. 他问我: 你想做产品经理么? 我回答说: 想啊! 他说: 那就来海南出差吧. 然后第二天, 公司行政就给我买了一张机票, 把我送去了海南.

其实, 背后的故事是这样的: 叫我去海南的产品总监是当时我司的唯一产品经理, 他因为生病不能再驻场参与项目, 因此他需要找个人来顶替他; 而当时我是公司业务部门里唯一稍稍知道些技术知识的人, 所以就选了我. 我的产品经理生涯就是这样开始的.

那是个采购支付系统建设项目, 它需要对接一套已建成的采购管理系统. 这套采购管理系统的建设方赛意是一家国内知名的 ORALCE 的代理商. 当我在阅读赛意的文章的时候, 我注意到一个细节: 它们所有的文档都有一个副标题 -- "赛意方法论".

后来我再听到类似的说法是在 2018 年. 当时我在一家大数据公司. 公司的产品经理给我们介绍公司的项目制度时, 再次说了类似的话: 项目经理主要提供一套方法论, 他可以完全不懂技术, 但是通过这套方法论, 依然可以使项目正常的运转起来.

项目管理是一套方法论, 这似乎是一个普遍的共识. 然而什么是方法论呢?

望文生意的说, 方法论就是方法的理论, 或者带着理论的方法. 方法是一套实现既定目标的, 解决既定问题的有效的, 可重复使用的经验. 照着亚里士多德在《形而上学》中说的, 感觉产生记忆, 重复的记忆产生经验, 从经验中提练出普遍性, 并使其得以广泛的应用就是技术. 从经验中提练出的普遍性, 就是我们说的理论. 这么说来, 方法论就是技术.

既然项目是 为了提供特定的产品, 服务或成果所进行的一次性活动, 那我们大可说, 作为方法论的项目管理是一种 把事务作为一次性活动进行管理的技术.

技术与系统

据说在考古学中, 有一种判断一个部落是否进入时器时代的标志: 在部落中是否出现了大量相似的石斧. 诚如亚里士多德所说, 技术通过从经验中提练普遍性来实现经验的复用. 当一个原始部落中开始出现 相似 的石斧时, 意味着这批先民们, 已经开始 掌握 一种特定的将石头制成石器的 方法, 并开始进行 复用 了.

掌握 是一种太过现代的想法. 对于先民来说, 这更多是一种自然 由隐蔽而开显 的过程. 赫西俄德在《工作与时日》中说:

诸神不让人知道生活的方法, 否则, 你工作一天或许就能轻易地获得足够的贮备, 以至一整年都不需要再为生活而劳作了; 或许立刻就可以把船舵卸下置于烟上, 牛和壮骡翻耕过的田亩又会变成荒地. 但是, 愤怒的宙斯不让人类知道谋生之法, 因为狡猾的普罗米修斯欺骗了他. 因些, 宙斯为人类设计了悲哀. 他藏起了火种. 但是, 伊阿佩托斯的优秀儿子又替人类从英明的宙斯那里用一根空茴香杆偷了火种, 而这位雷电之神竟未察觉.

人本来可以在自然中安乐和富足的生活, 但诸神因愤怒而隐藏了 生活的方法, 使人们只能辛苦流离. 类似的故事还有被亚当被逐出伊甸园. 或出于神的恩赐, 或出于人的智慧 ( 人的智慧不也是神的恩赐么? ), 自然中隐藏的 生活的方法 被再次开显出来, 被人洞察到, 这便是 技术 了. 无论是毕达哥拉斯为了勾股定理献上百牛祭的故事, 还是米开朗基罗从石头中看出大卫的故事, 都在讲述这个由隐蔽而开显的故事.

在一颗古典的心灵里, 自然是万物勾联的整体. 这个 "万物" 也包括着人与人造物. 子曰: "礼云礼云, 玉帛云乎哉; 乐云乐云, 钟鼓云乎哉." 开显生活方法的技术, 就不仅仅是一套制作的程式, 同时也是对自然勾联万物的方式的洞查. 在古希腊这种勾联方式是 努斯 ( 使万物处于对自己最好的位置的心灵 ) 和揭示努斯的 逻格斯, 在我们这里这种勾联是 道 和实现道的 德. 所以玉有五德, 鸡也有五德, 君子也有五德, 德 勾联着万物的心灵.

技术是那个使人与远超出自己的自然产生关联的东西.

然而哥白尼的革命切断了这个人与自然的联系. 人并不是自然的中心, 也与它并无 内在的 ( 目的论上的 ) 关联. 自然或者自有其与人无关的目的, 或者自然压根就没有目的. 无论如何人是不能想想, 自然与人同在一个目的之下了.

于是人造与自然就割裂开来, 玉也没有五德, 鸡也没有五德, 君子 ...... 厄 ...... 随他的便吧. 自然成为了人的改造的对象, 技术是驯服自然使其成为人造物的手段. 钢筋混凝土构筑的城市从大地上拨地而起, 水坝截断河流从其势能中榨取电力.

然而技术依然是哪个使人与 远超自己的存在 产生关系的东西. 只是这个 远超自己的存在 由自然换成了 系统 而已.

人从来不是孤伶伶的站立在大地上的. 人总得生活在一个超越自己的存在中. 这个存在在古典的时代是自然, 而今则是人造的系统. 自然固然也是一套系统, 但它浑然天成, 不假人力; 而人造的系统则全是人设计出来的. 当自然的目的与人无关时, 人就按自己的目的 ( 通常这个目的是效率 ) 设计出人造的系统.

因此, 要谈论作为技术的项目管理, 就要谈论绕围着这套技术的系统.

项目管理技术以及与之交互的系统

事业环境因素

项目是为了提供特定的产品, 服务或成果所进行一次性的活动. 因此项目本身具有明显的独立性. 然而这个具有独立的性的活动要正常开展并取得成功, 需要依赖一系统的内部外部的要素. 这些 决定项目成果的要素 我们称之为事业环境因素.

通常来说, 事业环境因素包括四类, 也即是项目实施组织内外部的 环境, 条件, 设施 和 系统.

项目的外部环境因素是市场环境, 内部环境因素是项目干系人.

市场环境是项目最重要的环境因素. 我们这个时代, 没有任何例外, 一切人造的系统都处在市场当中. 项目也是如此, 无论它是产出产品, 服务或其他成果, 它都要从市场获取基本的要素, 并最终向市场输出.

除了市场环境外, 项目干系人也是项目的重要环境因素. 所谓项目干系人指的是, 受到项目影响, 或者自认为受到项目影响, 并且也会影响项目的人. 项目的干系人包括 与项目有直接关系 的人员, 如项目发起人, 项目管理团队, 项目经理和其他项目成员; 对项目起支撑作用 的部门关键人, 如运营部门经理, 职能部门经理; 与项目有合作关系 的人员, 如客户或用户, 卖方和合作伙伴; 对项目起到制约作用 的人员, 如股东, 监管机构, 专家顾问团队, 环保人士, 金融组织, 媒体. 所有这些人都影响着项目的推进, 甚至影响项目的成败.

项目的外部条件因素是政府或行业标准, 内部条件因素是组织的文化与组织结构.

政府或行业标准限制了项目活动的边界. 项目活动必须符合项目的这管理部门的规章制度, 产品标准, 质量标准与工艺标准, 这个其实没什么好解释的, 不然那些部门为啥叫 "管理部门" 呢.

而组织自身的文化与组织结构则决定着项目活动的潜能. 不同组织的文化下, 会产生不同项目活动风格, 紧密联系的小团队, 富于创新精神, 行动力强, 出活快, 但往往在管理和制度方面不规范; 而依靠强分工的大团队, 做事中规中矩, 按部就班, 但强在稳扎稳打, 可预期性高. 而组织的组织结构真接影响着项目对资源调动的能力, 关于这点可以参考上一篇文章中中讲到的项目组织架构的内容.

项目的客观设施因素是项目开展的基础设施, 项目的主观设施因素是人力资源, 人事管理和人事制度.

项目的开展的基础设施是承载项目活动的载体. 就拿我从事的 IT 项目来说, 项目开发环境, 测试环境, 都是项目的基础设施. 而且得益于开源运动, 现在对于 IT 项目来说, 有了更多的公共项目设施, 这就是开源项目. 我就经常听开发朋友自嘲, 我们的开发模式应该叫做 "面向 github 编辑".

项目的主观设施自然是人以及对人的管理. 关于这点, 可以参与上一篇文章中所说的, 项目组织架构中强矩阵模式和弱矩阵模式的主要区别就在于绩效考核的权力在项目经理手理还是在部门经理手里. 人事制度和组织架构是一个组织非常底层的东西, 或明或暗的决定一个组织的很多事情. 所以如果你要去面试, 一定要问一下这个单位的组织架构是什么样的, 你所处的岗位管理模式是什么样的, 上游部门以及下游部门管理模式是怎么样的. 这个事情里, 包含无数的重要信息.

项目的外部系统因素是商业数据库, 项目内部系统因素是项目管理信息系统.

商业数据库在 IT 行业好像作用好象不是很明显 ( 也有可能是因为我从事的岗们接触不到 ). 但因为我们家里除了我和我表弟做 IT 以外, 几乎所有亲戚都在做建筑, 所以我大概知道, 建筑行业是有完备的行业数据标准的, 建筑行业的预算工作就是要通过每年的材料费用标准和人工费用标准来计算的. 在以后我们聊到项目的成本管理, 进度管理甚至风险管理时, 还会提到估算依据, 那里的估算依据, 就是从商业数据库里来的.

至于项目管理信息系统, 那我们做 IT 的可是最熟悉的了. 尤其是我现在所在的这个云计算公司, 有着成套成套的项目管理信息系统, 比如管理项目活动的 jira, 管理项目文档的 confluence, 管理代理版本的 gitlab 等等.

如果我们说技术是要围绕一套系统展开的, 那么项目管理的技术, 就是围绕着事业环境因素这样一套包含 条件, 设施, 环境和系统 的人造系统展开的. 当我们使用项目管理技术与事业环境因素进行交互时, 除出产出项目目标的产品, 服务或成果外, 我们还会基于技术活动本身产出一系列可以在其它项目中复用的东西, 我们称这些东西叫 组织过程资产.

组织过程资产

组织过程资产可以归纳两类: 组织进行工作的过程与程序, 组织整体信息存储检知识库.

组织进行工作的过程与程序包括:

• 组织标准过程, 如标准, 方针 ( 安全健康方针, 项目管理方针 ); 软件生命周期与项目生命周期, 以及质量方针与程序 ( 过程审计, 目标改进, 核对表, 以及供组织内部使用的标准过程定义 ).
• 标准指导原则, 工作指令, 建议评价标准与实施效果评价准则
• 模板 ( 如风险模板, 工作分解结构模板与项目进度网络图模板 )
• 根据项目的具体需要修改组织标准过程指导原则与准则
• 项目沟通要求 ( 如可利用特定的沟通技术, 允许使用沟通媒介, 记录的保留, 以及安全要求 )
• 财务控制程序 ( 如进度报告, 必要的开支与支付审查, 会计编码, 以及标准合同条文 )
• 确定问题与缺陷控制, 问题与缺陷识别和解决, 以及行动追踪的问题与缺陷管理程序
• 变更控制程序, 包括修改公司正式标准, 方针, 计划与程序, 或任何项目文件, 以及批准与确认任何变更时应遵循的步聚.
• 风险控制程序, 包括风险类型, 概率的确定与后果, 以及概率与后果矩阵.
• 批准签发工作授权的程序.

组织整体信息存储检索知识库包括:

• 过程测量数据库, 用于搜集与提供过程与产品实测数据
• 项目档案 ( 如范围, 费用, 进度, 以及质量基准, 实施效果测量基准, 项目日历, 项目进度网络图, 风险登记册, 计划的应用行动, 以及确定的风险后果 )
• 历史信息与教训知识库 ( 如项目记录与文件, 所有的项目收尾资料与文件记录, 以前项目选择决策结果与绩效的信息; 以及风险管理努力的信息 )
• 问题与缺陷管理数据库, 包括公司所有正式标准, 方针, 程序和任何项目文件的各种版本与基准
• 配置管理知识库 , 包括公司所有正式标准, 方针, 程序和任何项目文件的各种版本与基准.
• 财务数据库, 各种如工时, 发生费用, 预算以及任何基目费用超支等信息.

以上关于组织过程资产的内容, 完全是从教材上抄下来了. 这里不做过多解释, 原因除了内容太多外, 还在于其实这里出现的每一个组织过程资产, 在以后讲到具体的项目管理活动时候都会被提到. 显然在那里祥细讲解是更合适的方案.

我们可以看出来, 项目的组织过程资产就是在进行项目活动过程当中产生的经验的凝结. 这些凝结的经验又固化下来, 成为了项目管理技术的一部分. 这又可以看出技术的设计的特征: 技术就是在面对系统时, 根据系统自身特性设计出的流程, 标准和知识, 而在复用技术的过程中, 我们还可以不断优化我们的设计, 使技术本身得以进化.

PMO -- 项目管理办公室

项目管理是一种围绕事业环境因素展开, 产生特定产品, 服务或成果的技术, 这套技术在不断的复用的过程中, 将经验凝结为组织过程资产, 并不断的设计和优化它们, 并把它们纳入到项目管理技术中. 那么完成这些设计和优化工作的主体, 就是 PMO -- 项目管理办公室.

任何以项目为主要业务活动的组织, 都应该设立 PMO. 因为项目本身的特性, 项目活动中的管理经验都积累在项目经理身上. 不同项目的项目经理积累的经验如果不沉淀下来成为知识, 就无法进一步成为优化项目管理技术的组织过程资产. 因此需要项目管理办公司来完成上述沉淀经验, 总结组织过程资产的工作.

从组织架构上讲, 项目经理隶属于项目管理办公室. 项目管理办公室管理共享资源; 识别项目管理方法, 最佳实践和标准; 指导, 辅导, 培训和监督；制定政策程序和模板, 监督遵程度, 跨项目沟通协调.

有的 PMO, 只收集整理项目经验, 管理共享资源, 为项目经理进行项目管理活动提供支持. 这种 PMO 是支持型的 PMO. 有的 PMO 不但收集整理项目经验, 管理共享资源, 还对项目管理活动进行一定的控制, 比如对项目经理的项目管理活动提出约束和要求, 这种 PMO 是控型 PMO. 还有的 PMO 不仅仅是对项目经理的项目管理活动提出约束和要求, 还直接下达指令进行项目管理活动, 项目经理只是执行指令的工具, 这种 PMO 是指令型的 PMO.