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

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

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

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

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

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

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