案例(我们要的是开发者，而不是hacker)辩驳

  在javaeye上看到一篇文章:我们要的是开发者，而不是hacker(http://www.iteye.com/topic/221325?page=1).其中的观点有些片面,引来一帮网友的拍砖.我以为通过这个案例,企业的管理者在招聘时先考虑清楚,公司到底需要什么样的人才?通过什么考核方式为公司招到所需要的人才?这样才能为企业招到合适的人才.而这个案例中企业的管理者,我不禁要问他是称职的管理者吗?

案例

引用

    某网络广告公司需要招聘一个程序员，来帮助公司创建企业对外和对内的网站。于是，两个应聘者来面试.面试官给出了一个任务：将一个Csv文件从一种格式，转换成另外一种格式。并要求应聘者在24小时之内完成。
    第一个应聘者回到家，设计了一个简单而又令人惊奇的网站，用户可以同时上传多个文件，并且转换成功后，系统会通过SMS或者email的方式告知用户。的确是一个很好用的软件。
    第二个应聘者收到任务后，他接下来花了30分钟和相关人员谈论业务需求，他要搞清楚用户用何种方式使用这套软件，这套软件提供了哪些有价值的东西。问完他想问的问题后，CTO没有让他直接离开，而是当场给了Offer.
    第二天，第一个应聘者只接到了“谢谢来面试，期望以后有合作机会”之类的电话。

作者dazuiba观点
    程序员们都知道软件是为人开发的，你知道，我也知道。但是当我环顾四周，很少有程序员和用户交流。这貌似是不合清理的，但它的确大部分时间是这样，用这种开发方式，我们吃了很多亏。
    Hacker们每天都生产出高质量的代码。这很好，如果没有hacker，我不可能有消息系统、web服务器、等等等等。至少我不会有这么多可选的软件。但是，即使你是一个好的hacker，但这并不能保证能对业务有用！
   我经常会碰到这种事情：人们整理需求，但最终的结果已经离业务需要严重脱离。有两个途径可以解决这个问题
    1) 尽你最大努力把代码写好
    2) 好好和用户谈一下业务
    Hacker总是会选择第一个，这并不一定会错。事实上，一个好的hacker总会足够快地讲软件交付使用，即使他推到重来三四次。
   但是，作为一个开发者，应该在一开始就搞清楚这个软件到底是怎么被使用的。和用户多几次高质量的交流，会保证开发者理解业务如何运作，以及软件在其中扮演的角色。采用这种方式，更容易达成一个好的结果：软件为客户提供了一个好的解决方案，开发者也采用了最直接、高效的实现方式(比如：客户只需要一个命令行的csv转换工具，而不是一个websit)。
   Hacker们创建一个website(浪费了时间和精力)，而最终还会由客户买单。好的程序员用最快的方式满足客户，从而为客户节省了开支。
   以上这个道理，不是我头个讲的，但是我经常碰到，所以就把它写下来。Kent back好几年前就讲过，最近一次是在今年年初的伦敦的QCon上(InfoQ上有相关的视频)。
   不要觉得你是个写程序的，就可以不明白这个道理----只要你是在写软件，在写“给人使用的软件”。去看看Kent的演讲视频吧，他比我讲的透彻，看完后，你会想，是呀，这他妈的简直是真理呀，但是，环顾四周，大家都在这么做吗？如果答案是肯定的，你真幸运，你在和一帮优秀的同事共事。


我们再来看看正反双方pk的结果:
支持方意见
1.网友hyhongyong
凡事皆事出有因！
环境会改变人，人也能影响环境！
多从自己身上找原因，才能提升更多。
不论别人如何看待，自己都要从更高的角度看问题，要善其身！
程序员既要低头拉车，也要抬头看路。不为别的，要对得起自己！
2.网友dazuiba
程序员是一个很宽泛的职业定义，我想这里的程序员，应该是那种可以独挡一面，或者争取独当一面的任务角色。
做螺丝钉无可厚非，但如果改变一下自己，就等当上发动机的火花塞或者中心齿轮，也是很好的事情。



反方意见
1.网友jjx
再说如果不会写漂亮的代码,问清需求又有什么用.写出来的东西好维护吗?
凡事都掌握一个度就可以了,不要为了宣传一种思维将另一种思维贬到地下
2.网友equalto
如果作为项目经理甚至是部门负责人,产品规划师这样的人,完全的忽视客户和市场,那必然是灾难,但是,如果是程序员么,好好的干活就可以了.
每个人做好自己的本分工作,尽力做的出色,才是好的.
而且国内的情况,人心浮躁,从八〇年代开始的做导弹的不如卖咸鸭蛋的,我见过的人里面,想做项目经理的比愿意写好程序的人多几百倍.号召向市场看,不如号召踏实干.
也许,这个文章里面,所谓的程序员,不是和我们理解的程序员一个角色吧.
3.网友cocal
如果这个例子中的公司不是一个三、五人的小作坊，只充分说明那个CTO是个草包中的极品而已！！！他错失了一个高手。
当今世上能用甜言蜜语、喋喋不休把客户侃晕的“高人”一抓一大把，但能在极短的时间内拿出“简单而又令人惊奇的”工作成果的人却凤毛麟角的很。
这是一个完全失败的伪命题，明显，这个CTO不是在招一个程序员，但又堂而皇之把真正的程序员贬低为“螺丝钉”，然后把程序员和设计师、架构师、项目经理等概念混淆，拔高到非常人可到达的高度。既要和用户良好沟通，又能极快的拿出代码，那起码是“独挡两面”了，呵呵。一直以来总有些人把我们的IT往浮躁的方向上引，总有一种力量把中国IT引离最核心、最致命的区域，从而葬送了行业的过去、现在和未来。
个人感觉，这两个人是代表IT项目中两种十分对立的性格，一种是对外向的、一种是内敛的，让一个人同时具备两种性格，两者达到很高修为，是十分困难的。他们的对立在于相互矛盾，专注a方向的发展，b就会衰退，反之也一样。
但至少，我坚决反对把哪一种性格凌驾于另一种。一流的沟通能力是可贵的，一流的技术能力同样是可贵的。而对于程序员，毫无疑问（我是说程序员，不是说“很泛的职业定义”），应该是专注于前一种。
4.网友[e-mail]
支持cocal.有些人都是希望每个员工是超人一样，不同人有不同的特长，要因才而用，不要动不动就说这样不行，那样不行。
5.网友Else
不知道大家看〈赢在中国〉没有，里面几位大佬夸夸其谈。
你玩点擦边球吧，他说你没有规则，你讲点规则吧，他说你不会变通，不是做事的料。
反正是他说的都对，至少理由，从来都不缺。
6.网友jieyuan_cg
让程序员去讨论需求？去理解客户的业务，还要理解得到位，这样才能做出成功的软件来？听起来挺不错的，但现实如此吗？而且，我觉得直接让程序员去跟客户沟通，本来是一件很不靠谱的事情～
1)程序员去跟客户沟通，首先会有语言障碍，特别是专业术语方面的障碍。
2)难道程序员跟客户讨论两三次，就能更深入地了解用户的需求？我看未必～有些行业经验并不是一次两次就能理解的，要是一次两次理解，那程序员就直接转行算了～别干这个吃力不讨好的事情了。
3)如果程序员直接跟客户去讨论需求，那需求调研人员，需求说明书撰写人员去干什么？失业？还是给程序员做会议纪要？
4)程序员一边揣摩需要，一边考虑设计，一边还要注意进度，程序员是铁打的？呵呵～如果这些都能协调好，那还是程序员吗？是项目经理～
7.网友lhyasia
这种问题PASS掉世界顶级黑客， 留下些平庸的所谓分析员

评论

1 楼 vvvpig 2012-08-06  

他要的是项目经理，不是开发者
如果开发者还需要与客户沟通需求，那就是项目经理的工作没做好
如果经历真实项目，客户无止境的提需求，不仅产品开发会滞后，还有时间，开发成本问题等