Y04 POC的產出不適合直接使用

有些專案在競標之前會先製作POC（Prototype of Concept），等到專案開始後會有人直接拿POC裡的產出放到真正執行的環境裡。理由當然是說這個功能在POC已經做出來而且可以執行，只要再加上相關環節後就能擴充到足以驗收的程度。

這當然是從“可以驗收”的角度來看待POC的產出，但是深入一層去想，POC這個名稱已經很清楚地說是“概念的雛型”，目的在於驗證想法是否可被實現。在架構已經選定的前提下，自己在製作POC時思考的是：
●什麼時間點需要執行這個功能（入口）
●執行這個功能時需要哪些步驟（流程）
●每一個步驟各需要什麼元件來支援（動作）

決定執行的時間點後可以導向入口，在專案裡掛上功能的入口很簡單，但是需要調整傳入與傳出的資料。流程是功能進行的順序，在POC時幾乎都只製作正常的流程與幾個需要呈現的錯誤，要在專案實用就得加上所有的錯誤控制。動作方面大多會使用到其他元件提供的功能來組成自己的分解動作，倘若是第三方提供的元件使用的方式會比較固定，但要是使用元件預定是在專案內才設計的就會有被變動影響的風險。

達成目標經過的每一步以及收送的資料內容都需要經過設計，這些並不是在製作為了測試概念能否執行的POC時會考慮到的，僅求一時之快將POC的內容直接引用，未來勢必會出現設計想法不同的落差。能夠只作些小修改就融入專案設計算是最好的，但是大多數的情況還是需要打掉重做才能符合專案需要。

曾經在專案後期被POC改寫的元件卡著上下不得：想作些專案需要的修改時覺得綁手綁腳，想重做又會浪費重新測試的資源。捨棄POC所寫的功能而僅參考執行概念再重新設計出新的元件，是我決定的作法。

X05 積極主動的態度

在前面的例子裡，為了同步同一階層人員的想法建立的同步機制，相當於建立了一個“物”；而一個新“物”的產生所增加的“事”，至少需要讓不同角色的人知道怎麼使用，還有維持其運作的管理與維護。使用關係到個人怎麼操作，是每個人都必定要會的，但是管理與維護的工作卻不是明確屬於任一個人的。

在一個團隊裡要做的事非常多，明確屬於個人的責任就是自己所該做的，另外還有許多是沒法歸屬責任或是多人共同用到的。觀察人們面對那些公共事項時的反應是很有趣的，當然大多數人的心態是多一事不如少一事，拼命地閃躲或是推卸責任讓別人來負責。從個人的角度來看，會有這樣的反應是很正常的。

將視野提升到專案來看，當人們都自掃門前雪時就表示著那些事可能落在不適任的人身上，或者是被敷衍地完成，進而造成做出的結果並不符合眾人真正的期待；倘若很不幸地這些公共建設沒有做好時嚴重影響到日後每個人的工作方式與效率，就會造成深遠的影響。對於管理者來說，看著成員們動不動就說“那不是我負責的”或“我不知道”時，也會有深深的無力感吧。

在專案裡客戶會打電話過來問些問題，若詢問的對象不在，接電話的人通常會說那是誰負責的，然後就幫忙留話。這樣做當然沒有錯，假如態度積極一些，直接問清楚要問的問題後再問負責的人細節後再回覆客戶，對專案來說代表著反應機制的迅速，對個人來說可以多知道一件事情。具有如此積極態度的團隊，無論士氣或是效率都會提升很多的。

X04 同步的速度與內容是團隊戰力的關鍵

用這張圖簡單地描繪專案裡的人員階層與關聯，從人員間的關係可以看出訊息的傳遞普遍存在於每個人，同樣一個訊息需要根據不同的對象各自傳送一次。今天領導者A解決某個重要問題時剛好成員B不在身邊，他就將原因與解法對成員A與成員C說明，這個時候就造成成員B根本不知道發生過這件事。

將事件與對應的處理讓其他人知道的最佳解決方式是留下記錄。如果有個機制記錄每一天發生的事情與對應處理，那麼成員B回來後只要查詢一下就能知道那件事；如果有個機制記錄特定事情的歷史軌跡，那麼任何一個人都可以交待那件事的來龍去脈；如果有個機制記錄事情的類型，那麼可以延伸查詢相同類型的事件都哪些……。

記錄的類型與管理方式會造成不同的效果。電子郵件、文件、程式、錯誤回報系統都可能會有事件的記錄，假如保存與歸類的機制都沒有定義，所有的記錄就形同一盤散沙般無法整合。我們不應從記錄的角度來看待說只要在相關的地方註明清楚即可，而應該從事件的角度來看如何從一件特定的事件找到所有相關的一切，像是處理方式、前因後果、改變與影響等等的資訊，如此才能全面性地來看待該事件。



這正是我重視知識管理系統的原因，因為它提供的是記錄內容的整合。一個歸類後的題目，可以在類型與事件中交互查詢，也能深入一個問題內找出所有的關聯、追查所有的產出，更重要的是累積下來的資訊都可以在任何時候給任何人作為處理事件的標準參考教材。（當然，資訊的關聯都是由人所建立的，唯有全部成員都有正確的觀念後才有可能施行這個想法）

可以試著想像在需要某些資訊時，不知道放在哪裡、不知道是否完整、不知道為什麼要這樣做、不知道做了有什麼影響這些狀況都會影響一個人的認知與反應。從需要者的角度建立好他們需要的資訊是一種只需建立一次卻有永久影響的花費，資訊在成員間同步的速度與內容將會決定該團隊的戰力強弱──因為團隊的能力強弱並不是看最強的有多強，而是看最弱的有多弱！

X03 定義出正確的客戶並找出全部的需要

已知有一個重要的功能即將交給自己開發，這個時候在心裡盤算的是些什麼呢？大多技術人員都知道需要定義出功能清單作為開發的基準，功能清單應由提出需求的人認可才算數。但是若承接的功能是屬於底層架構的功能，未來會有許多專案人員根據這個功能來開發許多程式，這個時候心裡應該盤算什麼呢？

優先考慮的當然是誰來驗收這個功能？從句意來看很明顯地有兩類客戶：
●使用者：需要這個功能可以正常執行的人。
●專案人員：基於這個功能來開發其他程式的人。



做出可正常執行的功能給使用者驗收是一定要的，因為你的東西一定要先能用才有可能收得到錢。但是專案人員是使用自己產出的功能予以加工而包裝出使用者要的東西，需要考慮的項目就多很多。像是：
●功能的目的與限制條件
●使用方式與範例
●定義檔的格式
●設計的過程與想法（維護需要）
●輔助的設定工具（使用方式太複雜時需要）

雖然對專案人員來說提供這些是正常的，但要讓專案人員能熟練地使用必須要額外付出不少努力。聰明的人自然會提出能讓自己信服的理由：“這個功能最終目的是要讓使用者正常地執行，因此只要符合這個目標即可”，所以就縮小了客戶的範圍與要做的事；主管們當然很高興聰明的人可以用很短的時間“做好”這個功能而且驗收，可以繼續處理下一個功能創造更多的產能。

主管只看產能且設計者只看驗收的情形下，專案人員需要的東西大半被忽視，難以訓練成用快速的方法做出正確的東西，工作久了自然會有嚴重的倦怠感。專案人員在主管眼中僅是可被取代的生產工具而已，發出的聲音幾乎都被忽略，在此狀況之下公司的開發團隊文化就只能取決於聰明的人怎麼做了。

X02 領導的風格決定了文化

迪爾（Terry Deal）與甘迺迪（Allan Kennedy）在“企業文化”（Corporate Cultures）一書中明示：“企業文化是公司員工上下一致共同遵循的行為準則，一套做事情的方式”。企業文化也代表“在這裡，事情如何完成”與“組織成員間的互動關係”。

工作上有時遇到某些事情沒處理好，會聽人講起公司文化的影響與重要性。原先認為公司文化是種虛無的概念，在無形之中慢慢自行形成的；但經歷過一些狀況之後卻感覺到文化的形成主要在於“上行下效”，每個團隊的領導者如何做事連帶地會影響到團體內所有成員的做事態度。這個感想也剛好對應了前面的企業文化定義。

領導者在意的面向會影響成員的做事方式，絕大部分的領導者基於成本與績效的壓力，想法都是目標導向的。僅在意“事情何時完成”時成員就會找出最快符合驗收條件的方式來做事，連帶地成員之間在分配任務時也只在意自己的目標何時可以達成。每個階層都用自己的目標來檢視所有的事，眼光就逐漸變為短淺，落在自己頭上的事才算事，別人的事能夠不沾上邊就不要去碰，久而久之自然就會形成冷漠的公司文化。（切割系統介面如果也能切割到這麼乾淨的話，會是很令人佩服的事，可惜二者總是恰好相反）

領導者普遍在意的還有“解決眼前的問題”，資源的調度都是為了要快速地解決會影響驗收與成本的問題，只要搞定跟錢有關的問題就好，其他的都看不上眼。若是再搭配之前形成的冷漠文化，公司的氣氛低迷，團隊的士氣渙散等現象自然會跟著出現。更重要的是問題的根本原因從來都不會被搬上檯面來討論，也沒去研究未來如何要如何避免相同的現象，成員就這樣眼睜睜看著幾個同樣的原因造成各種不同的問題，令人疲於奔命。

希莉格在“真希望我二十歲就懂的事“書中說：“聰明的人往往陷入一個陷阱：他們寧可做〔聰明〕的事，而不是〔正確〕的事。所謂聰明，就是最符合自己的利益。”如果要提出公司文化形成的最重要因素，我深深地認同這一句話。

X01 系統的功能來自客戶需要的服務

系統的開發大多著重於系統如何滿足使用系統者的需求，對系統使用者作需求訪談後就會往下展開系統內部的相關分析設計。近幾年IBM提出服務導向架構（Service Oriented Architecture）的想法，資策會也在推廣服務體驗工程（Service Experience Engineering）的方法，最近剛好有機會接觸到這些從不同角度看待事物而產生的概念。



開發系統的時候注重的是從使用者角度做事時系統提供的功能；在以使用者為中心處理一件事時，系統提供越大範圍的支持會讓使用者做事越輕鬆。然而在很多情境下，像是銀行、電信局、郵局等等的櫃檯人員，使用者會做什麼事情是根據臨櫃的客戶的需要而決定的，使用者端提供越快、越正確、越完善的服務就有助於客戶的認同。（此時的系統只屬於服務的一部分而已）

既然發動使用者做出對應行為的真正原因是客戶想要的服務，那麼研究客戶端的需要便形成了現在的趨勢。定義出客戶在特定情境下想要達成的目標，洞察客戶在該情境下的行為、對四周人與物的互動，從中找出可以改善現有服務或是建立新服務的地方，就有機會提供給客戶更好的服務體驗並有機會為公司帶來更多的客戶。

在系統的關係圖上從Actor一分為二，在系統方面需要的是方便好用的整合環境，在客戶方面需要的是提供更切合需要的服務。原則聽起來並不難，但是要從原本的技術角度轉換到客戶角度來看待這層關係，視野很容易就被原有的思維所限制住而難以突破──至少我就經歷過這段痛苦期。

所有的事都發生的原因，也有其完成的目標，發掘出最根本的需要並依此展開為實行的細節就更有機會真正地滿足原始的需求。這不是很簡單的道理嗎？

Y03 與理論型同事對設計作法的討論

Ｅ主管是之前提到過的理論型同事，在技術部門裡可以說就只有我與他有把握能夠將分析與設計全部轉化為可以實現的作法。最近我們在參考RUP想要定義出一套可實現的OOAD作法，但是為了用什麼而做的議題有了一場“熱烈”的討論。

他的想法主要是參考大師們的說法，因為那些都是根據有經驗者的智慧結晶而定義出來的；不管是分析設計時應該做的步驟、使用的工具與應有的產出等等，都鉅細靡遺地遵循書上的方式。我則根據部落格上的心得，先把使用UML工具會作出的產出定義為程式碼，再逐一將分析與設計的想法衍伸在程式碼裡。

我們的分歧點在於“不應該用程式碼作設計”。Ｅ主管的感覺是直接產出程式碼而不先模組化就會回到以前設計不良的窠臼，同時也提到以前在學校若先寫出程式碼會被教授責備根本不作設計的事，當然也聽不進去我希望解決之前使用UML工具進度緩慢、達到分析與設計模組追溯的目標，因為他暫時落入“馬上有程式碼絕對作不出好設計”的想法中。

爭辯了一陣子雙方僵持不下，最後我只好換一種方式說明。先解釋說，現在有一個功能與Rose完全一樣的UML工具，採用的OOAD作法也與RUP完全一樣，然而那個工具的存檔格式剛好與Java程式碼一模一樣。今天我們的OOAD作法每一步應該做什麼就同樣地在“程式碼”會有什麼，這樣一來無論分析或是設計都能夠採用我計畫的工具作出全部的管理與追溯；分析的“程式碼”則在build產出時不處理而僅作為模組化的分途。

Ｅ主管認同了我的說法，但有個前提是：要先明確定義好OOAD的詳細步驟後，才能逐一定義與我想法之間的對應。前面的討論對於modeling來說都只是產出的物，先要有應做之事與其順序後再去談應有之物；這也正是做事的基本前提。

Y02 如何寫出難改又難懂的程式碼？

一直都在談如何作好分析與設計，這回就來個逆向思考的建議。

●目標：如何寫出難改又難懂的程式碼？

想像公司早上第一個到的人所要做的事如下：開鐵捲門、用識別證開門、開一號盤的15個電燈開關(1-15)與二號盤的15個電燈開關(16-30)。現要設計一個功能來實現這些行為，建議使用以下推薦的方式來撰寫程式，保證可以達到難改又難懂的特殊效果同時不會影響功能的正常執行。（此等技術暫時命名為程式碼的人工混淆化）

●Class、Method與Field的隨興命名
　效果：讓人即使看到名稱也不見得知道這就是他要找的程式。
●Class隨便放到某個Package裡
　效果：與上一招同時施展，可以讓人感覺Class在某個雲深不知處的地方。
●Class、Method與Field內外完全不寫任何註解
　效果：讓別人從眾多的程式碼反推你原本想要做什麼。如有人能完全識破此機關的話一定要選為衣缽繼承人，因為那是萬中無一的奇人。
●執行的大大小小步驟都寫在同一個Method
　效果一：搭配前一招時可以讓邏輯處理的焦點忽大忽小，明明在講進門要做的事卻一下子跳到拿出識別證的動作，完全不知道在幹嘛。
　效果二：可以保護自己想出來的程式解法，例如自己發明一個很帥的識別證拿法就可以直接寫在Method裡，其他人想要用就只能copy（因為要抽方法就得幫你改寫程式，以我所知沒幾個人有這閒工夫）；有天你發現姿勢可以更帥時可以保證只有你知道，因為別人抄到的是你前一次的姿勢，跟你肯定沒得比。
●不要花時間去想執行發生錯誤時該怎麼辦
　效果一：程式碼裡一定存在著錯誤，這樣一來可以用更多的錯來證明這句話是極為正確的。
　效果二：搭配前前招使用，可以讓別人在不知道處理邏輯之餘更不知道發生錯誤要怎麼辦？同時讓老板知道只有你能搞定這樣的錯誤處理問題。（註：平時常逛逛求職網站是有助益的，因為總有一天會發生連自己都搞不定的重大問題……）

採用以上方式撰寫程式碼，將會產生下列各方面的效益：

●個人方面：
　加速個人的效率與產能（不用抽Class與Method可減少思考與重構時間）
　提升個人在開發團隊中的重要性（沒人有把握修改別人的程式）
●公司方面：
　加強與其他公司合作的意願（即使程式碼外流也毌用擔心技術被學走）
　減少額外控管程式碼的成本（只要從jar file反組譯回來就是完整程式碼）
●產業方面：
　創造更多的營業額（因應提高開發與維護的成本會增加系統的售價）
　提升開發人員的素質（無法看懂別人程式碼者會被淘汰，只留下適任者）

註：最近一個多月狂寫公司某份計劃書，因而導致這篇文章的風格被影響。

Y01 程式設計是藝術創作？

Ｋ主管常說一句話：“程式設計在實質上是一種藝術的創作，同樣的需要被不同的人實現時會有不同的產出。”就我所知有不少人都贊同這個觀點。前陣子我也認為這個說法挺有道理的，可是總覺得似乎有哪裡不對勁；思索幾天之後終於有了不同的想法而與Ｋ主管聊起這件事。

我提出的切入點是人像的雕塑，這很明顯是屬於藝術的範疇，每一位作者都可以任憑喜好去製作各式各樣的人像。接著提出同樣屬於人像創作的秦朝兵馬俑，我們都曉得兵馬俑的數量很多，雖然姿勢、表情與裝扮都有不同，但是服裝與身材卻是大致上相同的。再極端一點可以想像有一國的統治者想在全國各地放置出他的雕像，於是他穿上最喜愛的服裝並擺出某種姿勢，要求全國所有工匠全部都得做出一模一樣的人像。（以上的前提建立在工廠出現之前，所有的人像都必須經由手工製作）

從上面的說法，我們可以發現隨著要求的規格越來越多，每個藝術家的創作也可以從依各人隨興而作演變為具有統一規格的產出。同樣的道理也適用在程式設計之上：在沒有規範時每個人寫出程式碼的想法與風格會是相異的，隨著種種規範與規格的建立將會調整每個人的想法與寫法，漸漸演進為所有人產出的程式碼每個人一看就明白。

Ｋ主管認同了我的看法，想法調整為：遵循規範與規則的部分像是工程，其他的部分則屬於藝術的創作。然而隨著規範與規則訂定地更加完整，藝術創作的範圍勢必越來越小；等到某一天程式設計的一切都有人定義出良好的規範與規則時，programmer是不是真的就會像作業員一樣，每個行為都只能根據該生產線的SOP找出適合的零件來組裝產品呢？