【算法思维】怎么和算法工程师打交道

【算法思维】怎么和算法工程师打交道——更多资源,课程更新在

资源，名师讲座课程简介：

 【算法思维】怎么和算法工程师打交道

在公司里，产品经理跟算法工程师经常不对付。算法工程师说产品经理不懂技术，过于简化问题，总改产品设计。产品经理说算法工程师不懂业务，把技术放在首位，还不会用人话交流。

这背后的原因，就是因为两边的思维方式不一样。

所以这一讲，我就来说说，如果你是算法工程师的甲方”，该怎么跟他们打交道。当然，这个甲方”的范围广一些，你们可以是公司之间的合作，也可以是公司内部的合作。

甲方在乎特定结果，算法工程师在乎通用方案

甲方经常对算法工程师不满的一个原因，就是做事慢。为什么总把简单的问题复杂化呢？问题一复杂，解决的时间就变长了。

还记得我们之前讲了开店的小文吗？她开了一个小商店，给附近的白领提供寿司和包子两种午餐。但她总是摸不清两种午餐应该准备多少份，于是找来了我们的算法工程师小扎，问他用算法该怎么解决。

小扎想了半天说，这个问题我得试试不同的时间序列模型，找到过去有断货的日子，看看需求是怎么转移的，用户的需求跟天气有没有什么关系……

话还没说完，小文就打断了他：你别说了，我还是靠直觉来吧，如果昨天备货备少了，我明天就多备点；昨天备多了，今天就少备点。

小文这么做肯定没问题。但作为一个靠谱的算法工程师，小扎的想法就不一样。明明要回答的问题是A，但我一定要回答一个更宽泛的问题A’。

你说这是不是有点杀鸡用牛刀”呢？确实是，但牛刀有牛刀的好处。

你想，小文的超市要备的商品肯定不是只有两样，没准有几百样。而每种商品的属性又不一样，像每天都有客户买午饭，但菜刀可能就不是每天都有人买的，有的商品一天就会坏，有的放很久都没事。

如果小扎把不同的商品属性分析清楚，就可以设计出一个通用性很高的算法，把所有商品的备货问题一起解决。

你看，甲方很多时候关注的是眼下问题的特定结果，而算法工程师更在意通用方案，解决更多更广泛的问题。

你可能觉得这有点狗拿耗子，多管闲事”，但这种更关注通用方案的思维模式用好了，甚至能成就全新的商业模式。

给你举个例子。

美国亚马逊公司，以电商闻名，但它其实不只是个卖货的公司，还是个卖云服务的公司。云服务简单来说，就是你自己手头没有硬盘，却想储存大量数据，做大量计算。于是你给亚马逊交点钱，你想做的事情远程就能实现。

这跟通用性思维有什么关系呢？听我给你讲。

在有云服务”这个概念之前，亚马逊管理各种硬件的算法程序，是每个工作组独立设计实现的。所以，公司里有多少项目，类似的算法、程序就要写多少次。这多麻烦啊。

这些算法工程师拓展了一下思路，发现这些问题完全可以用一个通用的方案来实现。这样，不只可以一并解决公司内部不同项目遇到的硬件管理问题，捎带着外部用户也可以用。

既然外部用户也能用，那不如把这个通用方案拿出去卖钱吧。这就成了如今每年营收几百亿美元的亚马逊云服务。

所以甲方在和算法工程师合作的时候，可以提前沟通清楚，想要的解决方案是速度重要，还是通用性重要，是短期一次使用还是长期反复使用。这就能够事半功倍了。

算法工程师的基本需求：数据

理解了算法工程师的思维习惯，甲方还得知道怎么激励算法工程师。这就像，导演爱剧本，演员爱舞台。你得知道算法工程师对什么感兴趣，什么能刺激他工作的热情。

算法工程师爱什么呢？爱数据。

有些算法工程师对数据的执念特别之强，他们甚至认为空口无凭，数据为证”。这怎么讲呢？

咱们课程说过王婆的故事。她觉得自己介绍对象的能力太厉害了。她说起自己做的媒，如数家珍。张三、李四、翠翠、花花，都在她手下结成了完满的婚姻。

一个算法工程师听了这些，会有什么反应？没什么反应。可能多问一句，你说得对，但除了这些特例，有其他数据吗？”如果没有数据，只有特例，算法工程师兴奋不起来。

但如果王婆说，她把去年她遇到的所有客户的兴趣、爱好信息，每对客户约会对对方印象的反馈，都记录下来了，连客户结婚半年后，对婚姻满意程度的记录都有。

那算法工程师的眼睛唰”一下就能亮起来。

还记得咱们之前说过的吗？算法是有输入、有输出的计算步骤。这儿的输入”就是数据。

算法工程师工作中有数学的成分，但他们不是数学家。数学家不需要数据，但算法工程师特别需要。没有数据，算法工程师就不能干活。这就好像你想盖房子，但又没有塔吊和钢筋，那工人拍拍屁股就走了。

所以当算法工程师的甲方，要学会拿数据跟他们沟通。数据越多，质量越高，算法工程师对你要解决问题的兴趣也越高，因为他们知道，自己大展身手的时候来了。

算法工程师的核心价值：问题的解决方案

好，你现在知道了算法工程师的思考方式，也知道了怎么激励他们。有了这两步的储备，那该怎么跟他们互动呢？

作为甲方，你有时候可能会发现，算法工程师不听劝”。他们解决问题的方法总是和你想的不一样。

还拿小文备货来举例子。如果她知道，预测备货量的最好方案，就是通过前一天的销售情况进行一些计算，那她直接把方案告诉算法工程师，不就可以了吗？

其实不是。如果甲方真的知道解决问题最好的方案是什么，那根本不需要算法工程师，方案直接交给软件开发去实现就行了。

之所以需要，那肯定因为问题的解决方案不简单。

而一个靠谱的算法工程师，擅长的是抽象思维。他能把一个复杂的实际问题转换为明确的数学问题，比较不同的算法解决方案，权衡利弊，找出最合适的一个，然后用算法解决。这就是他的优势。

而作为甲方，优势在于对问题场景的深度的、具象的理解。算法工程师和甲方最好的互动方式，就是他们能一起在抽象模型和现实场景当中来回转换。这也是算法工程师最期待的互动方式。

我还拿小文的备货问题举例子。

小文作为甲方，不懂什么是优化算法。但她理解问题的场景，可以告诉算法工程师，她以前对不同商品是怎么备货的。

然后算法工程师说想用某某模型的时候，小文会抓住重点发问：客人明天来不来没个准，怎么办？利润高和利润低的商品，备货应该有什么区别？社区小超市跟家乐福的备货一样吗？”

这些问题，会被算法工程师抽象成用户需求的不确定性和预测问题，商品的盈利率作为参数对决策结果的相关性问题，以及店铺规模的总限制条件分散到单个商品限制条件的机制问题。

一切确认完毕，算法工程师回去设计算法，运行程序，得到结果。这时候，小文又会和算法工程师一起分析结果数据。

比如寿司备货50份，合理。挂历备货20幅，不合理。现在明明是暑假，卖什么挂历。发现问题之后，算法工程师可以回去迭代算法，消除问题。

所以说，甲方和算法工程师工作的最好模式是，在布置任务的时候描述清楚不同情况下的问题场景，明确目标，限制条件，提供充分的数据。在算法工程师提出算法方案时，确认自己的问题核心有没有被解决。最后，在得到结果的时候，再把它们转换进实际场景，看看算法是不是合理。

。。。。