目录

原文作者：zer0black 来源：https://www.cnblogs.com/zer0Black/p/9463206.html

引导格式的文字为编者注，比如本句就是编者注，非作者编写。

文字通俗直白，很多管理者都会碰到，特别是第一次。错误的经验可贵。

前言

我是一名项目经理，在过去的四个月里，我把一个项目带崩了（上线后频出问题，用户无法使用）。

在最近的几天，我每天都在反思自己，我都在问自己以下几个问题：

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

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

项目和团队背景

首先给大家说明一下项目背景，以便各位对此项目有更清晰的了解：

  • 1.该项目是一个二次开发项目，第一个基础版本（打印申报系统）也由我带领开发。

  • 2.系统是需要和国家系统对接，有三条主流程。

  • 3.需求频繁变化，由于系统需要对接国家系统，需求方对需求也不甚了解。曾在5月份一个月内需求变更超过8次，都是主流程变更。

  • 4.项目大小按照最初需求估算，约在100人天左右。

  • 5.项目两条主流程无法测试，依赖于外部U盾，但开发过程中并没有U盾。

  • 6.客户现场使用U盾调试和开发时间约为20天左右。

  • 7.我当时同时负责大大小小4个项目，没有进入开发，仅管控进度。

  • 8.团队成员共3名，其中两名是当时开发基础版本的项目成员，他们对此项目较为熟悉。

  • 9.项目推进过程中，需要多次去现场调试测试，由团队中的两名工程师共同前去。

我做错了什么

除了监控进度，还要管理质量。

在项目的开发初期，我制定了一份详细的开发计划，用于指导整个开发过程。

开发计划交付与了客户，而答应了的事情就要做到，所以在整个项目过程中，我对进度管控很严。我定期检查功能是否完成，定期和客户汇报情况，保证了开发进度顺利推进。但也由此埋下了祸根，仅仅看需求是否完成，而未关注完成的质量如何。

项目质量出现了许多细节性问题。比如：

  • 1.上线后，客户那边发现其中一条主流程都走不下去
  • 2.其中申报功能，系统提示成功。但实际上并没有真的申报-成功，申报后在国家系统无法查询到
  • 3.打印功能小问题较多，打印获取的数据错误
  • 4.同步数据的功能无法同步或者同步的数据错误
  • 5.执行时间过长的功能，数据库会强制断开连接

等等问题，就不一一列举

流程走不通，应该不是细节性问题，功能完整性问题，测试最基本要求功能完整，数据闭环。

质量/性能是大部分中国公司不会很关心的事，特别是商务销售主导的互联网产品公司。但在个人倾向于质量保证。

反思1

  • 1.进度和开发速度固然重要，但以质量换速度不可取
  • 2.如果开发时间和质量冲突，优先保质量，毕竟你埋下的坑，总是要坑你自己的
  • 3.再困难的情况下，也要保证基本测试
  • 4.时间极其不允许的情况下，也要保证主线功能顺利执行

既要给予信任，也要保持警惕

项目中的三名成员，都是合格的开发，对使用的框架非常熟悉。其中两名还是基础版本开发成员，对需求也很熟悉。所以项目中，我放心的把整个项目交给了他们。基于对他们的放心，加上其他项目事情繁杂，对此项目关注度，对他们的关注度就不够了。

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

未谈及沟通。从上面可以感觉到项目成员一定程度上沉默，上下级未及时进行“会联商”（受吉田幸弘的启发，个人发明一个缩略词：知会、联系、商量，简称会联商）。沟通可以及时发现问题，促进解决问题。

反思2

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

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

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

负责：对事不对人，比如项目负责人可以协助完成成员负责的任务，这个任务上成员是负责人，项目负责人是配合者。而对于项目整个迭代或版本，项目负责人才是负责人。负责人经得起多大的压力，接受得起多大夸赞和成长。

负责人主动推进事项前进，协调沟通有利事项前进。

反思3

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

有权无责，有责无权，积极消磨

要控制需求，更要控制流程

项目是二次开发、成员对项目很熟悉、项目工作量不大、时间紧。

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

规范没有，规范不具体，下属目标不明确

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

对项目上心程度不够，未对客户的需求变更做控制和管理。所有变更都压给了开发的同事。

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

协调加压与减压，促进产品进度同时，也要维护团队利益

反思4

  • 1.不做设计，不进开发

    辩证法说相对，没有绝对，一切从实际出发。

  • 2.以管理工具指导开发进行，开发过程中所有变更、反馈做记录

  • 3.控制需求变更，拒绝不合理的需求

  • 4.需求变更规范化操作，统一变更，而不是直接压给开发

    产品设计变更属于上游设计失误，不应该转嫁给下游开发，或者应该对失误者惩罚，对促进者激励，赏罚分明。

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

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

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

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

code review 是件成本很高的事情，涉及到前期团队规范及培训，统一思想，专人及时codereview，及时反馈并及时调整，避免以为技术问题导致返工。对这个专人还有比较的高要求，具备资深开发经验、较强表达与沟通能力、眼光长远不局限、相关产品及周边大局观等

反思5

  • 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.压缩质量得到的进度保证不可取，开发周期不合理决不答应客户。否则坑了自己坑了同事，更坑了客户。

本文收藏来自互联网，用于学习研究，著作权归原作者所有

markdown @tsingchan

部分引用格式为收藏注解，比如本句就是注解，非作者原文。