阶段性技术复盘总结回顾

阶段性技术复盘总结回顾作为企业数字化落地项目的后端技术负责人，我刚刚带领团队完成了某制造企业生产管理系统第一期的交付，进入了两个月的试运行平稳阶段。这个节点刚好适合停下来，把大半年来从立项、选型、开发到上线全流程的经历梳理一遍——不同于公司要求的走流程式汇报，这次复盘是我主动拉着整个团队坐下来掏心窝子整理的，目的就是把踩过的坑、做对的选择都捋清楚，给接下来第二期项目铺路，也给后续同类项目做参考。接下来我就按照梳理的逻辑，完整呈现这次复盘的全部内容。1本次复盘的背景与核心目标本次复盘不是无的放矢，是针对特定阶段、明确目标展开的，先把基础范围说清楚。1.1复盘对应的阶段范围我们复盘的内容，覆盖了从项目立项启动，到第一期核心功能开发完成、上线试运行满两个月的全阶段，前后跨度大半年，团队先后投入了4名开发、1名测试、1名实施，完成了甲方要求的生产报工、设备管理、基础库存同步三大核心模块的交付，达到了合同约定的第一阶段交付标准，目前试运行状态稳定，甲方没有提出重大异议，刚好进入了开发节奏放缓的调整期，有充足的时间沉下心做总结。1.2本次复盘的核心目标我一直跟团队说，干技术这行，不能闷头往前走，走一段就要停下来看看，不然踩了坑下次还会摔同一个跟头。我们这次复盘的核心目标有三个：第一是把这一阶段做对的决策、走通的路径整理出来，形成可复用的经验，以后再接类似的中小型制造企业数字化项目，可以直接拿过来用，节省从零开始摸索的时间；第二是把开发上线过程中遇到的所有问题，不管是技术上的还是协作上的，都挖透找到根因，不能停留在“赶进度所以没做好”这种表面借口，要找到问题的本质；第三是明确团队和个人接下来的能力提升方向，把复盘的结果落地，真真正正解决问题，而不是开完会就把总结扔到文件夹里吃灰。讲清楚复盘的基础前提之后，接下来我们先梳理这一阶段我们完成的核心工作，以及实际拿到的成果，先把我们做对的部分拎出来，总结可复用的经验。2阶段核心工作成果与可复用经验整个阶段走下来，我们能顺利完成交付，其实不少决策和做法是走对了的，这些经验比问题更值得留下来。2.1技术选型的落地验证选型是项目启动后第一个核心决策，选对了后面少走很多弯路，这次我们的选型结果，经过落地验证是符合项目实际需求的。我们当时纠结了很久：甲方自己的IT团队只有三个人，技术能力不算强，后续需要他们自己做小需求的维护，所以不能选太冷门、太复杂的技术栈。一开始我想沿用之前做大型项目用的传统JavaEE架构，更稳定但是开发速度慢，后来团队里的年轻同事提出用轻量的SpringBoot+Vue的前后端分离架构，再搭一个成熟稳定的开源低代码基础框架快速搭架子，既能满足开发速度要求，架构又清晰易懂，新人容易上手。最后我们采纳了这个方案，现在验证下来这个选择完全正确：第一，开发速度比原定计划提前了一周完成核心功能开发，节省了项目时间成本；第二，甲方IT团队看完我们的代码架构和分层逻辑之后，明确说能看懂，后续他们自己加个表单、改个审批流程不用找我们，这点甲方特别满意，说我们解决了他们“买了系统没人改得了”的老问题。2.1.1基础设施选型的额外收获部署这块我们也做了对的选择：甲方不想额外采购新服务器，想复用现有两台闲置的旧服务器，我们就采用了容器化部署，把四个核心服务做了资源限制，压缩到两台服务器上还能留出足够的冗余资源，实际跑下来，核心服务的资源占用比我们一开始预估的少了三分之一，不光帮甲方省了几万块的硬件采购成本，运行稳定性也完全达标，核心服务的内存占用一直稳定在合理范围内，没出现过内存泄漏导致的宕机问题。2.2核心功能的迭代落地成果因为甲方一线生产人员一开始没法说清楚自己的具体需求，只知道原来手工记账太麻烦，容易错，我们就没有一开始就把所有需求定死，而是采用了小步迭代的方式，每两周出一个可实际使用的演示版本，拉着甲方一线班组长和工人现场试用提意见，慢慢调整。比如生产报工模块，一开始我们按照需求做的是班组长每天下班统一录入全天的产量，结果试用的时候工人就提意见，说他们是四班三倒，换班的时候就要报，不然转天交班了，谁也记不清哪个工序干了多少，出错了找不到责任人。我们听了之后马上调整，改成了按工位按班次报工，还加了扫码报工功能，工人到点换班，扫一下工位贴的二维码就能直接填产量，不用打开网页一层层找菜单，特别方便。现在试运行两个月，一线工人的日常使用率能到90%以上，比我们预期的高很多，不少原来抵触用新系统的老工人，现在都觉得比原来记账方便多了。我那段时间每周都跟着实施去工厂蹲半天，跟工人聊天，真的觉得技术不是坐在办公室想出来的，得去现场看人家怎么用，这点感受特别深。2.3上线问题的响应处理成果上线第一个月其实出了不少小问题，我们提前安排了轮值，每天有人盯着系统监控，承诺甲方小问题当天解决，大问题不超过24小时。最典型的就是高峰期库存查询慢的问题，每天上午上班后半小时，大家都要查原材料库存，系统卡得半天出不来结果，我们当天晚上就拉人排查，最后发现其实就是两个常用查询没加对索引，我们也没做常用数据的缓存，找到问题之后，加了索引又把一周内常用的库存数据放到Redis缓存里，改完之后查询速度快了四五倍，再也没人卡着抱怨了。到现在试运行两个多月，核心系统的可用性保持在99.8%以上，甲方信息部门对我们的响应速度特别满意，说比之前合作过的开发商靠谱太多。梳理完成绩和可复用的经验之后，复盘不能只报喜不报忧，真正有价值的其实是我们暴露出来的问题，接下来就仔细梳理这些问题，以及背后的根因。3阶段暴露的核心问题与根因分析整个过程走下来，我们其实踩了不少坑，这些坑有的是赶进度导致的，有的是经验不足导致的，我们把所有问题整理出来，分成了三个大类。3.1技术架构与开发层面的问题技术层面的问题最直接，影响开发和后续维护，我们总结下来主要两个问题。3.1.1技术文档更新跟不上开发迭代一开始赶进度，我们觉得文档是软需求，能省就省，前后端接口很多都是开发对着口头沟通，写完就完了，文档都是后来补的，补的时候还漏了很多细节。有一次测试改一个需求，前端开发找不到某个参数的定义，原来写接口的开发那阵子被调去改线上问题了，问半天都没回复，硬生生耽误了大半天的进度。还有现在甲方要对接第三方的生产设备，需要看接口文档，我们拿出来的文档缺了好多参数说明和错误码定义，现在不得不抽两个人逐个接口重新整理，多花了好几天的功夫，本来可以一开始就做好的活，最后花了好几倍的时间补。根因说穿了就是我们一开始重开发轻文档，觉得文档没用，其实文档不光是给别人看的，过几个月自己看自己写的代码，没有文档也记不清当时为什么这么设计，这个教训真的挺深刻的。3.1.2异常场景考虑不周全我们一开始测试都是在办公室满格网络的环境下测，所有流程都走通就完事了，没考虑工厂现场的实际环境。比如扫码报工，工厂车间角落的网络信号不好，有时候提交数据会失败，我们原来只做了失败提示，没做本地暂存，工人填了半分钟的产量，网络一断就全没了，人家当然生气，投诉了好多次，我们才赶紧加上了本地暂存功能，就算断网，数据也存在本地，有网了再重新提交，这个问题才解决。根因就是我们做技术设计的时候，脱离了实际使用场景，光想着走通正常流程，没考虑各种异常情况，说白了就是懒，不想多花心思考虑极端场景。3.2跨团队协作层面的问题这个项目是产品、开发、实施三个团队配合做的，协作流程上出了不少问题，也耽误了不少功夫。3.2.1需求变更管控不严格一开始我们怕得罪甲方，不管甲方提什么变更都接，说改就改，没有明确的变更流程。有一次本来已经开发完的设备报废流程，甲方生产经理说要加一个车间主任的审批层级，我们改完，信息经理又说原来的层级就够，公司要求简化审批，来回改了三次，浪费了两个开发两天的工作量，本来能提前完成的活，硬生生拖了两天。根因就是我们一开始没把规则说清楚，小变更可以随时提，大变更必须走书面确认，还要调整项目排期，我们想着和气生财，不敢立规矩，最后反而把自己搞的特别被动，其实好好跟甲方说，按流程走对双方都好，避免改来改去影响质量，甲方也能理解。3.2.2信息同步不及时实施人员天天泡在甲方现场，谈好的变更有时候忙着赶下一个场，就只在群里发一句，没人整理成正式的需求文档，开发有时候没看群消息，或者看了转头就忘了，还是按原来的需求做，做完了才发现不对，又返工。这种情况前前后后出现了四次，每次都耽误至少大半天的时间，挺闹心的。根因就是我们没有固定的信息同步机制，一开始都是松散沟通，群里的消息刷两天就找不到了，也没人专门整理记录，才导致信息不对称。3.3团队能力与个人认知层面的问题除了上面的问题，我们自己团队的能力和认知也有不足。3.3.1技术人员对业务理解深度不够我自己一开始就有误区，觉得技术人员就是写好代码就行，业务是产品和实施的事，我不需要懂太多。结果第一次做生产计划排程的雏形模块，我完全按照产品给的需求文档写，做完拿到现场用，人家生产主管一看就说不对，你这个排出来的计划没考虑设备每周固定维保的时间，排进去也没法生产。我那时候才傻眼，产品的需求文档里确实没写这个规则，我也没想着问问人家实际生产的流程，就闷头写，最后改了整整两天才改对。这件事给我教训特别大，技术人员不能只懂技术，得真的懂用户的业务，不然做出来的东西就是空中楼阁，看起来没问题，实际用不了。3.3.2新人带教没跟上节奏这次项目我们加了一个刚工作一年多的新人，想让他锻炼一下，一开始就给他分了报表开发的任务，没给他安排专门的带教，只是说有问题就问，结果老员工都忙着赶自己的进度，没人有空仔细给他讲我们的框架规则，他摸了一周还没摸清楚门道，导致报表模块延期了三天才出来，拖了整个项目的后腿。后来我们抽了两个晚上给他做专门的培训，他才跟上进度，这个就是我们一开始只想着赶进度，没考虑新人的适应周期，带教计划没做好，反而拖了进度，得不偿失。把所有问题和根因都梳理清楚之后，我们接下来就对应问题，整理了明确的改进方向和落地计划，确保复盘的结果能真正用到接下来的工作里。4下一阶段的改进方向与落地计划复盘的最终目的是改进，不是找问题追责，所以我们针对每个问题都定了可落地的改进方法。4.1技术层面补短板优化首先我们已经启动了技术文档补全工作，现在抽每周五下午的一个小时，每个开发负责整理自己模块的接口文档、架构说明，写完之后交叉审核，确保所有参数、错误码、设计逻辑都写清楚，以后不管是新开发接手还是甲方维护，都能拿着文档直接看懂。我们也定了规则，以后开发新接口，必须先写接口文档再联调，不许先开发后补文档，从一开始就把这件事做好。然后就是优化异常处理和性能，我们接下来会给所有核心接口都补上友好的异常提示，加上本地暂存、失败重传这些机制，针对工厂网络不稳定的情况做专门的优化；性能方面，我们打算每个月做一次核心模块的性能巡检，提前发现慢查询、内存泄漏这些问题，别等用户抱怨了才改，还会做分时段的资源调度，午休和下班之后自动降低非核心服务的资源占用，把资源留给核心的报工查询模块。4.2协作流程规范化调整我们已经把需求变更的流程明确下来，不管变更大还是小，都必须登记，小变更当天评估排期，大变更需要甲方签字确认，调整项目进度，我们会好好跟甲方解释规则，不是不配合改，是按流程走能避免改来改去出错，对双方都好。然后就是固定每日10分钟站会，每周五做一次全团队的需求同步，所有谈好的变更都整理成正式文档，存在共享文件夹里，所有人都可以随时查看，避免信息不对称。4.3团队能力提升落地接下来我们定了规则，技术团队每周抽一个小时，请产品或者实施给我们讲甲方的业务逻辑，每个月我们所有开发都去工厂现场蹲半天，跟着工人走一遍完整的生产流程，真的搞懂人家实际怎么干活，不能坐在办公室想当然。然后就是新人带教制度，以后新来的同事，都会指定一个老员工作为专门的带教老师，前两周不安排核心开发任务，先熟悉技术框架和业务，带教老师每天抽半小时答疑，带教效果也会算到老员工的绩效里，保证带教的质量。另外我们每周会做一次技术复盘分享，把这次踩过的坑，做成分享案例，整个团队都学习，避免下次再踩同样的坑。总结总的来说，这大半年的第一阶段项目，我们顺利完成了交付，拿到了甲方的认可，也踩了不少坑，积累了实实在在的经验