目前国内的软件方面的人才开始大量的关注软件工程这门学科，大有80年代末90年代初国人追捧汉字系统的劲头，但是实事求是的理解国内的开发过程，我认为软件工程固然是一个方面（甚至可能是非常重要的一面），但隐藏在表象后的问题也是不容忽视的， 我认为目前开发环节中存在着一些问题或理解的偏差，其中典型的表现在：
1、 学而优则士
这个问题很普遍，很多人都是这样想：开发到35岁以后就应该考虑管理的问题了。这个想法是“学而优则士”的想法，好的开发人员，不一定是好的管理人员，因为侧重的面不一样，知识结构也不一样。但是，由于很传统的思想，认为领导就是应该各方面都好些，所以强把“学”推为“士”。这样不但没有更好的提高效率，反而浪费了很好的人才。同时，也是由于传统的思想，“士”更受人尊敬，而“学”往往被认为是蓝领，所以很多的“学而优”者也就有成为“士”的激励诱因了。我认为，这是一个不正常的现象。“学而优”的地位及受人尊敬应该有相应的评判机制，比如说：系统设计师应该比项目经理更加受人尊敬。也只有这样，“学”者才可以安心设计，“士”者也可以更好发挥“士”的职能。
2、过程与阶段
只有过程没有阶段是没有意义的，我们都知道，任何一个软件产品的开发是需要很长时间的开发过程的，这个过程也是充满风险的，如果没有有效的把过程细化，只是简单的严格的按照需求、设计、开发、编码、测试的流程去做，问题簿驮毯渲辛恕１匦朊魅返氖敲挥芯猿晒Φ娜砑こ蹋裁挥新阋磺星榭鱿碌木缘目⒐蹋探锥位皇墙缦战档停案馇邢福淮纬圆涣硕啻纬浴Ｕ飧鲈谌砑こ讨械南嘤Φ慕饩龇椒ㄊ抢锍瘫Ｔ诰蠖嗍目⒐讨校锍瘫淖饔檬欠浅Ｖ匾摹Ｔ谟行┛⒐讨薪簿康氖墙ソ降目ⅲ菪降墓蹋涫狄彩嵌岳锍瘫囊恢掷┱苟眩徊还庑┛⒐痰睦锍瘫嵌ㄒ逶谧约旱目⒐讨卸选?lt;/P>
好的开发过程应该是在风险管理上的尽量灵活，我不赞成将里程碑式的阶段管理放入到开发过程中的明细规定中，而是应该在不同的产品或项目开发上灵活掌握。有时一个里程碑可能只是在需求分析阶段的初期，但是如果符合实际的开发的需要，我认为就是好的开发方法。用这种观点观察RUP，我认为RUP中关于里程碑的定义有些刻板，RUP基本上是一个演化式的开发方法，演化的层次很清楚，但是，对于实际的开发中的里程碑定义的灵活性表现的不够充分。当然，任何开发方法不可能满足所有要求，在相对固定的需求的项目上，RUP还是有很大的长处的。在这一点上，我比较偏向于MSF的开发方法。
3、软件工程的左与右
以前学马列的时候学了一个概念，就是左倾与右倾，好像是这样定义的：左倾是指的把将来的事现在做，右倾指的事把过去的事现在做。这两种都是不好的。实事求是的讲，我认为现在的推崇RUP、CMM等有些左倾的味道。从管理的角度来讲，管理有三个阶段：能人管理、制度管理、标准管理。我认为RUP、CMM等属于标准管理的范畴。现阶段很多的公司的能人管理还没有做好，就急于开展标准管理不是正确的方向。首先将能人管理方式进化到制度管理才是当务之急。所谓制度管理就是建立符合公司实际的规章制度，做到人尽其才，在一个游戏规则下做事，这样就可以很大的提高工作效率，更好的沟通开发中的方方面面问题。也只有这样，才能更加深刻的理解标准管理的重要。越过这个阶段，直接跳向更高层次，就象在现阶段实现共产主义的想法一样，有些不切实际。当然，少数公司的制度管理已经很好了，工作效率确实很高了，那就另当别论了。
4、缺少什么样的人才
记得一个笑话说：外国人搞软件工程是在一个黑屋子里面抓黑猫，不过到现在还是没有抓住，而中国人是在一个黑屋子里面，而里面连猫都没有，然后有人说，我已经抓到猫了。这个笑话一方面是说明直到现在，软件工程还是一个在继续探索、发展的过程，另一个侧面也说明中国搞软件工程摸不着边的局面。（以上摘自《我有一个梦》，作者：胡朝晖，详细参见ChinaByte.com）
那么中国最缺少什么样的人才呢？我认为是系统构架师。很多人会说：我们缺少软件工程人员、缺少良好的项目经理、缺少……，是的，这些人我们确实也缺，但最重要的是系统设计师。因为，无论是项目经理、精通软件工程的人员，我们都可以培养，相对的培养成本也不是很高，而系统构架师却需要多年的行业经验和高超的设计水平，这些都不可能短时间内得到。
很多人说，我们的项目大多都是低成本的包工头似的项目，但是大家是否想过，如果，真的有一个项目是让大家去完成很尖深的系统，又有几个公司可以胜任？！为什么很多的Open Source的系统可以做的很大，不是因为这些Open Source有多么的软件工程，只是由于有一些优秀的系统设计师在参与设计而已。软件工程只能使得可以做到的工作做的更好，不能解决连做都做不出来的工作。这也可以说明为什么商业软件中软件工程的重要性，其原因很简单：在大家都能做到的情况下，就要比较谁的作的更好了。软件工程是贴在楼房上的马赛克，有了当然更好，但是如果楼房的结构不好，贴在多的马赛克也可能只是金玉其外、败絮其中。
5、对程序员的正常理解
程序员是要求有创造性的，几乎每个人都是这样想。但在实际的情况下，又有很多人开始谈论如何将程序员当作运转机器的一个齿轮！这是很不对的，是对软件工程的一个曲解！首先，程序员不是打字员，程序员之所以重要，在于他的脑袋而不是他的键盘。程序员又不是设计师，这就不要求他有宏观的观点。程序员是要求对某个方面非常的精通的，哪怕是很小的一部分。系统设计师不可能将设计做到可以编程序的地步，他需要把握的是整体。而相对的，程序员需要把握的是局部。当然，如果任何局部都做的很好，整体不一定好，反之也一样。就想一条船，设计师是舵手，他需要有宏观的能力、需要知道那有险滩、需要辟其风险，而程序员是划手，他需要做到和大家行动一致、需要使用最佳的划船姿势、需要有吃苦耐劳的精神。
不要认为程序员是机器，在他的岗位上一样可以知道船航行的轨迹，要仔细听取他们的建议，因为，有时航行的问题往往都是先被划船的人发现的。
6、讨论的也需一定的标准
有时候会有这样的问题：一帮市场人员与一帮技术人员讨论，为了要解决市场与技术的协调问题，其中市场人员说市场的问题，技术人员说技术的问题，结果往往公说公有理、婆说婆有理。所以，讨论的也需一定的标准！如何定义这个标准在不同的场合和环境下是不尽相同的。技术人员最终需要解决市场上的问题，可是解决的方法并不是简单的服从。如果那样，是不可能做出真正符合市场的产品，因为市场人员看到的只是一定阶段的市场表象，他们并不清除这里面的原因，也不清楚原因的本质。
比如说：比如说现在人们常说的3层结构，往往客户需要让你使用3层结构的思路去解决实际的问题，可是他们并不清除为什么，只是认为很多人都是这样的做的。我不是否定3层结构的优点，只是说，在很多的项目中并不一定要求使用3层结构，因为那会使复杂度增加，而灵活性的掌握又需要很多客户的支持（客户的很明确的说明业务逻辑），同时，真正发挥3层结构的好处，还需要很强的设计师的良好的设计。在很多的小项目中完全没有必要多此一举，把两层的问题3层化。
建立这个讨论的标准就要求，技术人员理解问题的缘由，清楚问题的实质。我说的意思并不是要求技术人员要有很强的市场的眼光，而是需要把这些更深层次的原因及时的说明给市场人员听。
简单的服从市场人员的意志往往是项目可控性失败的直接原因。[本文共有 2 页，当前是第 1 页] <<上一页 下一页>>
您的位置：
