记一次失败的项目经历

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

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

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

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

项目中存在的一些问题

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

后续该如何改进

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

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

记一次失败的项目经历相关推荐

HID Relay, 有线键盘转蓝牙项目学习：记一次失败的尝试
HID Relay, 有线键盘转蓝牙项目学习:记一次失败的尝试开始学习嵌入式后,最难受的一个点在于电脑端口不够.我的电脑有两个USB口一个TypeC口,鼠标和键盘都要插USB口,stm32和51也都 ...
记一次jenkins 构建go项目经历
记一次jenkins 构建 go项目经历.为什么要用jenkins 去构建go项目,方便正式.测试等环境发布.简化发布流程. 1.首先安装jenkins jenkins官方文档, 我使用的是docke ...
如果当时这20道题能答好，现在应该已经被录取了（记一次面试的亲身经历 2020-8-27）
前情提要又一次的面试经历,下班去面试的,热情的HR,一家外企大公司,从未接触的规模与环境,满怀期待,面试的是三个中年男子,问了很多问题,真的很多,方方面面,感觉答的不是很尽善尽美,有些东西还是说不清 ...
如果当时这15道题能答好，现在应该已经被录取了（记一次面试的亲身经历 2020-7-23）
一.前情提要今天请假面试,上午两家,下午三家(暂定两点钟A.三点半B.四点C),全军出击的赶脚,有一家公司感觉还可以,来这家面试还真是一波三折: ① 一个不认识的猎头推荐的C(今天上午11点给我打的 ...
oracle中sp怎么写_校招简历中的实习和项目经历该怎么写？
在2017年和2018年,我针对校招生的简历分别写了两篇文章,一篇是<秋招中的互联网产品.运营岗,该如何准备?>,里面有一部分内容是关于简历的准备:另一篇是<如何用产品思维解决简历问 ...
看到这个机器学习项目经历，面试官跟我聊嗨了
"语言智能是人工智能皇冠上的明珠,如果语言智能能实现突破,跟它同属认知智能的知识和推理就会得到长足的发展,就能推动整个人工智能体系,有更多的场景可以落地." -微软亚洲研究院副院长 ...
Impala-shell卡顿分析——记一次曲折的Debug经历
Impala-shell卡顿分析--记一次曲折的Debug经历问题发现最近准备在Impala中增加对UTF-8的支持,以修正跟Hive.Spark等基于Java的系统在UTF-8字符串上的不兼容表 ...
盘点雷军、强东这些大佬们最失败的项目
在大学时,雷军读了一本讲述盖茨.乔布斯早年创业传奇的书<硅谷之火>,对他有极大触动--"我深深地被乔布斯的故事所吸引.在武汉电子一条街打拼一段时间后,自我感觉良好,就开始做梦:梦 ...
科学岛计算机考研经验,我失败的考研经历请吸取我血的教训
我失败的考研经历请吸取我血的教训题记: 没有经历教训的人生是有缺憾的人生,没有经历失败的成功是不完美的成功.教训和失败是人生历练不可缺少的财富. 因此,我们在学习时,不能只看到别人的成功,只学习别 ...
项目背景怎么描述_课程游戏背景下幼儿户外活动的组织和实施 ——记岱山县课程项目实施组活动...
课程游戏背景下幼儿户外活动的组织与实施 --记岱山县课程项目实施组活动为了深入推进园本化课程实施的实践与研究,加强项目组幼儿园课程的建设与实施,提升项目组幼儿园课程质量.11月23日,县课程项目实 ...

记一次失败的项目经历

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

项目中存在的一些问题

后续该如何改进

记一次失败的项目经历相关推荐

最新文章

热门文章