项目管理1

帕金森原理与彼得原理

学习项目管理理论, 通常会学到帕金森原理. 不知道为什么, 在解释这个原理的时候, 通常会举这样一个例子来说明: 即使你有整整几个月的时候复习考试, 但你依然会在考试的前一周开始复习. 这让人误以为, 这个定理是在说, 人们总在事情迫近时候在才开始准备. 但其实并非如此. 其实原理真正的意思是: 工作内容会自动占满工作时间. 比如, 如果我计划用一年的时候来写这一篇关于项目管理理论的文章, 我当然可以把工作内容排得满满的: 用三个月查找资料, 三个月写草稿, 三个月找师友斧正, 三个月润色字句; 但如果我计划明天就发这篇文章发出来, 一晚上的时间, 我也能把这篇文章写出来: 头脑里有一个大纲, 边写边查查资料, 顺便注意一下文字通顺. 帕金森原理其实说的是, 无论我们为一个事情规划多长的工作时间, 我们都可以想办法把这个工作时间填的满满的.

历史学家诺斯古德.帕金森之所以要提出这个定律是为了要解释科层制度不断膨胀的现象: 在工作中, 工作内容会自动占满工作时间, 如果工作时间充分, 他会放慢节奏或增添新的项目来以便用掉所有的时间. 同样的情况也出在对资源的使用上. 无论为事务分配多少资源, 该事务都会把资源消耗完. 而人们为了显得自己所从事的事务更加重要, 天然的会倾向为自己的事务分配更多的资源. 关于这点最好的例子就是 集中花预算: 一个单位只要有预算制度, 那它一要在预算周期内把预算花掉; 因为如果它没有把预算花掉, 次年的制定预算的人就会减少该部门的预算.

而更要命的是, 在科层制度中, 一个事务的负责人如果自己无法处理事务, 而需要寻找助手, 他会面临三个选项: 1. 找一个比自己能干的人替代自己; 2. 找一个和自一样能干的人与自己合作; 3. 找两个不如自己的人给自己打下手. 一个心智建全的理性人, 为了保持自己的位置, 理所当然的会选择第三个选项. 而当他的助手无法处理自己的事务时, 也会按同样的策略行事. 与是科制的机构就会迅速膨胀起来.

管理学家劳伦斯.彼得同样关注科层制度变得臃肿的原因, 他提出彼得原理: 一个组织通常以提高管理级别的方式来奖励组织成员, 因此一个组织成员最终会升任他所不能胜任的岗位; 而从组织的角度看, 最终所有的岗位都由不能胜任的组织成员所占据.

彼得原理和帕金森原理完美的形成了闭环, 一个组织成员总有一天会升任他不能胜任的岗位, 而一旦他不能胜任其岗位, 他就会把几个不如自己的人给自己打下手; 而这几个打下手的人如果干的不错, 也终有一天会升任到他不能胜任的岗位, 于是他们也会找人给自己打下手; 于是科层组织就这样膨胀起来. 更合况组织尽可能消耗资源的冲动, 也会使它创造出更多的项目来使自己的膨胀变的合理. 我就亲眼见过, 一个十几人的创业小团队, 在拿到投资后迅速膨胀成为一个百来人的团队; 很多我完全不知道是干什么的部门被建立起来, 而且被塞的满满的. 当然, 从某种程度上讲这也是合理的, 假如投资人来问你们拿我投的钱去干什么了, 公司也总得说: 我们拿了钱准备干一二三四五件事, 这些事由甲乙丙丁部门来负责.

但不论怎么说, 科层组织的这种不断膨胀的倾向, 一定会使它变的更加臃肿和低效. 因此人们一直在寻找解决这个问题的办法, 比如扁平化组织, 岗级和职级的分离, KPI/OKR 制度等等. 而项目制也是解决这个问题的一个方案, 而且在我看, 也是一个非常有成效的方案.

项目管理的起源

曼哈顿计划 -- 将事务作为项目

正如无数起源二战的现代制度和技术一样, 项目管理也起源于二战. 确切的说, 起源于曼哈顿计划.

时间线是这样的:

• 1937 年 2 月, 纳粹德国开始了执行 "轴计划";
• 1939 年爱因斯坦向美国总统罗斯福写信, 告知了纳粹德国研制原子弹的消息, 并详细解释了原子弹的效果;
• 1941 年日本人袭击了珍珠港, 美国加入二战;
• 1942 年 6 月开始实施研制原子弹的计划, 也即曼哈顿计划;
• 1947 年 7 月 17 日, 第一颗原子弹试爆成功;

曼哈顿计划的规模大的惊人: 该工程集中了当时西方国家 ( 除纳粹德国外 ) 最优秀的核科学家, 拥有 2000 多名文职人员和 3000 多名军事人员, 其中包括 1000 多名科学家. 历时 3 年, 耗资 20 亿元. 这项计划还是一个与纳粹德国赛跑的计划, 美国晚于德国研制原子弹, 却要赶在德国之前研制出原子弹, 在整体时间上有着严格的要求. 更麻烦的是这项工作的保密性. 如此多的人员加入到这一项工作当中, 但只有少数人可以知道这项工作是做什么的.

曼哈顿计划规模大, 时间紧, 独立性强. 机构臃肿, 效率低下, 关系复杂的科层制组织完全无法胜任该项工作. 于是曼哈顿计划的负责人格罗夫斯和奥本海默决定使用工程学的思路来进行组织和管理, 这种组织和管理方式就是项目管理.

项目管理之于科于层制管理最大的优点在于, 它将事务作为一个 项目 进行管理. 所谓项目是 为了提供独特的产品, 服务或成果所作的一次性活动. 将事务作为项目来进行管理, 是将把事务看作是一个独立的一次性活动, 并以此为核心来组织资源, 安排活动, 最终实现目的. 因为项目是既定约束条件下的一次性活动, 因此具有相对清晰的生命周期, 使我们可以对资源的使用管理进行规划, 并根据规划对项目活动进行分解, 基于分解的活动进一步对资源的使用进行优化, 实现险低风险, 保证质量, 提升效率的目标.

鲁布革冲击 -- 向管理要效率

1984 年, 我国首次利用世界银行的贷款修建了鲁布革水电站. 根据与世界银行的使用贷款协议, 该工程的引水隧洞工程必须进行国际招标. 当时共有中国, 日本, 挪威, 意大利, 美国, 德国, 南斯拉夫, 法国八个国家的承包商参于了竞标. 最后日本大成公司以比标底低 43% 的价格中标.

于是, 在鲁布革水电站项目中存在了两种管理模式: 一种是日本大成公司为的现代项目管理模式; 一种是中国水利水电十四局苏联工业企业管理模式.

日本大成公司向中国派遣了一支三多人的管理队伍, 从水电十四局雇了 424 名工人. 他们开挖两三个月, 单月平均进尺 222.5 米, 相当于我国当时同类工程的 2 至 2.5 倍. 1986 年 8 月, 大成公司在开挖直径 8.8 米的圆形发电遂洞中, 创造出单头进尺 373.7 米的国际选进记录. 1986 年 10 月 30 日, 遂洞全线贯通, 工程质量优良, 比合同计划提前了 5 个月.

相比之下, 中方施工企业水电十四局承担的首部枢纽工程于 1983 年开工, 工程进展迟缓, 一度被认为按期完成截流的计划难以实现.

1986 年 11 月, 国务院批准鲁布革工程学习日本大成公司的项目管理方法进行建设. 到 1986 年底, 历时 13 个月, 不仅把耽误的 3 个月时间抢了回来, 还提前 4 个月结束了开挖工程, 安装车间混凝土工程提前半年完成.

1986 年, 时任国务院副总理的李鹏视察鲁布革水电站工地时感叹: "看来同大成的差距, 原因不在于工人, 而在于管理, 中国工人可以出高效率." 1986 年 6 月他在国务院召开的全国施工工作会议上提出全面推鲁布革经验, 要求国家有关部门对布鲁革管理经验进行全面总结, 在建筑行业推广鲁布革经验.

这一事件被称为鲁布革冲击. 它使当时的人们切实的感受到可以向管理要效率. 由此中国开始了项目管理制度的改革.

项目与组织架构

项目与日常运营

项目管理是将事务作为 一次性活动 来进行管理的技术. 但我们日常所处理的大多数事务却总是持续重复的. 所以必然存在项目与日常事务的关系问题.

并不是所有的日常事务都可以被当作是项目来进行管理. 有很多日常事务是重复的和持续性的工作. 比如公司的日常行政和账务活动, 通常都是这类事务. 我们把这类事务称为日常运作.

通常来说, 日常运作没有生命周期, 它们是维持性, 支援性的. 它们可以看作项目的基础设施.

而项目通常有明显的生命周期. 在项目的立项阶段, 需要通日常运作的部门协调资源导入到项目中; 在项目进行的过程中, 日常运作工作和项目工作会相互支持相互影响; 在项目收尾阶段, 项目工作成果移交给日常运作部门, 并将资源释放回日常运作当中.

而通常组织的日常运作部门通常会支持多个项目.

在组织中, 日常运作部门与项目的关系, 可以将组织的组织架构分为三种: 职能型组织, 项目型组织, 矩阵型组织.

三种组织架构

职能型组织 是一种以职能部门为核心的组织架构. 在这种组织架构中, 组织的基本单位是职能部门, 人员完全隶属于职能部门. 项目跨职能部门进行协作时, 项目经理与职能部门主管领导进行沟通, 由职能门领导将任务分派给职能部门下的人员. 比如: 公司分为产品部门, 开发部门, 测试部门和实施部门. 当项目开展时, 产品部门产出设计, 交由开发部门开发, 经过测试部门测试后, 最终由实施部门进行实施. 项目经理只能在部门间协调工作, 而具体工作的落地则有部门领导负责. 这种组织架构中, 沟通成本非常高, 对文档, 会议, 邮件等正式沟通手段依赖较高.

项目型组织 是一种以项目为核心的组织架构. 在这种组织架构中, 项目的基本单位是项目组, 人员完全隶属于项目组. 每一个项目组中配置一个项目所需的各种岗位人员. 比如, 项目组中配有产品经理, 开发人员, 测试人员和实施人员, 所有这些岗位的人员都归项目经理负责. 这种组织架构, 优点于沟通成本低, 执行力强; 但缺点在于, 每一个项目组都要配置重复的岗位, 有可能造成人员浪费, 而不同项目组间也缺少必要的交流, 不利于知识的积累.

矩阵型组织 是一种以职部门为日常设置, 但项目立项后从职能部门抽调人员组成项目组的组织架构. 在这种组织架构中, 人员未抽调到项目上组中时, 由于职能部门领导, 而一但被抽调到了项目组中, 则转而由项目经理领导. 这种组织架构其实是职能型组织和项目型组织的混合, 一方面保留了职能型组织相对稳定的优势, 又发挥了项目型组织高效的优势. 但同时它的问题也很明显. 很有可能出现多头领导的问题. 同一个员工可能接到部门领导和项目经理不同指令. 根据项目经理对项目人员的管控能力的差异, 还可以把矩阵型组织分为 强矩阵型组织 和 ** 弱矩阵型组织**. 通常情况下, 人员的绩效考核在职能部门领导手里, 就是弱矩阵型组织; 相反, 人员的绩效考核在项目经理手理, 就是强矩阵型组织.

话说, 我现在就在一个职能型组织公司中的项目型组织团队里. 我们公司整体上采用的是职能型组织的组织架构, 但因为我所在的团队比较特殊, 所以团队本身是一个五脏具全的项目团队.

项目产品化与中台策略

2019 年, 我被无锡一家做支付的阿里系公司骗回无锡. 但很快就发现我并不适合这家公司. 于是很快, 我就从那家公司离职, 换到我现在工作的这家公司.

无独有偶, 这两家公司招产品经理, 都是要做项目产品化的工作. 我对比了两家公司, 突然的意识到, 项目产品化是这类公司到达一定体量后必然要做的事情.

我们已经知道, 项目最本质的特性是 一次性. 正是因为我们把事务当作一个有头有尾, 有生命周期的一次性活动来处理, 我们才能基于规划产生效率. 在一个公司早期, 为了高效率完成工作, 多半会以 "做项目" 的方式来维持盈利. 而一旦企业到达一定规模, 项目多到一定数量, 管理人员就会发现, 其实每个项目几乎都在做差不多的事情. 既然如此, 那么为什么不把不同项目中的相同部分做成通用产品呢? 而这就是项目的产品化. 因此, 我们可以看到, 项目的产品化其实是将项目的 一次性 特征扩展到 日常运作 的努力.

而我所经历的这两家公司, 在实现项目产品化时, 都将这个工作叫做 中台策略. 中台这个概念是阿里提出来的. 阿里系有很多公司, 每个公司又有不同业务, 不同的业务往往又涉及不同的系统. 每个系统从最底能开始建构, 一直到业务层, 与其它系统相互独立, 尤如一个个烟囱树立在那里. 这样的系统构建方式有着明显的问题: 首先不同系统的建设过程中一定会有重复建设的问题, 而更重要的是, 不同相互独立的系统中的数据无法交互, 不能形成有效的大数据系统. 为了解决这个问题, 阿里提出了中台策略: 对业务导进行归纳整事, 提练出共性业务需求, 根据共性业务需求将系统底层的能力以服务的方式提供出来. 这样不同的业务功能, 通过不同的服务获取系统底能提供的能力. 就比如淘宝和闲鱼的订单虽然有很多不同之处, 但也具有共同的内核, 就是要调用支付接口来实现支付. 那么就可以把支付功能作为一个服务提供出来, 淘宝和闲鱼的订单功能同时使用支付服务调用系统底层提出来的支付能力. 这时, 支付服务就是中台服务. 通过这个支付系统, 淘宝和闲鱼两个业务系统共享了一个底层提供的支付能力, 更重要的是, 这个业务系统的支付数据都通过支付服务沉淀了下来.

而我们看到, 项目产品化时, 几乎是在做同样的事情: 就是在具有共性的独立事务中, 归纳整理, 提练共性, 并将这共性以可得用的组件形式提供出来.