关于印度模式的另一种声音.docVIP

关于印度模式的另一种声音 我想大家是误解我的意思了。我说的技术当然也包括软件工程。但是现在做一个系统分析员要面对的却不仅仅是技术，他们还必须面对各种各样的商业规范，有些客户甚至把整个商业模式的设计也推到了系统分析员的身上，这些客户根本不知道自己要做什么，连人事，财务方面的要求都说不出来，商业模式的设计是经济学家的事，而不是计算机专家的事，但这种超越了外部设计范围的事却在很多情况下落到了系统分析员的身上，在这样的情况下也许系统分析员都得是MBA他的设计才能让客户满意，看着我那个roup里的那个系统分析员用了差不多一星期时间和客户讨论商业运作上的问题，我当时的想法就是我以后坚决不干这一行。其实公司应该专门养一个MBA(如果养得起的话)来应付这些无理的客户。因为一毕业就到日本打工，所以我说的都是日本公司的情况。国内情况不太了解，想必也差不多吧。听说国内还得应付公司内部的种种勾心斗角，更让我心寒。 现在软件工程论坛好像有一种盲目推崇印度的风气，其实印度的方法真的那么值得我们学吗?其实未必。 先谈一下waterfall的问题。waterfall的开发模型适合于印度，但不适合于中国。因为印度的主要市场是接受国外软件公司的定购，由于客户本来就是同行，需求非常明确，也不太可能在开发期间有什么改动，设计书大家都签了字，要改可以，拿钱来。另外，印度的程序员很多都是高中生，成本低，好管理，所以waterfall在印度并没有太高的风险和成本。虽然waterfall在印度获得成功，但的的确确它是一种非常古老和落后的模型。工程一旦启动，几乎无法更改，设计期间程序员几乎无事可干，人员利用率低下，抹杀个性，程序员劳动积极性低下，无法实现程序员富有创造力的想法，程序员对技术的研究不深入，开发出的程序运行效率低下。另外，设计几乎是面向工程的，代码的重用性很低。这种模型唯一的好处是对管理者和开发者的要求都很低，高压政策加上没有思想的廉价劳动力就可以了。这个模型对很多公司是不适用的，比如说在日本，如果客户在中途要更改要求，这时虽有法律文书在手却是一纸空文，因为大部分软件公司的主要客户是公司的最大股东，得罪了客户意味着什么就不用我说了吧(没有竞争的社会，也许是日本软件虽排名世界第二出口缺少的可怜的原因吧)。所以我们公司都是用的spiral模型。我想在国内，虽然不太会有类似日本的原因，但可能连相关法规是否健全(不是指书面条款而是具体执行)都成问题吧，另外还有同行的恶性竞争(往往是通过非法手段)。我想在这样的环境下盲目学印度简直是自杀。我想还是用spiral模型跟加适合国情。 (prototyping太作坊化，没有前途的。)其实piral是一个非常好模型，不光在日本，在欧美也非常普遍地被采用，因为它和当今的面向对象技术是最容易紧密结合的。有人抱怨这个模型开发的东西不稳定，确实这个模型给程序员较大的空间，但这并不成为程序不稳定的原因。这个模型需要管理者有更高的素质，在这个模型下高压政策行不通。所谓“牛人”在项目中捣乱，往往是出于它没有获得应有的尊重引起的。他们一腔热情去学习各种最新的技术，去了解系统，去研究各种算法，而换来却是编码是最低级的事情，拧拧螺丝罢了之类的话。其实他们不知道，做一个牛人要比做分析员付出更多的努力才行。那里有压迫哪里就有反抗，不写注释，无他，这样的领导太让人不放心，为了生存而已。变态到希望没有人看懂自己代码的人毕竟是少数。一个好的项目负责人，不应该忽视组里每一个人的作用，而不是整天一副高高在上，目中无人的样子。这样其实比一个坏的设计方案对工程的影响更大，大家不敢得罪你，就把气出到分析员身上，可怜的分析员。好像听说还有分析员兼任项目经理的，连分工都不明确谈什么软件工程。在日本，除了sa还有se，他们的主要工作仍然是代码，还有内部设计，但是他们几乎拿着和sa相同的工资。这样做其实让代码高手有了一个可以得到肯定的机会，对提高软件的质量其实是很有帮助的。其实在把外部设计和内部设计分开比印度人那样把内部设计和代码分开更科学，因为se负责的模块范围都不大，而se都是编码高手，对自己的负责范围几乎可以完全控制，所有代码都要经过se的检验和修改，其实每个模块都接近出自一人之手的状态，另外spiral模型是waterfall和prototypmg的混合，从se负责的模块开始使用prototyping，所以在这个层次上代码是完全独立的，所以即使将来要修改，一般也不会出现一发而动全身的事情。相反，像印度那样连设计函数接口的人都不写代码(其实一般直到这一步都是由sa完成)，其实在这种情况下，代码是很容易失控的，除非招收一批没有思想的编程机器，印度的种姓制度为产生这种机器创造了极佳的条件，我敢说，除了印度，世界上不会有第二个国家的程序员