本部落格已搬家
點此前往新部落格

新主機測試中...

十招打造史詩級失敗軟體產品

常常有成功企業分享他們成功的秘訣,例如 LINE的成功秘訣:不要想創新,做最簡單的事就對了! 或是 蘋果的設計魂強尼.艾夫: 打造出一流產品才是蘋果的使命與熱情,都說得很好,功夫兩個字,一橫一豎,站著的人講什麼都是對的。

那失敗的秘訣呢? 通常不會有人去採訪,一種是核心成員自己分享的,如進入ALPHAcamp當學生前的暗黑史 #AbnerChao說故事。另一種是外部人士分析的,例如每次某大公司有裁員之類的新聞,就會到處出現一堆分析文,如 Nokia 手機帝國的衰亡之類的...

那以軟體開發來說,一個製作軟體的外包商,要如何打造出一個史詩級失敗的軟體產品?(a.k.a 黑心軟體開發指南) 可遵照以下十大原則:

以下內容純屬虛構,如有雷同,純屬巧合。

1.找到對的客戶 - 對資訊產品不熟的族群
不管做什麼行業,都最怕「以前可以,或是免費的都辦得到,為什麼現在你不行?」的狀況。就像不會有人質疑為什麼 iPhone 這麼貴卻不防水? 除非品牌的信仰力足夠,不然這種疑慮是解答不完的,身為服務業,也不能用「不爽不要用」的大絕招。

如果做的是商業應用工具,而不是生活或娛樂用途的,首先要想辦法吸引對電腦或 3C 產品不熟,不太理解資訊系統邏輯的客戶群。

絕對不要找那些常使用套裝軟體、免費 XX 建置工具、先前已經用過其他高價軟體、時常在操作各種 App 的使用者,為什麼呢? 因為他們見多識廣,對視覺有一定水準的要求,有豐富的使用經驗。這種客戶的預算不一定比較高,但通常難以被滿足。

史詩級失敗的產品功能,以容易開發、公司的利潤為第一優先,幫客戶達成目的排第二。

與上面那種難以滿足的客戶比較起來,我們找了一些不太了解這些專業的客戶,他們也通常最會用價錢來評斷:「這個功能別人只要幾千塊,為什麼你的比較貴?」所以要準備一些完美的說法,好打發這些只論價錢、不論品質內容的問題。只要比他以前用的紙上作業流程或是傳統流程「好用一點點」,就可以輕易滿足他們。

當經營這種客戶久了之後,就會以為自己的產品很好,已經幫很多人解決問題,實際上體質很差又落後,在外界是毫無競爭力的。也許短期可以生存,但總有一天大廠商推出殺手級應用,就會死掉一堆這種產品。

舉例來說,常幫那種不開發票、商品只有一兩項的小店家做東西,如果有一天遇到財務流程比較完整的、商品細節比較多的客戶,就爆了。

2.前置工作 - 學生作業化
身為外包商,避免做出錯誤的決定,或是幫別人做出錯誤的決定。那要如何確定客戶提的需求是正確的? 如何知道市場上是否已經有類似的解決方案? 如何評估工程團隊是否可以達成客戶提的需求?

問題問對了,答案自動就會出來。但是沒簽約前,不要花太多時間去回答問題,能用口頭講的就不出資料,能貼網址就不要自己撰寫編排。唯一要做的事只有一件,就是像學生做作業一樣,把網路上的文章整理之後再胡謅一番,完成前置作業。

例如有人說自己的官網「要做得跟 Yahoo 商城一模一樣」,我們不需要進去 Yahoo 商城後台實際操作,也不需要知道店家只使用該系統的那些東西來進行出貨與銷售流程,更不需要考慮商城平台的發票、物流、客戶資料與自架官網的差異,我們只要把後台選單的東西複製起來,再擷幾張圖,讓他誤以為會做得跟圖片上一模一樣。然後看客人有要改什麼,再修改即可,完全不需要自己思考。

3.企劃與規格文件 - 大方向化
會找外包,一些情況是需求太專業,現有資源沒法處理。另一些是對要做的東西不太理解,用錢解決最快。

不過軟體開發嘛,資訊架構與功能流程絕對不是用幾行文字說得清的,所以企劃書寫得再詳細、再清楚都沒用,規格書厚厚一本也沒人會去看,只需要記得把修改次數與各種免責條款寫入合約即可。反正日後絕對還是會有風險與爭議。所以只要寫大方向,讓出錢的人看起來高興即可。

如果真的要寫詳細怎麼辦呢? 參考市場上同性質的商品。

首先以競品的收費方式為基準,如果人家的很貴,就用「他們要這麼多錢,我可以用比較便宜的工法幫你達成。」至於真的比較便宜嗎? 我們來看一個網路笑話,看完就懂了:

地獄的門也壞了,閻王吸取了上帝的教訓,下了一個3000的定價。
德國人看了一眼,走了。
印度人報價3000。
台灣人給了評標的小鬼500,報價3000,又得標了。
德國人、印度人很納悶。之後,台灣人花了500材料,500人工,修了一半宣布停工。拖了半年,閻王被逼追加投資3000,完工。

如果人家的比你的便宜,就用「他們那種會有問題,我們這種架構比較貴,但日後問題會比較少。」的方式唬爛過去。

再來抄一些別人的功能。如果別人的功能我們剛好都沒有,需求方也沒提,要嘛略過不寫,或是加碼成額外報價項目。

當每個不同的顧客都重複跟你提出同一個需求時,這就是一個警訊,你要堅守防線,拚死保留這個功能在下階段的報價內,不可以給客戶。

4.視覺風格 - 花俏化
畫面留白是大忌,第一眼一定要看起來很滿很豐富。只要不是用來顯示大量文字的區塊,一定要加上底色跟底圖。下圖右雖然是平面設計,但也為我們的概念做了完美示範:

有質感的精緻圖示? 符合視覺設計原則的排版? 現代感的平面化按鈕設計風格? 不干擾視覺、微微點綴的藝術感背景? 符合使用者體驗,不用花太多時間記步驟,也不容易出錯的操作方式? 這些都不需要,也不重要。

要把所有東西都當成密室解謎遊戲來做,重要功能要隱晦,按鈕陰影要多大有多大,漸層有多少放多少,連幾張會干擾視覺的底圖都不會做,別說你是設計師。

切記,史詩級失敗的設計流程不需要去構思「好不好用」這件事,做得越難用,才有改良空間,後續才有再追加報價的機會,公司的生存跟利潤是很重要的。

5.程式開發架構 - 不須優化
不需要引入任何專案控管原則、管理法則、程式架構原則,請開發的工程人員捨棄一切以前聽過的什麼續用性、追蹤性、命名...等開發原則。也不用寫任何文件,頂多在程式碼行間註解一下。

新技術都有學習成本與訓練成本,而且導入之後不保證案件成功、順利,搞不好人員中途離職,後來接手的還完全不懂那一套方法,所以封印一切會讓人員仰賴的特定開源工具或開發流程。我們可以找畢業生來面試,如果一個開發流程或方法,十個有九個沒實務經驗或沒做過的開發方法,那個方法就不要用。

一切只有一個原則: 機動性高,快速製作,快速修改。
開發只能用一次的產品、開發接手的人不知道怎麼改的產品。

6.減少測試,保留大量修改時間
坊間一些開發方法,強調單元測試、自動化測試、use case、test case...之類的的重要性,但我們做的是史詩級失敗軟體產品,只要做好之後看起來能動就好,其餘的就交給全民公測,因為就算內部測試步驟看似正常,但使用者又不是照你測的那樣去用!

而且由於我們在前期規劃時很精簡流程,很多部分都靠工程師通靈出來的,所以很多東西可能跟實際需求落差相當大,所以要在這邊保留大幅修改的時間,並秉持著第 5 點的原則,快速修改出一個看似符合驗收標準,功能跟大方向好像都有的產品。

7.團隊精簡化、年輕化
一個團隊中最重要的就是人,雖然年齡較長者比較容易有家庭包袱,不會下午請假去一下郵局,然後就人間蒸發了。但這裡還是強烈建議聘請剛畢業的新手,或是技職體系的實習生,絕對不可以請開發經驗豐富的老手。

因為請老手的人事成本很高,而且老手會胸懷壯志,想優化流程、或是用自己的方式做事,但綜合以上情況,除非他是柯 P 再世,不然一定優化得不好,反而造成案件製作成本爆增。

新手成員可能會覺得這個工作流程跟他學的不一樣,工作環境不佳,所以人員流動率很高,還會造成額外的交接成本,但沒關係,可以把事情推在離職員工身上,死無對證。

8.宣傳技巧 - 浮誇化
如果這次開發的是以往沒有的東西,對公司而言就是新產品,案件可能還沒做完,但我們要把效益最大化,業務就要開始用半成品開始對外宣傳,套用成長駭客理論,我們可以號稱這是已經 PMF 的 MVP。

遵照本文的原則 1,我們不跟競爭對手比較「軟體功能清單」的長度,因為使用者看不懂。而要強調此系統可以達成某件事,藉此製造良好的第一印象。但我們不會說達成這件事的步驟有多繁瑣,流程有多差,功能有多殘障。我們要吸引更多白老鼠,浪費客戶的溝通成本,來成就公司產品的完整度,一人付錢,萬人享受的概念。

還要再培訓一個專門的業務,有魔術師表演經歷,或是宗教佈道大師級為佳,這樣到客戶那邊去 demo 時,才可以化腐朽為神奇。

再次強調,史詩級失敗軟體的產品功能,以容易開發、公司的利潤為第一優先,幫客戶達成目的排第二,講求的是殺雞取卵的那套,至於貼心、好用什麼的,等日後有機會再精進即可。

9.聯絡窗口 - 職權弱化
為了外包案件順利進行,溝通是很重要的一件事,溝通透過的當然就是聯絡窗口,如果是一層包一層,那就是透過上一層的包商來傳達。

聯絡窗口的職責不是當郵件轉寄器就好,這樣 Outlook 或是 Gmail 就可勝任聯絡窗口了? 開發人員與需求人員對於聯絡窗口的美好想像,就是能統整兩邊彼此的意見,並濾除邏輯有問題的內容、把看不懂在說啥的需求整理成人話。最終告訴執行人員要做什麼。

但我們要做的是史詩級失敗軟體產品,所以聯絡窗口要有以下特點:

  • 沒人會聽他講話的人
  • 懂得越少越好,不需要理解需求方的操作邏輯與專業技能,
  • 不需要理解設計方的專業技術
  • 不需要具備開發方的流程與資訊邏輯
  • 懂得如何轉寄郵件
  • 找不到可以解決問題的那個「對的人」
  • 能自己做一些多餘的決定的話,就更好了。

負責當窗口的職稱也不太一定,如果沒有多餘的人力,那就直接由開發人員去面對客戶即可。

10.售後服務 - 公務員化
因為我們做的是史詩級失敗軟體產品,勉強結案之後,既不好用,用起來又容易出錯,該有的功能也沒有,常常要用一些折衷的方法來達成目的,所以操作人員的使用成本相當高。

使用者遇到問題,一定會找人來問,所以產品一定需要有售後服務,讓人問問題。有時候會遇到「預期產生的結果」跟「實際上產生的結果」不一樣,如果是發生在信仰力足夠的產品上,使用者會說「這是 feature」「是我不會用」,但一般會說「真爛」「遇到 bug 了!」

如果碰到要處理 bug 的情況,不管事態是否緊急,要先按標準流程一動一動來,先提交問題單給工程部,確認這是 feature 還是 bug,有人要去找對話紀錄,看是不是使用者自己忘記之前提過的需求,有人要去檢查此客戶是否在維護合約範圍內,最後來個跨部門會議......完全不對!

是因為原則 7 人力精簡,以上這些事搞不好都是同一個人在處理,根本不用開會?

還是不對!

史詩級失敗軟體產品的售後服務,客服起手式只有三招:
「請提供操作畫面擷圖/詳細操作流程/使用者裝置環境。」
(消費者遇到問題,無法購物就跑掉了,還有耐心再試一次,截圖給客服?)
「系統測試正常,查無此問題,請再重新操作一次看看。」
「此為新功能,不屬於維護範圍,需另外報價。」

因為「預期產生的結果」實際上是在原則 3 裡面偷藏的保留功能,所以該做的不是開設測試環境->修復BUG>內部測試->客戶驗收,更新正式機,而是直接寄出新的報價單,開始一段新的冒險。


隨堂測驗 :

1.(____).閱讀以下兩篇文章後,感想為?
讀者來信:UI 設計流程 « 嫁給RD的 UI Designer
開發流程重不重要? | gipi的學習筆記-專案管理、商務簡報技巧部落格 - 點部落
(A) 嗤! 這麼麻煩,這樣一個案子是要做多久、報多少錢啊?
(B) 真是不切實際的幻想,我們是在做生意,不是在做產品!
(C) 還輪得到你這小鬼來教我怎麼做生意? 這麼會的話,明天規劃一個淘寶網來看看?
(D) 好像可以解決我們的問題,有機會的話來試試好了。

2.(____).關於外包接案企業,以下敘述何者為真?
(A) 交出讓企業立即可用的人,是學校的責任。
(B) 產業落後,是因為客戶不拿錢出來讓產業升級。
(C) 員工是公司的成本,而不是主要資產,成本就是要越低越好。
(D) 打仗要靠武器,而打勝仗要靠人。

3.(____).閱讀工程師轉職商人的心路歷程 #1 - 這輩子成長最快的一年 « ADZ 學習筆記 之後,不同成員提出不同的意見,以下何者為真?
(A) 你看,就說整天搞什麼開發流程、code 漂不漂亮、做得好不好用都不重要,趕快做出可以賣的東西才重要。
(B) 你看,他說其他公司都把技術排在最後才考慮,技術不重要,還是要靠營銷跟推廣。
(C) 你看,客戶感覺很重要,每次我提一些很酷的 idea,就有人在跟我講程式流程與邏輯。
(D) 這是老闆跟技術人員思考邏輯的差別。


難怪有人說學界跟業界脫軌,畢業生都不好用,真是不意外。
因為好用的人不會到這些團隊去啊!

以上內容純屬虛構,如有雷同,純屬巧合。

推薦幾篇好文章:
李慕約公司 - 怎麼樣跟專家溝通?
工程師轉職商人的心路歷程 #1 - 這輩子成長最快的一年 « ADZ 學習筆記
讀者來信:UI 設計流程 « 嫁給RD的 UI Designer
開發流程重不重要? | gipi的學習筆記-專案管理、商務簡報技巧部落格 - 點部落


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助


Comments 轉載文章請留言說一聲

comments powered by Disqus