本文转载自iOS开发（ID：DS3589）
我是一名技术总监，在过去的将近一个月的时间里，我把一个项目带崩了（上线后频出问题，客户无法使用）。
在最近的几天，我每天都在反思自己，并且在不停的问自己：
我做错了什么？
我在其中占有多重的因素？
复盘，以后如何避免这些坑？
一、先说下我们的项目和团队背景
首先给大家说明一下项目背景，以便各位对此项目有更清晰的了解：
1.该项目是一个二次开发项目，类似于商城系统，需要有分销功能。
2.系统是需要和公司内部产品客户数据接口进行对接。
3.需求频繁变化，由于系统需要对接公司内部系统，我们对公司的内部产品系统也不甚了解，导致在一个月内需求变更超过3次，都是主要程序流程变更。
4.项目大小按照最初需求估算，约在8人左右（4人开发，3人设计，一人产品）。
5.项目两条主流程，一个是前端开发，一个是后台开发，但是我的注意力过于集中前端看到的。
6.总共开发周期为20天左右。
7.我当时同时负责公司大大小小4个项目，没有及时进入开发，仅管控进度。
8.团队成员共8名，其中两名是做过类似开发的项目成员，他们对此项目较为熟悉。
9.项目推进过程中，需要多次调试测试，但主要由项目中两名工程师完成。
二、我做错了什么？
1.除了监控进度，还要管理质量。
在项目的开发初期，我制定了一份详细的开发计划，用于指导整个开发过程。开发计划交付与了公司领导，而答应了的事情就要做到，所以在整个项目过程中，我对进度管控很严。我定期检查功能是否完成，定期和领导汇报情况，保证了开发进度顺利推进。但也由此埋下了祸根，仅仅看需求是否完成，而未关注完成的质量如何。
项目质量出现了许多细节性问题。比如：
1.上线后，用户那边发现其中一条主要流程都走不下去
2.其中分销功能，系统提示成功。但实际上并没有真的数据结算成功，后在系统无法查询到。
3.打印功能小问题较多，打印获取的数据错误。
4.同步数据的功能无法同步或者同步的数据错误。
5.执行时间过长的功能，数据库会强制断开连接。
等等问题，就不一一列举
反思：
1.开发的进度和开发速度固然重要，但以质量换速度不可取，最终速度和质量都没有提高。
2.如果开发时间和质量冲突，优先保质量，毕竟你埋下的坑，总是要坑你自己的，最后还得你自己去填。
3.再困难的情况下，也要保证基本测试。
4.时间极其不允许的情况下，也要保证主线功能顺利执行，很重要。
2.既要给予信任，也要保持警惕
项目中的四名后端成员，都是合格的开发，对使用的框架非常熟悉。其中两名还是对此系统非常有研究，对需求也很熟悉。在整个项目周期中，我放心的把整个项目交给了他们。基于对他们的放心，加上其他项目事情繁杂，对此项目关注度，对他们的关注度就不够了。
我在项目中给予了他们非常充分的信任，信任他们可以把一切事情都做好。但我没有在正确的时候给予他们正确的指引，项目中出现的困难点，我也没有帮助他们解决，甚至于没有给出思路。所有的一切，都靠他们自己完成。我在这个项目里做的，就是和领导沟通细节，催进度。再无第三件事。
反思：
1.不论什么原因，都要关注到项目成员的状态，看是否有开发过程中的异常。
2.给予信任没错，但也要适当保持警惕，他们多少会因为经验问题疏忽遗漏一些问题。
3.给予信任，也要给予帮助，不以时间为理由推脱你应该对他们进行的指点和帮助。毕竟现在省下来一分钟，以后要花一个小时或者更长时间去弥补。
4.若无法全局掌控，就指派专人负责，至少需要一个临时负责人和你进行对接。
3.手里捏着管理全局的权利，却没有做到管理的事情
由于种种原因，我无法掌握到项目的每个要点和细节。而项目中有好几个开发人员。我并没指明其中某一个来负责整个项目，所有事情都让他们自己商量。从领导对接来的问题，我也是仅告知对应的开发。整个项目中，没有一个人对项目中的每个要点了如指掌，当然我也没有进行充分的沟通。
反思：
1.手里捏着管理全局的权利，却没有做到管理的事情。是我在这个项目里最大的问题，这里面也有懒的心理因素。
2.授权！授权！授权！如果自己无法亲力亲为投入项目管理开发工作中，就授权给团队某个成员管理权限，让他代替你去做管理工作。
3.管理一人，总比管理多个人轻松，也更有效，因为你只需跟他沟通。
4.要控制需求，更要控制流程
因为项目是二次开发、成员对项目很熟悉、项目工作量不大、时间紧。
基于以上原因，我掉以轻心，没有在项目初期进行项目的设计和规划，未指定任何开发规范。仅仅告诉开发的同事要多复用，也未检查他们是否真的复用了。
项目开发中的需求变更，用户反馈意见，我我都仅仅是告知他们一声，未做详细的修改规划，所有事情都靠嘴说，所有变动都放在了我和他们的脑子里，仅仅是嘴说，很难形成标准，口说无凭。
对项目上心程度不够，未对领导的需求变更做控制和管理。所有变更都压给了开发的同事。
整个项目以及其不规范的方式在运行，我也未在其中起到控制中枢作用，项目开发一团乱麻。
复盘：
1.不做设计（需求），不进开发。
2.以管理工具指导开发进行，开发过程中所有变更、反馈做记录。
3.控制需求变更，拒绝不合理的需求。
4.需求变更规范化操作，统一变更，而不是直接压给开发。
无论什么情况下，都要进行code review（轻量级代码评审）。
整个项目过去了几乎四个月，我仅仅花了一个多小时简单看了下代码，导致未指出代码的任何问题。这也导致出问题后来我花了成倍的时间来处理code review的工作，并且项目成型后的代码修改困难。项目开发过程中，也未让开发间互相进行代码review，也没有进行代码评审，和项目组及时沟通。
其实代码中出现了很多问题，最后检查代码的时候，发现各种命名不规范、代码复用不到位、简单逻辑复杂写等等。而这些问题，很大一部分都是早期未做规定，未指定人负责项目、未进行早期code review造成的。开发各自为战，难免造成代码问题。
代码质量的问题，淋漓尽致的体现的在项目中，项目中的诸多bug，都是因为代码不规范引起的。甚至于开发人员自己对自己写过的东西，都有些拎不清了，最终结果就是推倒重写。
反思：
1.代码质量非常重要，代码越规范bug越少。
2.代码互评能让开发更注重自己代码的质量。
3.code review非常有必要，越早期的code review越能有效的节省后期的时间。
我在其中占有多重的因素——100%
三、我怎么填坑的
项目上线，问题频出，领导不满。花了8天时间来处理这个问题。幸亏项目不大，我一个人也能够挽回。
我简单说一下我是怎么填坑的：
1.和开发主要流程的同事详细熟悉了所有需求要点，越详细越好。
2.基于我对项目需求的熟悉，我花了三天把所有主要流程的所有代码分析完毕，做出了我认为应该的修改（写好注释），并实施部署到生产环境测试。
3.每天花超过一半的工作时间来进行code review 和修改，几乎每天code review + 修改到23点多（时间紧，仅修改了问题较大且影响较小的地方。小问题未修改、牵涉面较广的地方未修改）。
4.每次上班时间的修改让开发同事坐在旁边和我一起进行，我进行修改，开发同事在一旁监督。确保我不出错。
5.优化功能点，把我发现的提示问题，和优化点都同步修改进代码中，确保用户体验不要太糟，以期能挽回一些用户心态。
6.代码已经要及时进行备注（注释），很重要，一定要规范，方便下次你再次开放使用，最好形成文档形式。
四、我所吸取的教训总结
1.先设计（需求），后开发。
2.管理权下放，项目中必须有人带头负责。
3.无论什么情况都要进行code review。
4.压缩代码质量得到的项目进度保证不可取，开发周期一定要和客户沟通清楚。否则坑了自己坑了同事，更坑了客户。
每个技术人在走向管理的道路上都会遭遇不同的困难与问题，想要建立自己的管理方法论，除了从实践中经历、总结以外，还需要聆听更多同行及导师经过时间验证的经验，CTO训练营，20余位CTO导师精益分享，构筑技术管理的体系化思维及底层方法论，工具+案例+实操演练的方式保证落地实用，第七季正在报名中，欢迎加入。
招生要求：
CTO训练营第七季，共招生40个名额，采用【申请审核】报名机制，以下条件二选一满足的，可扫码申请：
A类-曾任或现任公司知名企业技术管理者
B类-创业公司核心创始人、技术高管
学习时间：
2019年10月-2020年5月，每月一个模块，每次2天，共14天
课程费用：32000元/人
学习地点：北京
报名咨询：张瑞 18401576051（同微信）
