免费asp地方门户网站系统,上海注册公司流程及资料,重庆网站建设找重庆最佳科技,有域名可以自己做网站吗本文为才聚学员投稿的原创作品#xff0c;现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章#xff0c;被采纳即可获得丰厚稿酬#xff0c;欢迎大家关注公众号踊跃投稿。
如您有意向投稿#xff0c;可将稿件投递给我们。
故事介绍
三段故事#xff0c;讲…本文为才聚学员投稿的原创作品现在才聚正面向专业项目管理者征集“项目管理实战案例”原创文章被采纳即可获得丰厚稿酬欢迎大家关注公众号踊跃投稿。
如您有意向投稿可将稿件投递给我们。
故事介绍
三段故事讲述了我作为一个小白从项目管理0经验如何一步一步历经各种职场上甲乙方的苦难后逐渐了解项目的正确打开方法的故事。分别是不懂相关的小白阶段初入PMP项目管理以传统的瀑布式项目管理方法与门径式项目管理方法的阶段最后通过敏捷式开发方法将所学所用融会贯通。
本人愚钝成长路线涉及到转型转型后艰辛坎坷无跳级从财务分析师到BI工程师、数据工程师、架构师、项管、最终到数据产品经理。从项目范围涉猎甚广的乙方创业公司到以敏捷、创新、数据战略为优先的甲方公司。
我所在的行业不固定但做的产品和项目总是和数据仓库商务智能BI数据平台打交道。数据项目最大的特性是时间的不可预估性第二大特性为需求的不可控性。下面的三段故事经历了三种不同的项目管理方式以故事案例的形式分享给大家希望这些经验多多少少可以帮助到大家。
小白阶段-盲人摸象
01、故事背景
公司正在摸索商业模式的初创公司
角色BI工程师数据工程师
团队Lead我一个队友
管理Team内自组织型无特殊项目管理方法
在这家正在摸索商业模式的初创公司我经常被一个人发配到一整个项目上去而在这被发配的期间CEO和各种创始人们经常在公司里忙的鸡飞狗跳基本上处于不闻不问的状态全权给我这样一个初入职场的新人来把控的。
虽说这公司和我都是初生牛犊不怕虎但却因为公司整体上下一心这勇往直前的价值观与态度被客户深深欣赏经常就和客户打成一片因此事情也一帆风顺。
当项目体量足够小产品创新性没那么高客户关系像一家人那么硬的时候似乎仅通过较高的技术业务知识水平目标拉齐快速交付貌似是一个非常不错的选择。省时省力也省去了项目管理人员和Scrum Master 的人工成本。
好景不长随着我们业务不断的拓展CEO后来也不直接带项目了客户关系逐渐变得一般新手光环就这么悄悄地褪去。而没有项目管理方法的我们当时就像是在新手村毫无畏惧裸奔着的菜鸟挥着那破烂一样的木剑冲向最终关底的 BOSS。只剩下勇气可嘉。
随着一个大客户的爆雷那天终于回想起了项目的恐惧与项目管理的重要性……
02、PX 项目爆雷
项目简介
某天公司签单了一个大客户项目范围是财务损益分析与BI可视化展示该项目原本期限3个月完成后会立刻推进后续分析项目。我一如既往的被发配到这个项目但由于该客户潜力较大附带一位创始人作为沟通角色。
在成员上来看我们作为乙方公司有上述两人。对方作为甲方公司对接人是负责该项目的项目经理需求人是财务部的各位分析大表姐们Excel大神戏称大表姐。
初期预估不足
该项目没有明确的项目阶段划分没有明确的milestone节点。主要范围和时间其实就是上述的内容没有特殊的直面合同文档也没有特别的需求文档。之所以没有这些内容是因为公司创始人经常以信誉和实力征服客户但这为后续的爆雷埋下了伏笔。
在我接到创始人这边沟通后的需求后经历了一周的驻场在此期间与财务分析打成一片了解了需求又经历了两周类似闭门造车的时间后终于自信满满的拿出了第一版Demo结果这版demo 蕴含了公司的分析底蕴和其他客户的经验。按照我们一贯的预期客户会在这版Demo结果上提出一到两次的问题再经历数据验证差不多就可以交付了这样来看时间应该2个多月不到3个月。
需求变更与膨胀
在demo会议中财务分析师觉得不错但甲方的项目经理却出乎意料的一脸阴沉并提出了诸多质疑与反对说来说去就是围绕着一句话来讲“分析的很不错但这不是我们想要的。”
现在回头看看在这个节点我务必说一个公道话此处错误有二
1甲方项目经理和需求方不知道自己想要什么需求方自己甚至没有认清到需求方是财务分析师与CFO而不是项目经理且妄想从开发完成的内容中找寻灵感。
2此处方案方没有尽到充分的需求沟通、痛点挖掘、产品设计的责任后续内容是由一个乳臭未干的开发人员自顾自看着需求做出来的内容不一定能满足客户的要求。
在后来的会议中甲方的项目经理以“不是我们想要的”为由强行的把项目从“开发测试阶段”变回需求评审阶段修改已有需求新增新需求每次做这些变更时天真的开发人员我总会给他们提供新鲜的技术解决方案与Idea。
然而我不知道的是这些个需求评审是基于现有合同的报价走的也就是说不管他加了多少需求合同金额不变。大家都知道在Project Management Triangle中成本、范围、时间是互相依赖的。当范围增加资源不变的情况下时间一定会增加。因此每新增一个需求双方就要大打出手一次。
图源作者
这种因为前期合同不够细致PRD没有规定好范围痛点挖掘不够需求方没确认清楚的情况下甲方项目经理死皮赖脸扩大范围也不加钱的行为乙方除了打官司以外是无力反抗的。
逐渐合作变成了勾心斗角协作开发变成了绝望与折磨。项目时长由3 个月变成6 个月最终上线后双方皆惨败。甲方由于时间未达到预期而错过了战略发展关键时期辞退了项目经理乙方搭进去了额外的开发资源和沟通资源。
以下为内容总结
初期预估
技术范围BI可视化展示
业务范围财务损益分析
时间预估3个月
后期制作
技术范围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。只不过对于数据产品来说我们要在这套管理方法上加以修改取其精华去其糟粕。最重要的是知其所以然才能够运用自如。
