魏永明:從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年上半年,大家都知道,這兩個項目終止了,這公
司根本沒法獲得進一步投資)。所以,並不是所有老外公司(就算是老美公司)都那麼遵守
規則和具有商業道德,你要做的就是,儘量在前期收到足夠多的錢,且不要盲目相信他們。

    敬以此文紀念飛漫軟件過去的十年。

發佈了22 篇原創文章 · 獲贊 4 · 訪問量 12萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章