目前国内的软件方面的人才开始大量的关注软件工程这门学科，大有80年代末90年代初国人追捧汉字系统的劲头，但是实事求是的理解国内的开发过程，我认为软件工程固然是一个方面（甚至可能是非常重要的一面），但隐藏在表象后的问题也是不容忽视的，我认为目前开发环节中存在着一些问题或理解的偏差，其中典型的表现在：
1、 学而优则士
这个问题很普遍，很多人都是这样想：开发到35岁以后就应该考虑管理的问题了。这个想法是“学而优则士”的想法，好的开发人员，不一定是好的管理人员，因为侧重的面不一样，知识结构也不一样。但是，由于很传统的思想，认为领导就是应该各方面都好些，所以强把“学”推为“士”。这样不但没有更好的提高效率，反而浪费了很好的人才。同时，也是由于传统的思想，“士”更受人尊敬，而“学”往往被认为是蓝领，所以很多的“学而优”者也就有成为“士”的激励诱因了。我认为，这是一个不正常的现象。“学而优”的地位及受人尊敬应该有相应的评判机制，比如说：系统设计师应该比项目经理更加受人尊敬。也只有这样，“学”者才可以安心设计，“士”者也可以更好发挥“士”的职能。
2、过程与阶段
只有过程没有阶段是没有意义的，我们都知道，任何一个软件产品的开发是需要很长时间的开发过程的，这个过程也是充满风险的，如果没有有效的把过程细化，只是简单的严格的按照需求、设计、开发、编码、测试的流程去做，问题也就蕴含其中了。必须明确的是没有绝对成功的软件工程，也没有满足一切情况下的绝对的开发过程，将过程阶段化只是将风险降低，将蛋糕切细，一次吃不了多次吃。这个在软件工程中的相应的解决方法是里程碑。在绝大多数的开发过程中，里程碑的作用是非常重要的。在有些开发过程中讲究的是渐进式的开发，螺旋式的过程，其实也是对里程碑的一种扩展而已，只不过这些开发过程的里程碑是定义在自己的开发过程中而已。
好的开发过程应该是在风险管理上的尽量灵活，我不赞成将里程碑式的阶段管理放入到开发过程中的明细规定中，而是应该在不同的产品或项目开发上灵活掌握。有时一个里程碑可能只是在需求分析阶段的初期，但是如果符合实际的开发的需要，我认为就是好的开发方法。用这种观点观察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层化。
建立这个讨论的标准就要求，技术人员理解问题的缘由，清楚问题的实质。我说的意思并不是要求技术人员要有很强的市场的眼光，而是需要把这些更深层次的原因及时的说明给市场人员听。
简单的服从市场人员的意志往往是项目可控性失败的直接原因。
7、片面的理解管理学；
现在有一股势头认为，软件工程中的管理者只要拿个手册照搬执行，肯定10有8、9不会有大的问题。但是问题真是这样吗？在《软件工程—实践者的研究方法》中有这样一段关于管理者的神话：
神话：我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有其需要知道的信息吗？
事实：不错关于标准的书籍已经存在，但真正用到了它们吗？……它们完整吗？很多情况下，对于这些问题的答案均是“不”。（P.11）
我们必须明确管理的责任、实质与优劣。优秀的管理是无为管理，管理的目标就是不管理。不管的前提是有一套符合实际的游戏规则，大家按照游戏规则做游戏。有些人理解管理就是天天跟到被管理者的后面，不定的催促、不停的调度。这是不对的，这样的管理者是妨碍了正常的工作，是对管理的曲解。
所以说，优秀管理的前提是建立一套大家都能遵守的有效的游戏规则，在此规则下，达到高效工作的目的。
那种认为管理就是找人谈话、挑人问题、催促进度的理解是错误的，如果，真的遇到了这样的问题，我认为那确实是需要重新审视一下自己定义的规则的时候了。
8、您有一个持续发展的框架吗？
明知不可为而为之的后果是怎样的呢？可能是这样的：项目进度太紧、产品问题很多、每天陷入到工期的泥潭之中……。很多人说项目太紧是市场的时间给的太紧、是项目计划不严密、是软件工程不到位等等，但是，回头想想，如果真的做到了：市场的时间给的充分、项目计划严密、软件工程符合实际，那么，您有把握完成一个符合用户实际需要的、优秀的、低维护的项目吗？我认为，还不行。
可能很多人不会反对，如果客户的要求是让我们做一些Word、PowerPoint的模板（无需编写很多的代码），我们可以很容易的满足客户的需求。但是，如果客户让我们做一些关于MIS、POS、甚或是如教育、政务等软件，我们的成功的把握度就大大降低了。为什么呢？如果，我们做其他类的软件如同做Word的模板一样容易的话，我们还会没有把握吗？我们缺什么呢？我们在做这些软件的时候为什么就有些信心不足呢？
问题的症结在于：您是否有一个持续发展的框架。您如果有一个基本满足用户需要的semi-application的话，您将不会遇到那些问题。
如果您在实际工作中屡战屡败又屡败屡战的时候，您会不会问自己这样一个问题：您有一个持续发展的框架吗？
9、对过程范型的误解；
任何过程范型都有它的优点和缺点。我们不能否定瀑布模型的优点也不能否认其缺点，我们不能否定演进模型的优点同时也不能否认其缺点，其他范型也一样。很多人推崇RUP、XP等过程范型，但是前提是我们必须知道这样的模型是演进模型，有很多的优点，同时也不可避免的有其缺点的存在。
比如说：我们需要做一个需求很明确，并且在一段时间内需求不易改变的项目的时候，如：一个数据结构类库、一个通讯底层库等，这时候，使用瀑布模型可能会得到更好的效果。为什么呢？首先，演化模型的任何一次跌代的终点就是下一次跌代的起点，这样有助于用户更好的把握系统，可以更好的理解需求，但这种模型并不适合需求非常清晰的情况，如果需求非常清晰，这种跌代只能更多的产生冗余的文档，更可能产生很多过渡的设计，而这些显然是一种浪费。有些人，干脆就把演进模型当作瀑布模型来使用，讲究的是一步到位，这种做法就更有问题了！
如果需要一步到位的系统（即需求非常明确，同时需求很少改变），演化就变成了瀑布，这时候提倡演化无非就是多走了几个弯路而已。
正确的理解过程范型是正确的使用过程范型的前提。
10、对测试工作的误解；
我们应该重视测试工作，但是，过度的重视测试又会产生严重的问题。测试工作最重要的是要发现问题，是保证提交给客户的软件中不再出现问题，从这个观点说，测试很重要，但是，我们不能因为测试而测试，很多问题不是能够通过测试而解决的。
发现问题的时候解决是对的，正如亡羊补牢，未为晚已。但是对于问题的源头我们需要更加的重视。我们更加需要重视对于需求分析的审核、对于设计的复审、对于代码的复审。将问题消灭在摇篮中，总比与问题搏斗来的容易。
对软件的测试固然重要（无论是单元测试还是系统测试），但这种只对产生了问题征兆的测试是一种狭义的测试。我们决不能忽略对需求分析的测试（需求复审）、对设计的测试（设计评测），这样的种种测试的综合，才是软件工程中对测试的广义理解。
如果，您发现在工作中测试的环节上发现了太多的问题，您就是真正应该考虑在其他环节上“测试”是否出了问题的时候了。有时候，羊亡的太多，补牢也就晚了。
测试在软件工程中是一个狭义的概念，但是我们应该努力广义的去理解。
11、对文档作用的错误理解；
文档在开发过程中是很有用的，但文档泛滥就不好了。有些人说，开发过程中文档越多越好，我认为这种观点是不对的。首先我们要明确开发过程中为什么要写文档，文档的最根本的作用是为了沟通！一个项目或产品可能需要延续很长的时间，开发过程中可能需要很多的环节，可能会遇到很多的问题和很多的解决的方法，这时，我们需要文档的帮助，我们需要有一个记录，我们需要有一个共同的声音。文档不过是一个准绳，将开发中的各个树枝树叶扶正。如果，这个准绳太多太紧，大树可能会发育的很高很直，但是就是有些畸形，如果这个准绳太少太松，大树可能就会变成灌木丛。文档的多少、繁简是有度的，绝对不能说越多越好。
那么这个度是多少最好呢？我觉得有几个标准：1、文档需要说明解决问题的方法而不是解决问题的理论；因为解决问题的理论是在文档形成中做到的。2、文档完整即可，每一份文档说明一个问题，无需将多个文档的内容放在一个文档的里面；3、除了重要阶段形成文档，其它部分都只是讨论或者说是想法（这些通过其它工具可以有效的管理起来）；4、不要让文档成为累赘，如果真是这样，我认为就是该考虑写作这些文档的必要性的时候了。
我们在文档的时候，一定要明白为什么要写这些（无论是为了现在还是为了将来）。
12、仔细审视神话！
在实际的软件工程的实施过程中，我们往往会遇到很多的神话，“软件神话具有一些特征使得它具有欺骗性……软件神话仍被不少人相信着”（参见《软件工程—实践者的研究方法》P.10），如果，我们使用审视的眼光，而不是盲听盲信的话，我们就有可能发现其中更多的玄妙了。
希望和大家共同努力，仔细审视软件工程中存在的神话！
