反思下项目的历程和带来的教训。此文就先简述下项目的历程：估计还是以抱怨为多。望各位谅解。
一个估计撑不了多久的项目的
发展历程
记得去年的仲夏时间，天气正是当热，三十五度算凉快的，三十七八很正常，还经常能串到40的高温，当然40度往上天气预报是不敢报的，但明白人都知道，一个铁皮碗放太阳底下晒个两分钟，鸡蛋往里一敲，一个五成熟的煎蛋就出炉了，让人不得不佩服太阳核聚变的威力。
X项目就是在这样水热火也热的环境下启动的。X项目启动之初，领导只说让G开个项目，实现这样一个功能，然后给客户看看。因为领导并没有说是正式项目，就权当是原型开发，G就给顺便整理个小三层，把页面先给画起来，数据读出来展示，然后就给客户看了。这个时候的还是直接跟A公司的老总直接联系的，M先生尚未上任。然后客户就开始提意见了，要这样，要那样的，G就照着做，但一直没有正式项目的说法，就权当是按范例这样的简单方式都给写了。G也跟领导提过，这个情况是不是应该正式立个项，领导说，再等等。就这样拖拖拉拉一个多月过去了，代码也七七八八写了不少。
有一天，领导带来个人，跟G说，你做的那个程序现在呢正式立项了，这位以后就是你们这个项目的主管，以后有什么问题就找他。G一听心里乐呵，这个把月没白搞。Q和P两位项目成员也就陆续的来报道了。既然正式立项了，那不能按之前那种烂法子做啊，G就寻思着把项目重新架构下，这么大个事当然得跟主管商量下，这一来二去的还算顺利（这中间有个关于使用ORM的事，见前文）。就在此时，A公司的M先生也上任了，并指定了跟X项目接头。M先生之前兴许看过原来的demo版本的程序，一听项目调整,1到2个星期不能有功能产出（“项目调整“这说法是领导提的，可能是怕客户有意见）,就有点不乐意，催着X项目组赶赶工，这时间太久了。这话就由领导传到了X项目组，既然是领导发话，X项目组只有惟命是从，G就给大家开了个小会，打打气，加了一个星期班，连架构，带实现，把之前一个月的事，大家给翻了个新。
这之后的一个月，都是领导亲自去客户调研，然后需求以口头和少许说明的形式，转到G这边，G再根据自己的理解分解素材，设计程序和数据库，把素材转化成任务，分配到QP和G自己。我想很多看管可能都看过这样的图：
在这样的需求调研下，程序表现往往跟客户的需求不符。领导就把需求调研的任务干脆就直接交给G了。G兼着项目管理和设计开发，本不想再参与需求调研的事，可主管说他很忙，没有太多时间调研写需求文档，公司又没有配置专门的需求调研人员，也就只好应承了下来。也就从这个时候开始，G认识了M先生，才了解到需求为何会如此零散。M先生的事，就不过多描述了，毕竟文章还是以X项目发展为主。
简单描述下X项目的组成：此项目为电子商务网站，而网站数据几乎全依赖外部接口，这个也是由于网站业务所决定的。X项目总共前前后后开发了各式各样9个外部接口。平均的说是一个月要针对一个接口开发。Q和P2位成员的能力，上个文章也说了，此处不再赘述。P要为X项目画界面做图片，尤其是M先生要求网站兼容IE678 FF 和谷歌浏览器，这也够P先生忙一壶的了。而这Q就闲了，每天只等着G设计好了，告诉他功能怎么怎么做，如果这天G没空设计新功能给他，他就聊一天QQ，听一天音乐。由此可见G要忙到什么程度。人不怕辛苦就怕比较，辛苦都是可以撑下来的，可要有个人在旁边这么一比较，这心理真是全然不同了。G是农村出来的娃，辛苦点不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁边聊QQ，看新闻，这感觉很是不爽，最最关键是这闲的主还是得听你指挥的小弟，这真是要命。于是就出现了前文中要求加人或者换人这样的事情。无奈项目组加人不成功，G只能继续匍匐前行。
转眼就到了年底，根据初始合同需求确认书，半年过去了，却才做完了三分之一多些的功能项，G的心中有些不安。有一次G去A公司跟M先生进行需求调研，讲到了对项目目前状况的担忧，M先生不愧是过来人，信心满满的说，你放心好了，这个项目我肯定给他搞活了，不可能倒。大有一切尽在掌握中的气势。虽然M先生如是说，但G心中始终是放下不，就细细总结了这半年的得失，和来年的一些计划和改进方案，交到主管手里。
这个文档的主要内容这里摘一下：
1.确定项目驱动因素，不能由M先生带领大家挤牙膏，必须要进行项目远景定义和功能集合的详细定义。
2.项目风险总结，将近半年的各种问题进行一个简单汇总，并请求主管对项目组外的风险提出相应的处理方案。
3.延迟发布周期为1周（原来是，M先生说个需求和修改意见，然后马上开动，做完就发布给M先生审查，几乎是一个星期要发布2到3次）,而且一周内已经定好在做的功能，不接受任何修改。
4.提出项目缺陷管理。对项目问题进行统一管理，这中间引起的客户和开发时间问题，希望主管能够帮助协调。
5.每日会议的召开。（原来只有1到2周有次项目总结会议），随时捕获风险。
6.望主管能够部分接收G手中的项目管理工作，减轻G的工作负担。
也主要摘下主管对这个文档的回应：
1. 明年会跟客户进行有效沟通。
2. 明年会跟领导报告，尽量解决。
3. 同意一周发布一次，但也要尽量满足客户要求。
4. 缺陷问题很重要，要管理，但还是要以客户发布时间为***位。缺陷可以后期修改。
5. 每日会议，有这个必要吗？如果没啥必要就不要开了，大家都比较忙。
6. 明年再定，看明年能不能抽出时间来。
再主要写下年后的实际执行情况：
1. 不知道主管有没沟通，反正M先生照旧。
2. 好像汇报了，但没有相应反馈动作。
3. 被G强制压为一周一次发布。M先生起初不满，但不发布他也无奈，就算是默认了。
4. 几乎是直接就丢下了。原因：主管再次表示要以客户发布时间为***位。而G照旧被压着这么多的活，再来一个缺陷管理完全是自讨苦吃，也就放弃了。
5. 这个倒是坚持了3个多月，效果还不错. 本来Q在表达方面就有些问题，就是话说不明白，每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗。于是美工P一走，就剩下G跟Q2个人，每日会议干脆停掉了。
6. 看到4就知道，这个没戏了。
回到去年年底，客户对项目总体上表示满意，G估摸着这里面有M先生很多功劳。而公司领导以业绩不好为由，让每人领了200块的过节费就匆匆回家团聚去了。当年后G从M先生那里了解到年前公司已经拿了X项目绝大部分款项时，已经离过年甚远，追悔莫及了。而这事也在X项目组3个成员的心里埋下了许多的怨愤。连G先生在内的成员也少不了在闲聊时间，发泄一些对公司的不满。这也一定程度上，导致了P的出走。有句话叫兵败如山倒，这P一走，Q也开始紧锣密鼓的找新单位，终于这个月公司也接到了Q的离职申请。本就人丁不旺的X项目组就剩下2个光杆司令：G和主管。其实Q的离职对项目影响并不大，而P的离职相对来说大的多，P这一走，美工就没了，而多功能的M先生重操就业兼职做美工，这是G也得佩服的事，说啥来啥，都能上。
项目晃晃悠悠的走到了今天，眼看着也要到头了。而G站在项目的边缘不知何去何从。
从G犯的错误来看看X项目失败的原因。
1. G兼着项目管理和设计开发，本不想再参与需求调研的事，可主管说他很忙，没有太多时间调研写需求文档，公司又没有配置专门的需求调研人员，也就只好应承了下来。
G本身已经兼着太多的职位，导致工作不能做好了，还要去接下一个本可以不搭的事情。这就导致时间更不够用。时间不够用将辐射出更多的问题：
1)因为很有多工作压着，为了能够按时完成，必然胡乱瞎搞，能省则省，最终的结果就是质量完全不到位。
2)没有办法进行有效的总结回顾
3) 长此以往，必将导致心理失衡，产生厌烦心理，从快乐工作变成了赶鸭子上架。
4)以上3点连在一起，必然出现恶心循环，最终要么人崩溃，要么项目崩溃。
目前想来，解决方法只能是，积极主动而又耐心的反复沟通，对主管和领导进行主动劝说，让公司安排个人来专门调研需求以及分担G的其他工作，让G能够专心与程序设计开发或者项目管理。上文回复中，有很多人提到了PM的重要性和存在的问题，而G身兼PM在内的多职，必然导致了项目问题，偏偏这么重要的问题，被领导主管和G在内的X项目组成员所忽略。
2. 人不怕辛苦就怕比较，辛苦都是可以撑下来的，可要有个人在旁边这么一比较，这心理真是全然不同了。G是农村出来的娃，辛苦点不怕，只是你辛辛苦苦一天忙到晚，人家坐你旁边聊QQ，看新闻，这感觉很是不爽，最最关键是这闲的主还是得听你指挥的小弟，这真是要命。
这个是心理因素，说明G这个人心理不够淡定。合理的解决方案之一兴许跟1中的一样，让人分担G的工作，使G专心与自己的所长。再者，就是人员合理流动，对于不能达到岗位需求的员工，要及时更换或补充，一方面不至于引起其他成员的不满，另一方面也是项目成功的必要条件。敏捷开发的中心思想就是以人为本，如果人心涣散，项目想成功都难。黎叔说了，人心散了，队伍不好带了，于是黎叔也被抓了。
3. Q在表达方面就有些问题，就是话说不明白，每次都要被G追问很多遍才能说出点头绪来。而这导致了Q对G的一些不满和抵抗
这是对人的管理不善，带来的严重后果之一，G明显缺乏那种让人家为他或者为公司卖力的领导能力。此点在2中已经有表现。
4. 连G先生在内的成员也少不了在闲聊时间，发泄一些对公司的不满。
G在一定意义上是X项目的负责人，而他带头在成员面前表示对公司的不满，这必将给项目组成员带领极坏的影响。这个举动说明了G在管理这个岗位上的不成熟，没有从大的方向进行考虑问题，而只是一泄心中怨气。致使人心动摇。
5. M先生提出需求和修改，然后马上开动，做完就发布给M先生审查，几乎是一个星期要发布2到3次（此处的发布指，将程序发布到测试服务器，供客户试用和审查）
这个就是明显的没有做好项目管理，简直就是把项目交给客户来管。程序发布，还是比较消耗精力的，而发布后，客户发现的各种错误异常，会要求马上更正，就导致了有时候一天中多次发布的情况出现，就因为几个很小的错误，导致时间消耗在 修改-发布-修改-发布 上。
解决方法：
1.按照较长的时间周期进行发布，但不宜过长，比如1周或者2周。并且跟客户协商好，当前发布版本的错误，推迟到下个版本修改。
2.每周邀请客户代表到公司来参与项目进展会议。让客户每星期都能了解到项目在进展，放宽他的心。约定好，每个月发布一次测试版本，让客户测试体验，相关问题，放到后续版本中修复。
3.对需求的获取和变更进行控制，比如要求客户形成书面文字，进行需求提交等。
6. G照旧被压着这么多的活，再来一个缺陷管理完全是自讨苦吃，也就放弃了。
G因为手里活来不及而放弃了缺陷管理，这是可悲的。缺陷管理可以说产品质量的保障之一，缺陷管理那长长的列表尖叫着提醒项目存在的问题。这是一个项目出现质量问题，最显眼的警报器。没有缺陷管理，几乎很难进行项目质量的监督。缺陷管理一开始的缺少和后来提出又放弃，很大程度上决定了项目的失败的必然，一个不注重质量的项目，谈何成功？即使功能全部完成，你敢放到公网上让黑客转悠2圈吗？
引用一段项目发展历程的回复，个人觉得这个回复一针见血的指出了G作为一个PM的不合格：
关于你的：
“是的，PM的问题。***个问题，这个项目就没有明确的PM。第二个问题，实际上的PM（就是G）不能行使全部的PM权力，受到主管的干扰。第三个问题，客观上说，G也没有全心投入PM工作的可能，他还兼着其他多个职位。关于G存在的问题，我会再写个，估摸着明天发。”
1、没明确的PM，项目实施难度与失败的可能性更大，公司管理体制的问题。
2、PM无实权:说明你公司属于职能型或矩阵型公司，员工面临两个直接上司，此时，PM是最无助的，唯一可做的，是先得到***领导的支持，再让其放权让PM对此项目放手一博。要不这样，失败可能性大，说得明白点，也是PM项目沟通的问题。
3、PM没全身心投入工作，有PM的原因，也有公司体制的原因，试问，你现在公司的这种体制，一个PM无实权等于没有PM，其实也是他很无助，没有办法。
说到底，要项目经理自己去争取，要项目团队去争取。沟通、沟通、沟通。
原文链接：http://www.cnblogs.com/geckor/archive/2011/05/24/2055541.html
【编辑推荐】
