飞漫软件十年回顾-MiniGUI 及飞漫软件创始人

飞漫软件十年回顾

2012年04月06日 19:26

北京飞漫软件技术有限公司（飞漫软件）成立于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 界，应该为这“失去的十年”感到悲哀。因为这样的十年可遇而不可求，下一个这样的十年在哪里HO KNOWS
我们看看在这十年中，作为我们中国的 IT 界之骄傲的一些公司在做什么事情：
   * 华为技术/华为终端。笔者和华为技术、华为终端打了多年交道。这公司作为中国最具代表性的民营 IT 公司，是我们的楷模，他创造了通信业中国民营企业的神话。不得不佩服。然而，大家都知道，华为终端直到今年，才开始逐步从围绕运营商的市场转向直接面向消费者的开放市场。华为的狼性文化注定了这个企业是短视的，看不到未来十年的发展方向，只能是跟随而不是主导。
  * 腾讯、百度、盛大、新浪等互联网企业。这些公司在这个窗口期，其目的就一个：赚现钱！这些企业在未来的十年内，仍然不能成为想苹果、谷歌这样伟大的、可以创造一个新的生态系统的公司。
  * 各类创业公司。这些公司忙于应付各类创业竞赛、写商业计划书、拜访投资方，能拉到钱就是成功，先烧钱再说，哪有什么心思考虑未来十年
归根结蒂，浮躁的大环境造就了中国 IT 界的现状——既然很多公司可以没有任何道德底线地生存，谁会脚踏实地地去积累果这样做，岂不是被人看成傻子
接下来的十年，不会再有嵌入式软件这个行当了。嵌入式软件将整个被平台化的系统（iOS、Android、Windows）占据，而这些系统平台，全 TMD 是老美的作品！这就是这十年的悲哀！不仅仅是笔者个人的悲哀，也是中国 IT 界的悲哀。不仅仅是飞漫软件的失败，也是中国 IT 界的失败！
三、软件工程管理
在飞漫软件发展各阶段，我们曾采用过多种软件开发管理模型。
以 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 这两项；很多人非要按照一周、两周或者一个月来划定一个冲刺的目标而不是按照冲刺工作集来确定发布时间；甚至一些管理人员，连燃尽图都懒得画。
这导出了本文的第四个主题。
四、中国软件工程师的特点
先告诉大家我的结论：中国的软件工程师，大致有一半或者更多是不应该从事这个行业的，他们做事随意，缺乏自律和学习精神，也缺乏必要的工程素养。
我们先看看中国软件工程师的来源。
中国几所顶级大学计算机相关专业的毕业生，大多选择了出国或者进入外企、知名国企工作（也有部分进入金融、投资等领域，少数选择创业或者加盟创业团队）。谷歌、百度、腾讯等大型互联网企业以及华为、中兴等大型通信企业，吸纳了这些顶级大学计算机相关专业中优秀的毕业生。但这些毕业生显然是少数，大多数从事软件开发的人员，毕业自二三流大学。
以笔者曾经面试过的应聘者以及很多共事过的软件开发人员为例，笔者得出了上述结论：
来源：linuxc2008