一个失败项目引发的思考

it2022-05-07  0

看着这个项目已经进行了漫长的半年时间,项目的生命周期已经变形,内脏也支离破碎。项目已经out control。不觉都要悲叹和吐糟下:

项目简介:

一个关于医疗行业心电图的Android项目。敏捷开发。1个PM,6人开发,2人测试。

项目刚刚出生一个多月,就来了一次大换亲。PM离职,技术经理离职。先不提客户反应,余下的战斗力经验少不说,对于OpenGL 的技术也不熟悉。但是生活还得继续不是吗?于是配备了新的PM和技术经理,这位技术经理还是借调的。于是新的团队成员也已到位。技术经理从能力态度人品上,都没有办法去评价啦。于是还不会走路的项目,又一次转送。技术经理离职,一个员工离职。于是又加入了新鲜的血液。重视程度也增加了。索性项目这孩子没有夭折,只是遍体鳞伤而已。看病,打针,对症吃药。

 

项目已经无法用三角架来衡量固定了,时间未知,质量待定,成本超额。只是大家还不想判定这个项目失败。最起码挽救还有有效果的。

 

经验教训:

1 敏捷就是一个错误 真是为了敏捷而敏捷,团队的个人能力达不到,需求的未知又贯彻的是那么彻底。玩敏捷,就是自掘坟墓。

2 PM太心慈手软,PM对我说,当你看到 交给程序员一个任务,他反馈回来的是一堆垃圾,你还要和客户去解释。噩梦吧就是。悔不当初,还在前期可控的时候,就应该强烈要求开人。总以为下一个迭代会好点。可是面临的只有时间紧,任务重,能力差,不出活。

3 频繁的更换团队主力。一个团队的组建,不都是要得心应手的兄弟嘛?频繁的更替,没有共同期望值,个人利益大于公司利益,人心涣散。

4 遇到问题不在自己可控范围内,尽快让问题升级。不要为了表现能力,反而将自己陷入泥潭。

5 最关键一点,得到上级领导大力支持。本项目,领导口头支持,但实际困难重重。人员将就, 开发、测试 使用的Pad也的抢着用,催你控制成本。

6 技术经理不屑与人沟通,自己能力却也有限。和PM吵架,不和谐的因素太多。其实离职也许对新任PM是个好事儿吧。只是在项目上挖坑太多,让后面的人深感苦恼。

7 交接工作不够完善:1〉 没有需求文档 2〉不用考虑时间,做就可以。----甩手掌柜的是走了,新的PM看到合同8月中旬项目交付,傻眼了。居然在还有3天需要交付的时候,才发现项目原来有交付日期。这简直就是一个笑话。能怎么办,延期,只能是延期。

 

这几天看到项目走上正轨,不觉想要夸赞下新的PM,一个有涵养,有责任的人。幸亏,还有这么一个负责任的人在。我们玩笑的时候会说:在美国这10年没白混,就是比我们有责任感。项目多亏有你。她开玩笑说:我也是死撑着。其实内心奔溃好几回了。谁都不能一走了之,太不负责任。

项目的损失会控制在最小。但吸取的经验教训却是珍贵的财富。你犯一次错,绝不会再犯。或者参考比较。

 

人非圣贤,孰能无过,过则能改,善莫大焉!

人能通过时间进行漫长的塑造。虽然不都会名扬千古,最起码有了塑造的功力,也差不到哪里去。但是项目呢,差之毫厘,谬以千里!所以计划在先,综合思考。值得谨记!

转载于:https://www.cnblogs.com/Elsie/p/3328409.html


最新回复(0)