我做行业软件这行十几年了，做过学校、医院，也做过政府部门的系统。

设计和体验

报表需求要问细。不同的人要的数据不一样，笼统说「要报表」等于没说。

历史数据迁移这块一定要留足时间，老数据很少是干净的。

培训这事别省。系统做得再好，没人会用也是白搭。

这个细节挺关键。

先把现有流程画出来，系统才有依据，不然就是空中楼阁。

接口对接经常是难点。跟现有系统打通这件事，要提前确认能不能做。

老实说，移动端要不要做，取决于使用场景。经常在外跑的岗位，手机端是刚需。

说实话，权限体系一开始就要定好，返工的代价很大。

需求调研这步别省。我一般会去现场待几天，看人家实际怎么操作。

上线和推广

试点先行是个稳妥办法。先在四个部门跑起来，改顺了再推广。

给用户留个提意见的入口，不然他们只会私下抱怨，你永远不知道。

做这类项目，我最大的体会是：技术是其次，把人的习惯改过来才是最难的。

各类文档要留全，人员变动的时候，没文档的系统会变成黑盒。我反正是这么看的。

验收要按真实业务场景跑一遍，功能清单打勾不代表能用。

调研这步别省

打印功能经常被忽略，但很多单位还是离不开纸质单据，这块要提前问。

后来才发现，首页展示的数据贵在少而准，放太多反而不知道看哪儿。

切换系统要避开业务高峰期，硬赶只会让大家更抵触。

系统要留扩展余地，业务一两年就会变，太死的架构很难改。具体还得看情况。

项目周期一般二个月起，太赶的话质量很难保证，这个得提前说清楚。这点挺重要。

日志和操作留痕，出问题时特别有用。谁在什么时候改了什么，一查就知道。

调研这步别省

需求方内部要先达成一致。我遇到过项目做到一半，两个部门的说法打架，开发只能干等。细节往往就差在这。

搜索和筛选是用得最多的功能，这块做得顺手，整体评价会高不少。

统计口径要统一。同一个数字，不同部门算法不一样，最后会吵起来。

调研的时候多问一句有没有例外情况，这些地方往往是后面出问题的源头。细节往往就差在这。

旧系统的使用习惯要尊重。改得太猛，抵触情绪会很大。这块别偷懒。

审批流程别设计得太长，环节一多，大家就开始绕开系统走线下。

说白了，安全这块，尤其是涉及个人信息的系统，存储和权限都要按规范来。

有个细节，批量的导入导出看着不起眼，实际能省下不少人力和怨气。

分阶段推进比一口气做完靠谱，中间还能根据反馈调整。

先说个前提，做这类项目久了，我发现最管用的判断标准很简单：一线员工是不是真的愿意用。我反正是这么看的。

听起来简单，上线之后的维护响应很关键，问题拖久了，大家就不用了。

顺便提一句，硬件环境也要提前看。有些单位的网络和设备比较老，会影响体验。

真要上的话，先把最关键的两个流程跑通。