下面这份清单，是我自己每次开工前会过一遍的。做管理系统的开发的话，可以照着对。
设计和体验
- 数据迁移是最容易低估的工作量。老系统的数据往往乱得很，清洗很费时间。
- 移动端要不要做，取决于使用场景。经常在外跑的岗位，手机端是刚需。
- 权限体系一开始就要定好，返工的代价很大。
- 做报表之前先问清楚谁看、看什么、多久看一次。
- 先把现有流程画出来，系统才有依据，不然就是空中楼阁。
- 培训这事别省。系统做得再好，没人会用也是白搭。
- 跟已有系统的对接要早点确认，卡在这上面的项目不少。
- 界面越简单越好，用的人不会为了好看去多学一套操作。
- 反馈渠道要留。用户用着不顺手，得有个地方说，不然问题一直埋着。
- 新旧系统并行一段时间会稳当些，一下子全切风险太大。
- 验收要按真实业务场景跑一遍，功能清单打勾不代表能用。
- 操作记录要留着，出了争议能查得到，这个功能平时不起眼，关键时候靠它。
首页展示的数据贵在少而准，放太多反而不知道看哪儿。
做这类项目，我最大的体会是：技术是其次，把人的习惯改过来才是最难的。
系统上线的时间点要挑。别赶在业务最忙的时候切换，那是在给自己找麻烦。
系统要留扩展余地，业务一两年就会变，太死的架构很难改。
上线和推广
别以为数字化了就不用打印，很多场景下纸质单据还是刚需。
项目周期一般十来个月起，太赶的话质量很难保证，这个得提前说清楚。
单据和审批流是最容易设计复杂的部分。层级一多，实际用起来就没人愿意走。
调研这步别省
需求方内部要先达成一致。我遇到过项目做到一半，两个部门的说法打架，开发只能干等。
说白了，查询和筛选的功能要好用。用户最常用的就是找东西，找不到就会觉得系统难用。
现场的网络和设备条件先摸清楚，不然上线了才发现跑不动。
统计口径要统一。同一个数字，不同部门算法不一样，最后会吵起来。
涉及人员信息的系统，安全和合规这块不能含糊。
系统成不成功，就看用的人是不是主动打开它，别的指标都是虚的。
别追求一步到位。分阶段上，每期解决几个痛点，效果反而更好。
换个说法，后期维护的响应速度，直接决定系统能不能长期用下去。
旧系统的使用习惯要尊重。改得太猛，抵触情绪会很大。
批量的导入导出看着不起眼，实际能省下不少人力和怨气。
有个细节，调研的时候多问一句有没有例外情况，这些地方往往是后面出问题的源头。
清单可以自己往下加，用着用着就变长了。