菜单
一家受监管的支付公司,靠着彼此割裂的工具和手工表格来运转全部业务:开通企业客户、追踪每一笔交易、并就这一切出具报表。它需要一个可以据以经营业务的门户。
我构建了该门户前端的约90%。客户改为批量开通,而不是一次一张表单,所有账户都集中在一处。
资金流向——收入、支出、代收、转账——是实时被看见的,而不是事后拼凑出来的。
最大的收获在报表。过去两个人每周仅在报表上就要花掉约20小时:15到20份周报和月报,每一份都靠手工完成。
从每天数千笔交易里取数、写Excel公式、逐个文件排版,这就是那份手工活。现在门户按计划自动汇总并发送同样的报表,没有人再碰表格。
保密说明: 出于保密考虑,客户与公司名称已作更改或略去。工作内容、我的角色与项目范围均属实。
过去两个人每周约花20小时手工制作15–20份周报和月报——现在门户自行汇总并发送
收款、付款、代收与P2P实时可见——不必事后对账
几乎整个网页门户前端,从设计到交付一以贯之
15–20份周期性的周报和月报,如今每一份都自行汇总并发送
总账、明细账和多方交易必须变成非专业同事也能放心操作的界面。
TypeScript配合Redux Toolkit状态管理与Ant Design体系,按功能模块组织,使门户能够持续生长。
四条支付流上的实时交易——每天1,000到10,000笔——需要一个始终最新的统一视图,同时不让界面变得拥挤。
覆盖收款、付款、代收与P2P的单一实时视图,并配以简化的单个与批量用户开通。
大型财务表格需要在客户端导出为规范的PDF和Excel文件,且不能让门户卡死。
按需与按计划生成的PDF(jsPDF + AutoTable)和Excel(XLSX)报表会自行生成并送达——数小时的手工汇总变成了后台任务。
企业客户需要把大量用户带上平台,一次一张手工表单永远跟不上。
基于角色的访问、企业账户管理、带状态且可检索的交易历史,以及为大数据量调校的响应式界面中的结算与对账视图。
现在我们的团队就是从这个门户经营业务的:开通、账簿和实时交易视图都在一处。穆罕默德理解的是业务本身,而不只是规格文档。
客户身份保密。本摘要来自客户向 Muhammad 与项目团队口头反馈的内容。
还没有评论,来说说你的想法吧。
分享关于 Web 开发以及如何做出真正能上线的产品的思考。