开发算法的痛点是什么

不同角度看到的痛点不同。从作为主管和工程师两个视角来答。因为谈痛点，所以消极成分比较多，但并不代表没有积极的东西，只是不符合题目，故略之，见谅。

以下纯个人经验，受限于经历，只能以偏概全。望能抛个烂砖，引些好玉。

主管视角

一、个人水平不足

这可能是工程师们面临的最大挑战。很多校招的硕士同学们几乎还没太理解什么是“建模”就已经开始了调包、调参之旅。面对标准化的task，同学们如鱼得水。但task一旦没那么标准，同学们基本无能为力。很多同学把比较复杂的实际问题转化成一系列标准任务的能力都缺乏，更别说那些奇奇怪怪的问题了。

博士同学们相对好点，至少在一个领域相对专业很多，也具备一些攻坚能力。但最近一两年毕业的同学们太“专”了。论文越来越好，基础越来越差。最后我竟神奇地发现，有些做Data mining的同学不但论文好，基本功也扎实，对CV、NLP常见玩法也都了如指掌。而反过来，CV、NLP的同学们基本“隔行如隔山”。

越是飞速发展的学科，基本功尤其重要。

二、傲慢与偏见

团队成员211、985硕士起步，这些同学在整个学生生涯基本都是佼佼者，到工作中心态很容易出问题。一些同学在讨论问题时比较自我，过于坚持已形成的观念，说难听点叫“张口就来”。很多事情不求证，不阅读，纯凭感觉就给定论。

这类伙伴如不更正、引导，到后面基本就是甩锅侠。github一拉跑完效果不好，开始说数据问题、说产品需求问题等等。总之，所有人和事都有问题，自己没问题。

反观大部分博士同学，paper与书的阅读量本来就大，工作中还一直持续，反倒谦逊不少，不争不吵，给方案、给分析、给结论，非常solid。

读书一本，会发现还差两本；读paper一篇，会发现还差五篇。

一本不读，一篇不读，就“无敌”于天下。

理就这么个理，共勉。

三、奇怪的方案

这个锅属于产品和一些研发leader。产品和研发伙伴们因为岗位原因，不会跟算法同学有一样思维方式。但他们偶尔会对一些清晰、偏直觉的算法需求给出一些方案或设想。不用多说，这些方案都是rule based。

就我的的人经验来看，遇到的类似方案基本都是错误甚至不可行的。但在一些需求会上要考虑对方感受，需要委婉表达。

对于一些不太爱表达、不爱争取的算法伙伴，这就很致命了。他们会去依照这些idea去跟进一段时间，当发现有大问题时才去反馈，但时间一去不复返，最终浪费的是自己、团队的宝贵时间。

四、模糊的需求

技术背景的产品少，算法背景的产品更是凤毛麟角。所以不能指望产品最后列出的算法需求是真的最终需求。

个人建议是对于任何小伙伴，即使你只负责产品一个小feature，产品在宣讲PRD时仍要聚精会神，清楚了解整个产品逻辑，来判断算法需求点是否合理，或者有遗漏。

在一些逻辑复杂的产品中，算法需求遗漏很常见。

工程师视角

一、缺少数据

我一直深信对于目前以深度学习为主流的AI来说，数据是AI的第一生产力。

我还深信，如果很多大厂把花在算法research上的投资（时间、金钱）拿去投数据，而把花在数据上的投资来投算法，AI的落地能力会更强、成果会更丰富。

一般的数据 + 极致的算法 = 一般的效果

极致的数据 + 一般的算法 = 极致的效果

一般的效果 * N = 很烂的产品

极致的效果 * N = 伟大的产品

二、只管人不管事的主管

算法这东西，三个小诸葛亮可能会顶上天皇老子。团队合作对于解决一些复杂问题非常重要，包括极致的分析、细致的coding和bad case的耐心追踪。一个管事的主管需要凝聚团队，带头参与团队讨论而不仅仅拍板。一群水平差不多的伙伴，每个人的idea一般无畏对错。在模型跑分结束前，没有谁可以拍胸脯说他的方案一定最好。所以主管需要尊重所有人，并在讨论不休的时候及时定调。

如果遇上不管事的，那这位leader就是最大的痛点。