這陣子忙翻天,除了捍衛自己的興趣;還要忙公司的Case;前不久做的Sample ER-Model工具;就拿來分析了一下舊的系統;這才發現...暈啊.....天啊!!....驚呼聲此起彼落....想到以後要接這些前人的"債"...突然覺得一陣暈眩..... 忽然想請大家聊聊...同時也想想幾個問題 1.哪個方法論在實際工作上較易落實呢?? 2.若依循某一個方法論來實踐,又如何把虛擬的成果表達到能讓Boss可以預見呢? 3.專案管理方式與方法論需要有特定的組合嗎?? 4.曾經遇到過專案管理與實際施工狀況'脫節'的情形...這是常態嗎?? 歡迎大家各書己見...說說您的"遭遇"與您的看法....

其實,小弟做過的專案,沒有1000也有800了.但,你的問題,我也在尋找答案中. 以我的感覺來說,案子的執行,其實沒有什麼特定的理論可以確保案子順利進行.原因有很多,諸如技術上的問題,客戶要求的完成日期與分配的人力是否在合理值之內,案子的大小、範圍等. 以前總認為經過事前詳細的sa,sd,coding,測試,是一個完整且確保可以完成的工作方法,但實際上,往往時間不允許你做這樣的流程.分工過細,代表的是溝通會越來越多,會議會越開越頻繁.同樣的,到了,sd,coding時,投入的人力更多,溝通與管理就越不容易. 而現在,雖然有所謂的uml做為分析的方式.但說真的,沒幾個人懂.且最重要的,是客戶不懂.這是重點,如果客戶懂就不會找你做了.老實說,光本人就碰過有人把案子做砸了,然後繞跑,而那個人還在市面上寫關於uml這類的系統分析的書咧. 真要說有沒有什麼方法可以知道案子會不會順利,我覺得客戶端負責系統的人的水準很重要.專案負責人能夠與客戶的負責人有良好的互動,訊息能夠正確的傳達,意見能充分交換,系統才可能做對.像之前在中科院做過一個專案,負責人對於整個系統要做成什麼樣子,會有那些功能已經有一個很清楚的view,所以系統做起來不會有打不到靶的情形.也有碰過不敢負責任,然後自己天馬行空的亂想系統的功能,溝通起來不但費力費時,加上沒有什麼水準,解釋master-detail的限制老半天,就是認為你不願意做. 至於案子的控管.其實我覺得倒還容易.把所有的功能清單列一列,看看會有幾隻程式,難易度大概抓一下,就可以換算成概略要執行的天數.然後,每個禮拜檢討進度,其實也都還OK.我覺得.

感謝您的熱心回應... 昨天在畫ER-Model時,的確被視為異類;巴不得我趕快Codeing..... 總想找個接近完全的方式來處理手上的工作;聽了您的說法,還真是令人感到無奈 希望大家能不吝給予指教,也許哪一天;有了大家的貢獻,這樣的生態應該會改變吧??....加油!!

我還是會試圖找到更接近的答案,把這樣的想法落實到工具中;屆時,請大家多多給予指導...謝謝!!

呵。軟體開發。必定尊循”莫非理論”。 很簡單的需求。會變得很複雜。 一定能做出來的東西。會變成四不像的怪物。。。。。。。^_^ 一堆的書在說怎麼做專案。 可是。專案中存在著太多的”未定數”。 尤其是M＄的作業系統由95到98到2000到現在的XP，2003 都在考驗程式設計師”跟著走的腳步”。 走慢點就要改行了。所以。你有太多沒測過。沒試過的功能 等著你去開發。 所以軟體能像蓋房子那樣用”人月”來計算嗎？^_^ 去看看一本”人月XX”的那本書吧。 很有趣。

呵呵呵....感謝暗黑破壞神的回覆..... 其實,光是把整各系統的概況描述的很完整;就是一件異常艱辛的工作 更別提是針對一般User了. 記得看過一篇文章是在說明專案進行的管理,到後來卻話鋒一轉;說到其實是變數很多,根本無法完全管控;只能做"風險管理"......^-^....!! 另外,提出這個討論主題也是希望能有個能讓User可以理解目前系統的方法,降低天馬行空的需求被提出的機率;不然真的是...做到死...又不知何時才能結束!! 還有就是有些分析工具離實際作業實在太遙遠...感受不到去做那些分析到底能不能落實到實際作業上....如果可以的話....那還真是我輩一大福音呢!!

其實每個專案(Project)成立前,都要有一位領導(Leader)和PM管理,一定會做所謂的"專案成立通知書",內容包含了市場評估,成本計算和生產利潤,以及是否有既定客戶需求(每月固定訂單)等等的前置作業討論;一般老闆最關心的就是客戶需求了,當然是有訂單的先處理,接下來就是苦了S/W和H/W的工程師,要趕出預計的進度來完成它.    所以新/舊產品都會需要做"專案成立通知書"的評估報告,因為老闆和業務的專業技術不見得會比工程師強,所以才會需要Leader和PM做出"統計分析"將結果數值化出來;雖然感覺像"紙上談兵",但是本人覺得這樣做可以把很多問題明朗化. 寒窗苦讀十年書；只待今朝狀元時！~~ ︵ / / ︵ ( ∩ ∩ ) ○ ︶ ○

------
Keni Lin

我記得當年年輕時去上過課。 老師說過一句話。我到現在還一直實行中。 ”在幾月幾日以前提出的需求。我們有權判斷是否受理。 在那之後所提出的需求。請另案處理” 否則。專案會結不了案。 因為使用者有些是根本不知道電腦能幫你做到什麼。 等你給他看到它的方便時。就會再。。。那能不能在這邊再加個XXX。 這類的話出來。那你依他。就會有做不完的事情了。 所以。務必堅持那一道防線。^_^

引言: 我記得當年年輕時去上過課。 老師說過一句話。我到現在還一直實行中。 ”在幾月幾日以前提出的需求。我們有權判斷是否受理。 在那之後所提出的需求。請另案處理” 否則。專案會結不了案。 因為使用者有些是根本不知道電腦能幫你做到什麼。 等你給他看到它的方便時。就會再。。。那能不能在這邊再加個XXX。 這類的話出來。那你依他。就會有做不完的事情了。 所以。務必堅持那一道防線。^_^

沒錯!!個人曾身受其害... 只能說當時熱心,忘了人心險惡... 學生時接案,遇到廠商一直要求加功能..真的差點結不了案... 那就算了,結案後,有很多案外問題他也拿來問你..甚至別的案子... ==================================== 生命的目的，在幻化出多采多姿的組合。 生活的意義，在捕捉住稍縱即逝的感動。 ====================================

專案最好玩的地方是沒有一定的解法,沒有標準答案.這中間,不只考驗技術上的功力,更考驗專案負責人的VIEW有多大?往往USER要的系統,其實出發點只有一個功能,然後系統在USER的想像力之下就會越想越大.重點是這個出發點能否被專案負責人發現並掌握. 至於我目前的做法,是以case tool做系統table的管理,然後產生程式碼.建議你,要有一套上手的case tool,否則,近200個table如何管理.不要天真的認為用人工去修改word檔裡的欄位規劃只是累一點而已,想想看.修改一個欄位,你要改資料庫,改程式,然後去改檔案說明書.沒有那個功夫啦!!就跟寫程式一樣,同樣的功能就是寫在一個物件裡,用到這個功能才去呼叫這個物件.同樣的,系統的table有那些,欄位怎麼定,就都記錄在case tool裡.然後由case tool去產生文件,產生程式碼.不要用人工去維護這些資料,很沒有效率!! "昨天在畫ER-Model時,的確被視為異類;巴不得我趕快Codeing"<----這就表示你的user不懂專案流程!!你有兩個選擇:1.想辦法說服user,教育user何謂專案流程,為什麼要先做系統分析,解釋你為什麼畫ER-Model. 2.想辦法改變自己的專案做法,訪談後就可以開table ,coding. 我是走第二種,為什麼不走第一種?試問,當一個人會把腳踏車騎上高速公路,你有沒有辦法去說服他為什麼不行!! 發表人 - change.jian 於 2005/04/14 13:26:29

我有一個朋友,他公司因為人員離職,被安排去接手維護系統 那個系統本身已經有客戶在使用,但是問題很多 他接手之後,想要整理文件,想要把規格弄清楚,才能把bug修復 他的老闆跟他說了這麼一段話 "現在沒有時間了,你不用把來源的各個table搞懂,就是把bug修好, 因為客戶不能等了" 他在跟我提的時候,我覺得真好玩,不把相關的table弄懂, 可以把bug修好? 有時候,有太多外行領導內行,土法煉鋼,打帶跑的情況不斷上演, 跟時間賽跑,然後是不斷的修補,每次都是,把這個弄好再整頓, 隨著人員的異動,熟悉度不斷下降,然後製造了更多的問題,或是 解決了一個bug,製造了十個新的bug. 台灣中小企業的精神,就是搶時機錢,打帶跑,能說什麼呢? 就因為有這種出錢請你來我是老大的土財主心態, 更有可能是大環境下的妥協不得不如此, 未來會如何? Who knows? 我這位朋友的老闆還說過一句名言 "生命會自己找到出路" 阿彌佗佛,善哉,善哉!

其實hahalin 說的話個人覺得真是 "心有戚戚焉".... 自從出社會的第二份工作以來做的就是"程式設計師"; 為何要特別註明?? 因為就根本上來說,到目前為止;覺得和'高級打字員' 的工作差不了多少---->問題在哪裡? 我們很少有機會真正坐下來好好分析一個系統.... 也許是我視野太狹隘了吧,唯一只有遇到一家公司; 真正利用改寫系統的機會,好好的進行分析....(PS.這讓我印象深刻極了) 雖說如此..還是沒能表達出整各系統的樣子...停留在以文件進行紀錄.....