|
||||||
當科技廠紛紛跨界伸展觸角，生產電腦起家的華碩做手機，做手機起家的宏達電跨足平板電腦；科技圈裡也有一群人跨出自己熟悉的領域，將軟硬體完美結合，在上萬種App中脫穎而出。 撰文‧翁書婷 「我很失望，台灣根本沒有我要的軟硬體整合人才。」去年五月，前宏碁執行長、現任聯想歐非中東地區總裁的蘭奇（Gianfranco Lanci），在請辭之際，對台灣科技業拋下了這句重話。事隔一年，Google台灣董事總經理簡立峰，在某個論壇裡也毫不客氣地說，「台灣的ＰＣ產業不 是被手機打敗，而是被自己打敗；台灣要打破軟體歸軟體、硬體歸硬體的模式。」發揮創意整合軟硬體 賺進可觀利潤蘭奇與簡立峰的話雖然說得難聽，但卻都在講同一件事｜｜台灣科技業缺乏軟硬體兼備的人才。一位電機系畢業，在緯創電腦任職，有五年經驗的硬體 工程師阿奇就說，「公司在軟硬體整合方面採用團隊合作，但硬體工程師常常不大懂軟體工程師在說什麼，若有人兩個都懂，那就會變成很好的Link(指溝通橋 樑)。」但當追問他，那為什麼自己不會想要成為這樣的通才？阿奇想了想然後搖搖頭說，「軟體的學習門檻也不低，真的要很厲害，得花個三、四年以上的時間， 現在工作就已經被綁得死死的，怎麼可能有時間去學！」阿奇的說法點出科技業缺乏軟硬體整合人才的原因，軟體與硬體工程師在公司任務劃分得很清楚之外，軟體 與硬體門檻都很高，兩者要專精兼顧太難，在工時長、工作壓力又很大的狀況下，先顧好一邊就好。 不過，現在有一群人想的與阿奇不太一樣！這群人與阿奇相同，都是電機電子或機械科系畢業，過去也都是從事與電腦電子硬體相關的工作，但是他們都大膽跨出自 己熟悉的硬體領域，在假日或下班後，前往資策會、巨匠電腦、台大資工等專業課程教室裡，摸著電腦鍵盤、眼神專注，仔細聆聽老師講著 Android（Google的行動裝置作業系統）、iOS（Apple的行動裝置作業系統）以及C/C++、JAVA（基礎程式語言）等電腦程式怎麼 寫。 這群人不像阿奇把軟硬體整合想得那麼艱難複雜，他們修習軟體課程時間不是很長，通常才幾個月到半年，與資訊工程系本科畢業生比較之下，也許並不專精與熟 練，但他們卻看到平板電腦、智慧型手機背後帶來的龐大軟體應用商機。App（應用程式）成為他們「軟硬整合」最佳切入口。 更重要的，在學寫App之前，他們早想好自己要寫出什麼樣的程式，要怎麼賣錢。因此，當寫App的同業都大嘆，寫App競爭越來越激烈，民眾都愛免費 App，寫App很難賺錢的同時，這些人卻靠結合硬體設備或技術的App，一個月就賺進百萬元營收。本來從事硬體設備買賣，後來切入手機應用軟體，今年三 十六歲的黃高新就是最好的寫照。 黃高新熟練地拿起iPhone，打開自己設計的i-car App，手指頭在手機上面輕輕地滑動，就可讓停放在遠處的汽車車門自動上鎖解鎖、遙控防盜設備、發動引擎並打開冷氣，「若車子停在停車場，卻忘記停放的位 置，也可遙控喇叭發出聲響找到車子；就算你人在美國也一樣可以遙控、監控台灣的車子。」笑起來還有幾分靦腆的黃高新，高興地介紹這項他辛苦研發的產品， 「這樣一個App一組可以賣三十美元。」這是一般○．九九美元App三十倍強。且「還沒有上架，就已經有美國汽車配件廠TESOR，跑來台灣找我談合 作。」此外，黃高新也順利申請到中國、日本專利，光是今年上半年，就有六百萬新台幣的營收。 黃高新走上軟硬體整合之路，其實來自於一場生意的大挫敗。他在明新科技大學電機系畢業後，做起電器自動化控制生意，向美國公司訂購已經寫好軟體程式的手持 裝置，然後自己研發接收這套程式的硬體設備，最後將整組設備賣給汽車旅館、汽車改裝廠，讓使用者可以自動遙控窗簾、燈光、空調等系統。 同時滿足消費者與廠商需求 訂單接不完「這樣一台東西就要十萬元，當智慧型手機、平板大量賣，一台只要一萬元左右，根本沒有人要買我們的產品。」加上黃高新又太大膽，投資了很多硬體 設備，結果賠了一屁股，負債達一五○○萬元，逼得他開始思考如何轉型。「那時悶在家裡一年，吃不下也睡不著，本來是當老闆，從雲端掉下來的日子很不好 受。」黃高新回憶。 一心想東山再起的黃高新，冷靜分析後發現，就是因為太著重於硬體設備，疏忽了軟體的競爭力，於是他大轉型，心想著要設計一個可以在遠端控制汽車空調、門 鎖、引擎等的手機應用程式。沒有軟體背景的他，跑去巨匠電腦上課，而剩下的時間就躲在家裡研究怎麼把手機軟體與車子硬體配備連結在一起，「我砸下一百萬 元，自己研發車用主機電路與硬體，軟體的部分除了補習班外，也上國外網站找資料看別人怎麼做，每天只睡兩個小時，長達半年時間都在研發。」皇天不負苦心 人，最後他終於將產品開發出來。 台大農業機械所畢業的李明達，則是另一個成功整合軟硬體的案例。 三十五歲的李明達與多數人一樣，只是一個普通的上班族，在一家數位機上盒品牌廠上班，工作內容就是設計數位機上盒的硬體設備，薪水穩定，一年破百萬元不是 問題。但在iPhone風行以後，李明達卻注意到App的風潮，於是辭去了外商硬體工程師的職位，學起iOS與Android的程式設計。 後來李明達所設計的App「移動書房」（數位內容閱讀軟體，此一軟體主要應用於閱讀電子書），在比賽中得了大獎；自此，各種手機應用程式的訂單如雪片般飛 來，一年來已經累積近兩百萬元的營業額，他分析「移動書房」得獎的原因說到，「因為我懂得軟硬體整合的加密技術，客戶不會擔心書籍的智慧財產權被拷貝，這 是純資工背景的人比不上我的。」而未來，李明達還打算結合自己的農機硬體專業，為種植文山包種茶的老家，研發溫室自動控制的行動軟體。 校園吹起實務風 師生一起換腦袋除了這些上班族外，在台大校園裡，也吹起軟硬混血風潮。一個秋日午後，踏進台大資工所的行動裝置與人機介面實驗室，三十幾位學生手拿貼滿電 路板或感應器的蘋果iPhone，正七嘴八舌地討論研發成果。這群學生有一半是電機跨資工的軟硬混血學生。「這個比例是三年前的十五倍，」打造這個實驗室 的資工系教授陳彥仰說，他是全台灣第一個開設手機應用軟體程式課程的老師。他帶著學生打造台灣第一個醫療用行動軟體「DR.Pad」，不但成功拿下國際知 名投資風向雜誌︽紅鯡魚︾「亞洲創新百強」獎項，也讓台北榮總的內科醫師讚不絕口。 陳彥仰帶學生走出實驗室走入人群。新生訓練課程，他就要學生到捷運站，請學生認真用眼、耳、口、鼻、觸覺等五官仔細觀察買票民眾的一舉一動，然後提出需要改善的地方，最後寫成一個手機程式。 這樣的安排是他的精心設計，「台灣長期為國外大廠ＯＤＭ（委託設計與製造）、ＯＥＭ（委託製造），以前學生只知道就是要把東西做得重量越輕、體積越薄、速 度越快，不問為什麼，就是一古腦兒去做。」但數位匯流、軟硬整合的趨勢下，這樣的思惟卻全部都要倒過來。學生需要觀察最流行的是什麼？必須知道產品是設計 給誰用的？想解決生活上什麼樣的問題？ 市調機構顧能（Gartner）統計，民眾下載的手機應用程式中，有九成以上的應用程式都是免費，因此，許多程式設計業者苦不堪言，大喊賺不到錢。而且軟 體很容易被盜版，要維護智慧財產權很不容易，但軟硬體整合式的App讓人願意掏出錢來，毛利又比較高。當這些科技大老大喊軟硬體整合的同時，這群人早已準 備好要成為未來需求的最佳人才。 熱門程式設計課程何處學？ 機構 資策會 台大資工 巨 匠課程名稱 1. C/C++、Java基礎程式設計2. iOS╱Android程式開發 1. C/C++、Java基礎程式設計2. Android程式開發 1. C/C++、Java基礎程式設計2. iOS╱Android 程式開發3. Windows Phone應用程式開發時數 15小時短期課程至600小時完整課程皆有 每門課皆30小時 C/C++為12~15小時，Android為48~108小時、Apple iOS為60~90小時、Win Phone90小時收費 約8000元至12萬元(課程種類繁多依課程難易度與時數不同有所調整) 每門課皆5000元 基礎如C/C++：約7500元，專業應用程式開發約為4萬元至6萬元 |
||||||
1.一切源於慾望
1.1 慾望?需求!
慾望!何為慾望?心理學上對慾望的解釋是由人的本性產生的想達到某種目的的要求。在這個定義裡有兩個關鍵詞：本性、目的。它指出了慾望的源頭，是由人的本性產生的，是一種本能，人人皆有。同時也指出了慾望的產生原因，是為了達到某種目的。
舉個例子，吃飯，這是一項最基本的生理慾望，每個人為了生存必須要吃飯。要吃飯，就得先把飯做出來。我們有微波爐，電飯鍋等等很多可選擇的工具來幫我們做飯，甚至，做特殊的食物有專用的工具提供給我們，比如面包機。再者，如果你不想做飯，連出門都懶得出，你可以用一款叫「餓了麼」的軟件將食物快遞上門。
前面提到的微波爐，電飯鍋，面包機以及「餓了麼」軟件，都是我們可以用來滿足吃飯這項生理慾望的工具。換個角度，這些工具不就是工具生產廠家的產品嗎?換句話說，產品就是為了滿足人們慾望而產生的工具。既然產品是為瞭解決人們的需求問題，也就是說需求就是人們的慾望。
1.2 慾望，如何滿足
每款產品都有自己要解決的核心的用戶需求，也就是說產品都有一個核心的慾望需要去滿足。比如，「餓了麼」軟件就是滿足人們叫外賣的慾望。但是，叫外賣的方式有很多種，為什麼用戶一定要用「餓了麼」軟件呢?這個時候，就需要對慾望進行深入的分析，已提供更好的服務來滿足人們的慾望，這個活動常常被產品人稱作需求分析。
舉個蘇傑大大在《人人都是產品經理》中的一個例子：絕跡小朋友想去吃火鍋，這是一個慾望。但是絕跡小朋友真的是嘴饞了想去吃火鍋嗎?可能絕跡只是餓了，但是這四川娃子餓了就只想到吃火鍋。如果真的只是餓了，給他倆包子也可以滿足絕跡的慾望，還能節省成本，何樂而不為呢。這就是一個典型的需求分析過程，通過需求分析找到了最簡單的滿足人們慾望的方式。
再來談談「餓了麼」軟件，在這個軟件出現之前人們也是能叫外賣的，那麼這款軟件有什麼更好的滿足人們叫外賣慾望的方面呢。我們先來看看以前叫外賣的痛點。叫外賣有兩種方式，如果店舖有官網，可以去官網訂餐，但是，這些只限於一些大型連鎖餐廳，比如麥當勞。另一種方式就是電話預定，但是前提是你要有店舖電話，一般人肯定不會有附近所有餐廳的電話。「餓了麼」軟件就解決了這兩個痛點，它能蒐羅用戶周圍提供送外賣服務的所有餐廳，並為所有餐廳提供網上訂餐服務，同時也免去了獲得餐廳電話的需求。通過分析，「餓了麼」軟件提供了更好的滿足需求的服務。
2.合適的慾望碰到合適的人
2.1 用戶角色建模
每一款產品都有自己的受眾，沒有哪款產品是每個人都需要的。為此，我們需要對自己產品的受眾進行分析，看看這些用戶使用產品的習慣是怎麼樣的。這樣可以更好的提取用戶的需求。
首先，要找出產品的受眾，這個流程一般被稱為用戶角色建模。用戶角色建模首先要通過頭腦風暴的方式列出可能的用戶角色集合。還以「餓了麼」軟件為例，一般都是什麼樣的人會叫外賣呢?勞累一天的上班族，學校的學生，偶爾想改善伙食但不想出門的人，加班的人，不會做飯的人。
在收集了用戶角色集合以後，我們需要對這些用戶角色進行整理，看看角色之間有沒有包含或者重合的地方，如果有，則需要考慮是否用角色需要被丟棄。比如上面的用戶集合中，不會做飯的人並沒有典型的特徵，而且，在上班族、學生、加班的人中都可能會有不會做飯的人。則，不會做飯的人完全可以被其他角色所代替，這個用戶角色就可以被丟棄了。
在整理完畢用戶角色後，可以將每個用戶角色寫在一個卡片上，並在每個卡片上寫下這個用戶角色的一些特徵，這樣可以方便的對用戶角色進行分析。比如，在上班族卡片上可以寫上對菜品質量要求較高，可以熟練使用電腦，可能會經常使用該軟件等等。
有些時候為了對用戶角色更加深入的瞭解，一般會對重要的用戶角色建立角色實例。角色實例是一個貼近生活的用戶場景，通過角色實例可以建立起一個真實的人物，讓我們對角色有更真切的瞭解。如果上班族是我們主要的目標用戶，我們為上班族建立一個角色實例如下：
有業界的大大建議在設計新系統時對一些極端人物建立角色卡。這些極端人物並不是產品的典型用戶，但是他們卻是真的會使用我們的產品。比如一些花痴小妹妹，叫外賣或許對她們來說並不是必須的，但是她們可能僅僅是為了看某個送外賣的帥哥，而經常定那家餐廳的外賣。我們不需要浪費太多時間在這些極端人物身上，甚至這些人物的需求根本不會被實現，但是花點時間在這些用戶身上，或許會產生一些意想不到的靈感。
2.2 需求源於角色
前面在用戶角色建模上浪費了很大精力，其實都是在為這裡的需求收集做準備。不同的角色肯定會有不同的需求，這個時候，我們需要將自己代入角色，仔細想想如果自己是這個角色，會有什麼樣的需求。將所有考慮到的需求都記錄下來，為以後的需求整理做準備。
比如，作為一名上班族，很晚才回到家，這個時候叫外賣肯定希望外賣會很快的到達。而且上班族一般都習慣刷卡，如果提供刷卡或者網上支付功能會很方便。而「餓了麼」軟件就為用戶提供的外賣到達時間的預估，用戶可以方便的選擇可以快速到達的外賣。
再考慮學生，學生這是個沒有收入的群體，所以物美價廉的外賣是他們的首選。學生一般對快遞的送達時間會有相對較大的容忍度。學生中對刷卡的需求不是很迫切，他們一般更喜歡現在付款，所以如果有貨到付款的服務會很合適。同時，如果可以用學生卡打折，我想會很受學生們的歡迎。
3.慾望也有輕重緩急
在需求收集和整理完成後和項目開始開發之前，我們需要召開需求評審會來確定每個需求的優先級和開發計劃。如果你的團隊正在使用 Scrum 敏捷開發，那麼你們一定在用用戶故事來整理用戶需求。用戶故事通常使用客戶和團隊都可以看懂的表達方式來寫，每一個用戶故事都是產品的一個需求。當然，用戶故事還包括需求的商業價值和相關人員。使用用戶故事可以方便的與客戶溝通，而且不用查看繁瑣的需求文檔。
用戶故事一般使用如下格式：為了[商業價值]，作為[角色]，我想要[做某事]。還是使用「餓了麼」軟件為例，比如上班族想找到送外賣快的餐廳的需求可以表述為：為了讓外賣更快的送達，作為上班族，我想要查看每家餐廳的外賣送達預估時間。
在用戶故事確定以後，我們需要召集開發人員，客戶還以一些產品的相關人員來參加需求評審會。在會議上，我們需要對每個需求的商業風險，技術風險，開發耗時和優先級作出評估。
首先需要確定的是商業風險，也就是確定哪些是核心需求，哪些是亮點需求。核心需求需要儘早完成，缺失了產品就不完整。而亮點需求有則會給產品加分，沒有也不會影響用戶的使用。一般來講，核心需求的商業風險會比較低，因為這些需求都是產品必須的，被砍掉的可能性很低。而亮點需求的商業風險就會高，可能會因為開發時間不足而被砍掉或者被放入下次版本迭代的週期中。
下來需要確定技術風險和開發耗時，技術風險代表的是這個需求開發的難易程度。如果這個需求所需要的技術開發團隊從來沒接觸過，需要對這個技術從頭開始學習。那麼這個需求的技術風險就會很高，因為這個新技術不知道開發團隊是否能掌握，多久才能掌握。技術風險的評估對開發耗時的評估有很大影響。開發耗時在 Scrum 開發團隊中一般用時間點來計算，一個時間點代表一個理想工作日。在我的團隊中，一般使用斐波那契數列來劃分時間點的等級。因為我們發現工程師經常在為一個需求的時間點而爭論不休。如果為一個需求是 2 個時間點還是 3 個時間點而爭論，這是有意義的，因為 3 個時間點比 2 個多了一半的工作量。但是如果在為一個需求是 99 個時間點還是 100 個時間點而爭論就是沒有意義的，因為這一個時間點的差別對我們的影響很小。為了避免這種無意義的爭論，我們使用斐波那契數列來劃分時間點，這個時候工程師只需要考慮這個需求的耗時更靠近 89 還是 144 ，而不用為了細小的差別而爭論不休。在評估技術風險和開發耗時時，一般都有技術人員和項目經理來確定，其他人員不應該左右技術人員和項目經理的思維。
最後則是評估需求的優先級，綜合分析以上三個要素，來最後給需求評估優先級。一般情況下核心需求的優先級往往是最高的，不過有時候由於技術風險過大，或者開發耗時過長，有些核心需求的優先級會被降低。在優先級評估完畢後，開發團隊會確定第一輪的迭代要完成的需求。如果是使用 Scrum 敏捷開發有一段時間的話，開發團隊是知道自己在一個迭代週期能夠完成多少時間點的任務的，也就是團隊的速率。一些高優先級的需求由於時間點太大而不能放入本次迭代，而使用其他優先級相對較低但時間點小的需求代替的情況也會時常發生。
4.讓慾望在掌握之中
在完成需求評估後，開發團隊就會進入開發階段。在 Scrum 團隊中，需要對開發中的需求進行管理。常用的方法是在一塊木板或是一面牆上列出正在開發的，開發完成的，正在測試的和完成了的需求。這塊木板或強被稱為看板。每個人都可以在看板上清晰的看到團隊現在的開發狀況。我的團隊沒有使用實體的看板，而是使用 JIRA 這個軟件提供的電子看板。
在開發過程中，需求的變更是必然會發生的。正常情況下，如果一輪迭代已經開始了，Scrum 團隊是不會中途停止的。新的需求必須在下一輪迭代中才能加入，這樣可以保證開發的正常秩序。為此，我們在看板最前方新加了一項：待開發。我們會將變更的而且有限級高的需求放在這一列，以保證在下一輪迭代中實現這些需求。
大部分公司都會要求寫需求文檔，這樣對所有需求歸類，並且可以方便以後的查閱。但是這些需求文檔有時候書寫的並不是很規範，或是很全面。導致查閱的時候很難找到我們需要的內容而且在需求，有時候甚至是寫完後根本無人去理會。而且，在需求變更時需要進行維護，耗費人力，文檔在多次修改後導致內容很亂，或是前後需求矛盾的情況時有發生。
現在一個新的需求管理方法，需求的實例化，可以解決這些問題。需求的實例化是不再編寫和維護需求文檔，而是直接使用高質量的測試用例作為需求文檔。通過測試用例可以很清楚的看到產品的需求內容，而且，在需求變更時，必然會產生新的測試用例，而不必費力去維護。在清晰的表現需求的同時，減少了維護需求文檔的人力。