今天说说有关需求的问题，可能有的人会说我是个码农，需求是产品或者运营的事，与我有毛线关系。

我不太清楚像BAT这类大公司的码农，他们需要对产品和用户需求会有多深的了解，但我认为一个码农，必须要尽可能了解客户或用户需求，也就是你在干的这个事解决了什么问题。

不是我看不起做需求工作的同志，但在实际工作中由于决策层面的影响，经常会导致派没有掌控需求能力的人去负责需求工作，其最主要的问题就在于需求理解错位或深层次的需求无法挖掘。

你不能指望客户或者用户懂产品，他们想要A说出B，对他们来说再正常不过，但如果最后程序员也按B做，那就完蛋了。

另一个问题是没有能力过滤掉不合理的需求，这个比较麻烦，你既然敢去说NO，就必须给出足够的说NO的理由，更牛逼的是要做到让对方觉得你说NO实际上是站在他的角度上帮他在考虑问题。

这个真不是刚工作1-2年的小朋友能做的。

其实我也知道，真让码农去做需求估计在一般公司基本不可能，但这确实是提升自己的最好途径之一。

能身临第一线掌握到用户真正需要什么，用自己的专业知识与分析能力告诉用户哪些是他们真正想要的，哪些对他们来说只是吃力不讨好，是不可取的。

可能一开始你没有这种能力，但如果坐在屋子里听一辈子非专业人转述的需求，那就永远没有这种能力。我在此只是想告诉大家一种快速进步的方式，至于如何获得机会，看造化和努力吧。

我之前提过，业务专家与码农结合，绝对是1+1大于2的，说实话，对一个系统的熟悉程度，使用者绝对比不上一行代码一行代码敲出来的码农。

早些年一个朋友跟我说的一件事：有个集团的信息总监曾经为了制定数据采集议的软件需求，去当了半个月走南闯北的销售人员。

回来后说了一句话：普通业务员天天在来回跑，他们跑两年也就是那么一回事；而我只要跑半个月，就已经完全明白了到底他们需要什么。

这就是一个拥有典型程序员思维的人与实际客户的业务人员之间最本质的区别——思考。思考是程序员的特质之一，其很大一部分增长都是借助于接触客户需求实现的。

当然，大家也不要指望刚开始工作就有接触业务需求的机会，还是得先把代码写好，再说这一步的事。下一章开始讲写代码。

摘自：@ZTalk青龙老贼