最近项目组进入了一个十分忙和乱的阶段，经常加班，生产问题频发，需求难以确认，人力紧缺。

本来，12月份，这个项目的一期就顺利结束了，在二期启动之前的这段时间，顺理成章的应该进入平稳的维护期，可事与愿违，这段时间反而成为了这个项目目前为止最不可控的高风险时期。

即使不是项目管理者，但我仍然忍不住想要对它做个阶段性的回顾与总结，一是分析面临问题的原因，二是总结经验。也算是对自己时间和精力付出的基本负责。

这个项目(内部名称 IT综合管理平台系统)是17年底正式启动的，到18年底交付一期，花了一年多时间，项目一开始是采用瀑布模式开发，中途换为敏捷模式，可能由于项目本身的需求收集与设计等方面的客观问题，造成该项目需求变动较多，节奏一直比较紧，同时由于系统的整体功能设计在一开始并不明确与项目组开发人员在技术层面缺少整体设计能力与编码规范，造成该项目的可维护性不高，常常面临改一处需求牵连多处功能的问题，简单说就是程序员在拿到一个需求优化过变动不得不反复推敲评估可能构成的影响和实际大量的代码量，直接体现就是工作量提升和风险难以把控。

同时，该项目开发人员构成复杂，参与方包括多个合作公司和团队，在完成一期后，主要开发团队人员撤离，留下我及少量原开发人员(一共三个)，除此之外的其他人员包括需求、开发、测试全部撤离。

在这样的情况下，若在维护期只做简单的维护性工作，凭着我与另外两名开发，我自认为是有信心胜任可能面临的问题，但现实永远很难按照理想的计划进行。

首先，在这段维护期内，该项目首次公开向客户群体大规模推广，也就是说才暴露出很多之前从未发现的质量问题(bug)，而且现在还只是开始，随着使用的推广，肯定还会发现更多的问题。但由于大部分开发人员都已离场，这些存在bug的功能大多都不是我们三个开发人员写的(现在发现的bug几乎都不是)，并且一期结束时交接文档并不详尽，所以就给现在的项目维护工作增添了很大难度。

然后，在本就维护难度很大的情况下，项目组却面临了不少客户新提的需求或变更与优化，一方面要解决遗留问题，一方面又不得不接新的需求。

其实，但现在为止，以我对这个项目的了解与掌握，一面解决层出不穷的遗留问题，一面应付新的需求，我们三位主力开发还是基本能胜任的。

可要命的是，我们缺少一个PO，也就是产品经理这个角色，造成的问题是，我们不得不直接与用户沟通确认需求，先不说我们作为开发人员去确认需求专不专业，但至少给我们增加了大量工作量。

更大的挑战可不止与于此，我们竟然还没有测试人员！也就是说出了确实需求和开发，我们还要自己做测试(如果是程序员都懂，自己能完全找出自己的bug还要测试做什么)，加上上文已经提到过的，这个项目本身可维护性就不好，经常是”牵一发而动全身”，所以测试特别是回归测试是很重要的，这在又给开发增加工作量的同时，更大的问题在于风险的陡增。

备注:项目组当然有在一期结束时申请测试资源，但测试人员加入也是需要时间的，而且加入后对于这样一个做了一年多的项目他们也是需要不少时间才能熟练起来的。

以上，从项目本身的条件到现阶段的运维期所遇到的各种困难，不难看出实际我们每天的工作一定面临了不少挑战和压力。

连项目经理都用了一个“乱”字来形容现在的状态，可见其情况确实不容乐观。

但作为一个团队的主力开发，不仅要能看清楚现况，更要能从中得出经验。

1.这样需求是自下而上收集而不是整体设计的项目是否应该采用“微服务”的技术架构？

2.这一年来，上线过很多次为什么一直未发现问题？如果推广使用有困难，注定会在一期结束时暴露大量问题，是否计划让同一个开发团队至少开发交付两期后再更换团队更好？

3.即便以上两点都无法改变，但发现问题及时，在一期结束时，提早让新的团队人员进场熟悉相关工作也是基本的风险应对手段。

最后，写这篇文章当然不只是为了总结经验教训，作为团队一员，在这样的情况，当然更应该努力寻求解决问题的方案，指导行动，解决问题。

最重要一点就是心态，我突然想起马云说过的那句“不抱怨”，工作几年下来，我越来越感受到马云这句话的分量，实际工作往往就是这样，很少有完全按部就班的，我们处在一个岗位上，就是要去解决问题的，一旦有了这样的观念认识，其实很多困难也不再像我们想象的那样难以应对了。