X34 開會時的一句話

開部門的PM會議時, 有人提到某同事都以自己的想法開發功能, 不僅進度落後而且產出也不好用, 還堅持自己是來做產品而不是做專案.


大家在討論如何修正他的想法時, 我提出應對他說:” 做產品是做出讓客戶滿意的產品”, 不過當時只被認為是耍嘴皮子的回答. 後來我發了一封信強調這句話並不是玩笑, 而是一種專業的基礎. 全文如下:


“做產品是做出讓客戶滿意的產品”, 這並不是玩笑話.


當然, “依照規格書來產出程式”一定不是錯的選項, 但是我們也明白在台灣專案裡使用的規格書從來沒有完備過, 依照一本不夠完整的規格做出來的產出, 在使用者的眼裡也肯定是不完整的.


我們產出的程式是給人用的, 平台是提供給開發人員設計交易用, 而整個專案所要做出來的產出是要給客戶使用的. 不管對象是誰, 沒讓操作對象感覺功能正常又方便好用, 都不能算是成功的結果.


昨天測試授權時, 有些錯誤(例如授權等級不足)無法用精確的訊息呈現, 原因是規格書裡“沒有提出全部要顯示的錯誤訊息“, 所以現在的作法是先將可授權卡片內容抓出比對而沒有帶其它資訊; 即使在規格書裡的可授權判斷寫著“要同單位且授權等級大於等於授權條件規定的主管”.


三年前在其他客戶那邊討論時, 我也對承辦人說過: ”這幾種方式都可以做, 就看你們想怎麼做”, 承辦人很嚴肅地回答我說: ”什麼都由我們決定怎麼做的話, 那我們找人外包開發就好, 所以這方面的作法請你們依照多年來的經驗, 專業地提出一個最適合我們的方案”.


“要同單位且授權等級大於等於授權條件規定的主管”這條規則我們一定會寫在程式的判斷邏輯裡讓符合的時候可以授權, 但是每一種判斷的失敗不是都應該“明確地”提供錯誤的原因嗎? 尤其與人有關的錯誤, 操作者更需要知道哪裡出問題了, 才會知道如何去解決.

從使用者的角度來看待自己開發的功能, 而不是自己的想法或只做出規格書的範圍, 才是更邁向專業的基礎.

[X] 網誌的最近變更

導引投影片下載頁面 [ 請按此 ]

功能真的是隨便用直覺式作法都可以完成
但是為了系統的彈性與品質，就需要額外投入時間來作設計
"做得快"與"做得好"，這兩個條件通常是互斥的
我相信－－
唯有適當的佈置與對應的工具，才有機會讓系統開發又快又好

[投影片進度]
已經製作單元 － 12 (完)
文章關聯建立 － N/A

[最近修改]
2009/07/14 － 導引投影片的內容製作完成。（還沒建立文章關聯）
2009/07/18 － IBM網站這篇MDD的文章 [原始網頁] 表達了程式碼與模型的相輔相成；RUP課程的講師的教授內容也很棒。
2009/10/24 － 推薦一篇文章：[別把專家當笨蛋] (吳俊瑩)
2010/01/13 － 兩個 Google協作平台都被關閉，發信詢問的回信：We disabled your Google Sites site for violatingone of our Terms of Service or our Program Policies。連放置自己寫的程式都不行？
2010/01/17 － 重新申請一個[協作平台]放置自製的投影片，至於程式產出就當作做開心的吧。
2010/01/20 － 如果感覺內容太雜亂，請先看[Y01]、[Y11]、[Y12]、[Y13]與[Y14]後再瀏覽[導引投影片]，就能大致明白我想做什麼。

X33 熱水器瓦斯氣爆的親身體驗

嚴重警告：此為極度危險之測試個案，沒有練過切勿依內容重現！！

緣由：在變冷的夜裡準備泡個熱水澡，卻發現熱水器的電池沒有電了

準備：將剩餘量大約2/3的20公斤瓦斯桶妥善連接到使用將近十年的瓦斯熱水器，點火用的電池先故意拆卸下來以模擬沒有裝好的狀況。

操作順序：先將浴室的熱水水龍頭轉至最大流量，大約15秒（最好不要超過，以免效果過強）後在瓦斯熱水器還有點火動作時將電池裝好，應該可以立即看到成效。（頭部距離熱水器不超過半公尺）

結束：此時的瓦斯熱水器的火依然沒點著，使用後切忌要將瓦斯關閉。（每15秒重覆裝電池的動作是否能持續重現同樣效果不得而知）

體驗感覺：以人體的五感加上發生前、發生時、發生後加以敍述。

●發生前
視覺：專注在安裝瓦斯熱水器的電池。
嗅覺：無。（若已能聞到瓦斯味，請立即中斷並在半小時後重新進行）
聽覺：無。
味覺：無。
觸覺：因天氣冷而感覺微涼。

●發生時
視覺：眼前瞬間冒出直徑接近一公尺的鮮黃色火球，並立即消失。
嗅覺：無。
聽覺：轟然一聲。因距離過近而無法判斷有多少分貝。
味覺：無。
觸覺：臉上有些微暖意。

●發生後
視覺：因視覺暫留而有短暫黑暗，約1至2秒後能再度看到瓦斯熱水器。
嗅覺：無。（如有焦味表示耽擱時間過久，可以考慮重做）
聽覺：聽到剛才的巨響在遠處傳來多次回音，並且夾雜數次鄰居開門或開窗的聲音。
味覺：無。
觸覺：臉上仍有些微暖意，不知是被火烘的還是怎地。

結語：前兩天才在電視上看過一段救難訪問，其中的消防人員說“明明目前什麼都很好，卻沒有辦法知道下一秒會發生什麼重大的改變”，現在深切地明白其中意味。

事件從開始到結束真的只是一瞬間的事，連眼睛都來不及眨而完整目睹過程；而且心裡並不像其他人所陳述那樣會將人生重要時刻快轉一遍，根本只是保持完全地空白。

最後，問了一下在旁見證的小朋友說我有沒有變捲髮？聽到“沒有”的回答並且到浴室鏡子前確認沒錯之後，留下了這份記錄。

後記：更換新的熱水器時，我同意安裝人員使用內附的瓦斯控制器。看到拆下的管線上連接著幾個月前購買的瓦斯防爆器，內心真有點五味雜陳；原來是是有這麼多的巧合放在一起才避免一場可怕的事……。

X32 程式寫作員的未來(10)──便利的學習

前幾天派駐國外專案的人回來，談到一位從台灣過去支援的同事學習上發生的狀況，同時提起國外客戶訓練新人的時間很短、而且訓練後人員的素質都有一定的水準；回頭看看自己的團隊，總是覺得距離那種程度還很遙遠，主要是因為沒法產生出有助學習的文件而只能請新人“自己看，有問題再問”的緣故。

在系統開發方面，可以想像新人面對兩種不同開發方式時所遇到的情況：在沒有工具的狀況下只從系統結構面切入，需要學習的深度與廣度範圍過大且不容易找出規則順序都會帶給新人很大的負擔；在使用開發工具的狀況下，對於需要關心的內容都已經被收集在工具裡，而且是順著思考邏輯（僅有少數實作被參考）編排，比較有助於新人進入狀況。



當新人比較瞭解開發規則後，都會需要跟隨著進入程式碼研究實作的方式，這時候就會遇到程式碼很難看懂的問題。連幾位資深人員都互相認為其他人的程式碼寫得很難懂，又怎麼能期望新人要快速看懂他們的程式？運用一些撰寫思考習慣的改變，鋪陳出任何一個“正常人”都能迅速讀懂的程式碼應是資深者的責任。將寫程式的目標從“電腦上正常執行”拉抬到“讓人一看就能懂”卻是極少人會去做的。

運用工具輔助開發人員明瞭系統開發的範圍與方法，需要深入研究時就由工具與程式實作的介接點進入，進入後的程式碼使用符合人類思考的面向編排並包裝。這樣的安排將有助於快速進入任何一個有興趣的區塊之中研究。

最後，故事再回到最原始的那張硬體架構圖。這個時候看著這張圖，心裡想架設在上面的系統是什麼模樣的呢？

X31 程式寫作員的未來(9)──知識的集中

要完成一件有目的的事，都需要知道其初始狀況、結束狀況與做法，還有必要的輸入資訊與輸出資訊；開發系統時自Use Case往下攤開更是有數不清地大大小小的事需要實現。每個人都各自負責一部分的事，但是要如何知道其他人是怎麼做事的呢？當然有文字與圖形描述的記錄會是比較容易看懂的。

除了如何讓成員心悅誠服地為了他人製作出符合範本的文件之外，怎麼妥善保存與利用所有有價值的產出也是個值得深思的議題。撰寫計畫書時需要某項產品的市場資訊，該市場共有三位業務負責，每一位都說不知道其他兩位有沒有更好、更適合的文件，寫計畫書的人要怎麼辦？某個專案開發時借用客戶的伺服器作為版本控管用，很久之後結案時沒有人備份下最後的版本，每位參與過的成員都說手上有他離開時的版本，現在有個問題需要修改最後程式再上版，公司該怎麼辦？

資訊的保存同樣可以根據共用的類型來決定存放的位置，從最底層依序向上（參考）或許可以分為個人、專案、業務、領域、平台、公司等，每一件事物都根據其應用的範圍放在對應的類型裡，輔以全文檢索的功能。每個人大多都會保留住經手的內容，除了分門別類之外甚至還會依時間版本存放，但是層級向上提升之後的資訊管理就不見得能夠做得理想。影響的因素當然很多，成員們是否認同知識管理的意義卻也佔了不少比重。

我們都習慣到Google搜尋不明白的事物，但是網路上絕對搜尋不到同事用什麼想法建置手邊的系統，也查不到某一段程式會這麼寫的原因，這些專案特有的人為動作如果沒有記錄就會是消失的謎團。正是因為經歷過不少這樣的謎，才知道知識的集中會是影響團隊戰力的重要因素。

X30 程式寫作員的未來(8)──重用的資產

運用交易開發工具可以加快開發速度並做到一致化的產出，如果再進一步分析出交易開發地圖讓開發人員按圖逐一填寫，完成後就等於完成一支交易的訪談。交易開發地圖與業務流程地圖雖然對象不同，但是在基本概念上是很接近的：都是定義其流程、各個步驟與步驟內應完成的事，而這些最終都對應到交易的各個組成單位。

關於“物”所能做的“事”，可以將物定義為一個Interface再將可做之事定義為Method，但是以Strategy方式設定會更有彈性。例如前面提到的身份證欄位，與其使用Interface包含validate、getLocation、getSex等三個方法，倒不如將之獨立為數個Class由工具列出來讓使用者自行勾選要執行哪些來得方便且有彈性。這幾個身份證欄位可做之事（Class）是每個系統都會再重覆用到的，因此需要Reuse Repository來管所有重用項目。



藍色的虛線框裡表示的是使用交易開發工具產出AP執行環境內容的開發模式，Reuse Repository的角色是提供重用的資產給這兩者，不管是加快開發時的設定或是減少測試的時間都會有相當的成效。

Reuse Repository會有一套進管的機制來管理所有的重用項目，同時也要有一套建立版本的機制──該機制會將儲存庫的內容產生兩種版本：一種是給執行環境使用的執行函式庫與預設參數，另一種則是給交易開發工具使用的畫面與欄位資訊以及搜尋用的關聯檔。



上圖是Reuse Repository裡應該管理的項目，以及各個管理項目之間的關聯；關聯的用途是在交易開發工具裡編輯該項目時會列出符合篩選條件的其他項目。例如要新增某個交易畫面時，會列出儲存庫裡該畫面內所有的欄位，開發人員只要勾選這次畫面要用的就能帶入原有的欄位設定；當然逆向的關聯也可以查詢，像是選擇某個欄位得知在哪些畫面裡存在、甚至哪些業務裡有用到。

Reuse Repository在交易開發工具裡是很重要的一環。若可以再堅持所有該管理的項目都被儲存庫管理，還能夠達成所有管理項目都有各自目的而完全沒有重覆的“絕對重用”目標。

X29 程式寫作員的未來(7)──完整的工具

（先聲明，工具的結構還是概念性的想法，還沒有完整地串接起來。若有不通暢的地方請自行想像並連結。）

Application Editor與Transaction Editor是提供給開發人員使用的工具，但是系統的開發必須倚賴系統如何架構，因此還需要有架構人員所用的Framework Editor（技術上的）與介接交易與框架間的Application Framework Editor。它們與系統架構的簡單關係大致上如下圖。



系統開發時除了編輯系統與交易之外，有些會直接引用框架編輯器來編輯與框架相關的內容，編輯的成果都會存放在開發專案的工作區裡；要匯出為執行用的資訊時就經由Deploy Tool根據選用的範本轉出對應技術使用的內容。各種編輯器、Deploy Tool與系統架構的概念關係圖如下：



建立系統架構就已經是一門大學問，很多時候得經過多次修修改改才能勉強順暢執行，要維持不變的定義又增加了一些難度；編輯工具的架構與抽換範本的功能之規模（如果想做到“萬用”的話）也是相當可觀的。會不會有哪一天，這樣的概念為人們所接受而投入資源進行發展呢？

X28 程式寫作員的未來(6)──系統的開發

曾經問過公司裡幾位資深的專案成員，請他們簡單描述心目中理想的開發工具是什麼？他們在開發系統上的期望都很一致：希望有個工具指引SA進行交易需求訪談的步驟，依序完成後可以自動建立可在系統架構下執行的交易骨架，同時產生需求規格書（給客戶驗證）與設計規格書（給PG開發），PG依據設計規格書將交易開發完成。



專案的開發模式為了爭取時效，大多只由SA根據需求規格書範本作訪談並填入結果後，就讓PG以人工方式建立所有相關內容並進行開發，設計規格書幾乎都從缺；測試出與需求有關的問題有時會發生沒有同步修改需求規格書的問題。從需求到可執行內容之間有很多需要記錄且有緊密關連的內容，全部交由人工製作時不僅比較花時間而且易產生錯誤，如果真的有這麼一種交易開發工具的話……。

公司裡較資深的技術人員的走向都是往快速建立可執行的系統架構，認為工具只能作為輔助設定的用途，唯有我在思考著定義可以增進開發人員產能的便利工具（我想，是因為從系統架構層層堆疊設計到工具並不在“可執行”那條捷徑上吧？），有時就會戲稱自己為“工具型”的資訊人員。2010年第一季試做了交易開發工具部分概念的POC，試用過的四位SA一致認為運用這樣的工具可以節省現行開發方式25%-33%的時間。

分析一個交易的組成單位大致有：主要的畫面、畫面邏輯、欄位、欄位邏輯、Context欄位、交易流程、交易參數（根據交易流程中使用的商業模組而來）以及次要的週邊控制、報表格式、電文轉換等。我認為不管要開發什麼用途的系統，幾乎都可以套用這些元素來定義交易內容，因此才會有“萬用交易開發工具”的想法；至於系統tier切割的差異，同樣使用替換“範本”的概念來對應不同的實作。

交易開發工具會有以下幾種不同的編輯器：
●系統參數（AP層）──編輯環境與系統面相關參數
●Context（AP層）──編輯Context欄位
●交易流程（AP層）──編輯交易流程
●交易參數──編輯選擇交易流程後所有商業模組的參數
●畫面──編輯畫面、畫面邏輯、欄位與欄位邏輯
●報表──編輯列印的格式與相關處理
●電文──編輯主機電文轉換與相關處理

X27 程式寫作員的未來(5)──不變的定義

系統架構必須在很多地方維持不變的才能持續運用相同的工具來開發，這在運用自己程式建立的系統架構上比較難達成。原因是在進行客製化的開發常會改寫原先的設計（尤其前次開發堅持只做滿足需求的最低設計時），要讓系統架構維持住原有的運行模式已經很不容易，更何況還要滿足讓工具持續原有的開發方式？工具有很大部分必須是依賴系統架構來決定作法，以滿足執行需求的想法來開發系統是不可能設計出好用工具的。



使用別人做好的框架可以加快開發速度，因為其他人已經將他們的經驗值包裝在框架軟體裡，甚至還提供對應的編輯器來輔助，這時工具的重點就落在框架上因應專案而自行開發的部分。開發者當然可以什麼都不定義而只確保系統能執行就好，但是若希望運用工具來管理更大的開發範圍，商業模組化的設計加上貼近開發人員思維的定義勢必是考慮的重點。



將使用與實作切割好的話，還有機會達成只使用一套工具卻可以產出不同系統架構使用內容的理想工具。在工具上定義好系統可以做的所有“事”，在將匯出編輯結果時根據定義好的範本（虛線框的部分）產生適合在不同架構下運行的內容。倘使工具的範本再進化為可以因應不同硬體架構且能夠選用不同技術組合的各種不同範本，那麼只要再管理好資料與程式邏輯部分，就有可能只運用一套工具來開發各式各樣的系統。



這個理想工具雖然目前只是推測，但是在邏輯上推演卻是有可能實現的，不過在沒有資源的狀況下，這種龐大且複雜設計大概就只能想想而已吧。