坑爹的盖雅工场
source link: https://liluoao.github.io/posts/fxxk-gaia.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
坑爹的盖雅工场
在《一个不知道咋说的业务》中讲过，用盖雅是为了解放门店算薪的人力。
当时人力总监考察了市面的系统后，发现只有盖雅能够支持我们的复杂逻辑，咱受对方蛊惑，听信了对方是考勤业界的王。
盖雅工场需要咱将员工与部门数据同步给他们，这看起来并不是啥麻烦事，我原本是这样以为的。
开幕雷击，可能还是我见的世面少了，系统对接使用文件传递，需要以 csv 文件方式将员工的增量数据放进他们的服务器。
通过询问后知道，他们每次对接都是这样，都是进行定制开发（表头不一致），没有统一的处理方案。
这样就导致我们的进度是完全依赖于对方的，就算我们是甲方，也没有说能百分百控制住关键时间点。咱们的业务分与对方沟通了数次之后，终于确定好了各字段内容的格式。
业务方偶尔反映数据有问题，这时没有一个判断依据，因为对方每次处理完文件后都会删除掉，我们的文件也在容器里。更窒息的是对方没有错误提示，要登录服务器才知道同步因为报错卡住了！就很好奇这样的方式之前没人吐槽过吗。并且他们的逻辑是一个文件里遇到一行错误，剩下的就不执行了，而且之后的新文件也不执行了
对方也是急需吃下我们这个大单，再经过很多次的反馈后，对面逐渐重视，由领导来牵头解决了对接中的一些情况。经过我们持续优化后，终于保证了整个业务高可用。
上线后，由于之前员工都习惯了钉钉打卡，改用盖雅的 H5 后不熟悉，并且 UI 简直是十几年前的画风。我方提出了几点来兼容使用习惯，例如增加查看打卡记录的入口、自动打卡、修改 UI 等，又需要对方进行排期与估价。一点小修改开出了 18w 的报价，所以我们决定自己出 UI，让他们直接替换掉。
“业界领先”的系统连很多基础功能都没有
经过几个月的折腾才完成了整个计划的前奏，关键的目标是用对方提供的考勤数据来计算薪资，所以咱还得接着开发。
果不其然，整个数据又是放在他们服务器，让我们去取。但是直到上线，对方都没有保证每个月什么时间点能生成好数据。
现在回头看看最初的目标，由于对方生成的文件数据并不准确，还是没有解决算薪的问题，需要花整个部门（三支柱的SSC）的几天通宵去验证对方数据准确性。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK