Skip to main content

如何對治思維籠統

· 8 min read
Gordon Lau
Gordon Lau
Software Engineer & Programming Instructor

以下情況相信大家似曾相識：

A公司希望完成一個專案，將專案外判給一間軟件開發公司B開發，專案開始後，總發覺B公司不太理解要求，製成品也與要求相去甚遠，與B公司的 程式設計師多次開會亦結果不彰，最終專案「爛尾」收場，A公司不得已又將專案再外判給C公司，同一問題似乎又再上演...

探究原因，何解此類問題經常出現？原因往往在於A公司的相關負責人本身沒有編程背景，因此給出的要求相當籠統，B公 司的程式設計師亦不理解A公司期望，因此導致專案最終失敗。

讀到這裏，大家可能會嚷道：「A公司的負責人當然沒有編程背景啦，不然A公司自己做就好了」其實問題重點不在於A公司本身是否有編程的專才，而在於產品 負責人(Product Owner)與程式設計師溝通良好與否，即使A公司本身有編程Team，如果溝通不良，專案失敗是不會改變的。要討論溝通良好與否，先 要理解平常人的思維方式，與程式設計師的思維方式，往往差別甚大。

Playing Mahjong

Source: https://www.cbc.ca/life/culture/the-beginner-s-guide-to-the-greatest-pastimes-mahjong-1.4739808

由打麻雀開始​

大家懂得打麻雀嗎？如果你不懂打麻雀，或猶記得學打麻雀的事，你家人／朋友教你 的時候總是會說：「邊學邊打吧！」開始時的一兩小時內，總是雲裏霧裏，大惑不解，不知道發生了甚麼事情。那為何麻雀那麼難玩，一兩小時都無法自動學 會，你的家人／朋友何不先解釋規則，再邊學邊玩，不是更事半功倍嗎？原因很簡單，因為麻雀規則很難玩，而大多數人不習慣有系統解說複雜事物。以下是香港麻雀的一些規則，大多數人潛移默化學會了玩法，但不能夠以清晰文字解說給未明白的人：

  1. 麻雀有144隻牌
  2. 同一時間有四個人參與，每個參與者在非食糊時有13隻牌，食糊時有14隻牌，比正常牌數多稱為大相公，比正常牌數少稱為小相公。
  3. 開局須經過洗牌
  4. 食糊時需要符合一定的牌格，以三隻為一組，三隻順序，或是三隻一樣的同類（筒子、索子、萬子、其他番子）牌，食糊時該有四組，加上另外一對一樣（一對眼）的牌。
  5. 開好局，擺好牌以後，每個參與者需抽一隻新牌，打出一隻牌，因此總數維持13隻。

還有許多許多規則，不能盡列。想像一下，要逐款解說，相當不容易！

Mahjongs

Source: Wikipedia

啟示​

打麻雀的故事有何啟示？看起來平凡的事物，要以文字解說，遠比想像中困難。造一個網站，也是類同，看起來簡單的網站，也要花費不少時間，筆者曾 不只一次聽過有客戶的要求是：「將網站造成和Facebook/Airbnb差不多就可以了。」要造成Facebook或Airbnb一樣，當然要投入如Facebook 及 Airbnb一樣的資源，只以一個人的力量，當然是不可能完成。程式設計師由於以開發程式為業，習慣了細緻之思維方法，去理解事物每一個細節。所以當無任 何編程經驗的產品負責人，與程式設計師解釋心中所想時，常常會出現思維籠統的問題，無法以準確文字表達要求是甚麼。

如何對治思維籠統​

所謂思維籠統，就像上面「邊學邊打麻雀」的故事一樣，要開發者邊做邊理解要求，省略了最重要的解說步驟，開發者又不是產品負責人肚裏面條蟲，當然就 無法得知真正的要求是甚麼，造出來的專案當然爛尾收場。 要對治「思維籠統」的問題，最佳的方法當然一而再，再而三那樣將要求提煉(Refine)得更精簡準確。

試比較以下幾個關於一個簡單TodoList的要求：

  1. 我想做一個Todolist，可以新增、更改、刪除、讀取TodoItems。

  2. 我想做一個Todolist，由React JS編寫，完成品將會部署在Amazon Cloudfront之上，前端的軟件需要使用Redux 作為狀態管理工具。後端軟件需以Node 編寫，使用Express框架，並使用PostgreSQL作為資料庫。前端及後端都需要寫單元測試(Unit Testing)。

  3. 我想做一個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)。

前端界面需如下圖

TodoList

Source:http://todomvc.com/examples/typescript-react/#/

可見，這三個要求，隨著加入愈來愈多資訊，要求愈來愈清晰無歧義。 第三個要求很「長氣」是嗎？可是其實只有第三個才算是及格的軟件要求(Software Requirements)。

總結​

要寫出第三個版本的要求，需求的當然不只common sense，需要有軟件開發經驗，以及少許用戶設計的經驗，現在有不少簡單易用的 用戶設計軟件如Figma，也令整個過程更為簡化。