一般，SA (這裡是指與客戶作需求訪談的分析師) 若是需求規格作得不好，拿回來給自家的程式開發人員 Coding， PG (Programmer) 肯定會哇哇叫，覺得需求不明確，無法正確實作。 SA 與 PG，長久以來，總是存在著溝通上的隔閡，包括看待系統的角度、包括價值觀等，經常是大不相同的。

不過，我就認識一個實做能力相當高強的軟體工程師，年輕脾氣又溫和。 最重要的是，他對軟體設計有著相當高度的熱忱，在他所負責的開發專案，總是會把一些物件導向的觀念帶進專案實踐，反正，他的專案主管不會管他用什麼技術做出來，對 PM (Project Manager) 而言，準時交付專案才是最重要的事。 有趣的是，他說全公司上百多人，雖然公司已走向 CMMI 甚至往 Level-5 的認證，但是全公司只有他一個人在用所謂的 O-O，其他人還是走向 Web-based, Form-driven 的二維開發方式。 反正，CMMI 認證可不管你用什麼開發流程或技術，只有一個重點，就是要能作出美美的文件，可以說服評審委員、取得認證，這才是一等一的重要。

話說，這位年輕工程師實做能力非常強，所以相對多少也有取得專案主管與同僚的信任，甚而說服她們採用一些 "新" 的技術，例如 使用案例 (Use Case)。 喔，這位年輕工程師雖然是典型的物件導向狂熱份子，但是可不會把所有所謂他所認知的 O-O 給整個 Apply 到專案上，就是只採用一些他認為是關鍵性的技術，例如在 O-R Mapping 中，他甚至自行研讀 Martin-Fowler 那本 "POEAA (Patterns Of Enterprise Application Architecture)" 裡面所介紹的一個設計樣式，Repository，來實踐 O-R Mapping 的機制。 反正就是以實驗的心態，然後利用現實所開發的專案來驗證之。

上面他的事蹟是順帶一提的，我真正佩服的是，專案很趕，他也從不叫苦，反正，他知道他自己在做什麼就是了，而且他也有他的興趣、熱情，以及未來期許當個軟體架構師為目標。 這些都只是過程，而且往正面一點想，他有實際的專案可以拿來實驗，那還不好？ 對比於此，我可是對那種對現狀很不滿但又看起來很無奈、經常哇哇叫的軟體人員總是不以為然，要嘛，就是皮一點待著，裝著很忙，作個樣子就好了；要嘛就是多提昇自己的能力，待價而沽，自己選擇想待的單位。 喔，那位工程師所待的公司環境可是不好的，與他聊天才知道有些 "腦殘" 的大主管，竟然還會要他們自行開發如 Msn 這樣的 IM(Instant Message)用來作內部的溝通機制，真難以想像，難道你會開發出比這麼多大廠推出的 IM 還要好？ 如果有這樣的志氣，那還沒話說，但是，就是只有用來團隊內部的溝通，真的是 "吃飽閒閒沒事幹"。

還沒還沒，最最佩服他的，不只是他不叫苦而已，與他 Cowork 的 SA，要交付的需求規格文件，主要是以使用案例來紀錄的。 但是，那個使用案例，除了案例圖有橢圓形 (代表一個個的使用案例)，還有那小人 (代表 參與者,Actor) 長得是與標準 UML 制定的一樣外，實在喔，嗯，不知道該如何形容耶，反正就是 "披著橢圓皮的狼"，一點都不叫做 "使用案例"。

要是我，肯定會哇哇叫，問題是我們這位仁兄，實在有大器，不管妳畫出幾顆橢圓，隨便畫，只要不變成正方形就好，他就是可以生出應用程式碼來，還真的可以跑。 說真格的啦，中小型專案，的確最關鍵的還是在實做能力。 在需求分析與結構設計上的講究，不盡然是影響到實作，而其實主要是在於延展性與彈性度、可維護性等的考量。

為什麼我們這位年輕的工程師可以這麼包容 SA，從來沒有怨言，甚至會主動補足這位 SA 的不足？ 後來我見到這位 SA 後，喔，換成是我應該也會有無限的包容了。 因為：

1. 這位 SA 是可愛美麗又活潑的女孩子。
2. 原來已經是變成了我們這位仁兄的女朋友了啦。>-<

所以啊，這也就是我為什麼一直主張 SA 最好是女孩子來擔任啦。 除了女孩子對客戶的需求訪談比較有耐性外，回到自家來，團隊內部的開發工程師也會比較包容、更能溫柔的對待了。

朋友啊，是非要溫柔，慈悲得公理，智慧少煩惱。 團隊能和諧，我們的專案一定會往幸福安定之路的美麗心境界。 🙂