案例(我们要的是开发者,而不是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.网友[email protected]
支持cocal.有些人都是希望每个员工是超人一样,不同人有不同的特长,要因才而用,不要动不动就说这样不行,那样不行。
5.网友Else
不知道大家看〈赢在中国〉没有,里面几位大佬夸夸其谈。
你玩点擦边球吧,他说你没有规则,你讲点规则吧,他说你不会变通,不是做事的料。
反正是他说的都对,至少理由,从来都不缺。
6.网友jieyuan_cg
让程序员去讨论需求?去理解客户的业务,还要理解得到位,这样才能做出成功的软件来?听起来挺不错的,但现实如此吗?而且,我觉得直接让程序员去跟客户沟通,本来是一件很不靠谱的事情~
1)程序员去跟客户沟通,首先会有语言障碍,特别是专业术语方面的障碍。
2)难道程序员跟客户讨论两三次,就能更深入地了解用户的需求?我看未必~有些行业经验并不是一次两次就能理解的,要是一次两次理解,那程序员就直接转行算了~别干这个吃力不讨好的事情了。
3)如果程序员直接跟客户去讨论需求,那需求调研人员,需求说明书撰写人员去干什么?失业?还是给程序员做会议纪要?
4)程序员一边揣摩需要,一边考虑设计,一边还要注意进度,程序员是铁打的?呵呵~如果这些都能协调好,那还是程序员吗?是项目经理~
7.网友lhyasia
这种问题PASS掉世界顶级黑客, 留下些平庸的所谓分析员

猜你喜欢

转载自staratsky.iteye.com/blog/222429