如何對治思維籠統
以下情況相信大家似曾相識:
A公司希望完成一個專案,將專案外判給一間軟件開發公司B開發,專案開始後,總發覺B公司不太理解要求,製成品也與要求相去甚遠,與B公司的 程式設計師多次開會亦結果不彰,最終專案「爛尾」收場,A公司不得已又將專案再外判給C公司,同一問題似乎又再上演...
探究原因,何解此類問題經常出現?原因往往在於A公司的相關負責人本身沒有編程背景,因此給出的要求相當籠統,B公 司的程式設計師亦不理解A公司期望,因此導致專案最終失敗。
讀到這裏,大家可能會嚷道:「A公司的負責人當然沒有編程背景啦,不然A公司自己做就好了」其實問題重點不在於A公司本身是否有編程的專才,而在於產品 負責人(Product Owner)與程式設計師溝通良好與否,即使A公司本身有編程Team,如果溝通不良,專案失敗是不會改變的。要討論溝通良好與否,先 要理解平常人的思維方式,與程式設計師的思維方式,往往差別甚大。
Source: https://www.cbc.ca/life/culture/the-beginner-s-guide-to-the-greatest-pastimes-mahjong-1.4739808
由打麻雀開始
大家懂得打麻雀嗎?如果你不懂打麻雀,或猶記得學打麻雀的事,你家人/朋友教你 的時候總是會說:「邊學邊打吧!」開始時的一兩小時內,總是雲裏霧裏,大惑不解,不知道發生了甚麼事情。那為何麻雀那麼難玩,一兩小時都無法自動學 會,你的家人/朋友何不先解釋規則,再邊學邊玩,不是更事半功倍嗎?原因很簡單,因為麻雀規則很難玩,而大多數人不習慣有系統解說複雜事物。以下是香港麻雀的一些規則,大多數人潛移默化學會了玩法,但不能夠以清晰文字解說給未明白的人:
- 麻雀有144隻牌
- 同一時間有四個人參與,每個參與者在非食糊時有13隻牌,食糊時有14隻牌,比正常牌數多稱為大相公,比正常牌數少稱為小相公。
- 開局須經過洗牌
- 食糊時需要符合一定的牌格,以三隻為一組,三隻順序,或是三隻一樣的同類(筒子、索子、萬子、其他番子)牌,食糊時該有四組,加上另外一對一樣(一對眼)的牌。
- 開好局,擺好牌以後,每個參與者需抽一隻新牌,打出一隻牌,因此總數維持13隻。
還有許多許多規則,不能盡列。想像一下,要逐款解說,相當不容易!
Source: Wikipedia
啟示
打麻雀的故事有何啟示?看起來平凡的事物,要以文字解說,遠比想像中困難。造一個網站,也是類同,看起來簡單的網站,也要花費不少時間,筆者曾 不只一次聽過有客戶的要求是:「將網站造成和Facebook/Airbnb差不多就可以了。」要造成Facebook或Airbnb一樣,當然要投入如Facebook 及 Airbnb一樣的資源,只以一個人的力量,當然是不可能完成。程式設計師由於以開發程式為業,習慣了細緻之思維方法,去理解事物每一個細節。所以當無任 何編程經驗的產品負責人,與程式設計師解釋心中所想時,常常會出現思維籠統的問題,無法以準確文字表達要求是甚麼。
如何對治思維籠統
所謂思維籠統,就像上面「邊學邊打麻雀」的故事一樣,要開發者邊做邊理解要求,省略了最重要的解說步驟,開發者又不是產品負責人肚裏面條蟲,當然就 無法得知真正的要求是甚麼,造出來的專案當然爛尾收場。 要對治「思維籠統」的問題,最佳的方法當然一而再,再而三那樣將要求提煉(Refine)得更精簡準確。
試比較以下幾個關於一個簡單TodoList的要求:
-
我想做一個Todolist,可以新增、更改、刪除、讀取TodoItems。
-
我想做一個Todolist,由React JS編寫,完成品將會部署在Amazon Cloudfront之上,前端的軟件需要使用Redux 作為狀態管理工具。後端軟件需以Node 編寫,使用Express框架,並使用PostgreSQL作為資料庫。前端及後端都需要 寫單元測試(Unit Testing)。
-
我想做一個Todolist,可以新增、更改、刪除、讀取 TodoItems,每個 Items 可拖移排序先後次序,並可剔選至「Completed」狀態,首頁需要看到全部 TodoItems 的列表和以狀態分類的列表,由 React JS 編寫,完成品將會以 static-site 部署在 Amazon S3 上並由 Amazon Cloudfront 作 CDN 前端,前端的軟件需要使用 Redux 作為狀態管理工具。後端軟件需以 Node 編寫,使用 Express 框架,並使用 PostgreSQL 作為資料庫,需要使用 Amazon EC2 以 Ubuntu 18.04 OS 部署。前端及後端都需要寫單元測試(Unit Testing)。
前端界面需如下圖
Source:http://todomvc.com/examples/typescript-react/#/
可見,這三個要求,隨著加入愈來愈多資訊,要求愈來愈清晰無歧義。 第三個要求很「長氣」是嗎?可是其實只有第三個才算是及格的軟件要求(Software Requirements)。
總結
要寫出第三個版本的要求,需求的當然不只common sense,需要有軟件開發經驗,以及少許用戶設計的經驗,現在有不少簡單易用的 用戶設計軟件如Figma,也令整個過程更為簡化。