Hadoop develop

博学笃志,切问近思,此八字,是收放心的工夫。 神闲气静,智深勇沉,此八字,是干大事的本领。

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

项目管理之授权,拿什么信任你,我的兄弟

作者:张子良

版权所有,转载请注明出处

  刚刚遭遇一个失败的项目,在遭遇和经历两个词之间我有点犹豫,最后还是选择了遭遇。这是一个外包项目,是的,外包项目,不过我们是乙方(相对的甲方),而我就是这个悲催的乙方的项目经理。先介绍一下项目的情况,整个项目分为三个部分,界面子系统、业务子系统和数据子系统(专业名称替代品,有些东西不方便说),各系统之间采用SOA架构设计,采用通讯中间件作为连接的桥梁和纽带。原计划界面子系统由我们进行开发,业务子系统外包给第三方(丙方),数据子系统为我方现有系统,不做调整。说失败是因为,界面子系统在入场联调当天即被客户否定,然后两个周后被Pass,客户找了另外一家公司,另外两部分不做变化,吃到嘴里的肉被别人给抠了出来,这也是做项目以来的第一次。写此文,以做祭奠和反思。

  一、输在起跑线,撒手的外包项目管理

  三月份确认项目由我负责跟进,业务子系统的外包已成定局,也已经启动,前期需求和分析都没有参与。得到高层明确的指示,完全外包出去,不要干涉具体的实施,现在看来这本身就已经是一个悲剧,后续的很多问题都是由此引起的。甲方和丙方直接沟通的结果,就是我被透明化处理,直接被无视,乐得清闲的懒惰和高层对外包方的盲目信任,成了一切罪恶的根源。期间4月份申请进入项目组,被高层以节约成本为由,婉拒。现在看来,项目管理过程中的妥协和退让,必须是有原则的。其实,从一开始就已经嗅到了其中可能的问题和风险的味道,所以我也并非完全的无所作为,既然是项目的外包,那就按照外包的套路来,以下是我所采取的措施:

  1.明确时间节点和里程碑

  与丙方项目经理明确要求对方提交时间节点和里程碑节点。没有时间节点的项目是可怕的,既然外包了,就不要关注细节,只需要把握大的时间节点即可。这一点感觉对方配合的并不太好,并不积极,前前后后沟通了很多次,到最后只要到了一个5月20号入场测试的时间点,这一点很是不满意啊。其实原因可想而知,要么对方并无明确的时间节点,一边开发,一边测试;要么就是对方对时间节点没有把握。后来的事实证明证实确实是后面的情况。而时间却在这无尽的往复沟通中流逝。

  2.阶段成果阶段提交审核

  软件开发是一个分阶段的过程,项目成果的提交必须是分阶段的,想做甩手大爷,也并不是件容易的事。不做需求分析可以,但是不了解最终的需求就是你的问题了,我脑子里的浆糊浓度还是不够的,关于阶段成果的提交,意识到对方问题的所在,我态度很坚决,也如愿拿到了个阶段的成果,需求规格说明、数据库表设计说明、界面接口报文规范和标准。

  二、不要把一切都归咎于接口,不懂业务才是真

  拿到界面报文接口的同时,我就开始申请资源,正式邮件,资源需求都提出来了。得到的回复就一个没人。那就没人吧,做自己能做的事情吧,别的不说,需求,关键是需求,需求是业务的代表,弄明白了需求,其实业务也就清晰了。5月10号左右吧,总算有了人可以进来,矩阵型的项目组织结构,就不要奢求全职的进入了,然后就有了界面设计的实质性工作。而在这个时候,我犯了一个致命性的错误,放手,放手让界面设计人员去主宰界面设计的工作,而自己醉心于继续整理业务流程和规则。页面部分,介入的人员据说是一个对界面很熟的人,其真能力和技能现在来评价的话,只能是一个功能级的程序员,而我却由于认识的错误,放手让他去负责整个界面的设计工作,而不是单独界面的实现,而过程中,也没有及时的跟进,阶段成果的审查。而结果,可想而知,花费了大约一周的功夫弄出来的东西,是一个增删改查都单独存在界面,没有业务,没有逻辑,没有跳转,没有...,总之除了不需要有的,其他都没有。此前,关于界面的设计,相关部分的相关人员的说法,就是很简单,很简单,这算是给了我一个血的教训:不要相信任何人说的话,除非是你亲眼看到。 其实还是我的警惕性不够高,真正的问题,其实还是在我的身上,界面部分需要和业务联调,单独根据接口设计的界面,没有经过业务的检验是不可能作为成品出现的,正是因为抱有这样的想法,我才放心的把界面设计的工作抛诸脑后的,而现实再一次击碎了谎言:做界面,是需要逻辑的,即界面逻辑,不是摆上元素就叫做界面设计的,虽然没有业务支撑的界面逻辑是不完整的,但是不符合常规习惯的界面逻辑也是不可接受的。所以,软件设计的过程中,不要将任何东西,作为默认的逻辑,常规的逻辑,即使是最简单的东西,也必须有明确的规定,否则谁也不知道最终你会拿到一个什么样的东西。

  三、行动,拿什么才能挽回你的心

  5月20号丙方项目团队进入客户现场进行联调,而我也终于化来了缘,界面开发人员终于到位,外部协调进来一人,原有其他项目现场人员三人,负责界面设计和实现。这样的人员配备还是满意的,虽然前期的设计版本很是不满,但考虑到现在的人员配置、任务量和时间计划,按照进度进行,完成界面设计工作还是有富裕的。

    计划中与用户业务部分的沟通是迭代式,按照业务类型分类,每完成一部分类型的业务立即进行一次的关于界面设计的沟通。毕竟,业务人员要看到的是实实在在的东西,其他一切都是虚妄。而这个时候,又有一个意外发生了,部署完开发环境后,在我不知情的情况下,业务部门负责人员看到了界面设计的第一个版本,耶稣、上帝、如来佛啊,这哪是敢给客户看的东西啊。

    不好的声音不断的传来,客户对界面极度不满,主要集中在三个方面。(1)界面元素看不懂,元素名称都是些技术化的名称;(2)界面设计技术化,没有考虑实际业务操作的用户习惯;(3)界面逻辑简单化,跳转关系根本就没有。突然间的变化,打乱了我的计划。调整在所难免,淡定,告诉自己要淡定。立即调整计划,界面逻辑和业务逻辑分离,集中力量调整界面逻辑,尽快拿出东西,挽救危机,争取业务部门的认可。而此时,也到了故事的高潮,界面设计负责人员执行力不够,配置了相关的资源,但是始终拿不出阶段性的东西。锦上添花易,雪中送炭难,而这时计划中的人力资源却发生了变更。

  四、资源,又是TM的资源

  界面开发人力资源情况的变更是意料之外的事情,来现场之前并不知晓,让我有点措手不及,三个人离职了,跳槽到了甲方。虽然经过与甲方的磋商,可以让相关资源留用到界面系统完成,但是,三个人本身要参与其自身工作内容的完成,还有一个休假回家,资源占用数不足一人,使用率不到50%。只好立即向公司申请资源,然后,我就不够淡定了。各种声音,各种阻力,前车之鉴,原则问题寸土不让。软硬兼施、软磨硬泡、争过、论过、吵过、也骂过娘。三天后,总算是有了结论,补充一个非界面设计人员进入项目组。而收到消息的同时,也从客户方面得到结论:界面子系统交由第三方进行实现,其他部分不变。

  五、出师未捷身先死,长使英雄泪满襟

     项目还在继续,而我依然不够淡定,毕竟还是道行不够啊。完败,完败啊。借用一位师兄的话收尾:"公司的事,没人就是没人,做成什么样就是什么样,关你屁事"。是啊,关我屁事。也许真有到了关我屁事的那一天,也许我就淡定了,也许就真的不关我屁事了。

 

 

项目故事,如果喜欢就推荐一下,评论一下,多多交流,寻求正能量,积极做事,加油!!!

 

 

 

 

 

 

  

 

 

posted on 2013-06-13 23:35  张子良  阅读(6242)  评论(1编辑  收藏  举报