软件系统开发总结文档

软件系统开发总结文档本次总结针对刚刚完成交付的中小企业定制化客户关系管理（CRM）软件开发项目展开，整个项目从需求对接至正式上线，历时六个多月，由我们八人的开发团队全程跟进，最终按照约定时间、符合所有核心需求完成交付，目前系统已经稳定运行两个多月，客户反馈良好。写这份总结的目的，是梳理整个开发流程中的得失，沉淀可复用的经验，也为后续同类项目提供参考，避免重复踩坑。接下来我会从项目概况、执行复盘、问题总结、经验沉淀几个维度展开详细说明。1项目开发整体背景与核心目标1.1项目发起背景这次的客户是一家做本地商贸批发的中小民营企业，一共十五名员工，其中八名是一线销售人员。在找我们开发之前，他们的客户信息、销售跟进、业绩统计全都是靠销售个人微信备份、Excel表格零散存储，大大小小十几张表格存在不同人的电脑里，经常出现找不到旧客户信息、数据重复录入的情况。最让客户老板头疼的是，之前有销售离职，带走了手上大半的客户资源，新接手的销售根本理不清跟进进度，平白丢了好几个长期合作的老客户；每个月算业绩，财务要对着十几张表格核对整整一天，还经常出错。他们之前也看过市面上标准化的CRM产品，要么价格太高，一年服务费比他们整个部门的月薪还高，要么功能太复杂，一堆用不上的模块，销售人员学半天也不会用，所以才找我们做定制开发，想要一个贴合他们实际业务、简单好用成本又低的客户管理工具。一开始我们团队还觉得这就是个几千块的小活，没太放在心上，直到上门跟着他们待了一天，看到财务对着满屏幕的单元格揉眼睛，才意识到这个“小活”对他们来说就是解决大麻烦的刚需，也认认真真把这个项目放在了心上。1.2项目核心开发目标结合和客户反复沟通的结果，我们最终确定了三个层级的核心开发目标，所有开发工作都围绕这个目标展开：1.2.1基础功能目标核心要解决客户现有的痛点，实现客户信息统一存储管理、销售跟进记录实时更新、跟进任务自动提醒、业绩回款自动统计、权限分层管理五个核心功能，确保所有原来手工做的麻烦事都能通过系统完成，从根源上解决客户信息流失、统计效率低的问题。1.2.2用户体验目标因为客户的销售人员大多不是互联网从业者，对复杂软件接受度低，所以要求所有操作逻辑必须符合他们原来的工作习惯，页面简洁直白，新员工不用花超过一天时间培训就能上手，同时要支持手机端访问，方便销售在外跑客户的时候随时查看记录、更新信息。1.2.3成本控制目标客户预算有限，所以开发阶段尽量选用成熟的开源框架，降低开发成本，后期部署和维护也要简单，不需要专门配技术人员维护，服务器选普通的云服务器就能满足需求，把后续的使用成本降到最低。1.3项目团队与时间规划我们团队的分工是：1名产品经理负责需求对接和梳理，2名前端开发负责页面和交互，3名后端开发负责接口、功能开发和数据库设计，1名测试负责功能测试和兼容性测试，我作为后端开发的一员，同时兼项目协调工作。时间规划上我们一开始就留了10%左右的缓冲时间，整体排期是：需求调研梳理两周，架构设计与技术选型两周，编码开发十周，测试与问题修改三周，上线部署与培训一周，最终实际完成时间比计划只晚了两天，缓冲时间刚好够处理突发问题，这点现在回头看是做的非常对的。2项目开发各阶段执行情况复盘梳理完整体的目标和规划，接下来我按照开发的时间顺序，对每个阶段的执行情况做详细复盘，整理过程中做得好和不到位的地方。2.1需求调研与梳理阶段一开始我们踩了个不大不小的坑：最开始我们让客户把需求整理成文档发过来，客户只给了三行字，说“要管客户，要算工资，要提醒跟进”，根本没说清楚具体规则。后来产品经理带着我们一起上门，蹲在客户的销售部待了一整天，跟着他们开早会，看他们怎么录入信息、怎么和客户对接、怎么算业绩，才挖出来很多客户自己没说出来的隐性需求。比如他们算业绩是按照实际回款金额算，不是按照订单金额算，这点客户一开始根本没提，如果我们按照常规的订单算业绩做出来，肯定要全部返工。最后我们整理出来二十多个功能点，分了核心必做和后续可扩展两个优先级，和客户签字确认了需求说明书，明确了后续加需求要走变更流程，从根源上避免了需求乱改的问题，这个阶段比原计划多花了三天，但换来了后续的顺畅，非常值得。2.2架构设计与技术选型阶段确定需求之后，我们开会讨论技术选型，一开始有人提出要用现在流行的微服务架构，说扩展性好，听起来也专业。后来我们仔细算了算，客户一共也就十几个用户，同时在线最多也就十几个人，微服务架构部署复杂，维护成本高，完全没必要。最后我们选了最适合这个项目的技术栈：后端用SpringBoot+MyBatis，轻量开发快，部署也简单，数据库用MySQL，完全能承载几十万条客户数据，足够客户未来五到十年的业务增长；前端用Vue，做响应式布局，同时适配PC和手机端，不用单独开发APP，节省了很多成本。架构设计上我们用了分层的单体架构，逻辑清晰，开发效率高，同时提前预留了扩展接口，如果客户未来业务做大了，想要加功能或者拆成微服务，也不用全部推翻重来，兼顾了当前需求和未来扩展，是非常稳妥的选择。2.3编码开发阶段我们这个项目用了两周一次迭代的敏捷开发模式，每个迭代开发完核心功能，就发给客户看一次，确认没问题再往下做，避免做到最后才发现需求理解错了，改起来成本太高。比如第一个迭代做完客户信息管理模块，给客户看的时候，客户才提出他们需要给客户分等级，不同等级的客户提成比例不一样，我们原来只做了等级分类，没做和提成模块的关联，这个时候改只需要调整客户模块和提成模块的对接，要是等到全部开发完再改，就要动好几个模块的代码，浪费很多时间。我自己负责的是业绩统计和回款管理模块，一开始做出来的月度统计报表，打开要三四秒才能加载出来，我自己测试的时候觉得不对，翻了一下SQL才发现是忘记给常用的查询字段加索引，调整之后加载时间降到了几百毫秒，体验一下子就上去了，现在想想，这种小细节最容易影响用户体验，真的不能大意。2.4测试与调优阶段测试阶段我们除了自己的测试人员找bug，还特意让客户派了两个经常用电脑的销售来帮忙测，毕竟他们是真正的使用者，能找出我们发现不了的问题。比如我们原来觉得按钮大小、位置都挺合适，他们说跑业务的时候都是拿手机点，手容易出汗，小按钮经常点错，我们就把核心操作的按钮都放大了两成；还有他们说原来的提醒声音太小，在外面听不到，我们就加了音量调节和短信提醒的选项，这些细节都是我们坐在办公室里想不到的。整个测试阶段一共找出了八十三个问题，其中三个严重的权限bug，最开始做的权限校验有漏洞，普通销售居然能修改其他同事的客户信息，我们赶紧调整了全局的权限拦截逻辑，花了一天时间就改好了，最终上线前所有严重bug都全部修复，不影响核心使用。2.5上线部署与培训阶段我们特意选了周末上线，不影响客户正常上班，部署完之后，我们现场给所有销售和财务做了两个小时的培训，一步步演示怎么用，还做了一份图文并茂的简易操作手册，存在客户的服务器上，忘了操作随时就能看。之后我们还建了一个答疑群，前一个月几乎天天都有人问问题，大多都是操作不熟练的小问题，我们都第一时间回复，慢慢大家用熟了，问题就越来越少了。3开发过程遇到的核心问题与解决方案整个开发推进过程中，我们遇到了三个之前规划阶段没预料到的问题，也总结出了切实可行的解决方法，在这里整理出来：3.1需求蔓延问题项目开发到一半的时候，客户提出要加一个功能：给销售提供现成的朋友圈文案，方便他们发给客户，这个需求最开始的需求说明书里没有，如果我们直接加进去，就要挤占核心功能的开发时间，项目很可能延期。后来我们和客户沟通，明确这个功能不是当前必须用到的核心功能，我们先把核心的客户管理、业绩统计功能做完按时上线，这个功能作为后续迭代需求，如果客户需要，我们再做开发，只收少量的额外费用，客户也非常认可这个方案，既没有影响项目进度，也满足了客户的额外需求。这件事给我们的教训就是，不管项目大小，一定要提前锁死核心需求，额外需求必须走变更流程，不能随便答应加功能，不然很容易做着做着项目范围越来越大，最后延期又赚不到钱，两边都不开心。3.2旧数据迁移问题客户原来有十几万条客户信息存在好几个不同的Excel里，格式乱七八糟，有的缺手机号，有的重复录入，我们一开始以为导入就是点一下的事，没想到第一次导入，居然有将近两成的数据出错。后来我们专门抽了两天时间，先写了一个简易的数据清洗工具，自动去重、自动补全缺失的非必填字段，把格式统一，然后让客户的工作人员对着自动整理好的数据手动核对一遍，最后才导入新系统，花了整整四天时间才把数据全部弄好。这件事提醒我们，只要是涉及旧数据迁移的项目，一定要提前预留出至少一周的数据整理时间，不能小看这个工作，里面的坑真的很多。3.3移动端兼容性问题我们一开始测试都是在自己的新手机上测，所有功能都正常，结果客户拿来几个用了三四年的旧安卓手机测试，发现有的页面打不开，有的按钮错位。后来我们才知道，很多销售的手机都是用了好几年的旧机器，系统版本比较低，我们用了一些新的前端特性，老系统不支持。最后我们把不必要的新特性都换掉，兼容了五年内推出的所有安卓版本，又找了好几个不同牌子不同版本的旧手机测试了一遍，最终所有设备都能正常使用了，这件事也告诉我们，面向普通用户的系统，一定要考虑设备的多样性，不能只在自己的新设备上测试。4项目开发总结与经验沉淀整个项目交付完成，客户反馈现在找客户信息不用翻半天表格，财务算业绩从一天变成一分钟，也再也不用担心销售离职带走客户了，我们整个团队也收获了很多书本上学不到的经验：首先是对定制化开发的理解，原来我总觉得开发就要用最新的技术，做最多的功能，才显得专业，这个项目做完我才明白，定制开发的核心是贴合用户的实际需求，不是功能越多技术越新就越好，够用、好用、解决问题才是最重要的。我们这个项目没有加什么人工智能预测、大数据分析这类花里胡哨的功能，客户根本用不上，反而会让操作变复杂，增加成本，适合用户的就是最好的。其次是团队协作，原来我们团队沟通也有问题，前端催后端接口，后端说需求改了所以慢，后来我们改成每天早上开十分钟站会，每个人说一下今天要做什么，遇到了什么问题，有问题当场说，不要攒到最后，效率一下子提高了很多。还有写文档，我原来特别嫌写文档麻烦，觉得自己能记住，后来改需求的时候，我自己都忘了当初为什么这么设计，翻了文档才理清楚，才明白“好记性不如烂笔头”这句话真的没错，哪怕简单写两句注释和说明，也比不写强。最后是面向用户的设计思路，做软件真的要多站在用户的角度想问题，用户不会管你用了什么厉害的技术，他们只在乎能不能帮他们少干点活，省点时间。比如原来我们做的报表，默认打开是全维度的统计，客户说我们就只要看每个月每个人的回款，其他的我们很少用，我们就把默认报表改成客户需要的，把其他维度的统计放到二级菜单，用户打开就能看到自己要的，体验一下子就上去了，这点真的比堆十项新技术都有用。总结整个这个软件系统开发项目，从最开始接下小活的不以为意，到最后交付的时候