项目管理之授权，拿什么信任你，我的兄弟
作者：张子良
版权所有，转载请注明出处
刚刚遭遇一个失败的项目，在遭遇和经历两个词之间我有点犹豫，最后还是选择了遭遇。这是一个外包项目，是的，外包项目，不过我们是乙方（相对的甲方），而我就是这个悲催的乙方的项目经理。先介绍一下项目的情况，整个项目分为三个部分，界面子系统、业务子系统和数据子系统（专业名称替代品，有些东西不方便说），各系统之间采用SOA架构设计，采用通讯中间件作为连接的桥梁和纽带。原计划界面子系统由我们进行开发，业务子系统外包给第三方（丙方），数据子系统为我方现有系统，不做调整。说失败是因为，界面子系统在入场联调当天即被客户否定，然后两个周后被Pass，客户找了另外一家公司，另外两部分不做变化，吃到嘴里的肉被别人给抠了出来，这也是做项目以来的第一次。写此文，以做祭奠和反思。
一、输在起跑线，撒手的外包项目管理
三月份确认项目由我负责跟进，业务子系统的外包已成定局，也已经启动，前期需求和分析都没有参与。得到高层明确的指示，完全外包出去，不要干涉具体的实施，现在看来这本身就已经是一个悲剧，后续的很多问题都是由此引起的。甲方和丙方直接沟通的结果，就是我被透明化处理，直接被无视，乐得清闲的懒惰和高层对外包方的盲目信任，成了一切罪恶的根源。期间4月份申请进入项目组，被高层以节约成本为由，婉拒。现在看来，项目管理过程中的妥协和退让，必须是有原则的。其实，从一开始就已经嗅到了其中可能的问题和风险的味道，所以我也并非完全的无所作为，既然是项目的外包，那就按照外包的套路来，以下是我所采取的措施：
1.明确时间节点和里程碑
与丙方项目经理明确要求对方提交时间节点和里程碑节点。没有时间节点的项目是可怕的，既然外包了，就不要关注细节，只需要把握大的时间节点即可。这一点感觉对方配合的并不太好，并不积极，前前后后沟通了很多次，到最后只要到了一个5月20号入场测试的时间点，这一点很是不满意啊。其实原因可想而知，要么对方并无明确的时间节点，一边开发，一边测试；要么就是对方对时间节点没有把握。后来的事实证明证实确实是后面的情况。而时间却在这无尽的往复沟通中流逝。
2.阶段成果阶段提交审核
软件开发是一个分阶段的过程，项目成果的提交必须是分阶段的，想做甩手大爷，也并不是件容易的事。不做需求分析可以，但是不了解最终的需求就是你的问题了，我脑子里的浆糊浓度还是不够的，关于阶段成果的提交，意识到对方问题的所在，我态度很坚决，也如愿拿到了个阶段的成果，需求规格说明、数据库表设计说明、界面接口报文规范和标准。
二、不要把一切都归咎于接口，不懂业务才是真
拿到界面报文接口的同时，我就开始申请资源，正式邮件，资源需求都提出来了。得到的回复就一个没人。那就没人吧，做自己能做的事情吧，别的不说，需求，关键是需求，需求是业务的代表，弄明白了需求，其实业务也就清晰了。5月10号左右吧，总算有了人可以进来，矩阵型的项目组织结构，就不要奢求全职的进入了，然后就有了界面设计的实质性工作。而在这个时候，我犯了一个致命性的错误，放手，放手让界面设计人员去主宰界面设计的工作，而自己醉心于继续整理业务流程和规则。页面部分，介入的人员据说是一个对界面很熟的人，其真能力和技能现在来评价的话，只能是一个功能级的程序员，而我却由于认识的错误，放手让他去负责整个界面的设计工作，而不是单独界面的实现，而过程中，也没有及时的跟进，阶段成果的审查。而结果，可想而知，花费了大约一周的功夫弄出来的东西，是一个增删改查都单独存在界面，没有业务，没有逻辑，没有跳转，没有...，总之除了不需要有的，其他都没有。此前，关于界面的设计，相关部分的相关人员的说法，就是很简单，很简单，这算是给了我一个血的教训：不要相信任何人说的话，除非是你亲眼看到。 其实还是我的警惕性不够高，真正的问题，其实还是在我的身上，界面部分需要和业务联调，单独根据接口设计的界面，没有经过业务的检验是不可能作为成品出现的，正是因为抱有这样的想法，我才放心的把界面设计的工作抛诸脑后的，而现实再一次击碎了谎言：做界面，是需要逻辑的，即界面逻辑，不是摆上元素就叫做界面设计的，虽然没有业务支撑的界面逻辑是不完整的，但是不符合常规习惯的界面逻辑也是不可接受的。所以，软件设计的过程中，不要将任何东西，作为默认的逻辑，常规的逻辑，即使是最简单的东西，也必须有明确的规定，否则谁也不知道最终你会拿到一个什么样的东西。
三、行动，拿什么才能挽回你的心
5月20号丙方项目团队进入客户现场进行联调，而我也终于化来了缘，界面开发人员终于到位，外部协调进来一人，原有其他项目现场人员三人，负责界面设计和实现。这样的人员配备还是满意的，虽然前期的设计版本很是不满，但考虑到现在的人员配置、任务量和时间计划，按照进度进行，完成界面设计工作还是有富裕的。
计划中与用户业务部分的沟通是迭代式，按照业务类型分类，每完成一部分类型的业务立即进行一次的关于界面设计的沟通。毕竟，业务人员要看到的是实实在在的东西，其他一切都是虚妄。而这个时候，又有一个意外发生了，部署完开发环境后，在我不知情的情况下，业务部门负责人员看到了界面设计的第一个版本，耶稣、上帝、如来佛啊，这哪是敢给客户看的东西啊。
不好的声音不断的传来，客户对界面极度不满，主要集中在三个方面。（1）界面元素看不懂，元素名称都是些技术化的名称；（2）界面设计技术化，没有考虑实际业务操作的用户习惯；（3）界面逻辑简单化，跳转关系根本就没有。突然间的变化，打乱了我的计划。调整在所难免，淡定，告诉自己要淡定。立即调整计划，界面逻辑和业务逻辑分离，集中力量调整界面逻辑，尽快拿出东西，挽救危机，争取业务部门的认可。而此时，也到了故事的高潮，界面设计负责人员执行力不够，配置了相关的资源，但是始终拿不出阶段性的东西。锦上添花易，雪中送炭难，而这时计划中的人力资源却发生了变更。
四、资源，又是TM的资源
界面开发人力资源情况的变更是意料之外的事情，来现场之前并不知晓，让我有点措手不及，三个人离职了，跳槽到了甲方。虽然经过与甲方的磋商，可以让相关资源留用到界面系统完成，但是，三个人本身要参与其自身工作内容的完成，还有一个休假回家，资源占用数不足一人，使用率不到50%。只好立即向公司申请资源，然后，我就不够淡定了。各种声音，各种阻力，前车之鉴，原则问题寸土不让。软硬兼施、软磨硬泡、争过、论过、吵过、也骂过娘。三天后，总算是有了结论，补充一个非界面设计人员进入项目组。而收到消息的同时，也从客户方面得到结论：界面子系统交由第三方进行实现，其他部分不变。
五、出师未捷身先死，长使英雄泪满襟
项目还在继续，而我依然不够淡定，毕竟还是道行不够啊。完败，完败啊。借用一位师兄的话收尾："公司的事，没人就是没人，做成什么样就是什么样，关你屁事"。是啊，关我屁事。也许真有到了关我屁事的那一天，也许我就淡定了，也许就真的不关我屁事了。
项目故事，如果喜欢就推荐一下，评论一下，多多交流，寻求正能量，积极做事，加油！！！
来源：https://www.cnblogs.com/hadoopdev/archive/2013/06/13/3133815.html