我们要的是开发者，而不是hacker

我们要的是开发者，而不是hacker
作者：jayfields
译者：dazuiba


某网络广告公司需要招聘一个程序员，来帮助公司创建企业对外和对内的网站。于是，两个应聘者来面试。

面试官给出了一个任务：将一个Csv文件从一种格式，转换成另外一种格式。并要求应聘者在24小时之内完成。

第一个应聘者回到家，设计了一个简单而又令人惊奇的网站，用户可以同时上传多个文件，并且转换成功后，系统会通过SMS或者email的方式告知用户。
的确是一个很好用的软件。

第二个应聘者收到任务后，他接下来花了30分钟和相关人员谈论业务需求，他要搞清楚用户用何种方式使用这套软件，这套软件提供了哪些有价值的东西。问完他想问的问题后，CTO没有让他直接离开，而是当场给了Offer.

第二天，第一个应聘者只接到了“谢谢来面试，期望以后有合作机会”之类的电话。

程序员们都知道软件是为人开发的，你知道，我也知道。但是当我环顾四周，很少有程序员和用户交流。这貌似是不合清理的，但它的确大部分时间是这样，用这种开发方式，我们吃了很多亏。

Hacker们每天都生产出高质量的代码。这很好，如果没有hacker，我不可能有消息系统、web服务器、等等等等。至少我不会有这么多可选的软件。但是，即使你是一个好的hacker，但这并不能保证能对业务有用！

我经常会碰到这种事情：人们整理需求，但最终的结果已经离业务需要严重脱离。有两个途径可以解决这个问题
1 尽你最大努力把代码写好
2 好好和用户谈一下业务

Hacker总是会选择第一个，这并不一定会错。事实上，一个好的hacker总会足够快地讲软件交付使用，即使他推到重来三四次。

但是，作为一个开发者，应该在一开始就搞清楚这个软件到底是怎么被使用的。和用户多几次高质量的交流，会保证开发者理解业务如何运作，以及软件在其中扮演的角色。采用这种方式，更容易达成一个好的结果：软件为客户提供了一个好的解决方案，开发者也采用了最直接、高效的实现方式(比如：客户只需要一个命令行的csv转换工具，而不是一个websit)。

Hacker们创建一个website(浪费了时间和精力)，而最终还会由客户买单。好的程序员用最快的方式满足客户，从而为客户节省了开支。

以上这个道理，不是我头个讲的，但是我经常碰到，所以就把它写下来。Kent back好几年前就讲过，最近一次是在今年年初的伦敦的QCon上(InfoQ上有相关的视频)。
不要觉得你是个写程序的，就可以不明白这个道理----只要你是在写软件，在写“给人使用的软件”。去看看Kent的演讲视频吧，他比我讲的透彻，看完后，你会想，是呀，这他妈的简直是真理呀，但是，环顾四周，大家都在这么做吗？如果答案是肯定的，你真幸运，你在和一帮优秀的同事共事。

评论

28 楼 icewubin 2008-07-31  

大家说得都有理，最开始的例子直接理解不太好而已。

程序员沟通的不一定是客户，但是可以把业务分析师当作客户，一样的，既要充分了解客户的想法，也要和客户PK功能，适当引导客户。

不太可能一个程序员没有任何沟通，直接看需求说明书就能完成功能，这里面是有陷阱的，这个说明书说不定就是哪个快辞职的需求分析师赶工出来的次品，天知道质量到底如何，尤其是中国客户，即使签字的需求说明书照样可以说最终产品不是他想要的。

我觉得这样说比较好，一个程序员不管是做什么项目，必须要有个人即使沟通反馈，降低自身需求的分险，这个人既有可能是客户，也有可能是业务分析师，也有可能是项目经理，也有可能是TeamLeader，如果不好找，就看谁来验收你的工作就找谁。这些人都可以称为“客户”的。

有这样的变通思维，再去理解最开始的那个例子就好理解多了。

27 楼 jian'shang 2008-07-31  

这两个人最好在同一项目组，呵呵

26 楼 qmug 2008-07-31  

大家的见解都很 独到而犀利。 可以各抒己见 是好事情。都是吃这口饭的， 不用争的太严重了伤了和气。 问题是在于探讨 最终可以找寻到解决问题的方法和途径。不一定是最好，力求更好。各位觉得呢？

25 楼 sigmad 2008-07-31  

不切实际。
当程序员后再也没看过读者了。

24 楼 lhyasia 2008-07-31  

这种问题PASS掉世界顶级黑客， 留下些平庸的所谓分析员

23 楼 mk926 2008-07-31  

这种故事现在的中国到处都有，一看就是编的:)

22 楼 gm8pleasure 2008-07-31  

既然是面试题，何来的用户？这个问题值得商榷。

21 楼 jieyuan_cg 2008-07-31  

让程序员去讨论需求？去理解客户的业务，还要理解得到位，这样才能做出成功的软件来？听起来挺不错的，但现实如此吗？而且，我觉得直接让程序员去跟客户沟通，本来是一件很不靠谱的事情～
1.程序员去跟客户沟通，首先会有语言障碍，特别是专业术语方面的障碍。
2.难道程序员跟客户讨论两三次，就能更深入地了解用户的需求？我看未必～有些行业经验并不是一次两次就能理解的，要是一次两次理解，那程序员就直接转行算了～别干这个吃力不讨好的事情了。
3.如果程序员直接跟客户去讨论需求，那需求调研人员，需求说明书撰写人员去干什么？失业？还是给程序员做会议纪要？
4.程序员一边揣摩需要，一边考虑设计，一边还要注意进度，程序员是铁打的？呵呵～如果这些都能协调好，那还是程序员吗？是项目经理～

20 楼 BlueMeteorolite 2008-07-31  

为什么打工的总TMD的弱势?我要是第一个人,对道不谋着根本不屑一顾.去他妈的OFFER.

19 楼 Else 2008-07-31  

不知道大家看〈赢在中国〉没有，里面几位大佬夸夸其谈。

你玩点擦边球吧，他说你没有规则，你讲点规则吧，他说你不会变通，不是做事的料。

反正是他说的都对，至少理由，从来都不缺。

18 楼 kaipingk 2008-07-31  

cocal 写道

如果这个例子中的公司不是一个三、五人的小作坊，只充分说明那个CTO是个草包中的极品而已！！！他错失了一个高手。

当今世上能用甜言蜜语、喋喋不休把客户侃晕的“高人”一抓一大把，但能在极短的时间内拿出“简单而又令人惊奇的”工作成果的人却凤毛麟角的很。

这是一个完全失败的伪命题，明显，这个CTO不是在招一个程序员，但又堂而皇之把真正的程序员贬低为“螺丝钉”，然后把程序员和设计师、架构师、项目经理等概念混淆，拔高到非常人可到达的高度。既要和用户良好沟通，又能极快的拿出代码，那起码是“独挡两面”了，呵呵。一直以来总有些人把我们的IT往浮躁的方向上引，总有一种力量把中国IT引离最核心、最致命的区域，从而葬送了行业的过去、现在和未来。

个人感觉，这两个人是代表IT项目中两种十分对立的性格，一种是对外向的、一种是内敛的，让一个人同时具备两种性格，两者达到很高修为，是十分困难的。他们的对立在于相互矛盾，专注a方向的发展，b就会衰退，反之也一样。

但至少，我坚决反对把哪一种性格凌驾于另一种。一流的沟通能力是可贵的，一流的技术能力同样是可贵的。而对于程序员，毫无疑问（我是说程序员，不是说“很泛的职业定义”），应该是专注于前一种。

十分支持，有些人都是希望每个员工是超人一样，不同人有不同的特长，要因才而用，不要动不动就说这样不行，那样不行。

17 楼 kaipingk 2008-07-31  

楼主是理想派，少糊弄人啊。。。。。。

16 楼 etng 2008-07-31  

Hacker慢慢培养成为你说的“开发者”嘛。
看你需要什么人才而已

15 楼 cocal 2008-07-31  

如果这个例子中的公司不是一个三、五人的小作坊，只充分说明那个CTO是个草包中的极品而已！！！他错失了一个高手。

当今世上能用甜言蜜语、喋喋不休把客户侃晕的“高人”一抓一大把，但能在极短的时间内拿出“简单而又令人惊奇的”工作成果的人却凤毛麟角的很。

这是一个完全失败的伪命题，明显，这个CTO不是在招一个程序员，但又堂而皇之把真正的程序员贬低为“螺丝钉”，然后把程序员和设计师、架构师、项目经理等概念混淆，拔高到非常人可到达的高度。既要和用户良好沟通，又能极快的拿出代码，那起码是“独挡两面”了，呵呵。一直以来总有些人把我们的IT往浮躁的方向上引，总有一种力量把中国IT引离最核心、最致命的区域，从而葬送了行业的过去、现在和未来。

个人感觉，这两个人是代表IT项目中两种十分对立的性格，一种是对外向的、一种是内敛的，让一个人同时具备两种性格，两者达到很高修为，是十分困难的。他们的对立在于相互矛盾，专注a方向的发展，b就会衰退，反之也一样。

但至少，我坚决反对把哪一种性格凌驾于另一种。一流的沟通能力是可贵的，一流的技术能力同样是可贵的。而对于程序员，毫无疑问（我是说程序员，不是说“很泛的职业定义”），应该是专注于前一种。

14 楼 qjzhyf 2008-07-31  

Else 写道

这个故事的风格很像《读者》。空谈！

我们的老大天天跟我们说没功能啊，没功能啊，你们要想些功能。。

客户是公安局，从来不跟我们谈需求，一句话：你们先做。。

功能全是我们自己想的，至于靠不靠谱。。难说啊

所以，才需要一个行业专家来引导客房获取需求.即使是客房说不出他们的需求，那有这样一些行业专家，还是可以找到一些能用的业务需求，导出业务原型的。这样和客房讨论的时候，可能更保险一些。不过，这样的话，客房都不知道他们到底想要什么，而是我们全盘替他们想需求的话，我看，很悬啊。

13 楼 Else 2008-07-31  

这个故事的风格很像《读者》。空谈！

我们的老大天天跟我们说没功能啊，没功能啊，你们要想些功能。。

客户是公安局，从来不跟我们谈需求，一句话：你们先做。。

功能全是我们自己想的，至于靠不靠谱。。难说啊

12 楼 z.cen 2008-07-31  

       想了一下,貌似正确.
       那么对立面就不对吗?

11 楼 mfcai 2008-07-31  

伪命题。是在招程序员还是需求分析工程师？
招程序员，第一个应聘者的表现很出色。如果是招需求分析工程师，可能做法上有欠缺。
但用人单位首先要清楚他能提供的是什么岗位。

10 楼 诺铁 2008-07-31  

说实话，这个案例很没意思。作为辩论大赛的主题还不错。

9 楼 dazuiba 2008-07-31  

[也许,这个文章里面,所谓的程序员,不是和我们理解的程序员一个角色吧. ]

我这里说的程序员，不是螺丝钉。
你说的是螺丝钉。

程序员是一个很宽泛的职业定义，我想这里的程序员，应该是那种可以独挡一面，或者争取独当一面的任务角色。

做螺丝钉无可厚非，但如果改变一下自己，就等当上发动机的火花塞或者中心齿轮，也是很好的事情。