记一次失败的项目经历

最近因为疫情原因一直在家，已经有快半年没有更新博客了，最近返回公司上班之后，去年做的项目已经完结，虽然已成功交付用户使用，但是在我看来这仍然是失败项目，在这里我想回顾这些经历，算是给后面的自己一个警醒吧

为何说这是一个失败的项目

我一直认为这是一个失败的项目，原因有如下几点：

1. 项目为能如期交付，原定计划是在2月份交付并发行1.0稳定版，但是由于种种原因推迟到了6月1号，延期了快半年
2. 项目到后期难以维护，在后期代码复杂度上升了不止一个层次，给维护与扩展带来了不小的麻烦
3. 项目质量无法达到预期效果，在发布之时仍有部分隐藏bug，没有经过细致的测试，为了按时交付，很多测试工作都省略了，目前只进行了两轮测试。
4. 功能有些无法达到预期效果，当初为了赶进度很多不重要的功能也是能省则省，有些需求并没有很好的实现

项目中存在的一些问题

1. 前期需求设计不合理：早期立项的时候，我参考了许多类似的产品、与相关同事进行过探讨，但是由于经验不足，没有相关产品的开发与使用经验，导致许多需求设计不太合理，后续变更需求频繁，甚至出现过回炉重造的情况，这个主要责任在我这边，当时很多需求是我自己一拍脑门想起来觉得这样做可能符合客户需要，但是没有跟其他人进行商量，导致在后续实施时要么是在此基础上无法实施，或者成为鸡肋功能影响后续工作。
2. 后续需求变更频繁：后续需求变更频繁，很多时候老板看过项目之后觉得哪块不好会直接提出来，比如某些功能不合理，某些地方配色，页面布局不合理之类的。测试人员会在测试实际使用中告知他们想要某个功能，以便更方便的使用与测试。但是这些变更往往是在后期开发已经完成，正式进入测试流程中时提出，给后续开发与维护造成很多不必要的麻烦。这种情况的主要问题在于老板与测试人员在早期需求制定时参与过少，以及我本身对这方面不够专业。导致出现后期疯狂修改需求的情况
3. 需求记录不及时：在前期需求设计时我会详细记录需求的相关内容与演示效果，但是后续开发任务紧张，需求变更频繁，无法有充足的时间进行需求变更的记录，很多时候都是老板或者测试人员口述，然后由开发人员进行修改，没有合理的需求评审，没有详细的记录，有时候时间一长自己都给忘了当初是如何制定的。后续无法复盘
4. 架构设计问题：还是由于自己当初经验不足，当时考虑到用户可能需要二次开发，所以规定当时所有的功能都采用restful-API的形式，并且前端采用纯粹的ajax请求直接调用后台接口，但是有些功能确实不太适合做成接口，而且对于前端大家都不了解的情况下没有使用常用的前端界面框架，而纯粹采用自己编写的方式造成大量的时间浪费与遗留无法解决的bug。这些都给项目造成了不小的麻烦；
5. 没有详细设计：当初项目留给前期设计的时间并不充足，按照一般软件功能的流程来说，重要的时间应该留给前期设计，编码与测试只占极少数部分，而在这个项目进行过程中，完全颠倒过来了，不到一个月完成前期的需求与详细设计以及开发测试的分工，和接近3个月的开发与测试。导致的结果就是代码臃肿，很多公共功能没有抽象为具体的函数，重复代码过多，代码结构混乱无法进行后续维护。也就是说我们项目一开始就早就出了一个屎山。
6. 分工不合理：在前期设计与开发环境框架制定完成之后，进入到分工环节，在这个环节中出现分工不够合理的问题。主要体现在我自己不清楚员工的能力与擅长的部分，在制定计划时采用平均分配的方式没有考虑需求难度与员工自身的能力相结合。导致后续能力强的员工快速完成任务而存在空闲时间，而能力一般的往往会拖慢进度，或者对于困难需求实现的也是差强人意。或者出现能力强的员工去帮助能力一般的员工完成剩余需求，出现能者多劳但是无法多得的情况。
7. 测试与验收问题：在早期设计阶段并没有完整的测试计划，测试一直推迟到开发完成之后，在那个时候发现想要详细测试时间不够、测试出来的bug由于设计等原因难以修改、甚至出现某些地方使用不太合理又要新加需求的情况，这些都导致无限期的加班与代码修改，代码越改越乱，人心烦躁，开发与测试怨声载道。

后续该如何改进

1. 培养自己的产品思维：早期需求制定的不合理，我自身有很大的原因，我由于本职工作是做开发的，很多时候在设计需求时采用的是开发者的思维方式，而没有站在用户角度，设计出来的系统在后续测试中会发现很难用，没有合理的引导，功能过于分散，常用功能操作不够简单，操作步骤过多等情况时有发生，为了用户必须得改需求。我想自己得加强这方面的素养，设计完成之后少改需求
2. 制定规范的需求管理制度：在需求制定、变更、实现、验收这些过程，在项目中没有与很好的得到解决和管理，造成很多需求后续无法查证，不合理的需求无法定位到具体的责任人，甚至谁都可以提需求。为了解决需求相关的问题，需要引入规范的需求管理制度，加入需求评审等操作，让需求更合理，更有迹可循。
3. 延长早期设计时间：在大学中学习软件工程相关课程时，我的老师告诉我，在项目开发中，编码只占很少一部分，而现在似乎反过来了，编码占据了时间的大头，而前期设计只是为了给开发人员安排工作而已。我想一个成功的项目应该是会在前期设计过程中下了很大的功夫的。可以在前期多进行相关会议，比如需求评审、针对需求进行测试用例的评审、开发框架与相关方案的评审、以及工作计划的合理安排等等。
4. 规范开发中的代码审查机制：员工的能力，与代码编写风格对项目的可维护性有巨大的影响，过去我一直觉得开发人员应该保留自己的个性，编写能体现能力的牛X的代码，但是经过几次与他人合作、带领团队开发项目之后，我改变了这个看法，作为底层的码农，为了项目的统一于可维护性，最好还是安心做一颗螺丝钉，多人合作不需要个性，一切为了项目才是正道。所以在后续如果还有项目需要我带队开发，我会统一编码格式与注释格式，像大厂那样制定编码规范，甚至细微到如何给变量、函数、类命名等等。最好每天下班前一次 code review，及时消除冗余代码、不规范的代码、不合理的功能，特别是同一个功能，多个人编写函数，函数的参数列表与实现完全不同的情况。
5. 测试与开发并行的机制：之前测试永远是等到所有开发任务完成之后进行，一旦项目完结，进入维护节点，要修改bug是相当困难，而且是牵一发而动全身的，测试应该与开发并行，在需求评审时应该做到给出需求验收标准与对应的测试用例，而且需要配合代码审查，提醒开发人员针对每一个功能函数编写单元测试。需求完成之后立即对照测试用例进行测试，保证每个需求都准确无误。
6. 更加合理的工作安排：合理安排工作，需要做到针对员工的能力和需求评审时得出的需求的难度来合理安排，合理安排包括合理的时间、合理的人员与合理的需求安排等等。这个可能没有相应的参考标准，只能根据经验来判断了。
7. 自己应该更加投入到这个项目中：由于我在公司待的时间较长，对公司业务比较熟悉，所以很多时候总有人会来问问题、商量某些事，我一贯又是一个老好人的态度，甚至有时候做到事无巨细都亲自动手。甚至公司主要产品也需要我来进行维护，而且由于项目人手不够，我也参与到项目的具体开发与测试工作之中，导致长时间都消耗在无意义的事情之上，无法专注于项目管理工作上。在后面项目需要做需求变更、更改开发计划时无法及时记录与评审；看到不合理的代码没有时间做code review、提取公共部分，重构部分代码，这些工作都由于没有时间而暂时搁置了。在后面项目越发的超出我的掌控。

以上就是之前带队开发时出现的问题以及一些反思，如果后面还有机会作为项目的leader，我想尽量避免这些情况。更加专注于项目。制定相关制度，保证项目质量。