七个项目经理的项目管理总结与反思，成败皆有原果

(一)项目管理的一些反思

简单复盘下最近几个版本迭代的工作：
先说结论：
1.     在项目的开发和进展上，大部分时候是符合预期的
2.     上线后的用户反馈并不是很满意，总是会出现奇奇怪怪的bug，有的影响到用户体验，有的没有。事实上，我觉得这些bug在测试的时候谨慎一点是完全能够避免的。当然，已经很久没有出现文字错误，换行错误这样的错误了。
3.     基本上每一个版本都前松后紧，对于任务的时间节点，缺少控制。

从这几个版本来看，每个版本的迭代周期为4-5个星期，前2-3个星期做开发，后面的一个星期用来测试和预发布环境测试，最后一个星期用来上线和做上线后的扫尾工作。一般来说，上线后都会遇到各种各样的问题，好在问题一般出现在后端，是上线遗留问题，基本在上线后发现了问题，可以很快处理。
这样的线性流程会带来部分问题，主要提现在以下几个方面：
1.     开发过程，前松后紧，在开发的前期，总是出现，部分开发人员没有按照进度完成需求，到了项目后期，只能砍需求或者将需求草草完成。这两个处理方案，都会带来问题，砍需求的话，比较直接就是项目没有按照预期完成。而第二种处理方案则是导致项目质量变低，需求没有最大范围和限度内完成，同时质量较差，容易有其他的问题，浪费测试和开发的资源。
2.     没有很好的使用敏捷的开发方式，将测试的放在最后，也同样会引入两个问题，比较直观的问题是，测试的时间不够，测试的深度和广度都不够，就很容易在上线后暴露出其他的问题，其次就是有些设计的逻辑问题或者不合理的规划，没能很早的暴露出来，而是在后期才暴露出来。
3.     因为对项目的把控力度不够，资源也没有很好的被利用起来。例如，前几周的时候测试的资源就是闲置的，或者开发按照自己的喜好安排工作，工作没有全部完成而是一块一块。

为了解决以上的几个问题，我们引进了敏捷开发里面常用的，看板和sprint，每个周期的任务在开发前计划好，在任务的安排上也不再是之前的前松后紧，而是替换称为了前紧后松，当然这也并不是真正意义上的前紧后松，而是在可以预见的周期内对需求和用户故事进行安排，而后面的周期内，则主要是解决bug和处理一些可能会临时插入的问题。而测试人员也可以在每个周期结束的时候介入，提出bug，开发人员修复。
使用这样方案的可能可以在一定程度上解决上面所提到的问题：
1.     开发在不同的阶段目标都明确，对于项目进展的把控的比较好，开发人员遇到的问题可以及时的暴露出来。
2.     在每个周期结束后，测试可以根据上个周期的任务进行测试，避免测试任务堆积，相关的问题可以及时修复。
3.     资源的利用效率较高，实际上也更更敏捷。 

总结去看，之前的方案，其实并不是真实的敏捷开发，而更偏向于瀑布型的开发方式，需求定了，上线的时间定了，每个版本之内的任务是线性的而并非交叉的。
而后面的方式，则是比较好的运用了敏捷的优点，并且使用了看板和sprint这两个工具来辅助进行项目管理。


（二）项目管理工作中的一些自我反省


项目管理培训学习体会总结，工作中自身的一点不足之处：
1.平时工作之外的交流太少

2.主动性不是很强，特别是针对上面的项目争取，人员争取

3.过于专注细节，有的时候缺少大局观

4.什么事情都想亲力亲为，不利于团队成长，自己也很累

5.做事缺少详细的计划

6.过于追求完美，影响速度

7.说话过于直接，偶尔有抢领导的话的毛病，需要注意

8.团队气氛凝聚力方面做的不够

这是一次深刻的批评和自我批评中得到的收获，认识我的人可以再提一些，我一并改正.


（三）一次失败的项目管理的反思


一、开始：
1.要有规划，并且铁一般的意志推进规划的执行！
2.规划不是大概，而是要有可量化的目标和标准，比如写作写了几页。
3.唯结果论，只有输入没有产出等于零。跑了一天code没写几页等于作废。
二、事中
1.不为未来而忧虑，不为过去而后悔。我所有的现在就是最应该好好把握的时间。
2.我不是一蹴而就的天才，当下没做的事情别指望下一刻就能勤快起来出现奇迹。
3.完成胜过完美。只要出了成果就可以不断修改，烂尾楼被返修成精装容易还是平底一夜起高楼的概率大？
4.带着目标、带着问题去做事，而不是盲目尝试，否则就是浪费时间。
5.写不出来其实是编不出来，有理有据阐述事实就容易多了。所以怎么想办法去做得扎实？
三、事后
1.只为成功学经验，别为失败找借口。
2.成功、勤奋其实是一种惯性，你尝到奋斗的甜头就会不断原因去拼搏，像滚雪球一样越来越容易成功。越努力越幸运！
3.拖延到最后那一刻全力爆发的感觉其实会上瘾，但是更想要玩个踏实睡个好觉的心安。


（四）项目管理之感想与反思


带项目已经一年了，在这期间无论从技术上还是管理经验上感觉自己成长了许多，在整个项目组中，我为项目经理，但同时我也是最辛苦的。但我更享受这种感觉。

现总结下这一年在项目中是如何进行管理的，希望大家看了能给出好的建议。

首先说明下，因为公司是属于事业单位，而且里面的员工大多都是干了好多年的老员工，所以公司里平时的工作氛围并不好，工作非常懒散，迟到现象更是非常严重，一天中有效工作时间能够保持在5小时就不错了。当然，我并不属于这一类。我曾像领导反映多次这种现象，但领导并没有给出一个合理的解决方案。

之前项目组分工的时候，都是给某人分配好任务，然后就不管了，对工期也没有太多的限制。因为本身员工懒散，公司也习惯了这种懒散的状态，所以每个项目的工期都会拖得很长。

在我管理项目后，领导和我说需要改变这种状况，于是我们实行明确的分工制度：
1、项目开始时由我对项目进行拆分，将其拆分为一个个的小功能点
2、将每一个小功能。分给项目组每个人，并指定工期。
其实对项目进行拆分并预估工作量是一个挺困难的工作，当我对项目进行拆分完毕，其大致的实现思路我也基本了解了。
我对项目组成员进行分工，最初公布分工以及工时时，大家都感觉不可思议，因为我分的时间几乎都很短，大家都认为完不成。但最终，却是在我估计的时间内完成了。而这个项目，大家对时间的利用率，大家的工作效率有了明显的提高。

在我管理项目中，我主要做以下工作：
1、和需求对接，进行整体的技术选型与数据库设计
2、控制项目的进度
3、对项目组成员分工
4、项目创建，核心代码以及一些基础代码的编写

到了后面这个项目，公司需求方其实不太负责，基本上整个项目的所有工作都由我们项目组做了，而做好的原型图也没有一个好的反馈。在这推荐一个画简易的原型的工具 Balsamiq Mockups 3，简洁易用，我一直在使用。 

通过这几个项目，也发现了些问题：
1、项目组成员之间交流不够，有的一个同样功能的方法，却写了不同版本。
2、其中个人觉得最难办的就是项目组中有个别老员工，工龄都比我长好几年，有些时候甚至会耍脾气，开会的时候只会盯着手机。我也没法去说这种情况，说了只会使关系恶化，当然，像我领导去反映这情况，我也没干过这事儿，因为我和领导关系还不如人家。
文笔不佳，大体的流水账般叙述出了这些事儿，希望大家能够给出管理上的建议，互相的学习与成长。

最后想说的是，工作时间的长度并不会成为你引以为傲的资本，努力的提身自己，提升自己的技术，走到哪里才会都有饭吃。


（五）项目管理之反思一设计篇


     客户要求改图纸。这已是第N稿改图了。业主的善变，一会要这样，一会要那样，要改图。业主挑刺图纸的问题要改图。甚至在管间距上，设计150业主要160，本来150-200之间的管间距是符合设计规范的，业主独独提出要160，我也真想不出来，他是要怎样？

  业主说我们不专业，这个话成功挑起了我的怒火，作为十几年专业经验的团队，就因为一公分只差就被客户戴了这样一个帽子。有对客户无妄挑刺的气愤，有对团队的不用心，也有对自己的失望。种种情绪交织而来。

   后来，仔细想想。我们的确有做的不如人的地方。否则也不会让业主产生这样的误解。这么多年我们收获了很多业主的肯定，我们也陶醉在业主对我们专业的夸奖里。一猛的，有人说我们不专业，似乎一个清凉凉的耳光打在脸上，火辣辣的！但这耳光打的好，让我瞬间明白，人外有人山外有山，英雄莫提当年勇，每次的战役都没有长胜将军军。我们做不到行业内的NO.1，就需面对自身的不足。提升自我专业能力，提升团队技术能力，提升团队服务意识！通过努力扭转客户的观念。即便这次项目流产，对以后也会利大于弊。

      前些天我还在和设计师说，我最喜欢的还是项目前期设计的纸上谈兵阶段。在这段时间阶段里我沉醉在设计思路里，设备的有效性和建筑的美观性和谐统一，建筑的硬伤如何去规避，设备的尺寸怎么隐藏在装修的各样造型里。怎么样为业主提供更专业的服务？怎么做更深入更细致？等等等等，我在很认真的孵一颗蛋。但往往是这颗蛋孵着孵着就变成一颗臭蛋，一颗让人心生芥蒂的臭蛋。

     首先，这个孵蛋的甜蜜期自合同签署就基本要结束了。收款的难度是其一。其次是协调的难度增加。刚开始画图时只有设备工程师，装饰设计师，业主三方沟通，在施工阶段，我们的施工团队，与现场各专业间的配合，包括现场与图纸之间的误差。多角色之间的沟通难度也会根据专业特点，协调人的专业素养，协调沟通能力等等加大。作为总负责人，工期质量现场要求，业主新的要求等等都会出现。只要有一方不满意，下面工作的推进就有了不同程度的障碍。都说人生是喜忧参半，在每一个项目上体现的更为明显。一半是火一半是水。业主开心时，你有百般好。业主不开心时，一点小问题也会把你骂的死的心都有。没有一个人想把项目做砸，但每个项目都有他的宿命。不管你怎么用心，最后的结果总归是不能让人十分的满意。

     吐槽归吐槽。作为职业经理人应有的思维方式还是应在每个项目中总结经验，吸取教训。虽然每个项目出现的问题都不一样。每个项目总是不停出现新问题然后想尽办法解决他，就好像通关打怪兽，层出不穷的小怪兽让你疯狂与崩溃，有的时候还会被小怪兽踢出局，但每次都是不可多得的工作经验。还是要感恩业主给的试错机会。

     每个项目从开始到结束，都是一场虐恋。每个项目都会做检查与总结。有关项目中的种种失误，有设计有施工有沟通有配合等等各种类型。这次为设计篇。

     本文发自图纸出现设计粗糙、被业主指出违反规范等重大设计失误，特记文反思！

     也希望能抛砖引玉，获得更多的管理理念与思路。

（六）项目反思

从好几个月前开始的一个关于医院回访系统的项目，项目倒是一个很普通的项目，复杂点的可能是这个项目有关于事业单位的一个项目。经过这个项目的教训，让我明白了他复杂在那里。事业单位的干系人，每个人都怕承担责任，而恰恰跟民营企业不同的是，他们可能有多个干系人。一个干系人负责拍板，一个干系人负责对接，一个干系人负责体验等等，再加上一些外部干系人，OMG（这么小的一个项目都搞不定，书白念了，汗颜）！

那么由此，问题就来了，这种复杂的项目，我们该做好什么呢？或者说那些因素影响我们签字验收的进度呢？是【沟通管理】。

下面科普下影响签字验收的几个因素吧

项目具有商业或企业范围内的影响
错误或失败可能导致死亡或生命，财产等重大风险
严格遵循预测型生命周期的项目
监管严格的行业
从上面发了2点 

一是影响，签字了万一有问题，谁承担责任？
二是医院有的时候属于业务繁忙期，这时候分心来验收项目？分心导致医院诊疗业务发生医疗事故谁承担责任？
问题这么多，怎么办，我想了下，确实是我们这边的沟通管理没做好

没有规划谁来负责沟通，什么时候沟通，什么方式沟通，沟通是否记录备案
没有沟通对方的时间安排，没有明确的时间点，外部的原因造成的问题，沟通是否有记录
事先没有明确的定义相关干系人，并定制化沟通
问题很多，也让我学到了很多，后面的项目可能会在这块格外注意下。

最后对项目团队成员感到深深的歉意，这么小的一个项目，居然还出这么多问题！另外一点是肯定会越来越好的，看接下来我们怎么做了。

（七）“纸上谈兵”与项目管理事后反省

　　“纸上谈兵”一般被人们用来形容只会夸夸其谈、不切实际的人。不过有时候，“纸上谈兵”也能帮你解决问题。下面，我们就来看看项目管理中的“纸上谈兵”。
　　案例 ：
　　国内某城市在建设“数字城市”工程时，需要在全城主要的公共场所设立多媒体终端，形成“城市多媒体终端网”(简称“城市多网”)，向社会提供城市综合信息查询。
　　此项目由该市信息中心和当地电信部门合作完成。其中，市信息中心负责信息资源的整合和“城市多网”的报建及施工协调；电信部门负责“城市多网”硬件设备的购买和安装、软件开发、网络建设以及系统集成。
　　经过双方协商后，确定项目进度为：在协议签订30天内，完成所有的报建审批，同时开始信息资源的采集和发布；在协议签订60天内，完成整个项目的集成测试，进入系统试运行及验收阶段。项目在协议签订之日正式启动。
　　接手的项目经理王先生，来自电信部门的通信建设部。虽然他很年轻，却已参加过多个类似项目的管理。
　　很快，王先生组建了由技术人员、网络专家等组成的项目组，并召开了几次工作会议，确定了以下几项工作：(1)与市信息中心一起确定多媒体终端的安装地点，并与业主、供电等部门协调安装施工的相关事宜；(2)将多媒体终端部分外包，相关的网管功能一并由生产厂家设计实现，为此，需要与厂家就终端的外形、功能等进行商讨，并确定交货日期；(3)安装终端及相关软件；(4)联调后移交。
　　随后，王先生向项目组成员分配了任务，并向大家强调了项目进度。
　　项目开始后，王先生发现，困难层出不穷，远远超出他的经验。比如，以往他参与的线缆敷设工程，施工地点大多是在路边或绿化带，施工需协调的部门相对较少，施工时受到的干扰也少。而现在的施工地点大都是在人流密集的繁华地段或是宾馆、商场等的大堂，施工需协调的部门很多，包括设计部门、市信息中心、业主、供电局、规划局等等。而且，这些部门之间的利益要求非常复杂，甚至还有冲突。一些地点经协调后不能达成一致，不得不重新选址和报批。而且，由于施工协调的流程复杂，往往一次流程还不能解决问题，需要往复多次，造成进度拖延。
　　结果，报建工作超出两个多月后还没有完成，只好采取一边报建、一边协调施工的办法。
　　不仅如此，外包的部分也出现了严重的进度拖延。由于在项目开始时，项目组和厂家双方都对终端的最终功能及性能需求不很明确，造成终端生产出来后不能满足要求，需要修改。同时，项目组还发现厂家的技术能力不够，对新提出的功能需求及性能指标不能及时跟进，影响终端的安装进度。无奈之下，项目组只好重新选择了一家供应商参与终端的设计生产。
　　王先生与项目组一直在紧张地工作着。然而，在超过最初项目进度目标250%之后，该项目才最终通过了合作双方的联合集成测试。
　　项目是完成了，但是却大大延期了。作为一个有经验的项目经理，小王对这一结果感到既无奈又有些不解。自己明明已经参与过类似项目，怎么还会出现如此“后果”。
　　事后的“反省”
　　在这里，我们可以仔细分析一下，在这个项目中，小王都遇到了哪些问题？
　　实际上，小王负责的“城市多网”项目，在工作内容上超出了他以往的经验。“城市多网”的工作内容中，只有网络施工和小王以前的工作经验有关，但还不是完全一样。“城市多网”项目的施工难度大大超出了他以往所参与的网络施工项目。
　　并且，项目中的其它工作内容，比如终端设计、软件开发和产品外包管理，都与他以往参与的工程中服务外包的管理经验有很大不同。这是因为小王以往参与的项目基本上都是需求明确的，且工作在施工现场，便于监控；“城市多网”项目的产品设计和生产是在供应商方面，与项目小组不在同一地点，管理和监控的难度更大。
　　把上面提到的问题总结一下，就可以知道，导致此项目延期的主要原因有两个：
　　(1)实施过程中出现了太多的变更，比如终端安置地点的改变，终端硬件设计的改变，软件功能需求的增加、修改，网络设计的改变等等，这些都造成了大量的无效工作以及新增工作。
　　(2)施工协调难度太大，远远超出了最初估计的工作量，导致协议要求的进度目标根本就不现实。
　　“纸上谈兵”第一步
　　在项目工作内容超出项目经理包括项目小组成员的经验时，就需要通过预先的筹划来模拟项目实施的可能情景。这就是我们所说的，需要先进行“纸上谈兵”。
　　针对上面总结出来的两个主要原因—变更太多和协调难度太大，我们可以做进一步的分析。
　　首先，变更太多的第一个问题就是多媒体终端安置地点的变更。这是由于项目组在确定多媒体终端网点分布图时，没有明确定义网点可以进行安装所需要的条件，或者说验收标准不明确，导致在一些还不具备施工条件的网点上做了许多无效的工作。
　　其次，对于“城市多网”的关键组成部分—多媒体终端产品的需求不明确，导致了项目实施过程中出现大量关于产品范围的变更。比如，在进行供应商选择时，缺乏有效的技术指标要求。在与供应商签订采购合同后，项目组对供应商缺乏有效的时间监控点和产品质量控制点，导致供应商产品返工，进度失控。最终，还导致项目组被迫调整供应商。
　　第三，施工中协调难度太大。这是由于项目组在进行协调工作安排时，考虑得不够全面，没有将所有需要协调的部门、单位考虑进来，也没有事先了解协调的流程以及相关部门的协调需求，因而低估了协调的工作量和难度。在项目实施过程中，造成工作安排的混乱，出现了许多不可控的等待时间和低效的协调工作。
　　既然发现了问题的原因，我们就可以对症下药，找出解决问题的办法。针对上面的问题，项目组应该从以下三个方面入手：
　　(1)关于产品需求不明确的问题，通常需要在项目开始实施之前，安排一个产品需求分析过程，并对该过程需要做的工作、过程中可能出现的困难以及过程结束后需要提交的结果，做出一个明确的说明。
　　(2)在讨论项目时，一定要面向工作的结果。比如，仅仅知道要对安装地点进行施工协调还不够，还要知道什么条件下安装地点可以算是准备就绪，这是安排具体施工的前提。
　　(3)对于施工协调工作，要周密地分析所有相关的干系人，得到一个准确的协调行动计划，并对可能出现的等待，预留出足够的时间。
　　这里只列出该项目的部分工作。这些工作都可以在“纸上谈兵”的过程中完成。在这里，“纸上谈兵”的目的就是要得到一个系统、有效的项目计划。