我们要的是开发者，而不是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的演讲视频吧，他比我讲的透彻，看完后，你会想，是呀，这他妈的简直是真理呀，但是，环顾四周，大家都在这么做吗？如果答案是肯定的，你真幸运，你在和一帮优秀的同事共事。

评论

48 楼 csf178 2008-08-11  

看完这个故事 产生了一个强烈的想法
他们公司打着招程序员的旗号招PM

这时代 连敢报PM的人都少了 只能说招程序员 把人骗来
公司都不容易啊

47 楼 dracularking 2008-08-11  

现在时代的发展会越发地要求更精细的分工
并行能力的不足可以通过人员数量来弥补
但是某一个技术方面的造诣高低可不是简简单单靠多拉几个人就能叠加起来的 在这里1+1未必大于等于2 所以还是呼吁术业有专攻 可以有偏带 但不要被浮躁的思想所左右 除了那些刻意想成为多面手的人 但事实往往是很难样样皆精

46 楼 chinata 2008-08-07  

ajoo 写道

willbfx 写道

我肯定选第一个

错呦。你被忽悠了！

如果走在街上一个人说“这里有颗1克拉的钻石，一千块，归你了”。不用看，肯定是假的。

故事里那个大拿，那水平，后面那人只够给他倒水捶背的，这样的牛牛到你这小卖店面试？做梦没睡醒呢吧？（嗯嗯，如果robbin有一天到我负责的大厦保洁部第二小组面试，我据了丫的，嘿嘿）

肯定是回家找别人帮着做的，而且没准儿是把别人现成的软件拿来充数的。就算是真得，那人是他娘的重生或者穿越的，也肯定over qualify。还是现实点儿，老老实实地雇那个民工踏实。

那也不至于，文件上传+转换+发email，也没啥难的，原型半天也就够了（发sms会麻烦一点，不过如果有现成的网关的话，也没啥）。不过用网站来做这事，实在是他经验欠缺。
估计作者自己也没啥技术经验，这个文章里面的2人技术水平差距不能说很明显，这削弱了文章的主题，俺个人比较认同作者的观点，但是作者的表达能力真是惨不忍睹。

45 楼 ccxw1983 2008-08-07  

sigmad 写道

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

非常赞同，故事如果不真实就没有价值，看读者看10本，以后的故事基本不会出这个模式了，以后大家老了，不适合编程了就把现在的读者翻出来，改改人名、地点、时间，剪刀剪剪去当作者去。

44 楼 ccxw1983 2008-08-07  

我想这个公司是想招一个IT部的光杆司令，业务、代码全部搞定的，所以没办法拉，什么都得会（复合型人才）。
前面的那个人搞技术确实不错，去找家大的公司干活去。

43 楼 i18n 2008-08-07  

这种文章容易误导人,例子看上去也是生造出来的

42 楼 meng9999 2008-08-02  

第二个，不是真正的程序员，以后可能会变为产品经理，或者老板;
第一个，是不错的技术型程序员；
如果是我，我选第一个；能懂我的意思做事情，就很不错了；

41 楼 ajoo 2008-08-02  

willbfx 写道

我肯定选第一个

错呦。你被忽悠了！

如果走在街上一个人说“这里有颗1克拉的钻石，一千块，归你了”。不用看，肯定是假的。

故事里那个大拿，那水平，后面那人只够给他倒水捶背的，这样的牛牛到你这小卖店面试？做梦没睡醒呢吧？（嗯嗯，如果robbin有一天到我负责的大厦保洁部第二小组面试，我据了丫的，嘿嘿）

肯定是回家找别人帮着做的，而且没准儿是把别人现成的软件拿来充数的。就算是真得，那人是他娘的重生或者穿越的，也肯定over qualify。还是现实点儿，老老实实地雇那个民工踏实。

40 楼 willbfx 2008-08-02  

我肯定选第一个

39 楼 hcongqi 2008-08-02  

很明显是国外的例子，不符合中国国情

38 楼 dch1287 2008-08-01  

诺铁 写道

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

俨然已经是一个辩论大赛了 大家继续 。。

37 楼 mfcai 2008-08-01  

icewubin 写道

mfcai 写道

icewubin 写道

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

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

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

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

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

作为一个企业管理者,
首先,得看项目的情况:
如果项目进展顺利,或者公司需要知识储备型人才,第二类比较合适.
如果项目紧张,那就需要第一类人,即熟练型人才,在使用时,尽可能地规范他.
在一个项目管理中,只有尽其才,这个管理者才能算的上称职.
否则,什么都程序员干了,我要管理者干什么?
我直接招程序员得了

啊，管理者只关心这些事就够了么，差远了吧，项目经理或者是TeamLeader的职责要远远超过这里讨论的程序员的基本沟通能力，不是一个概念。不可能都是程序员干的，比如需求管理、进度控制、风险控制、协调测试、QA和开发人员的关系等等，这些怎么可能让程序员做，这里只是说了程序员的沟通能力，不代表程序员越俎代庖，包办项目管理人员的职责。

不要因为某人起了个头，就说是二元论，人才不是第一类就是第二类。只不过是第一类才能和第二类才能各有高低。
像我们公司招人，如果不具备基本沟通能力的话，是不予考虑的。
比如如果招一个很牛的，但是沟通能力比较差的，此类人往往技术观点已经定型，不肯轻易妥协，和公司现有技术观点难免有不一样，如果硬是招进来，造成频繁冲突不说，他做的不爽还容易导致他不久跳槽走人，这样的人工资又很高，很难招的。

1）一个团队需要由很多类型的人才来组成。
2）管理人员的选择不是非此即彼的选择，应综合评判。
3）人才只有放对地方才是人才；放错地方只能是垃圾。
4）在很多时候我们需要基础和经验很扎实的研究型人才。比如，在用户不知道自己要干什么的情况下，你怎么去解决问题？我看最好的办法就是给他实物。让他知道，阿，我要做的就是这样。这也只有那些刻苦钻研的人才才能做到。
5）文中的管理者还没有结束的情况下，就妄下断言，这是他最大的错误。难道管理员看人就那么准？一个小时就能得出结论？更何况第二个面试者还没有给出他的答案---即他的技术到底如何。

36 楼 icewubin 2008-08-01  

hutuchong 写道

学习,觉得看环境来的.不是有专门的需求分析师吗

对，如果程序员是和这个需求分析师经常直接沟通的，这个需求分析师就是这个程序员的“客户”。

如果程序员和自己的“客户”都沟通不好，很容易出现内部的需求风险的，比如程序员蒙头做了一周，正好项目经理也没有及时的关注进度和质量，公司也没有严格的质量保证计划，一周后，需求分析师看了这个程序员做的某个模块的内部测试版，然后说，你做的有问题，然后程序员发现当初理解错了……。

35 楼 hutuchong 2008-08-01  

学习,觉得看环境来的.不是有专门的需求分析师吗

34 楼 icewubin 2008-08-01  

mfcai 写道

icewubin 写道

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

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

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

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

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

作为一个企业管理者,
首先,得看项目的情况:
如果项目进展顺利,或者公司需要知识储备型人才,第二类比较合适.
如果项目紧张,那就需要第一类人,即熟练型人才,在使用时,尽可能地规范他.
在一个项目管理中,只有尽其才,这个管理者才能算的上称职.
否则,什么都程序员干了,我要管理者干什么?
我直接招程序员得了

啊，管理者只关心这些事就够了么，差远了吧，项目经理或者是TeamLeader的职责要远远超过这里讨论的程序员的基本沟通能力，不是一个概念。不可能都是程序员干的，比如需求管理、进度控制、风险控制、协调测试、QA和开发人员的关系等等，这些怎么可能让程序员做，这里只是说了程序员的沟通能力，不代表程序员越俎代庖，包办项目管理人员的职责。

不要因为某人起了个头，就说是二元论，人才不是第一类就是第二类。只不过是第一类才能和第二类才能各有高低。
像我们公司招人，如果不具备基本沟通能力的话，是不予考虑的。
比如如果招一个很牛的，但是沟通能力比较差的，此类人往往技术观点已经定型，不肯轻易妥协，和公司现有技术观点难免有不一样，如果硬是招进来，造成频繁冲突不说，他做的不爽还容易导致他不久跳槽走人，这样的人工资又很高，很难招的。

33 楼 RCFans 2008-08-01  

gm8pleasure 写道

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

程序员所称的客户不一定是end-user，一个比较规范的公司，程序员的客户就是业务分析师，甚至有可能是系统架构师，你的编码在直接为谁所使，他就是你的客户。一个团队20来个人，各有各的表达方面和思考习惯，直接去见end-user得把人逼疯……

32 楼 waryist 2008-08-01  

dazuiba 写道

我们要的是开发者，而不是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的演讲视频吧，他比我讲的透彻，看完后，你会想，是呀，这他妈的简直是真理呀，但是，环顾四周，大家都在这么做吗？如果答案是肯定的，你真幸运，你在和一帮优秀的同事共事。

感觉上这个故事确实比较虚伪，缺乏必要的细节说明，得出的结果也是教化式的，程序员要提高自己的综合素质的基础就是技术要过关。

31 楼 Else 2008-08-01  

qjzhyf 写道

Else 写道

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

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

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

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

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

这个行业的专家，据我所知，还没有。

我们做的是治安卡口监控项目，给公安用的。以前有过类似的项目，不过一般是交警用的。

如果哪位知道有哪个公司或者城市做过，我们倒是想联系一下搞些需求。

30 楼 maxiaoxia 2008-07-31  

"Hacker们创建一个website(浪费了时间和精力)，而最终还会由客户买单。好的程序员用最快的方式满足客户，从而为客户节省了开支。"
忽悠好好的忽悠
微软的软件都不用卖了，IBM的中间件也歇了吧，SAP的东西都留给自己用吧，因为这些破软件都没有为“客户节省了开支”
这不是搞笑么.....

29 楼 mfcai 2008-07-31  

icewubin 写道

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

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

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

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

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

作为一个企业管理者,
首先,得看项目的情况:
如果项目进展顺利,或者公司需要知识储备型人才,第二类比较合适.
如果项目紧张,那就需要第一类人,即熟练型人才,在使用时,尽可能地规范他.
在一个项目管理中,只有尽其才,这个管理者才能算的上称职.
否则,什么都程序员干了,我要管理者干什么?
我直接招程序员得了