项目实际问题分析：如何收拾烂摊子
目前陷入了一个泥潭项目，难以自拔，而且遇到的问题非常危险，甚至可以威胁到公司的生存，现在把问题提出，请大家帮忙解决。
问题:中途接手
我是项目中期接手的。原来时间限期达到的时候，项目只完成了 10% 不到。只有 1/5 的设备给了客户，软件一点都没有，环境完全没有建立，甚至需要的网络环境都不具备。所有供应商代理商的信息我都没有，所有的价格都掌握在少数人手里。甚至开始的时候，我要自己去找网线在墙的什么地方(以前的项目经理撒手不做之后，什么都不想理会了，只给了我一张那时已经过期的，过去项目的进度表)。
分析:在没有接手前就应该先搞清楚项目的现状和面临的问题，你接手后是否可以获取到高层的支持，可以利用的干系人和资源以估计项目风险和胜算。只要接手了就要承担项目失败的责任而不是去找客观的原因推脱责任，项目存在的任何问题只要转变心态都是可以找到解决方法的。所以我们强调的是中途接手项目第一重要的就是充分的分析项目的现状，理解项目目标，重树项目团队信心。但这绝对不是操之过急可以解决的，你越急会增加整个团队的混乱。价格掌握到少数人手里可能需要考虑的如何获得他人的信任和高层的支持，自己找网线更不是什么大不了的事情，团代队没有稳定前项目经理可能充当任何一个团队成员的角色。
问题:没有需求管理
我甚至不清楚过去项目进行中，以前的项目经理、业务甚至是公司总经理对客户口头做出了什么样的承诺。客户经常把我问的一楞一楞的。他说：以前你们公司都满口答应了，为什么你还推三阻四的。其实不是我不答应，我是要负责任的啊，有些根本就是不现实的，或者对项目进度有重大影响的。我回公司问相关人员，没有人可以确认相关问题。
分析:完全是公司自身的工作交接出现问题，你和以前的项目经理，业务和公司总经理应该进行完整的工作交接，以前项目经理有过的口头承诺虽然没有通过需求管理很好的管起来的，并不代表这些信息无法获取到。新项目经理去和客户沟通之前必须对整个项目有完整的理解，通过工作交接将用户的需求文档化下来，如果不这样仓促和用户沟通是很被动的，而且用户本身也不应该承担这些重复讲解需求的业务。
要让对方让步首先要表明你已经付出了巨大的努力，客户也不希望整个项目搞砸，这样的话客户方的相关人员应会承担相关的责任。所以明白2/8原则哪些是用户真正关心的功能和模块，这些才是需要重点考虑和满足的。
问题:客户拒绝交流
由于中途接手，客户告诉我，相关的需求已经同我们公司不同的人员讲述了三次，不想再多讲一次了。而且，要求直接和我们的程序员对话。但是那个程序员已经走了，不再做了，他连一份书面文档都没留下。只有代码。
分析:工作交接和过程管理真的太多问题了，这种项目没有最终失败真的都是奇迹，在这种焦油坑下已经不是去改进工作现有的过程可以挽救的了。先给公司内部人员沟通吧，用户给公司讲需求不会每次都给那个走了的程序员一个人讲吧?这种情况下要么项目经理是业务技术超牛的能人，要么项目经理能够找到1-2个类似的能人。能人的作用就是项目经理他们创造良好的环境后，他们往往能够创造奇迹，从代码逆向分析需求不是什么不可能的事情。
问题:没有资源
要人没人要钱没钱。客户要我们程序员配合，没有。要钱请民工，因为我是中途接手，甚至成本都算完了，我不能申请。要项目奖金，没有。甚至我当初要求给客户的设备，推迟了四次，累计三周的时间才给到客户。项目能不延迟么?
分析:晕倒，再死亡之旅的项目能大逆转的前提一定是资源能保证和项目高层的支持，如果这点还不能满足，项目基本注定失败。聪明的项目经理对于这种项目一定是不会盲目接手的。如果接了，你唯一的期望就是如何死的好看点，如何为这次承担替罪羊后捞取其它的资本补偿。
问题:无法控制的进度
没的说了，各种以前遗留的问题冒出来打扰我的进度。而且公司经常调我的人手去做其他的事情(小公司么)。甚至问程序员那边要进度表，给我的表吓我一跳，整整比预计推迟了两个月(要知道，总共才两个月的项目时间要求，而且已经是和客户协商推迟的了)。其实程序不复杂啊。
项目做到现在，我已经把所有的硬件问题解决了，并且客户要求的主要工作，我也做好了大半。但是最关键的程序却一直没有办法给到客户，客户越来越恼火了。他们计划的是上个月就一定要用上我们的软件!
分析:生于忧患，死于安乐。项目经理没有很好的风险意识而防患于未然，再好的进度跟踪和控制都没有用。
|
