案例分享|我是这样转型做数据产品经理的？

本文为才聚学员投稿的原创作品，现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章，被采纳即可获得丰厚稿酬，欢迎大家关注公众号踊跃投稿。

如您有意向投稿，可将稿件投递给我们。

故事介绍

三段故事，讲述了我作为一个小白，从项目管理0经验，如何一步一步历经各种职场上甲乙方的苦难后，逐渐了解项目的正确打开方法的故事。分别是不懂相关的小白阶段，初入PMP项目管理以传统的瀑布式项目管理方法与门径式项目管理方法的阶段，最后通过敏捷式开发方法将所学所用融会贯通。

本人愚钝，成长路线涉及到转型，转型后艰辛坎坷无跳级，从财务分析师到BI工程师、数据工程师、架构师、项管、最终到数据产品经理。从项目范围涉猎甚广的乙方创业公司，到以敏捷、创新、数据战略为优先的甲方公司。

我所在的行业不固定，但做的产品和项目总是和数据仓库，商务智能BI，数据平台打交道。数据项目最大的特性是时间的不可预估性，第二大特性为需求的不可控性。下面的三段故事，经历了三种不同的项目管理方式，以故事案例的形式分享给大家，希望这些经验多多少少可以帮助到大家。

小白阶段-盲人摸象

01、故事背景

公司：正在摸索商业模式的初创公司

角色：BI工程师+数据工程师

团队：Lead+我+一个队友

管理：Team内自组织型，无特殊项目管理方法

在这家正在摸索商业模式的初创公司，我经常被一个人发配到一整个项目上去，而在这被发配的期间，CEO和各种创始人们经常在公司里忙的鸡飞狗跳，基本上处于不闻不问的状态，全权给我这样一个初入职场的新人来把控的。

虽说这公司和我都是初生牛犊不怕虎，但却因为公司整体上下一心，这勇往直前的价值观与态度被客户深深欣赏，经常就和客户打成一片，因此事情也一帆风顺。

当项目体量足够小，产品创新性没那么高，客户关系像一家人那么硬的时候，似乎仅通过较高的技术业务知识水平，目标拉齐，快速交付，貌似是一个非常不错的选择。省时省力，也省去了项目管理人员和Scrum Master 的人工成本。

好景不长，随着我们业务不断的拓展，CEO后来也不直接带项目了，客户关系逐渐变得一般，新手光环就这么悄悄地褪去。而没有项目管理方法的我们，当时就像是在新手村毫无畏惧裸奔着的菜鸟，挥着那破烂一样的木剑，冲向最终关底的 BOSS。只剩下勇气可嘉。

随着一个大客户的爆雷，那天终于回想起了项目的恐惧，与项目管理的重要性……

02、PX 项目爆雷

1. 项目简介

某天，公司签单了一个大客户，项目范围是财务损益分析与BI可视化展示，该项目原本期限3个月，完成后会立刻推进后续分析项目。我一如既往的，被发配到这个项目，但由于该客户潜力较大，附带一位创始人作为沟通角色。

在成员上来看，我们作为乙方公司，有上述两人。对方作为甲方公司，对接人是负责该项目的项目经理，需求人是财务部的各位分析大表姐们（Excel大神戏称大表姐）。

2. 初期预估不足

该项目没有明确的项目阶段划分，没有明确的milestone节点。主要范围和时间其实就是上述的内容，没有特殊的直面合同文档，也没有特别的需求文档。之所以没有这些内容，是因为公司创始人经常以信誉和实力征服客户，但这为后续的爆雷埋下了伏笔。

在我接到创始人这边沟通后的需求后，经历了一周的驻场，在此期间与财务分析打成一片了解了需求，又经历了两周类似闭门造车的时间后，终于自信满满的拿出了第一版Demo结果，这版demo 蕴含了公司的分析底蕴和其他客户的经验。按照我们一贯的预期，客户会在这版Demo结果上提出一到两次的问题，再经历数据验证，差不多就可以交付了，这样来看时间应该2个多月不到3个月。

3. 需求变更与膨胀

在demo会议中，财务分析师觉得不错，但甲方的项目经理却出乎意料的一脸阴沉，并提出了诸多质疑与反对，说来说去就是围绕着一句话来讲：“分析的很不错，但这不是我们想要的。”

现在回头看看，在这个节点我务必说一个公道话，此处错误有二：

（1）甲方项目经理和需求方不知道自己想要什么，需求方自己甚至没有认清到需求方是财务分析师与CFO而不是项目经理，且妄想从开发完成的内容中找寻灵感。

（2）此处方案方，没有尽到充分的需求沟通、痛点挖掘、产品设计的责任，后续内容是由一个乳臭未干的开发人员自顾自看着需求做出来的内容，不一定能满足客户的要求。

在后来的会议中，甲方的项目经理以“不是我们想要的”为由，强行的把项目从“开发测试阶段”变回需求评审阶段，修改已有需求，新增新需求，每次做这些变更时，天真的开发人员（我）总会给他们提供新鲜的技术解决方案与Idea。

然而我不知道的是，这些个需求评审是基于现有合同的报价走的，也就是说，不管他加了多少需求，合同金额不变。大家都知道，在Project Management Triangle中，成本、范围、时间是互相依赖的。当范围增加，资源不变的情况下，时间一定会增加。因此，每新增一个需求，双方就要大打出手一次。

图源：作者

这种因为前期合同不够细致，PRD没有规定好范围，痛点挖掘不够，需求方没确认清楚的情况下，甲方项目经理死皮赖脸扩大范围也不加钱的行为，乙方除了打官司以外是无力反抗的。

逐渐，合作变成了勾心斗角，协作开发变成了绝望与折磨。项目时长由3 个月变成6 个月，最终上线后双方皆惨败。甲方由于时间未达到预期而错过了战略发展关键时期，辞退了项目经理，乙方搭进去了额外的开发资源和沟通资源。

以下为内容总结：

1. 初期预估

技术范围：BI可视化展示

业务范围：财务损益分析

时间预估：3个月

2. 后期制作

技术范围：Power BI可视化展示、数仓数据处理包含财务分摊、抵消、重分类、调整、报表（范围从仅BI到Data Warehouse 数据仓库的处理）

业务范围：财务损益分析、财务资产负债分析、财务现金流分析、公司对标分析-

实际时间：6个多月

问题出在哪里了呢？自此，公司和我都深度的进行了反思，并进入了我项目管理第二个阶段–照本宣科的术与器。

初入项目管理-术与器的盲目崇拜者

01、故事背景

公司：成熟商业模式的初创公司

角色：架构师+项目管理

团队：我+开发Team

管理：PMP传统瀑布式管理法

在该阶段中，我作为架构师与项目管理角色，初入门径，窥探瀑布式管理法。但却知其然不知其所以然，徒留在表象，沉迷与术与器之中不可自拔。

下面，是数据产品与数据项目之中，运用瀑布式项目管理法的反面教材。

由于种种项目的爆雷，我们引入了传统的瀑布式项目管理方法。当时在位的几个高管比较习惯于传统的项目管理方式，于是我们在几周疯狂的调研、复盘下，运用瀑布式项目管理法、门径式项目管理法、关键路径、PERT任务计划法、需求变更管理办法、绩效调整等方式，对整体项目甚至公司管理方式，进行了彻底的变革。

02、一板一眼的项目阶段分配

为解决项目中权责不清晰，阶段不明确等首要问题，我们引入了各种管理框架作为基础。

首先，我们应用了SDLC软件开发生命周期，作为瀑布式管理方法的几个阶段。他们分别是：

1.需求分析

2.设计阶段

3.开发阶段

4.测试阶段

5.上线阶段

6.维护阶段

图源：作者

也就是说，如果我们想要完成项目，那么每一个项目都要按部就班的经历上述 6 个阶段，无论这个项目是多大的级别，项目范围有多广，时间线有多长。这也是瀑布式项目管理法中所提倡的，将项目分割为多个阶段，每个阶段互相依赖，串行完成任务。

在该方法应用的后期，我们对其进行了小部分的修正，找到关键路径Critical Path后，串行安排该路径上的所有任务，其他任务在瀑布阶段中可以适当并行。

接下来，我们针对每个阶段设立了相关的角色，如：需求分析师，只需要在第一阶段和交付阶段出现即可；架构师只需要在设计阶段出现即可；开发只需要在开发阶段；QA 只需要在测试阶段…… 等等等等。

而每一个阶段，都有一个对应的通过验证环节，只有该阶段通过了，相关的人才能结束他们的任务，完成他们的绩效。因此，我们引入了门径管理法相关内容，该环节在门径项目管理方法中，叫stage-gate 。

03、设计先行的拍脑门子大法

为完全控制好客户的需求范围，并根据其范围与内容准确预估出实施时间，我们想尽了各种办法。最终给项管和架构师出具了一个极其恐怖的预估文档-“PERT任务计划预估法” 。

该方法的最终计算过程如下图demo所示，该预估事无巨细，将所有需求归类，按数量、难度、公司背景等等因素建模。项管只需要收集信息，就可以在最终得到一个时间范围和一个置信度（你没有听错，还应用了统计学）。

该方法从头到尾的设计是本人出的，虽然该方法事无巨细，面面俱到，甚至有理论支持。但我依然只能戏称他为一言难进的拍脑门子大法。

我认为，预估未来这种事情，连神仙也无法做到，尤其是在这种数据领域。

04、甘特图与Milestone-只为领导满意

在应用了如此多的理论框架，并记录了茫茫多的文档后，我们要在项目Kick-off会议上让领导看到项目的范围、预计上线时间、阶段拆分与Milestone等等。同时，我们也会在规定周期的会议中，按当前甘特图的状态，给领导汇报项目的情况。

这时候，甘特图就派上了用途。甘特图这种可视化工具，是将项目规划和阶段高度抽象到一张图中的可视化方式，可以让领导对项目的进度一目了然。在很多领域中，甘特图是一个非常不错的工具，深得老板们的喜爱。

甘特图，也经常被成为甲乙方的沟通桥梁。只不过，就不知道在数据开发领域，这条桥梁是通往项目成功的彼岸，还是无尽炼狱的奈何桥罢了。

05、需求变更流程-敬而远之

至此，我们已经有详细的项目过程文档与方法论，在这套方法论之上，我们拥抱稳定，厌恶变更，因为变更给我们带来的是风险、Scope扩大。

风险给项目带来的是delay与失败

Scope扩大意味着乙方的资源投入增多

而甲方是否会变更合同或签订补充协议则是双方协商的结果。

如果客户在预估之上，想要增加、修改项目范围，那么我们就要出具一套详尽的变更流程，与商务流程挂钩。这个流程，甚至可以让他的审批流程越长越好，复杂度越高越好，让客户敬而远之，最好在项目期初，就把所有需求、设计、输出，全部想好。

这套流程叫，需求变更Request Change Management。

06、为解决效率问题导致的项目失败

我们在项目管理方法上线后，又进行了薪资体系变更：惩罚，个人绩效与项目负责范围与完成情况挂钩。惩罚力度非常大。

单人完成项目奖金高，多人完成项目奖金少

时间花的越少奖金越高，时间花的越多将近越低

项目delay有惩罚措施，最严重的奖金全无，项目白做

随着公司回款发奖金

这种管理办法看似目标是为了解决员工与公司利益不同的问题，其实是将外部矛盾转向了内部。项目团队很多都是些初入江湖的孩子，还有外地人，在北京都没站住脚，金钱的压力像大山一样压着喘不过气来，使得他们不得不想尽办法避免自己的钱被别人抢去，独揽项目，以“自己最快的速度”完成自己的阶段。

也许这种薪酬体系的变化在其他类型的行业，其他类型的团队中，是非常奏效的吧。但在这种大数据开发与数据产品团队，高度脑力劳动的工作内容中，大家对团队的热爱，对专业的憧憬，对创新的愿望是第一原动力，而这一薪酬体系立刻将这些美好的东西原地打散。

《Scrum: The Art of Doing Twice the Work in Half the Time》 by Jeff Sutherland：这本书解释了为什么团队协作和积极氛围对敏捷项目管理至关重要。 《Drive: The Surprising Truth About What Motivates Us》 by Daniel Pink：这本书讨论了工作中的动力来源，表明内在动机（如自主性、成就感）比单纯的外在激励（如薪水）更加重要，特别是在创造性工作中。

而我所见到的，是原本团结的团队变得分崩离析。

07、盲从术的结果

瀑布式项目管理法，真的适合数据项目吗？

在我们的脑海里，一般的项目管理就犹如自家的装修，只要图纸有了，材料方案有了，总价就八九不离十，如果前期有个充分的设计与考量，项目就会正常进行。

而在一个数据项目中，数据应用部分，比如BI分析系统，CRM系统等等数据应用侧，是需求方肉眼可见的、可以被项目初期就预估内容。该内容仅占整体的工作量 20%左右。而数据流上游中的数据仓库与数据源的集成，由于各家的业务不同，数据质量不同，数据基建不同，工作量往往占到了80%左右。这一部分内容由于甲乙方关系，IT安全限制，公司内外部信息差不同等等各种限制，往往是不可预估的，或需要花费大量的代价去进行一次看似正确的预估。

数据项目的签单，就犹如散客与庄家的一场酣畅淋漓的豪赌。没有散客一开始就知道庄家葫芦里卖的是什么药，而每个庄家都希望散客能在不完全了解全局的情况下下注，逐步被引入他们设定的框架和节奏，最终在双方的博弈中达成他们预期的结果。

在瀑布式项目管理方法的带领下：

需求分析师：在需求分析阶段结束时，产出了需求分析文档，和项目经理与架构师一起拍脑门子大法，拍出了项目预估范围与时间。在此之后几乎就不存在于这个项目之内了。而他们，却是对这个项目最了解的人。

架构师：花费大量时间在设计阶段，有些1年的项目甚至4个月都在设计。在设计结束后，不管开发的死活，留下一堆看似高端的设计文档，实际上落地起来困难重重。“也许是架构师不够专业？” 要我说，就算最高端的数据架构师设计出的文档，也会有这种问题。你问我为什么？因为数据行业中最苦的事情，莫过于如何调整方案、处理源源不断的数据质量问题。而数据质量问题是在设计阶段无法被提前探知的。

开发/测试：开发与测试是这个模式下最无脑的角色了。他们不和客户沟通，只承接架构师的方案与需求分析师的需求文档。在和他们做好交接之后，就开始一整个闭关。小项目闭关2月，大项目闭关1年。唯一汇报的，是甘特图上的任务节点有没有完成。至于输出的交付物是否符合用户需求，解决了什么痛点，用户最开始在想什么，一概不用管也根本无从得知，牛马的命也不过如此罢了。

项目经理：每周，项目经理都会花费大量的心思，整理、调整项目甘特图，调整着项目计划。每一个节点的变动，是否有影响后面的节点，风险与问题是否要暴露给管理层，亡羊补牢一样对着甘特图拆东墙补西墙。实在不行借调资源，这也是项目经理在这里唯一能做的事情了。最终随着项目DDL的逼近轰隆一声毁于一旦，产出的内容delay并且不符合预期。哎，净整些没用的。

团队氛围：在运用了这种方法后，哪里还有什么团队氛围？分工明确的体制下，各司其职。大家没有交流的空间和机会，也因为绩效设计问题不想要和其他人分享自己的项目。主打一个死气沉沉。

客户团队：客户团队期初倒是老实许多。在架构师/数据产品的忽悠下，在前期设计时非常满意产出的内容。在开发阶段，确实也没有过多的对团队进行干预，因为这个阶段主打一个闭门造车。同时，因为有了需求变更管理，他们也主打一个不变，因为一旦和项目团队提出了变更，所有人都脸色大变。可最终呢，客户的信任和关系会在项目delivery那一天，瞬间崩塌。

项目交付：这种模式下，交付的内容几乎不会是客户想要的，但客户碍于合同流程规章制度等原因，也就无法不接受这种残缺品或者压根不是他们想要的产品了，但这种客户也没有了下一期的合作。有些客户甚至就不接受这种模式下产出的内容，懒得惯着这种乙方，直接宣告项目失败。

初窥门道

上述的故事是一套反面教材，结论是：数据产品不适合传统的瀑布式开发项目管理法。

那什么项目管理方法适合像数据产品这种，问题总比方案多，需求变化比开发速度还快的项目呢？

实际上，市面上已经有这样的项目管理法了，它就叫敏捷式项目管理-Scrum。只不过对于数据产品来说，我们要在这套管理方法上加以修改，取其精华去其糟粕。最重要的，是知其所以然，才能够运用自如。