對於許多人來說, 買個袋子是件很常見的事情, 不同的人會有不同的需求. 男孩子們可能講求實用, 對於女孩可能要求時尚, 可以展示身份.
圖 2-1 背包
但是, 如果我們把範圍縮小到IT行業的朋友, 並且是工程師背景出身, 是否就會好些呢? 事實上. 還是很不同的. 我曾經在課堂上問過, 每一組答案很接近, 但是還是略有不同. 例如如下圖 2-2 所示:
老王在意的順序是:價格、造型、實用.
小華考量的順序是:造型、收納、價格.
佳佳則是:品牌、重量、和實用.
大家有點像, 可是卻又不太像.
圖 2-2 每個人對於背包考慮的因素不同
同理, 在品質的定義也是如此.
我們來看看IEEE 對品質的定義是什麼:
The degree to which a system, component or process meets specified requirements. The degree to which a system, component or process meets customer or user needs or expectations
基本上就是滿足特殊需求, 或是客戶的需求的程度.
這裡有趣的點來了, 何謂客戶的需求? 每個客戶都是不同的. 就像前面背包的範例一樣. 同一個系統, 客戶 A 覺得可以用完成目的就好. 客戶 B 覺得要很快不要佔記憶體. 客戶 C 覺得畫面感覺要溫柔一點.
所以品質難的地方, 就是不同人對它有不同的期待, 因此你必須要對不同用戶做出不同品質結果.
這裡我們從幾個面向來討論, 如何思考客戶想要什麼:
a. 企業用戶
在企業中的軟體, 大多是有專門的 IT 負責管理和部署. 因此, 他們不喜歡你常常發佈更新, 這樣會造成他們的工作量很大. 並且有些企業人數很多, 每部署一次新的更新, 所花費的時間可能要 2 週到一個月.
在發佈的過程中, 因為要面對的機器或是人數眾多, 他們不太想要一台一台地去處理, 自動化去做會是最棒的. 但是這裡需要軟體配合, 要能有 API 或是 命令列的介面, 讓用戶 IT 可以用寫程式的方式, 去客製化處理部署的工作.
此外, 因為平時工作就很忙了, 對於系統畫面操作的要求, 不需要很多花俏的互動, 就是希望越簡單越好, 趕快把事情做完就好.
這些就是企業IT用戶常見的問題, 以及他們希望系統能夠注重的特性.
b. 一般用戶
對於一般用戶來說, 他們比較沒有負擔, 軟體比較可以隨時移掉或是隨時安裝. 因此, 對於新的事物, 他們願意去嘗試. 軟體開發者比較有機會增加新功能, 或是做出新的修改.
對於使用的系統, 他們也是希望不要太複雜, 有些事情可以自動去做就好. 否則當發生問題時, 並不是大多數的人了解發生什麼事情, 更不用說能夠去解決.
對於系統的畫面, 會希望花俏一點, 有趣一些, 這樣每天在使用的時候才不會無聊.
所以上述的描述可以知道, 企業用戶和一般用戶兩者的角度是大不相同.
在跨越鴻溝一書中, 提到技術採用的生命週期有以下幾階段, 每個階段會有不同的用戶, 他們對產品品質的接受度不同.
a. 創新者 (佔 2.5%)
市場推出新產品, 他們就會想要試試看. 對廠商來說可以提供創新與改進的意見. 如果想法可行, 他們就不會有太多意見
b. 早期採用者 (佔 13.5%)
他們大多是意見領袖, 如果可以搞好他們的關係. 他們會幫忙宣傳產品. 如果想法可行, 他們就不會有太多意見
c. 早期大眾 (佔 34%)
謹慎務實的實用主義者, 確認利益才會購買. 是非常關鍵的用戶. 產品有基本的品質, 他們就可以接受.
d. 晚期大眾 (佔 34%)
傳統的保守派, 對於價格非常敏感, 對新科技感到困惑, 如果品質方面沒有達到一定水準, 他們是無法接受的.
e. 落伍者 (佔 16%)
否定高科技產品的行銷, 也不購買新產品, 很難推銷產品給他們, 所以他們也不在乎你產品的品質是如何.
圖 2-3 不同產品階段有不同品質要求
根據這樣的想法, 在不同階段的產品, 你需要做到相對應的品質程度就會不同
圖 2-4 常見產品的 3 個階段
a. 1.0 產品
主功能可以運行
b. 快起飛的產品
沒有重大問題. 可以穩定運行一段時間
c. 搖錢樹的產品
前後版本相容性高, 執行的效能也不錯, 也沒有安全性的問題
很多時候工程師會埋頭苦幹, 很認真把是請給做好. 但是這不一定是老闆要的, 當老闆跟你說不對時, 你便會很傷心難過.
所以最好的方式, 一開始就要和老闆確認做完的定義是什麼, 測完後要給誰用, 測試的目標是什麼. 在時程開始時就要討論這些事情.
為了怕有講沒有懂, 雙方需要不斷地對齊, 每測出一些結果, 就和老闆確認, 一方面讓他知道目前產品品質狀況, 另一方面也確認測試方向或是測試強度, 是否可以. 避免到最後, 做到流汗,卻也讓人嫌到流涎.
軟體開發團隊必須要知道為何而戰,不然很可能蹉跎愉快的下班生活,最怕自己想、做壞了又不敢講,結果跟客戶和PM的想法毫無交集,做了一整個白工...