You are here

方法論

方法論導入的障礙

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

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

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

標準化

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

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

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

是否需要資訊架構決定文件

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

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

關於方法論

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

Subscribe to 方法論