飞漫软件公司十年反思--节选软件工程管理章节

三、软件工程管理

在飞漫软件发展各阶段，我们曾采用过多种软件开发管理模型。

以 MiniGUI 为例。最初，基本上是作坊式的小团队，没有独立的质量保证团队。MiniGUI 1.0 到 2.0 的各个版本，基本上出自本人以及当时公司的另外一个主要创始人Snig。那时，基本上没有什么管理，靠的是兴趣和一腔热情编码。

在飞漫软件开始开发一些 MiniGUI 的外围软件时，比如简易浏览器（mSpider）、PMP 方案（mGallery），很自然地想到引入质量保证团队来协助开发团队保证软件的质量。

时间推移到 2008 年，在我们开发 MiniGUI 3.0、mDolphin 等产品时，飞漫软件内部形成了一套严密的、基于瀑布模型的软件开发管理模型和体系，制定了一系列的软件开发管理规范和工作规范。最多时，围绕 MiniGUI 3.0 开发的人员总人数高达 20 人，其中包括产品管理团队（含产品经理、UI设计师等）、开发团队以及质量保证团队。

直到 2011 年 4 月，笔者从未考虑过我们投入 20 人的团队开发 MiniGUI 3.0，到底是不是值得？暂且不说是否脱离了市场，但在长达一年多的开发过程中，层出不穷的缺陷和不停的小版本演进，到底给飞漫软件以及用户带来了什么？

直到 2011 年上半年，飞漫软件和一家老美公司合作开发一个 ACL 项目时，笔者才发现，我们多年来自然而然坚持的一些软件开发管理方法，其实并不是最佳的方法。该项目试图为不同的操作系统引入一个统一的 Android 兼容层，使得标准的 Linux、Windows 或者 RTOS（如 VxWorks）上，能够运行 Android 应用程序，开发过程采用了 SCRUM 敏捷开发模型。本人花了两天的时间阅读了两本有关 SCRUM 开发模型的书，结果得到一个惊人的结论：传统的软件工程思想，其实是一个大大的骗局！

传统的软件工程思想，以“瀑布法”为典型，按照需求分析、设计（又细分为概要设计、详细设计、单元测试设计、测试用例设计）、编码、测试的过程进行管理，不停迭代，直到缺陷数量降低到零，或者缺陷数量从最初的几百个收敛到几个，才认为是形成了可正式发布的版本。但这个过程极其漫长，MiniGUI 3.0 从第一个可发布版本 3.0.2 发展到基本稳定的 3.0.8，跨度居然长达一年半时间。

为了有效实行瀑布法模型，我们制定了详细的过程管理规范，从需求分析（草案）的编写、概要设计、详细设计、单元测试设计到最后的测试用例开发，每一步都要求形成对应的文档，经过评审后进入下一个单元。比如，软件架构师负责分析需求并进行概要设计，高级工程师来编写详细设计文档，经软件架构师审定后进入下一个环节，等等。看起来，一切都那么完美，只要每个人都按照要求和流程来做事，没有达不到的目标。但现在想来，这其中存在如下一些深层次的问题：

* 文档流于形式。一方面是因为开发人员本身对文档工作存有天然的抵触情绪，另一方面，开发人员并没有受到过如何撰写开发文档的培训。自然而言，文档描述不清、不及时更新等问题就出现了，最后，文档基本上就会流于形式。通常的结果是，需求文档或者概要设计文档写得很好，但详细设计文档、单元测试文档等等，越往后越差。

* 没有人仔细阅读文档。大部分开发者其实不会仔细阅读文档，他会根据自己对需求的理解进行编码，即使详细设计文档就是他自己编写的，他仍然会给你敲出一份偏离详细设计的代码。

* 瀑布开发模型，忽视了软件质量的第一保证人是开发者本人这一要求，使得开发人员非常依赖于测试人员，测试人员又抱怨开发者编写的软件充满了缺陷。最后，使得整个开发过程充斥着责任不清和相互的埋怨，大大降低了开发效率，质量也很难得到保证。

然而，如果我们仔细回想 MiniGUI 早期版本的情况，我们会发现，那时，没有专职的质量保证团队或者测试人员，就两三个开发人员，软件的质量仍然相当好。再比如，Linux 内核的开发过程显然也没有采纳瀑布模型，但为什么仍然取得了那么伟大的成果？

如果你仔细想想这其中的奥秘，你就会发现，传统的软件工程思想，是模仿传统工程管理方法，比如建筑工程的管理方法设计出来的。瀑布模型，有其可适用之处，但并不是万能药。在任何一个软件开发中，期望通过传统软件工程方法来进行管理并取得良好效果，基本上属于一厢情愿。

为什么笔者认为传统软件工程思想是一个骗局呢？其一，宣传传统的软件工程方法，为那些靠 CMM 等软件管理标准或者规范吃饭的人给了一个可以赚钱的机会；其二，利用传统的软件工程方法，为那些贩卖项目管理软件的公司一个可以赚大钱的机会；其三，传统的软件工程方法，创造了更多的就业岗位。

自从笔者接触了 SCRUM 开发模型后，我发现它和传统软件工程方法最大的不一样，就是：前者围绕软件本身进行管理，后者围绕流程进行管理。SCRUM 开发模型强调 3C，即 Card（卡片）、Confirmation（确认或承诺）和 Communication（沟通或交流）。该方法去除了一切形式化的东西，比如复杂的文档和流程，让开发过程关注到最终可以交付的软件及其功能的演进上。而且，采纳 SCRUM 开发模型时，它的管理手段非常简单，任何有基本管理素养的人，只要遵照其基本原则和方法，都能做好相应的管理工作。

然而，SCRUM 开发模型的执行过程非常容易走样。很多人仍然喜欢使用电子化的方式来管理项目，比如使用 ScrumWorks 这样的软件，但这其实违背了 3C 原则中的 Card 和 Communication 这两项；很多人非要按照一周、两周或者一个月来划定一个冲刺的目标而不是按照冲刺工作集来确定发布时间；甚至一些管理人员，连燃尽图都懒得画。

这导出了本文的第四个主题。

四、中国软件工程师的特点

先告诉大家我的结论：中国的软件工程师，大致有一半或者更多是不应该从事这个行业的，他们做事随意，缺乏自律和学习精神，也缺乏必要的工程素养。

我们先看看中国软件工程师的来源。

中国几所顶级大学计算机相关专业的毕业生，大多选择了出国或者进入外企、知名国企工作（也有部分进入金融、投资等领域，少数选择创业或者加盟创业团队）。谷歌、百度、腾讯等大型互联网企业以及华为、中兴等大型通信企业，吸纳了这些顶级大学计算机相关专业中优秀的毕业生。但这些毕业生显然是少数，大多数从事软件开发的人员，毕业自二三流大学。

以笔者曾经面试过的应聘者以及很多共事过的软件开发人员为例，笔者得出了上述结论：

* 教育方面的问题众人皆知，笔者不再赘述。许多来自二三流大学的毕业生来应聘我们公司的职位，甚至还有一些有过专业的职业培训经历，然而，我看不到任何可以录取他们的理由。在我看来，大多数人是因为就业压力大，找不到适合自己的职位，才选择薪水水平相对较高的软件开发职位作为自己踏入社会的第一步。有些人为了加大成功就业的概率，自己掏钱做职业培训，之后再找工作。但问题是，大学里边基本上什么也没学到，怎可能靠几个月的培训就能达到用人单位的要求？

* 很多软件开发者不明白为什么要有一致的编码风格（coding style）。写出来的代码行文混乱，毫无美感而言。其实，字如其人，敲不出漂亮代码的开发者，也写不出符合要求的文档，而且代码必定错误百出。这些开发者，显然没有经过良好的工程素质训练，缺乏必要的工程素养。

* 我们公司从 2005 年起利用 Wiki 系统管理内部文档。我发现，许多开发者连基本的 Wiki 标记语言都不能快速掌握。许多情况，照猫画虎就可以的，还会弄得乱七八糟。就一个命名规则，很多人都无法理解命名规则到底有什么意义，非要取“概要设计”这样的主题名称。怎么就不能想想，下个项目的概要设计，难道你也用这个名称？在我看来，这些开发者其实不应该进入这个行业，因为他缺乏必要的计算机科学、软件工程敏感性，他的头脑其实根本不适合做软件开发。

* 如上一章节所说（SCRUM 开发模型的执行容易走样），包括一些管理者在内，许多软件开发者并不是合格的管理者或者被管理者。他们做事随意，不讲规则，缺乏自律。当然，这主要的原因来自管理者自身，大多数普通的开发者需要一定的管理约束和鞭策，当管理者自身随意、不讲规则，缺乏自律，那整个团队也会这样。这和大多数管理者出身自技术人员有关。

尽管笔者得出上述结论来自于笔者接触过的软件开发者，但相信这些问题也存在于很多企业当中。华为、中兴等大型企业的管理策略，基本上靠流程和人海战术，导致组织越来越庞大，效率越来越低下。这些企业因为已经具备了一定的市场地位，组织的臃肿和庞大并不会带来致命的后果。但如飞漫软件这样的小型企业或者创业团队，如果模仿华为、中兴等大企业的做法，必定要承受昂贵的代价。请各位看官切记！

五、外聘 CEO 之殇

2007 年，飞漫软件吸纳外资从内资企业变更为合资企业。根据外方董事的建议，公司用高薪聘请了一位来自台湾的H姓女性作为合资公司的 CEO，本人改任 CTO。

新聘 CEO 曾有过海外工作经验，主要工作经验是销售管理，来飞漫软件工作，算是第一次担任 CEO。H CEO 显然对第一次担任 CEO 表示出了极大的热情，问我在大陆，她名片上的职位，到底应该是“执行长”呢还是“首席行政长”还是其他的什么名称。我说，就是“首席执行官”，要么就写 CEO，大家都明白。最后，那名片上还是写了个“执行长”——也许“执行长”这个抬头，更加有气势？

H CEO 上任伊始就对公司进行了大刀阔斧的改革，比如，培养人事经理成为项目经理，以高薪吸纳她之前的台湾下属作为海外销售经理等等。同时，H CEO 也积极行动，发挥她的销售专长，去上海、深圳、台湾等地方拜访客户，寻找可能的销售机会。当然，每次出行必然是住四星级以上酒店。在北京，也住的是包月酒店，每月一万的房租。

然而，在其工作三个月之后（2008年元月），公司突然出现了一个离职潮，大量员工提出离职申请。显然，这位 CEO 并不适合飞漫软件这样的小企业。本人不得不提请董事会解雇职这位 CEO。但我们为此付出了极大的代价——成立合资公司引入的资金之一半基本上赔偿给了这位 CEO。这也是 2008 年，除了金融危机的影响之外，飞漫软件不得不裁员的一个另外一个主要原因。

这位 CEO 在被解雇后，在香港注册了一家皮包公司，从我公司采购了一套 MiniGUI，然后改头换面开始当做自己的产品进行销售。当然，笔者根本不在意这点，因为离了飞漫软件，MiniGUI 就是无源之水，你想复制飞漫的业务，那基本上不可能。

这里有个类似的插曲。2009 年的时候，2005 年期间代理 MiniGUI 的一家韩国公司，突然联系我，说我们公司有个前员工弄了个什么软件，想找他代理，还把其技术白皮书发给我了。但其实呢，就是他自己找这个前员工弄的，事情没弄成，反过来到我这里告状——蛮有意思的。

外聘 CEO 这件事情，在外方董事推荐之时，我内心其实不是非常赞同的，但我没有听从自己内心的声音，而选择了盲目的信任。

我记得在确定 OFFER 之前，曾邀请这位女士到我公司，作为双方互相考察之用。我开车去了机场接这位女士。见面之时，我注意到了两个细节：

* 这位女士脚穿凉鞋，同时还穿着一双袜子。
* 这位女士在见到我们举着写有她名字的牌子时，眼神掠过一抹非常难以察觉的轻蔑之神情。

之后我和当时的销售总监邀请她吃饭，送她去酒店住下，然后我就扁桃体发炎，高烧到了 39 度（我自打记事起，还没有如此发过烧）。之后的两天，打吊针输液，昏昏沉沉就过去了。出于对外方董事的信任，这考察也就草草走过场，然后就给了这位女士一个按照国际标准执行的 CEO OFFER。

显然，老天爷提醒了我，但我没有听从自己内心的声音，导致这惨痛的教训。各位看官，也请吸取我的教训，一定要按照乔布斯所说，听从自己内心的声音。当然，你面临的问题，也许是根本不知道自己的内心到底发出了什么样的声音，呵呵。

六、最大的经营失误

飞漫软件的过去十年，经历了很多事情。现在回过头来看，最大的经营失误是盲目开发新的软件产品，为此浪费了很多现金。

除了 MiniGUI 之外，飞漫软件曾经开发过很多东西，比如 mEagle、mSpider、mGallery、mDolphin、mStudio，包括后来的 HybridOS 等等。

在这些软件产品当中，给我们带来收入最多的自然是 MiniGUI，除此之外就是 mDolphin。其他的软件，现在看来，根本没有必要开发，因为这些软件脱离了市场需求，自然不会有客户买账。要是不开发这些软件，飞漫软件基本上可以以一个不超过 30 人的规模高效运行，按开发人员计算，人均年收入达到 40 万到 50 万是没有任何问题的。

然而，这些都是马后炮。写出来，是为了给各位看官一些启迪，希望对创业者、中小软件企业的管理者有所启发。

七、通过合作看华为

这里主要讲讲华为这个公司。

我之所以直接提这个公司的名字，是因为我希望这个公司能够有所变革，成为一家像苹果、谷歌等真正伟大的公司。

华为技术在 2004 年的时候以买断形式采购了 MiniGUI 软件，飞漫软件由此获得了在当时可以在北京四环外购买一套小两居住房的现金收入。

2009 年时，华为终端使用 MiniGUI 开发数码相框类的产品，遇到了一些技术问题，找我们公司帮忙。起初我们不同意他们的出价，他们的领导不停给我电话，说了很多好话，说和华为合作机会很多，这次少点，下次多点云云。最后五万块钱的服务费，我同意帮了。我安排了公司最资深的 MiniGUI 专家前去服务，前后两周时间，纯粹就是帮他们个忙。这样的事情很多，华为的人，总是以业界大拿的做派找我们这样的专业小公司，帮这个忙帮那个忙。去年底，海思还找我们帮他们解决浏览器上 Flash 插件的问题，我们帮了。领导说跟华为搞好关系，以后有大大的机会赚钱云云。结果呢，我们从华为系统的企业赚到的钱并没有多少。我现在已经死了从华为再赚钱的心了，所以我爆料给各位看官。

前文已经提到，华为终端采用 MiniGUI 开发的终端产品接近或超过一亿台。

各位看官，你们大概不知道华为技术和华为终端是两个独立的法人企业吧？我也是之后才知道的。也就是说，华为终端使用来自飞漫软件许可给华为技术的 MiniGUI 产品，是未经许可的。我们提出这个问题后，经过了长达半年的唇枪舌战，华为终端不得不在去年上半年补上了 MiniGUI 的许可费。当然，以华为一贯的作风，这个钱没有太多。

华为技术、华为终端也好，这个企业骨子里有股不好的基因，那就是喜欢压榨供应商，对供应商抠门的不行。我的结论是，华为当前充其量就是个“独善其身”阶段，还达不到苹果那样可以创建一个生态系统，从而“兼济天下”的水平！

华为，你未来的路还很长。

八、一些小的教训

作为结尾，我给大家罗列一些十年里边遇到的小的教训，希望各位看官防备：

* 你永远会遇到一些小人，试图以不道德的方式获取利益。比如本文提到的韩国代理，H姓CEO。这种情况下，不用理会，事实证明小人成不了大事。如果你花更多的精力和他们较真，你将失去更多。

* 本文提到的 ACL 项目，那美国的公司欠了我们将近 2.5 万美金不付（这公司是个初创公司，没有足够的现金做这个项目，加之 ACL 项目本身前景不妙，他们希望卖给 Intel 在 MeeGo 上用，希望卖给 HP 在 WebOS 上用，但 2011 年上半年，大家都知道，这两个项目终止了，这公司根本没法获得进一步投资）。所以，并不是所有老外公司（就算是老美公司）都那么遵守规则和具有商业道德，你要做的就是，尽量在前期收到足够多的钱，且不要盲目相信他们。

敬以此文纪念飞漫软件过去的十年。

飞漫软件公司十年反思--节选软件工程管理章节相关推荐

软件公司多注重开发不注重管理
为什么80%的码农都做不了架构师?>>> 许多软件公司,多数是不注重管理的,虽然有管理岗,但还是不重视,管理人员缺乏. 在他们眼里,开发是主要生产力,管理可以省一些. 多数软件 ...
飞漫魏总的：回首十年路，一把辛酸泪-------飞漫软件十年回顾
(引用)评:对于外聘CEO及与华为打交道,这个实际的经验是书本上学不来的. ===================================================== 回首十年路,一把 ...
飞漫软件十年回顾-MiniGUI 及飞漫软件创始人
飞漫软件十年回顾 2012年04月06日 19:26 北京飞漫软件技术有限公司(飞漫软件)成立于2002年,今年是第十个年头了.飞漫软件的十年,浓缩了嵌入式软件技术在中国的发展历程.本文将回顾飞漫软件 ...
数字化转型对接活动促进深度融合，飞讯软件受邀共探新机遇
由惠州市工业互联网产业联盟主办的惠城区工业企业数字化转型对接活动于5月24日举行,旨在推动数字经济与实体经济的深度融合创新应用,助力惠城经济高质量发展.活动邀请了区科工信局数字化转型分管领导及股室相关 ...
印度软件和中国软件工程师_印度的软件公司类型
印度软件和中国软件工程师 The demand of software is all time increasing that has been quite instrumental in a vas ...
PMP 考点第十二章项目采购管理
PMP 第十二章项目采购管理章节序号知识点考点级别备注第十二章项目采购管理 12.1 采购活动的职责和典型步骤.供方选择分析.采购管理计划.采购策略 3 12.2 合同类型.采购文件. ...
看国内十大EDA软件公司排行榜，总人数不到全球EDA研发总数的1/100，怎样突破困境？
芯片是中国科技行业目前最被卡脖子的一个环节,而EDA是芯片设计的必备工具,国际上主要被Synopsys.Cadence和Mentor Graphics占据着95%的市场,高端复杂的芯片设计更是依赖这三 ...
2023年中国十大软件公司排行榜 2023国内软件公司排名前十强
2023年中国十大软件公司排行榜 2023国内软件公司排名前十强 (1)华盛恒辉软件开发有限公司,专注于高端软件定制开发服务和高端建设的服务机构,致力于为企业提供全面.系统的开发制作方案.在开发.建设 ...
亚太地区最佳十大软件公司排名公布
G2.com(前身为G2 Crowd)发布了其首份亚太地区最佳软件公司(Best Software Companies in Asia Pacific)排名.该排名标志着G2在新加坡成立新办事处,考虑 ...

飞漫软件公司十年反思--节选软件工程管理章节

飞漫软件公司十年反思--节选软件工程管理章节相关推荐

最新文章

热门文章