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

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

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

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

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

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

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

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

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

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

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

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

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

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

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