Wed, 2007-10-24 17:27 — Euta
關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答...建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要...關於上一討論單元中,刺客先生詢問如何產生好的應用系統,在此接續回答.
其實建置一個良好的應用系統原本就是使用方法論的重要目標之一.在提案建置初期通常會做一段評估規劃.在規劃過程中會探討未來資訊系統的範圍與架構,並討論所使用的技術等細節.這一單元想與各位先進討論的就是架構決定文件的重要.
資訊架構方法特別對於資訊架構決定文件有特別的描述.其中一項重要的內容就是必須將討論過程與決定的原因詳細紀錄於資訊架構決定文件中.或許有些人會覺得為何要花時間紀錄這些枝微末節?大家開了那麼多會來討論,不是已經有共識了嗎?
筆者曾於數年前參與一項新專案評估規劃,當時以為很快就可以拍板定案,接著馬上開工執行.沒想到因為種種原因,甲乙雙方都數度更換專案小組內的成員,使規劃時間一直延長.這時馬上就暴露了沒有資訊架構決定文件的風險.因為新成員並未參與之前的討論,因此對於建議書內所使用的技術與架構有不同的看法.因為規劃過程拖延太久,人員又變動,因此對於當初如何決議採用這些技術的過程,已經無法交代清楚.因此該案最後在新成員彼此的意見無法整合的情況便胎死腹中.
若是當初有把討論的過程詳加紀錄,讓後續成員能理解當初設計的架構為何?後來這草案是如何因應需求的修改,以及預算時間等因素的考量而變更,他們便可以理解整個故事的來龍去脈.撇開政治因素以外,其他應該尊重原來專案人員的決定,這樣規劃過程應該可以更順利.
不曉得各位是否也曾有此經驗?
討論主題類別:
說的比寫的容易
開發過程中,撰寫技術文件當然是絕對必要的,但是現狀國內技術人員,特別是應用系統開發人員經常是-
1.嘴巴可以說的口沫橫飛,但是要他(她)們寫文件,簡直比登天還難
2.即使有寫,也經常過於簡略,除了自己,大概旁人看了也不知所云
3.不尊重前人經驗,即使前輩有留下文件,後繼者應繼續遵從增修力求精進,但是大部份的人總有自己一套,好像不這樣無法表現自己青出於藍
4.沒有標準用語與格式,旁人無法抓住其精髓
5.自私自大心態,不思撰寫文件要字句斟酌精益求精,反而表現不屑做這種他們心目中的雞毛蒜皮小事
6.明明是寫最難讀次之說最容易,但是發達之路往往是重說輕寫,所以聰明人一窩蜂勤練天花亂墜神功,難怪無人願意好好下苦功勤練撰寫高水準文件
刺客兄果然是武林高
刺客兄果然是武林高手,深知江湖之險惡.
個人最讚嘆就是第六點.大部分主管每日忙的昏頭轉向,因此只能以聽覺管理,無法坐下來詳細閱讀.造成今日的"呼巄"文化盛行.
小弟剛踏入此行時,覺得最困難的就是寫報告."死工程師"的心態就是,我明明會做,而且也幫你做好了,為什麼還要我寫報告!隨著經驗的與日俱增方知寫文件是一種沉澱,協助自己進行邏輯思考,同時也協助日後回憶細節.
導入方法論的一項好處就是標準化.沒有標準化的文件,不是資產,而是垃圾.此項極為重要,他日另文再敘.
管理機制的引思
寫文件,這件事情的確是流傳久遠的爭執
小弟認為撰寫系統文件的確是需要的,不過背後支持這件事情的管理機制,卻常為大家所忽略
小弟 拋磚引玉提出下列一些想法
(1) 文件要怎樣寫才能讓別人看的懂(有共通的符號嗎)? 有人管理嗎?
(2) 文件一定要用寫的嗎 ? 可以錄音 ,影像儲存嗎? 不同的工作內容
造就不同習慣? 每個人用來寫文件的筆不一定相同?
(3) 可能用些平台工具來協助嗎??
不知各位先進有其它看法嗎??
既修史、也修身
非常贊同 Euta 所說的：要有架構決定文件
當然過去大家的習慣是不去做，不受重視是最主要的原因
頂頭上司的任期如果通常都短暫，那更是不值得認真
接手的人缺乏這類文件，無法窺見當初的決策取捨
對於可疑處，總是回頭訕笑、責怪、甚至鄙視前人
惡性循環的結果就是層次永遠難以提高
真希望有心在這技術領域獨當一面者，能以既修史、也修身的心情從事之
Add new comment