在过去两年里，我个人解决问题的方式经历了很大的转变，逐渐从一个新人转变为比较合格的小职员。
最开始工作的时候，老板抛给我一个小问题，我就钻里面去了，每天为了哪一点提升，绞尽脑汁。大概过了3个月，模型效果看似提升了不少，但是也只是对当前的数据集罢了。最后，果断被老板叫停了，原因很简单，这些提升，大部分情况是靠人力堆出来，并没有抽象出方法论上的东西，同时这些提升带来的业务上的收益几乎为零。
然后开始接手一个实际的业务，是从同事处交接过来的一个业务，项目需求和解决方案都很清晰。不过对于一个空降人员，理解起来也挺费劲的，不得不从头梳理代码，理解方案和原理，最后重新写一遍。这个项目下来，自己大概知道一个成熟的方案是什么样子的？不丢主线，注重细节（很多很多case要考虑）。不过也是依葫芦画瓢，顺着别人道走。方案本身存在的问题，我也解决不了。
这之后，我渐渐独立做一些事情，亦或和小伙伴一起解决问题，发现做工程解决实际需求真难。理论上夸夸其谈何其简单，一到落地问题各式各样。自己解决问题的思路大致如下：
- 1）需求来了，首先是理解需求，我们要解决什么问题？翻译成技术人员能够理解的语言；
- 2）如何解决问题？先从大的框架上设计再到每个环节的拆分，从输入到输出要涉及什么环节，拆分如何使合理的？尽量做到细致；
- 3）技术选型，每个环节都会涉及一些算法，往往有很多种，最后选择哪一种，往往需要平衡效果和资源；
- 4）方案验证，没有什么方案从一开始就考虑地面面俱到，很多细节可能在验证阶段发现并处理；
- 5）最后是上线应用，我们有很优秀的工程团队，上线的事情交给他们，上线后业务方会定期反馈一些情况，一般先尽量按线上配置化的方式快速解决，遇到一般问题再迭代方案。
这样的处理问题方式，能帮助我们解决大部分的需求。不过也只是思路而已，具体问题具体分析吧。很多事情，很多环节我们其实做的并不好。最近，朋友在微信上说，一个好的程序员不仅是解决需求还要有产品思维，从产品的角度思考问题。其实我们老板也这么强调，但是怎么做是有产品思维呢？有产品思维的人是怎么解决问题的呢？这个值得探讨。
网友评论