眼睁睁看着乙方把项目作死是一种什么感受（项目作死10大方法）

刚跟乙方开完会回来，在会议的后半程我感觉快要窒息了。基于本次项目合作浓郁的“政治因素”，作为“掮客”的我们只能要求不再延期跳票，尽快处理等嘴皮子功夫，其它的实在力不从心，这种感觉就真真是眼睁睁看着甲方作死，极力想拉住它，它还嫌“累”。

我是如何看着乙方把项目作死的呢？

1：乙方作为我们的行业典范、领头羊，本来一开始在实施项目的同时要起到顾问的作用，把先进的管理方法带到我们的甲方。但是，最怕的就是但是，前期乙方先以“顾问”的方式，把项目按照自己的那套照搬给甲方，到后面，发现甲方不买单啊，也对，你家东西搬到我家根本不能用，我凭什么买单？!要退货！，于是甲方已各种原因不签需求规格说明书（BR）。为了解决这个问题，乙方也吃一垫、长一智，放下姿态，去老老实实做用户需求调研，可是冰冻三尺非一日之寒，之前一半的项目时间，被自己拿来自嗨了，还剩下的一半项目时间才算要真正开始做项目，这如何得了，基于“政治因素”本来原项目时间就够呛，从剩下的一半时间开始做,天了噜!过不其然,现在离项目完结还有不到半个月的时间,却还在跟用户扯皮需求问题,我想静静!

说好的行业标杆呢?!之前说的给甲方洗脑，把甲方掰弯的承诺哪里去了？！

说好的世界500强呢?!头衔是没有用的！

说好的……?!现在反而被甲方完全给牵着走，现在对日益临近的交付日期说办不到，需求不合理等……心中感慨：被掰弯了还话多。

若不考虑到“政治因素”，信不信我赏你一丈红！没点屁用。

把项目作死首要条件：不管用户需求，不坚持该坚持的。

2.​乙方本来有成熟的产品（业界排名第一）和解决方案，之前的计划到本项目中只要实施和部署就基本能完成80%的项目工作，可做到中间的时候，发现连自己都玩不转自己家的东西，于是决定另外开发一套产品和解决方案（是否乙方是出于自己的商业目的要这样做，我们先不表）。单纯从这个决策看就有隐患：离项目交付期不到半年的时间（这是甲乙方协议延期后的时间，之前只剩不到3个月），你要另外开发一套产品并实施？！这可不是互联网用几千块开发一个APP可比的开发时间。你要架构、设计、开发、测试等......哎，不知我们谁喝高了，既然高层同意，那也无法可说，只能默默的看着它离项目截至时间越近，不能交付的功能越多，已交付的功能被甲方发现一堆Bug.

历史是车轮，只是现在它爆胎了。

项目作死条件2：中途改变实施方式​

​3:这个项目每周会有一次甲方与乙方的大会，在大会上，乙方为了彰显自己的能力（姑且这么认为吧），经常会拿出很炫的东西给甲方看，甲方看了那还了得，所以不管是什么都是“要！要！要”。这里只能说是乙方还嫌自己死的不够快，还要主动去挖坑，你放着合同中的主要功能不做，去做那些花里胡哨的东西干什么（其实就是UI设计）？！你有能力就先把主要功能给做出来啊！被表象疑惑的人都只会糊涂一时，而不是一世，这么简单的道理都还不明白，能怎样？所以本来就剩的寥寥可数的时间又去做花边设计，甲方用来验收的主要功能在交付期交不出来，WBS上一片红，这还是变更无数次交付日期的结果。对此，心里只有：打死你这妖孽的想法。

​项目作死3：需求漫延，漫延的需求还是自己作的。

4：​截至目前为止，乙方答应的功能点交付时间已经不知道变更了多少次了，2周一小变，1月一大变，再玩“政治”的也会受不了如此的“队友”。果真应了那句话，不怕神一样的对手，就怕猪一样的队友。

乙方的时间变，所以承诺给甲方的时间也需要变，然后就看到甲方的用户，从之前的满怀期待，你要怎样就怎样的合作，到后面的“只是这样”，再到后面的“还没有好”、”怎么能这样“、”不好“.....等系列失望、不配合的变化。好比狼来了的故事，你忽悠的次数多了，人家也就不管是不是真狼了。

​项目作死4：多次变更对用户的交付承诺时间。

5​.因为在自己的玩法下，交付时间更紧，在紧张的交付压力下，一般的解决办法都是项目参与人员加班，偶尔加一下班本无可厚非，但是长期加班就要出问题，而压垮长期加班问题最后一根稻草的就是团队内一碗水还端不平。怎么说？乙方团队内的正规军没有多少，主要负责在文档的书写上，主要的开发人员为外包人员，所以这就存在这天生的端不平的潜在因素。不可能要求外包人员在长期加班的情况下还保证质量，并且还需要对你的项目忠贞（这里并没有歧视外包人员的意思，只是能理解在同一家公司因为不同的工作合约方式，所带来差异的后果）。整个项目过程中就看到乙方的人不停的变化，来了，走了，人员离职变动率高。项目中人员变化会是对项目时间和质量的严重考验。

​项目作死5：项目离职率高，团队不稳。

​6：在项目早期，乙方承诺会有X位员工执行项目，我们实际看到的只有一半，每次问题另外的人呢，乙方的答案就是在远程支援。远程支援我们也认，只要能按时交付就可以了，可是到了交付的时间还是没有东西出来，所以逼了几次后，终于搬来了”YY团队“、”ZZ国“的专家，超乎意料的是，他们停留的时间可是比旅行团还短，所以估摸着就是过来走一下秀，在项目所在地旅个游的？！没有看到他们对项目的贡献。在以结果为导向的项目中，看中的是结果，真的不是中间的”秀“，需要以实实在在地人完成交付，以满足既定任务。

项目作死6：缺乏人力资源，并持续不投入。​

7：​IT项目为了赶工期，一般会节省的都是测试时间，在这里乙方已经刷新节省的下线，略过测试，直接对甲方进行交付。在约着用户一起进行功能交付确认时，直接打开就是满屏的错误，把甲方都逼出了”你是直接拉我们来做测试的吧“。事已至此，能奈何？！作为中间方的团队也碰到了一大难问题：”政治原因“必须协助乙方在最后的时间通牒进行交付，​但乙方的交付质量又如此不堪，若让交付必不能避免用户看到问题的情况。所以最后也只能表示乙方交付前让我们看一眼，保证避免满屏错误的尴尬。但个人内心对于此种做法是相当不耻。若没有”政治“原因护航，对于乙方的问题，乙方早就死了百次了，换谁当甲方都不会买单。

​

项目作死7：​交付用户的产品没有质量

​8：乙方勉强交付的几个功能在实际使用过程中，经常碰到无法使用的问题，最后往往发现是因为新版本发布所导致的问题，而版本发布的如此随意想来也是醉了。没有明确的测试环境，正式环境；没有严格的版本管控，是位开发人员都可以提交代码直接发布，在没有测试这个条件下，不出问题才怪。对拿频繁上版作为解决用户问题的手段，本人相当不耻。交付中必须要有严格的上版条件，及版本发布信息，用户是上帝，而不是测试人员。估计把用户当测试人员的也就只有在”政治因素“下的独一家了。

项目作死8：没有严格的版本管控，发布作业。

​9：今日早会中，竟听到有要求乙方一功能模块的开发人员必须100%投入到该功能的开发中用以完成既定的交付期。我的内心就开始崩塌了，与功能开发相比，对Bug进行修复就更是小问题了，而关键是乙方为何会将同一人分配到不同、并行开发的模块中？！不管最后乙方的处理结果是什么，都已可以预料到势必2个模块都会再次不能如期交付（降低标准，完成开发即可）。

项目作死9：人力安排混乱，人员同时并行开发多模块。​

​10：深通中国式关系的国人，在甲乙方关系相处中，稍微灵活点的都知道怎样与甲方进行合适沟通。而我们的乙方显然是不懂，即不能放低身段的与甲方打成一片，深入了解需求，也不能约着甲方的核心用户一起吃吃饭加深感情，探讨项目上的不足。作为项目问题多多的乙方不知从哪来的硬气，可以如此对甲方软硬都不施，这也难怪乙方做不到12306的样子，在用户大会上被抨击的一无是处，大投入可以被当做儿戏样，怒呼：不做了。

 

项目作死10：项目硬件条件（交付能力）达不到的时候，不从用户下手，采用软策略。

古人云​不再其位不谋其职，故，对乙方有太多的不满也都在”政治因素“下按下来了；能为乙方想到的各种方法也都只能烂到肚子中，只能以乙方这个项目的全过程为鉴，自己以后不犯。

一场游戏一场梦，只能继续这样看着乙方在剩下的时刻仍然继续作死，要改变？早已耗尽热情。