如何對治思維籠統
2019-01-23
以下情況相信大家似曾相識：
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，也令整個過程更為簡化。
留言
閱讀更多
新年願望：學寫程式懶人包
2019-01-02
剛剛過了2019的新年，大家許下了甚麼新年願望呢？也許大家會希望在2019年學會寫程式，突破自己
寫Blog與寫Code
2019-01-07
在外國，程式設計師在課餘時間寫Blog是很平常的一回事，大家在找尋技術問題的解決方法時，除了全知的Stack Overflow之外， 很多時候閱讀的就是一些其他高手所撰寫的技術文章，博客平台如Medium等也應運而生。相較之下，香港甚少有聽聞程式設計師有寫博客的習慣，大概是由於 工作繁忙，抽身不暇。筆者此前也只是曾經在一些Facebook專頁寫過一些技術文，現在才算上是恆常出文。短短數月中，已感受到為何外國程式設計師如此樂 此不疲，即使要抽出私人時間，也會寫Blog出文。
平常人都能掌握的Programming 原則
2019-01-29
大家會定時整理自己電腦中的文件嗎？大家看軟件工程師工作時，往往會發現他們的檔案總是井井有條，資料有條不紊地排列。難道學習軟件工程能使人變得 整齊？原因其實在於軟件工程師經常需要處理大量檔案及資料，因此發展出一套完整的工程原則(Engineering Practice)，久而久之，就掌握了資料管理 的要訣。而如果平常人也掌握了這些工程原則，在日常電腦使用，其實也有不少好處。
專家級新手
2019-03-19
今次要介紹的，是一個非常常見之現象，不論你是學寫程式、學做甜品、學寫文章，又或是練習球技、體能訓練等，都會經常窺見其身影。 想像一下：你的朋友問你：「你的駕駛技巧好嗎？比較起其他司機來說如何？」如果你本身有駕駛執照，但是不常常駕車，大概你會回答：「中規中矩吧，平均水平」；經常駕駛的人，因為經驗豐富，會覺得自己是中上甚至良好之水平。然而，這個想法人人都有，卻與現實完全相悖：因為任何羣體之中，必然有一半個體在中位數(Median)以下，而一項經典的調查發現，八成的司機都認為自己的駕駛水平在平均之上，這明顯代表在駕駛技術的世界上，大部份人都有自視過高的問題，也代表其實大多數司機，無法準確判斷駕駛技術之高下。