魏永明:从MiniGUI看嵌入式十年收获与失去

 北京飞漫 软件技术有限公司（飞漫软件）成立于2002年，今年是第十个年头了。飞漫软
件的十年，浓缩了嵌入式软件技术在中国的发展历程。本文将回顾飞漫软件的十年历程。回
味过去，或许能给我们的未来发展一些启迪。

       一、十年回顾

       笔者创办飞漫软件的2002年，正是嵌入式软件技术在全球开始得到关注的一年。在此之
前，2000年开始，才有嵌入式（embedded）这个领域被专业人士提及。笔者供职过的深圳（
蓝点）有限公司，是国内最早专注于嵌入式软件技术的公司。然而，蓝点因为2000年的
.com泡沫而关张大吉，未能坚持到嵌入式软件开始创造市场价值的那一刻。

       此后，笔者供职于北京中科红旗软件技术有限公司的嵌入式事业部。当时，该事业部认
准了实时工控领域，计划开发一款名为ControlLinux的嵌入式实时操作系统。当时，该产品
的规划非常宏伟，从内核、基础库到开发工具均有涉及。然而，因为缺乏基本的市场认知以
及研发团队能力的不足，该产品无疾而终，该事业部也在笔者离开之后合并到了其他事业部
。当然，中科红旗在过后多年，又重新设立了嵌入式事业部——这是后话。

       笔者离开中科红旗之后，即筹备创建了飞漫软件。起初，并没有明确的思路来如何经营
这个公司。但开源MiniGUI的一些用户给了飞漫软件起步的机会，飞漫软件通过定制
MiniGUI或者开发一些基于Linux和MiniGUI的外包项目开始创造收入。飞漫软件也逐步壮大
，到2003年，有了十人左右的团队，并实现了微薄的盈利。

       2004年，《MiniGUI及其配套开发工具》项目入选科技部中小企业创新基金，并获得了
国家和地方政府超过百万元的无偿资助。另外，华为技术也在2004年采购了MiniGUI，从而
获得了一笔不小的收入。这两笔资金，足够让飞漫软件继续发展MiniGUI，并将MiniGUI打造
成了一个颇有知名度的嵌入式图形中间件产品。公司也随之进一步发展壮大。2005年初，和
大唐移动签署的TD手机合作项目，为飞漫软件转向手机行业起到了举足轻重的作用。

       2005、2006年，飞漫软件基本上保持了30%的年增长率，积攒了大量的用户基础，也基
本确立了以销售软件使用许可（license）为主的业务模式。

       2007年，飞漫软件获得了一笔外来投资，因扩大研发团队而首次出现亏损。2008年，金
融危机的出现，给飞漫软件的发展雪上加霜，不得不通过裁员来获得生存的机会。2009年，
飞漫软件开始获得联芯（大唐移动）支付的TD手机使用MiniGUI的提成费，从而扭亏为盈；
2010年，飞漫软件继续保持了良好的增长势头，开发了mDolphin等浏览器软件，并保持盈利
。

       然而，2011年起，Android系统的飞速普及，为飞漫软件的发展带来了非常大的不确定
性。之前，飞漫软件的主要收入来源于MiniGUI等产品在功能手机上的许可费以及军工、工
业控制等行业客户的许可费。从2011年下半年起，因为Android的普及以及冲击，大量的功
能手机厂商及芯片厂商缩减了在功能手机上的技术投入，飞漫软件的收入也急转直下。在飞
漫软件成立九年之际，飞漫软件面临着成立以来的最大的危机。

       面对此市场大势，在一些核心员工的倡导下，飞漫软件从2011年6月起，开始迈向了向
移动互联网业务转型的步伐。在2011年10月之后，陆续发布了面向Android平台的领航桌面
、领航浏览器等产品。尤其是领航桌面产品，在上线三个月，即达到了100万激活量的骄人
战绩，在国内工具类软件中，各项指标排名前5%。这一来自市场的积极反馈，增强了笔者及
团队的信心，飞漫软件转型移动互联网的目标更加坚定。

       2012年，飞漫软件除了服务于联芯、RDA等手机芯片厂商、军工客户等重点客户获得
MiniGUI及其相关软件的技术许可费之外，在移动互联网新业务上将近千万元的投入，将从
下半年起带来可观的收入。对此，作为创始人，笔者坚信这一天将在不久的将来来到。

       二、成功的十年、失败的十年

       通过简单回顾飞漫软件的十年，我们能够明显感觉到，飞漫软件创立于嵌入式软件行业
萌芽之时，转型于智能手机崛起之时（也就是所谓后PC时代的到来）。飞漫软件走过的十年
历程，基本浓缩了中国嵌入式软件行业发展的十年。

       笔者之所以说这是成功的十年，是因为飞漫软件打造了一个成功的系统级软件，在中国
嵌入式软件技术发展的历程中留下了或浓或淡的一笔。使用MiniGUI的各类嵌入式设备，不
完全统计至少有两亿部。仅华为终端使用MiniGUI开发的数码相框类产品，就接近或超过一
亿部出货。另外，功能手机方面，总出货量已接近一亿部，而且该数字在未来的几年内，还
将保持一定的增长。

       然而，因为对国内各行业对软件价值的鄙视，飞漫软件并不能获得和MiniGUI这个产品
的市场地位相匹配的收入。当然，笔者说是失败的十年，并不仅仅是这个原因，而是因为我
们国家的IT行业，在后PC时代萌芽的十年窗口期中，并没有任何一家企业可以抓住这个机遇
，成为苹果、谷歌这样可以在后PC时代创造新的生态系统的伟大公司！想想看，在新千年之
初，嵌入式软件技术刚刚得到全球关注之时，我们就有MiniGUI这样的开源软件，并具有相
当的国际知名度，但为什么没有一家企业可以基于这样的软件以及其他的开源软件（如
Linux、Java、WebKit等），将其打造成一个类似Android或者iOS这样的系统呢？显然，这
样的任务不是一个仅有不多投资的民营企业可以完成的，而是那些手握重金的大佬们去完成
。中国的整个IT界，应该为这“失去的十年”感到悲哀。因为这样的十年可遇而不可求，下

一个这样的十年在哪里？WHOKNOWS?

我们看看在这十年中，作为我们中国的IT界之骄傲的一些公司在做什么事情：

    *华为技术/华为终端。笔者和华为技术、华为终端打了多年交道。这公司作为中国最具
代表性的民营IT公司，是我们的楷模，他创造了通信业中国民营企业的神话。不得不佩服。
然而，大家都知道，华为终端直到今年，才开始逐步从围绕运营商的市场转向直接面向消费
者的开放市场。华为的狼性文化注定了这个企业是短视的，看不到未来十年的发展方向，只
能是跟随而不是主导。

    *腾讯、百度、盛大、新浪等互联网企业。这些公司在这个窗口期，其目的就一个：赚
现钱！这些企业在未来的十年内，仍然不能成为像苹果、谷歌这样伟大的、可以创造一个新
的生态系统的公司。

    *各类创业公司。这些公司忙于应付各类创业竞赛、写商业计划书、拜访投资方，能拉
到钱就是成功，先烧钱再说，哪有什么心思考虑未来十年？

    归根结蒂，浮躁的大环境造就了中国IT界的现状——既然很多公司可以没有任何道德底
线地生存，谁会脚踏实地地去积累？如果这样做，岂不是被人看成傻子？

    接下来的十年，不会再有嵌入式软件这个行当了。嵌入式软件将整个被平台化的系统（
iOS、Android、Windows）占据，而这些系统平台，全TMD是老美的作品！这就是这十年的悲
哀！不仅仅是笔者个人的悲哀，也是中国IT界的悲哀。不仅仅是飞漫软件的失败，也是中国
IT界的失败！

    三、软件工程管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    五、外聘CEO之殇

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

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

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

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

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

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

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

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

    *这位女士脚穿凉鞋，同时还穿着一双袜子。

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

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

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

六、最大的经营失误

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

    除了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年上半年，大家都知道，这两个项目终止了，这公
司根本没法获得进一步投资）。所以，并不是所有老外公司（就算是老美公司）都那么遵守
规则和具有商业道德，你要做的就是，尽量在前期收到足够多的钱，且不要盲目相信他们。

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