这篇文章从数据分析师和算法分析师的合作问题出发，分析了典型的错误局势并提供了破局思路，向我们展示了正确和谐的合作场景。推荐数据分析师和算法工程师阅读学习。

数据分析师该如何与算法工程师合作，是个老大难问题。一方面是业务方日益提高的，对模型的幻想。另一方面是大量企业里存在的数据采集差，缺少足够数据人员，工作目标不清晰等等问题。分析与算法到底该如何协同增效？今天系统分享一下。

一、两种典型的错误做法狗不理式

有些公司领导喜欢嫌弃自家数据分析师没本事，总认为“上个模型才牛逼”。于是数据分析师们皆明哲保身，干脆和所有带“模型”俩字的工作划清界限，统统甩给算法工程师。

这么干，当然会坑死算法。

且不说，很多时候领导口中的模型根本就是“SWOT”一类虚无缥缈的东西；

且不说，很多建模目标根本就是：“预测我做什么能成功”一类不切实际的东西。

就单单基础特征筛选工作没人支持一项，就会让算法工程师累死。项目进度慢，最后还是被嫌弃：“为啥你的模型不能100%精准预测！！！”

当然，此类问题常见于传统企业。特别是数字化转型阶段，领导们看了很多高大上的ppt，自以为自己很懂的传统企业。

当狗用式：一些互联网公司对于算法的应用有相对清晰的定位，算法小组的地位也较高。于是走向另一极端：把配给算法组的分析师当狗使。做啥你不用管，你按我说的取数就好了。用无休无止的取数表淹没了数据分析的工作。

这么干，坑的是所有人。因为连数据分析师都不懂算法逻辑，那运营部门更不懂。在茫然无知的情况下，运营部门只能通过简单的数据指标监控，来推测算法效果。并且稍有风吹草动，就开始质疑：“算法不灵了吧！”，“你们悄悄改了啥！”,“就是你们瞎搞！”这些质疑，又会成为部门间甩锅、扯皮的导火索，引发无休无止的内耗。

二、破局的基本思路

从本质上看，分析和算法，都是数据的应用。那么灵魂拷问来了：是不是有了数据，钞票就源源不断从电脑里喷出来了？显然不是！数据本身不能包治百病，想让数据发挥作用，得紧密结合业务实际，找好数据能帮上忙的发力点才行。

而业务的实际情况又很复杂，经常是数据和业务行为交织在一起。

比如：

• 短视频DAU下降，是算法推荐不给力，还是创作者本身质量太差
• 交易转化率下降，是商品推荐不给力，还是货源本身没有选好
• 业绩预测不精准，是预测模型不给力，还是业务自己放水了

这时候，业务部门永远可以甩锅：“我们的数据太无能，我们要是有字节的算法就牛逼了”。而数据这边，不管是算法还是分析，都是背锅的。所以最终的破局思路，是数据的同学们团结一致，找好场景，做出成绩，减少背锅，而不是自己人踩自己人。

空口说显得太空洞，下边结合一个具体问题场景看看。

三、典型合作场景之一

项目立项问题场景：某大型制造企业，期望建立“多维度立体式分析模型”，提升招聘效率。问，此时该怎么接需求？

这是个典型的需求不清晰场景。

• 什么叫：招聘效率？
• 招聘成本更低？招聘回来以后留存更好？招聘到合适的人？
• 什么叫合适的人？是否已经有清晰定义？
• 流水线工人、销售、营销策划、管理人员的“合适”定义是否一致？
• 流水线工人、销售、营销策划、管理人员的招聘问题是否相同？

以上情况统统不清楚

因此无论是算法/分析，谁接需求，都得先问清上边的问题。当然，在问题定义都模糊不清的时候，让数据分析师站出来沟通更合适。数据分析师和业务贴的更近，更容易理解业务语言，引导业务思路。

业务方进一步给出的回答是：

• 要帮助管理岗位招到更合适的人
• 要发现：XX省市的流水线工人更容易招，我们集中招聘
• 要让整个部门的用人成本，控制在XXX万元以内

那么，是不是可开始建“多维度”“立体式”的模型了呢？

不！远远不到！

四、典型合作场景之二

任务分解有三大问题，制约着项目推进：

1. 管理岗位的“合适”定义不清晰。

管理人员的考核，远比流水线工人复杂。流水线工人只要考察年龄、身份证、学历几个简单维度即可，考操作技巧也能通过标准化作业考核。管理人员则复杂的多，还有“领导看他顺不顺眼”这种高度个性化、无法量化的考核点。因此不能简单的止步在这里。需要进一步定义。

2. 各省市劳动力数据缺失。

注意：从现在HR收到的简历里筛选出合适的，和从茫茫人海里锁定哪里的劳动力多，完全是两个问题。因为已经收到的可以统计数据，茫茫人海压根连数据都没有。如果盲目开工，很有可能引发误判。

3. 整体部门用人成本与招聘效率，根本就是两个问题。

整个部门用人成本，除了新招聘以外，还有在职工资福利，还有离职人员赔偿等等。如果目标是控部门整体成本，那到底哪一块总量最高，哪一块占比最大，哪一块是冗余，哪一块增长最快，要提前一一分析清楚。再看怎么解决。

此时，可以拆出至少五个任务。

1. 定义管理岗位的“合适”（可能为了定义合适，要单独建个业务模型，比如胜任力模型）。
2. 基于过往面试数据，为管理岗位“合适”做标注，为建模做准备。
3. 收集各地区劳动力市场数据（劳动力市场发布信息、中介提供信息等）。
4. 结合过往招聘活动，验证分地区招聘合理性（也有可能求职者虽然是内地省份的人，但是找工作还是跑到沿海省份找，分地区意义没那么大，这些假设都待验证）。
5. 分析整体用人成本结构与走势，找到成本控制关键点。

这五个任务，主要都是数据分析的活。数据分析理清现状，采集数据，后边算法就能有的放矢。比如：

1、在已有管理岗位“合适/不合适”标注的情况下，结合简历信息、猎头给到信息、招聘渠道信息，对面试人员建分类预测的模型（逻辑回归/决策树），预测“合适”概率

2、在已经有整体用人成本结构、增长原因、发展趋势数据情况下，建预测模型（时间序列/多元回归）判断用人成本是否会超出预期，从而干预决策（不要因为短期缺人就大量招聘，对比给加班费和增加新人成本差异）。

当然，还有第三个合作点：在工作中遭遇挑战，大家一起应对。

五、典型合作场景之三

问题解答面对“模型为什么不准！”终极问题，一定是所有人一起努力。首先要排除的，是外部因素、意外波动、业务主动行为的影响。不要是个问题就往模型身上泼脏水。

比如：突然有高管变动，引发管理层招聘要求全变招工来源地发生疫情，人员出不来行业领头企业突然提高了薪资，拉高了整个行业成本原定的招聘计划因为各种原因推迟原定招聘计划，没有达成预期，要加新渠道/新方式 所有这些因素都会让原先设计的模型不成立或者效果下降。应对这些变化，数据分析要冲在前边，在日常监控数据的时候，就及早发现问题，提示业务风险，提醒所有人关注变化。而不是等着业务打上门来再来扯皮。

六、小结

算法和分析的工作性质差异，使得这两者合作分工的时候，天生侧重点不同。理想的合作方式，就是：分析扫清业务障碍，算法集中提升效率。大家一起做出成绩。

实际上，如果你工作时间够久，和业务接触得够多，就会发现：大部分直接从业务口中冒出来的“建模型”需求，都不靠谱，不是数据缺失，就是目标不清。别是涉及预测问题的时候（分类问题相对好一点）。经过数据分析师转化的需求，反而靠谱很多。

作者：接地气的陈老师

微信公众号：“接地气的陈老师”

本文由 @接地气的陈老师 原创发布于运营派，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议