在《C++头文件风波》中提到我所在的team使用C++开发时遇到遇到的一些管理上的问题。对于软件开发项目来说，评价项目是否成功的因素恐怕最关键的就是

　　·是否能按期完成

　　·是否能够保证质量

　　按期完成的事情就不要提了，到目前为止我还没有看到过能够按期交付的项目。原因很多也很复杂，大概有人读过《人月神话 》的焦油坑那节就知道怎么回事，连精英汇聚的IBM 360系统开发都能出这么多的问题，就不要指望我们这些平庸之辈组成的团队还能能够创造什么奇迹。这个观点也许有点消极，但是事实的确是这样的。虽然很多人在想办法解决软件开发中的各种各样的问题，但结果却仍然不那么理想。

　　软件质量不能得到保证也是问题。软件质量衡量的标准有很多，你可以从不同的侧面说出来一个优秀的软件项目所能创造的价值，比如，健壮性，弹性，可移植性等等。问题是，很少有人或者团队在项目开发的时候能保证取得他们想要的所有质量特性。“先把事情作出来，然后在把它作好”，也许这也是个说辞。但现实情况是，如果没有良好的迭代流程，几乎在每一次版本变更或者移植的时候都会将上个版本完全抛弃。这就是我们遇到的问题。此外，第一个版本似乎永远是要被扔掉的——这句话也是《人月神话》来的。扔掉某个软件版本并不是很可怕的事情——比如用脚本语言开发的用来引发讨论和idea的原型，可怕的是，有的项目展开了都有一段历史了，版本变更的时候源代码还在剧烈震荡。你找不到清晰的版本线，你拿捏不了这玩意儿为啥要这么做。我遇到的一个比较极端的例子是一款浏览器的开发，main函数所在的那个文件有6000多行!!!而且这玩意儿是用C++写的，虽然按照《Code complete》的说法，C++代码比较verbose(如果c语言是1，那么C++的代码量是2.5左右)，但也不至于到这种地步。很显然，这个浏览器在最开始的时候就没有经过良好的设计。有人把GUI的处理，HTTP通讯，业务逻辑等等混杂一气写到了同一个文件当中。于是造成的结果是，在开发下一个版本的时候，总是有大量的代码要被重写，6000行的源文件，几乎是全部被抛弃。日本人有保守谨慎的做事风格，因为他们认为上一个版本是能够使用的，所以，下一个版本应该仿照上一个版本来写。于是继续制造一堆根部不可读平且继续会被在下一个版本中抛弃的代码。就是再也样。代码重用如果有问题，恐怕想做到敏捷开发也是不可能。比如，新版本变更中仅仅影响到了图形界面——这是最常见的情况，例如从Graphic Toolkit从gtk换到Enlightenment，或者再从Enlightenment换到miniGUI上，如果在第一个版本中就搭建了一个良好的结构的话——Bridge Patten 是一个解决方法——以后的版本之需要按照简单的体替换规则做些改动就可以了。这是一种理想状况。我想说的是为什么在现实中无人关心这件事情。

　　每次新项目开始，总会有很多部门的不同人员加入进来，关键是每次新项目的项目经理都在换!这个项目的项目经理不需要对下一个版本负责，他关注的只是现在，当下。他需要的是只要能把自己的task完成，至于以后怎么办，“那不是我的事情”。

　　优秀的软件开发人员实在太少，即使能够找到，也会因为论资排辈的“科层”制度被埋没。我一直认为在研发上构造职权的层次结构是非常SB的行为。但是，往往会发生屁股指挥大脑的行为 。最狠毒的老板恐怕是下面这种人。 项目管理者联盟文章

　　[This] reminds me of a true “Dilbert moment” a few years ago, when my training.mypm.net

　　(obviously non-technical) boss commented that he never understood why it took months to develop software. “After all”, he said, “it’s just typing.”

　　——来自Coding Horror 。

　　被公司放出去的项目经常难于管理。曾有Moto的VP大声疾呼，一定要把发放到亚洲地区的设计和软件开发工程收回才能拯救Moto的手机部门——虽然他们已经这么做了，但是很显然最终还是臣服于Google的Android平台。以我接触的项目为例，公司采用外派人员来参加项目开发，这样作的好处是不需要养那么多人而在长期来看是降低了人力成本，但弊端却是数不胜数!因为契约的关系，外派人员通常是按照计时或者计件收取费用的，所以，他们在项目之中呆的时间越长或者生产的代码量越大，他们获得的薪水就会比较高。很显然，这个利益获得方式与项目的进展不在同一条道路上。项目延期，代码重写对这些开发人员来说是“利好消息”。如果原动力都不一致，怎么能保证一个团队齐心协力的工作?

　　人员替换和流逝过于快速。而恰恰因为传统的公司风格——以“管理人”为管理的核心，而不是把“管理知识”作为管理核心来看待——导致了人力资源流失直接造成产品研发能力的流失。代码，文档等内容管理被放在一个很不起眼的地位上，这些事情被认为只是辅助工具，而不是管理核心和作业对象，一遇到问题你得到的答案不是“参照XXX文档/标准”，而是“去问一下XXX大侠”。其结果是，人走了，软件版本会跟着出现断层。我一直认为对一家软件开发团队而言，最重要的财富就是良好的文档和优秀的代码，如果舍本逐末的只把着眼点放在最后产出上，那将又是一个只要葫芦不要藤的故事。

　　设计理念和方法在团队中不能取得一致。大学的时候学过一门课程叫《系统分析与设计 》，我至今觉得这门课是我大学学习的最重要的课程之一。比较丢人的事情是，第一次考试我竟然把它挂掉了，挂课原因不明，呵呵。这本书中提供了(至少)两套系统分析和设计的方法——虽然不够完善，这个先按下不谈——随便按部就班的坚持一套作下来都会对你要完成的事情有比较清晰正确的认识。但问题是，这样的方法论在一个团队之间不是所有人都了解和认同的。往往设计方法的讨论结果是虽然作软件架构的人声明这个应该那样那样，虽然开发人员也只能按照那个方法去做了，但却不能完全理解他的理念，造成很多偏差和错误。所以我有时候想，是不是与大学同班同学开一家公司会比较强大，哈哈哈。《系统分析与设计》这本书虽然阐述了一套普遍的方法论，但遗留问题是，它只能作出对现事世界的直接描述，而这种直接描述只能适应现在的情况，而不适用于变化不定的未来。分析模型和设计模型之间存在一定的距离，而这个真空地带只能依靠工程师的经验后者新的方法论来填补，到目前为止我觉得比较有指导意义的一本书是《设计模式 》，具体的算法实现以及更加深入一点的实现部分最好的教本恐怕是Knuth大侠的《The art of computer programming 》，当然这个又是方法论的话题，扯远了。

　　上面所说的这些原因，恐怕只是冰山一角。但以管窥豹可见一斑，那就是很多问题并不是单纯的技术问题，往往这些问题是人员，技术，管理，商业契约甚至是公司文化的综合问题。头疼医头，脚疼医脚是于事无补的，却往往把问题掩盖让情况变得更加扑朔迷离。要搞清楚这些事恐怕还只能踏踏实实的继续观察思考和实践。