说实话,这类项目的成败,一半在需求调研那几周。
设计和体验
做报表之前先问清楚谁看、看什么、多久看一次。
简单说,不到现场看一遍,做出来的东西大概率是想象的。
换句话说,历史数据迁移这块一定要留足时间,老数据很少是干净的。
原理是这样:要不要做手机端,看人在不在办公室,这个决定很实际。
流程梳理比功能清单重要。先把现在怎么干写清楚,再谈系统怎么支撑。各家情况不一样。
上线和推广
试点先行是个稳妥办法。先在三个部门跑起来,改顺了再推广。
培训这事别省。系统做得再好,没人会用也是白搭。
先说个前提,系统成不成功,就看用的人是不是主动打开它,别的指标都是虚的。
后期维护的响应速度,直接决定系统能不能长期用下去。
安全这块,尤其是涉及个人信息的系统,存储和权限都要按规范来。
分阶段推进比一口气做完靠谱,中间还能根据反馈调整。
调研这步别省
统计口径要统一。同一个数字,不同部门算法不一样,最后会吵起来。
项目最怕的是甲方内部意见不统一,做一半停在那儿,谁都不敢拍板。
别嫌我啰嗦。
搜索和筛选是用得最多的功能,这块做得顺手,整体评价会高不少。
说白了,审批流程别设计得太长,环节一多,大家就开始绕开系统走线下。各家情况不一样。
我记得,旧系统的使用习惯要尊重。改得太猛,抵触情绪会很大。
老实说,硬件环境也要提前看。有些单位的网络和设备比较老,会影响体验。
做这类项目,我最大的体会是:技术是其次,把人的习惯改过来才是最难的。
各类文档要留全,人员变动的时候,没文档的系统会变成黑盒。
别以为数字化了就不用打印,很多场景下纸质单据还是刚需。
项目周期一般十来个月起,太赶的话质量很难保证,这个得提前说清楚。
调研这步别省
验收的时候别只看功能有没有,要让人实际操作一遍走通业务流程。
反馈渠道要留。用户用着不顺手,得有个地方说,不然问题一直埋着。
二次开发的可能性要提前考虑。业务会变,系统得留点余地。
系统上线的时间点要挑。别赶在业务最忙的时候切换,那是在给自己找麻烦。
日志和操作留痕,出问题时特别有用。谁在什么时候改了什么,一查就知道。
数据看板别做得太花。领导要看的就那几个数,堆一堆图表反而找不到重点。
能记住的就一句:让用的人省事,系统才活得了。