方法論

By Euta , 8 November 2007

企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一...企業導入方法論時會面臨窒礙難行的其中一個問題,就是組織及任務編製的變革.筆者認為這是推動新方法實施的重大障礙之一.

嚴謹的方法論會定義資訊工作流程中,每階段應參與的角色與該角色所應進行的工作.這些定義與現行企業日常工作會有以下差異:
1. 與現有工作流程不同,亦或新增工作流程
2. 新增角色或角色定義不同
3. 新增工作產出

筆者碰過最麻煩的就是為了調配角色與工作流程,而必須進行組織改造與變革.以公家機關而言,新增的角色涉及相關組織章程的變動,因此以簡馭繁的方式通常是一人兼多職,最後的結果就是流於形式,不了了之.以民營企業而言,除涉及人事成本增加,另外最麻煩的就是權力的分配.通常這就是一般顧問案無法取得一致共識的原因之一.

By Euta , 1 November 2007

關於之前刺客兄提及的標準化一事,小弟在此進一步報告...從開發團隊的編製來看,大型開發專案若沒有在專案開始之前就制定各種標準,那保證是一場災難...關於之前刺客兄提及的標準化一事,小弟在此進一步報告.

一般軟體開發過程可分成兩個維度,一是時間軸的開發流程,另一是涉及成員的開發團隊.

不論是所謂傳統的Waterfall開發流程,或是新的Iteration開發流程,不外乎可分成以下的階段:需求收集>架構分析>細部設計>功能及壓力測試>上線>監控效能>回饋修改.在每階段會有不同的人員與角色參與,這些人員會使用不同的工具來執行任務.若是沒有標準化的機制,則可能發生以下情形:
1. 本階段的工作產出無法提供給下階段的工具使用
2. 本階段的文件必須花時間逐一解釋給下階段的人員了解

關於第一點,筆者曾遇過某一公司因為不同單位分開採購不同階段所需的開發工具A與B,導致業務分析師從A工具所畫的業務分析圖無法直接匯入細部設計工具B,使得程式設計師必須將該圖形重新再以B工具的形式畫一次.關於第二點,這就是為何每天會開不完的原因.再從資方的觀點來看,現在流行將程式編碼工作外包給金磚四國以降低成本,標準化工作產出才可能實現此理想.

從開發團隊的編製來看,大型開發專案若沒有在專案開始之前就制定各種標準,那保證是一場災難.相信各位看官多少有此經驗,不是嗎?

By Euta , 24 October 2007

關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答...建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要...關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答.

其實建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要.

資訊架構方法特別對於資訊架構決定文件有特別的描述.其中一項重要的內容就是必須將討論過程與決定的原因詳細紀錄於資訊架構決定文件中.或許有些人會覺得為何要花時間紀錄這些枝微末節?大家開了那麼多會來討論,不是已經有共識了嗎?

筆者曾於數年前參與一項新專案評估規劃,當時以為很快就可以拍板定案,接著馬上開工執行.沒想到因為種種原因,甲乙雙方都數度更換專案小組內的成員,使規劃時間一直延長.這時馬上就暴露了沒有資訊架構決定文件的風險.因為新成員並未參與之前的討論,因此對於建議書內所使用的技術與架構有不同的看法.因為規劃過程拖延太久,人員又變動,因此對於當初如何決議採用這些技術的過程,已經無法交代清楚.因此該案最後在新成員彼此的意見無法整合的情況便胎死腹中.

若是當初有把討論的過程詳加紀錄,讓後續成員能理解當初設計的架構為何?後來這草案是如何因應需求的修改,以及預算時間等因素的考量而變更,他們便可以理解整個故事的來龍去脈.撇開政治因素以外,其他應該尊重原來專案人員的決定,這樣規劃過程應該可以更順利.

不曉得各位是否也曾有此經驗?

By Euta , 18 October 2007

方法論在台灣一直不被重視,我的初淺看法是五千年來的民族性使然,無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與.... 關於方法論這檔事,小弟實在是一位菜鳥,因此不敢提出什麼長篇大論.不過關於這個主題,我是非常有興趣,因此希望能在此先拋磚引玉,引起大家討論的興致.

先就方法論本身在台灣一直不被重視這件事,我的初淺看法是五千年來的民族性使然,這應該是無法在短時間改變.諸位可以回想通常我們在興起做一件事的念頭時,不太會有一些像西方的邏輯思維計畫.原因是通常我們不會期望這樣的一個事件需要太多人參與,因此通常只要詢問周遭三五好友的意見即可,而且通常這樣一個事件歷時不長,會在短時間結束.比如大部分的人在買車或買房子時,會將所中意的標的物以類似招標工程的方式去分析,這樣的人大概少之又少.

畢竟牽涉的人少,就不需太多溝通協調.歷時短,就不會有太多的變化與意外.因此在方法論裡所強調的文件紀錄,流程控管就顯得多此一舉.但奇怪的是,買股票都會做什麼技術分析,產業分析,然後才買個一兩張,對於房子車子這麼大金額的資產卻很少用科學的方法去分析如何買,怎麼買,買什麼.可見這就是天性.因此若是以這種方法來管理一個登陸月球的專案,我想應該是永遠都不會發射成功的吧?