滴滴做过的项目和反思

我在简历上是这么描述自己在滴滴做过的项目，描述的很笼统。也是借此机会细化和总结这些项目，寻找之前的不足和有没有突破点！

金融商户减免活动

商户减免活动目的是促进用户形成用公司支付平台支付的习惯。通过和商户合作的方式让用户在支付时可以减免部分金额从而吸引用户。目前主要在巴西和墨西哥开展。我们主要负责活动后台开发。
负责：活动后台开发和审批流程

5W1H

what,where,when,why,who+how

why: 目前滴滴国际化在MX和BR的用户量是比较大的，在这两个国家也都有滴滴自己的支付方式（99pay，ddpay）。不过目前滴滴的支付主要是发生在打车场景下，且国外更多的习惯用现金支付。通过商户减免活动也是为了刺激用户在其他支付场景也会使用滴滴的支付渠道。对于中国来说，使用线上支付已经是一种习惯。但是在国外来说由于这个比例很低，如果尽早的去占有线上支付这个市场，那么就会可能做成国外市场的支付宝或微信支付。
what：商户减免活动通过和商户合作的方式，在用户支付时如果我们和这个商户有合作关系，则可以享受优惠力度最高的减免。这个活动通过国际化APP作为线上推广渠道，支付团队扩展优惠券使用功能，运营通过商户后台配置活动。
where：MX和BR
when：2022年4月中旬上线
who：国际化APP团队，支付团队，司机准入团队
how：首先运营人员通过商户后台配置好活动，然后活动会通过审批流程进行审批，审批通过之后才会把活动信息同步给支付侧，支付侧会通过一些配置项去校验这笔支付是否满足条件。

对于我们来说，完成的功能主要是：商户后台和审批流控制。

模块设计

编码->核心编码->模块设计->应用设计->系统设计

核心编码：活动状态机（审批流程）。
活动状态机：将状态的触发行为枚举成不同的事件，事件的枚举值用二进制表示。通过Action+State。不过这些都是基本的代码实现思路，我认为是比较简单的。

这个项目的难点在于边界的划分：

• 活动参与次数校验
• 符合活动的列表

国家化任务审核系统

5w1h

why：我们部门是国际化司机准入，司机上传的证件最后都会通过人工审核。而人工审核的通过率也会直接影响司机转化率。人工审核的准确性也会间接影响到司机进线和数据维护。人工审核是采用外包形式的，不同的国家都是这种形式。当然公司为了确保数据的准确性也有质检团队，质检团队一般是国内的员工。他们采取线下导出数据的方式对审核的数据做抽样考核（考核的量是他们的指标）。审核的外包结算受考核的质量影响。所以这个审核系统会关系到质检团队和审核外包团队。
线下抽检的问题：

• 效率低
• 结果不透明
• 不易统计
  质检功能的线上带来的好处：
• 提高效率
• 结果更加透明
• 结果可供统计使用，有提高司机转化率可能
  what：质检功能就是对审核的质量考核
  where：国际化已开国国家
  who：质检团队，审核外包团队
  when：2021-11-01
  how：怎么做？
  这个项目是属于研发团队推动的项目，需要拉齐质检团队和产品。在设计之前也咨询过国内的抽检做法。在设计上我们和国内的区别是：
  国内：国内的证件比较统一，所以审核更多是通过智能审核为主，人工审核为辅。质检是通过人工每次配置审核任务，支持审核人员的审核数量定制化。但是国内的质检配置必须要指定人才行，如果这个人刚好请假就不得不重新指派。
  国际化：
• 支持定时生成审核任务
• 可指定分配任务，也可不指定分配
• 可按多种维度去审核任务

难点：

• 初期收集需求难
• 可扩展性要求高

解法：
对可扩展性展开讨论下：
（1）首先解答下为什么要高扩展呢？
由于抽检项目初期收集需求时，无法对所有的国家的诉求都采集，因此只能尽量做到满足大部分诉求却不失可扩展。这样就能满足今后的产品诉求。
（2）产品的主要诉求有哪些呢？

• 定时生成任务
• 指定分配和平均分配任务
• 按不同条件过滤任务：通过任务，某拒绝原因，审核人员等

方案设计 && 模块设计：

每个模块之间都是异步的，用户通过页面交互设置完抽样的规则后，我们会通过异步脚本将规则解析到规则列表，然后在通过异步脚本从规则列表解析规则并且从ES抽取样本放到样本表。接下来质检团队就可以初审了。初审后的结果又可以供复审。初审的样本是通过ES获取，而复审则是从初审的数据中再抽样。初审一般是周内每天都会进行，而复审一般是一星期一次。

设计方案中最重要的一点就是规则的设计，因为规则设计好了其他的都是围绕着规则在转。所以规则的最初设计是这样的：

{
    "main_tasktype_id": "37,39,41",
    "time_type": 0,
    "begin_time": "2021-10-01 00:00:00",
    "end_time": "2021-10-10 00:00:00",
    "country": "MX",
    "city": 0,
    "scale": 0.1,
    "auditor": "zs,ls",
    "auditor_type": 2,
    "result_enum": "",
    "schedule": 1,
    "datetime": "2021-10-01 12:30:00",
    "week": "2-6",
    "Cron": "",
    "total_num": 9000,
    "approved_total_num": 6300,
    "rejected_total_num": 2700,
    "sample_total_num": 900,
    "distribute_type_by_audit": 2,
    "distribute_type_by_maintt": 2,
    "distribute_config": [
        {
            "main_tasktype_id": "37",
            "total_num": 3000,
            "approved_total_num": 2100,
            "rejected_total_num": 900,
            "result_enum": "",
            "detail": [
                {
                    "auditor": "zs",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                },
                {
                    "auditor": "ls",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                }
            ]
        },
        {
            "main_tasktype_id": "39",
            "total_num": 3000,
            "approved_total_num": 2100,
            "rejected_total_num": 900,
            "result_enum": "",
            "detail": [
                {
                    "auditor": "zs",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                },
                {
                    "auditor": "ls",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                }
            ]
        },
        {
            "main_tasktype_id": "41",
            "total_num": 3000,
            "approved_total_num": 2100,
            "rejected_total_num": 900,
            "result_enum": "",
            "detail": [
                {
                    "auditor": "zs",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                },
                {
                    "auditor": "ls",
                    "total_num": 150,
                    "approved_num": 105,
                    "rejected_num": 45
                }
            ]
        }
    ]
}

抽检的过滤字段主要是：

• 审核结果：通过或拒绝，拒绝原因，审核时间,审核人员，任务ID。

抽取样本方式：随机和按比。

• distribute_type_by_audit：1按审核结果随机抽取,2按审核结果比例抽取。

抽检的规则：按周期和一次性活动

后来规则分层：

规则JSON因为没有主要的查询，所以把配置的规则都放在一个JSON，这样如果有扩展的诉求则只需要修改JSON字段即可。
规则列表会将规则JSON经常用来搜索的字段平铺在数据表字段，然后把分配规则用JSON保存。
分配的方式还是按照JSON。

配置规则流程图：

Cron定时任务流程图：

请介绍下你满意的项目

回答：近期做的一个审核任务抽检系统，我认为还是满意的。为什么觉得满意呢？因为在设计的时候充分考虑了扩展性的这个点。那如何设计的呢？
首先，我先讲下需求的背景：
再次，讲下设计思路：
抽检就是从一批已审核的任务中抽样再次校验的过程。那么就离不开三点：

• 原审核数据
• 抽检出样本
• 样本审核

原审核数据的过滤条件：任务ID，时间范围，审核人员，审核结果。
抽检出样本：抽检的数量是多少，由谁来抽检？
样本审核：抽检和复检

然后考虑到抽检这个动作可能是周期性的一个行为，所以要支持周期性。