我是一名项目经理，把一个项目带崩了--案例分析

​ 这是山猫的第61篇原创

今天来给你们看个真实案例分析（如下为案例故事）：

我是一名项目经理，在过去的四个月里，我把一个项目带崩了（上线后频出问题，用户没法使用）。在最近的几天，我天天都在反思本身，我都在问本身如下几个问题：

1.我作错了什么？
2.我在其中占有多重的因素？

如下内容，我将回答以上问题，并在最后说一下个人补救措施。

1 项目和团队背景

首先给你们说明一下项目背景，以便各位对此项目有更清晰的了解：
1.该项目是一个二次开发项目，第一个基础版本（打印申报系统）也由我带领开发。
2.系统是须要和国家系统对接，有三条主流程。
3.需求频繁变化，因为系统须要对接国家系统，需求方对需求也不甚了解。曾在5月份一个月内需求变动超过8次，都是主流程变动。
4.项目大小按照最初需求估算，约在100人天左右。
5.项目两条主流程没法测试，依赖于外部U盾，但开发过程当中并无U盾。
6.客户现场使用U盾调试和开发时间约为20天左右。
7.我当时同时负责大大小小4个项目，没有进入开发，仅管控进度。
8.团队成员共3名，其中两名是当时开发基础版本的项目成员，他们对此项目较为熟悉。
9.项目推动过程当中，须要屡次去现场调试测试，由团队中的两名工程师共同前去。

2 我作错了什么

2.1除了监控进度，还要管理质量
在项目的开发初期，我制定了一份详细的开发计划，用于指导整个开发过程。开发计划交付与了客户，而答应了的事情就要作到，因此在整个项目过程当中，我对进度管控很严。我按期检查功能是否完成，按期和客户汇报状况，保证了开发进度顺利推动。但也由此埋下了祸根，仅仅看需求是否完成，而未关注完成的质量如何。

项目质量出现了许多细节性问题。好比：
1.上线后，客户那边发现其中一条主流程都走不下去
2.其中申报功能，系统提示成功。但实际上并无真的申报成功，申报后在国家系统没法查询到
3.打印功能小问题较多，打印获取的数据错误
4.同步数据的功能没法同步或者同步的数据错误
5.执行时间过长的功能，数据库会强制断开链接
等等问题，就不一一列举

2.2 反思：

1.进度和开发速度当然重要，但以质量换速度不可取

2.若是开发时间和质量冲突，优先保质量，毕竟你埋下的坑，老是要坑你本身的

3.再困难的状况下，也要保证基本测试

4.时间极其不容许的状况下，也要保证主线功能顺利执行

2.3 既要给予信任，也要保持警戒
项目中的三名成员，都是合格的开发，对使用的框架很是熟悉。其中两名仍是基础版本开发成员，对需求也很熟悉。因此项目中，我放心的把整个项目交给了他们。基于对他们的放心，加上其余项目事情繁杂，对此项目关注度，对他们的关注度就不够了。

我在项目中给予了他们很是充分的信任，信任他们能够把一切事情都作好。但我没有在正确的时候给予他们正确的指引，项目中出现的困难点，我也没有帮助他们解决，甚至于没有给出思路。全部的一切，都靠他们本身完成。我在这个项目里作的，就是对接客户，催进度。再无第三件事。

2.4 反思：
1.不论什么缘由，都要关注到项目成员的状态
2.给予信任没错，但也要适当保持警戒，他们多少会由于经验问题疏忽遗漏一些问题
3.给予信任，也要给予帮助，不以时间为理由推脱你应该对他们进行的指点和帮助。毕竟如今剩下来一分钟，之后要花一个小时去弥补

2.5 若没法全局掌控，就指派专人负责
这是我在项目中作的最错误的地方。

因为种种缘由，我没法掌握到项目的每一个要点和细节。而项目中有三个开发。我并没指明其中某一个来负责整个项目，全部事情都让他们本身商量。从客户对接来的问题，我也是仅告知对应的开发。整个项目中，没有一我的对项目中的每一个要点了如指掌。

2.6 反思：
1.手里捏着管理的权利，却没有作到管理的事情。是我在这个项目里最大的问题
2.受权！受权！受权！若是本身没法亲力亲为投入项目管理工做，就受权给团队某个成员管理权限，让他代替你去作管理工做
3.管理一人，总比管理多我的轻松，也更有效

2.7 要控制需求，更要控制流程
项目是二次开发、成员对项目很熟悉、项目工做量不大、时间紧。

基于以上缘由，我掉以轻心，没有在项目初期进行项目的设计和规划，未指定任何开发规范。仅仅告诉开发的同事要多复用，也未检查他们是否真的复用了。

项目开发中的需求变动，客户反馈意见，我我都仅仅是告知他们一声，未作详细的修改规划，全部事情都靠嘴说，全部变更都放在了我和他们的脑子里。

对项目上心程度不够，未对客户的需求变动作控制和管理。全部变动都压押给了开发的同事。

整个项目以及其不规范的方式在运行，我也未在其中起到控制做用，项目开发一团乱麻。

2.8 反思：
1.不作设计，不进开发
2.以管理工具指导开发进行，开发过程当中全部变动、反馈作记录
3.控制需求变动，拒毫不合理的需求
4.需求变动规范化操做，统一变动，而不是直接压给开发

2.9 不管什么状况下，都要进行code review
整个项目过去了几乎四个月，我仅仅花了两个多小时简单看了下代码，未指出代码的任何问题。这也致使出问题后来我花了成倍的时间来处理code review的工做，而且项目成型后的代码修改困难。

项目开发过程当中，也未让开发间互相进行代码review，也没有进行代码评审会。

其实代码中出现了不少问题，最后检查代码的时候，发现各类命名不规范、代码复用不到位、简单逻辑复杂写等等。而这些问题，很大一部分都是早期未作规定，未指定人负责项目、未进行早期code review形成的。开发各自为战，不免形成代码问题。

代码质量的问题，淋漓尽致的体现的在项目中，项目中的诸多bug，都是由于代码不规范引发的。甚至于开发人员本身对本身写过的东西，都有些拎不清了。

2.10 反思：
1.代码质量很是重要，代码越规范bug越少
2.代码互评能让开发更注重本身代码的质量
3.code review很是有必要，越早期的code review越能有效的节省后期的时间

**我在其中占有多重的因素

100%

我怎么填坑的**

项目上线，问题频出，用户不满。花了8天时间来处理这个问题。幸好项目不大，我一我的也可以挽回。

目前暂时解决完毕，我简单说一下我是怎么填坑的：
1.和开发主流程的同事详细熟悉了全部需求要点
2.基于我对项目需求的熟悉，我花了三天把全部主流程的全部代码分析完毕，作出了我认为应该的修改，并实施部署到生产环境测试（这是在给开着的飞机换引擎，但须要U盾才能测试，仅有生产环境的机器有U盾，别无他法）
3.天天花超过12个小时来进行code review 和修改，几乎天天code review + 修改到凌晨2点多（仅修改了问题较大且影响较小的地方。小问题未修改、牵涉面较广的地方未修改）
4.每次上班时间的修改让开发同事坐在旁边和我一块儿进行，我进行修改，开发同事在一旁监督。确保我不出错
5.优化功能点，把我发现的提示问题，和优化点都同步修改进代码中，确保用户体验不要太糟，以期能挽回一些用户心态

我所吸收的教训总结

1.先设计，后开发
2.管理权下放，项目中必须有人全身心负责
3.不管什么状况都要进行code review
4.压缩质量获得的进度保证不可取，开发周期不合理决不答应客户。不然坑了本身坑了同事，更坑了客户

以上案例做者：r0black 原文 http://www.javashuo.com/article/p-vxjarvyv-x.html

**山猫案例分析**

上面这个真实的项目案例，咱们能够看到该项目经理梳理总结的仍是比较细致，我暂且以一个旁观者角度再提炼下从这个项目中发现的最大的三个问题：

1）需求变动频繁

“因为系统须要对接国家系统，需求方对需求也不甚了解。曾在5月份一个月内需求变动超过8次，都是主流程变动。”

看到没，若是遇到这么频繁且影响到核心流程的变动，在正常项目管理过程当中是不该该出现的。那么遇到客户对需求不懂的状况，做为项目负责人应该如何作？

首先能够找公司懂这块业务或者熟悉此类系统业务流程的人去把关，来引导客户对需求的理解，确保你们对需求理解一致，且确保需求可以解决到当前系统须要解决的问题。这个很是重要，不然若是咱们自身对需求把握不到重点，那么被客户牵着鼻子作需求变动就会很频繁了。

而后是要有变动控制审核的，尽管说这是一个不大的项目，可是发生主流程变动，是应该要求客户出具书面变动申请的，若是项目有监理，则须要拉上监理一块儿盖章签字确认。

爱情不是你想买想买就能买，需求也不是你想变就能变的

2）身兼数职，把本身累成狗，也无法很好兼顾

“我当时同时负责大大小小4个项目。。2.基于我对项目需求的熟悉，我花了三天把全部主流程的全部代码分析完毕，作出了我认为应该的修改，并实施部署到生产环境测试（这是在给开着的飞机换引擎，但须要U盾才能测试，仅有生产环境的机器有U盾，别无他法）

3.天天花超过12个小时来进行code review 和修改，几乎天天code review + 修改到凌晨2点多（仅修改了问题较大且影响较小的地方。小问题未修改、牵涉面较广的地方未修改）”

这让我想起了本身以前在某个公司，有的时候真的是这样，能力越强，公司给你的任务就愈来愈多，我最高纪录也是同时负责5个项目，还要身兼大部分的需求工做，好在这几个项目有部分关键节点是错开的，并且相比这个哥们我也不用参与具体的技术研发这块。

有的时候要适当学会拒绝，对于项目负责人若是参与项目过程落地环节中的各类细节，会形成一叶障目，看不到项目全局的重点，并且会致使在关键节点上失控。

而一旦失控，项目的问题就会愈来愈多，长时间把本身身体搞到极度疲惫也会让本身很难长期继续下去。项目经理应该专一于项目总体态势的把控，发现问题及时采起纠偏措施。

3）信任和检查

当你同时负责多个项目时，意味着你必须作出选择，你首先要干的是和项目管理相关的重要事情，其余事情须要尽可能信任安排其余的人协助你来处理，哪怕这我的干某件事没你干得好，你也得接受这种现实状况。

试想一下，若是你不给他人机会去犯错成长，靠你一人累死累活能干出多大的事情？即使人力资源再紧张，你也要适当学会放手，信任他人，什么代码Review，修改代码让兄弟们本身干，你作好相应的指导和结果检查便可。

最后，这个案例是否有让你有似曾相识的感受？从案例分析中，你有收获到了什么吗？欢迎留言分享。