公司裡的同事都是技職體系畢業的，因此他們從高職就開始寫程式；有的人甚至於國中就開始寫VB了，跟同事們比起來，我真正開始寫程式的時間不過就是畢業後進入社會的這十個月。這一段時間內，公司軟體開發的過程卻是讓我最困惑的部分。一套數百萬的系統，可以沒有系統分析與設計；而是直接進入系統實作。一套系統由一個工程師負責，所有的產品系統公司內沒有任何一本相關的技術文件；唯一的文件是給顧客看的使用手冊，每套系統的所有技術與知識都只存在於一個工程師的腦中。 進公司後，想要瞭解公司產品的方法是在品管部同事的旁邊看他們測試系統，要會厚著臉到不同的部門問問題，最後兜起來的才完整。開會時，沒有任何的文件，任何事都是用談的。只要在客戶要求的日期前，把系統整合完成就可以了。剛開始時，我邊學系統邊寫一些技術文件，將系統的需求，規格，功能及相對應負責的人員等相關資料整理成一個資料庫，主管卻直接對我說，做這些事情是浪費時間。縱觀整個公司的知識管理庫卻貧乏的可憐，一套結合軟體、韌體、硬體的系統，各個不同的軟體、韌體、硬體部門間的互動也是少之又少，反正只要產品可以兜的起來，可以即時完成就好。 這一段時間，所遇到的專案跟我過去在大學所學的專案完全不同；幾個月前，公司招募一個剛由資管所畢業的碩士；也是我進公司後唯一聽到談系統分析與設計步驟的人，可是今天他卻說，沒有所謂的文件也沒關係，只要有程式碼就可以了，寫程式是越快完成越好。只要看的懂程式就可以了，對一套系統只要知道它的架構就可以了，也不用花那麼多的時間去瞭解。技職體系訓練出來的就是這樣，所謂的程式設計師只要坐在那邊準時上下班，把工作完成就可以了。 難道是因為我不是他所謂的技術體系學生，所以才會這麼的不進入狀況嗎？堅持系統會有需求、分析、設計以及相對應的文件？現在業界中的產品設計都是這樣的嗎？還是軟體系統的開發更是重視速度？反正產品只要能快速的開發完成，能動就好了？根本不需要分析設計？

我個人認為 還是分析設計比較重要 開發之後的方向才能明確修正 任何事都是用談的 我公司也是耶 哈哈 不過 時間到會交 哈哈 因為有默契之後 不會再寫有的沒有 只寫重要的 不過程式上也會寫 至於 系統分析與資料字典一定會有的 甘特圖嗎看案子的難易度與時間 ********************************************************* 哈哈&兵燹 最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好 Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知 K.表Knowlege 知識,就是本站的標語:Open our mind to make knowledge together! 希望能大家敞開心胸,將知識寶庫結合一起

------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind

若以現在的 開發工具而言,有些實際上已經有相當足夠將來維護 系統的流程/架構...等所謂的文件 以我個人而言,做文件比開發程式痛苦,而且未必有用,所以學校那一套 感覺是未必適用. 若程式是一行一行的輸入,那程式員很重要,一但離職,可能後面接的人就辛苦了 但是現在很多開發工具,已經跟以前學校那種寫程式法不太一樣了 所以,有很多的程式設計師未必會依照早期的做法 另外一個有經驗的 SA 程序員,是可以直接邊開發邊修正,或許文件不是很完美,但是小系統也無嘗不可. 以上是針對提問者問題,個人一些經驗,未必是對的,供大家參考!!

我指的小系統是類似簡單的進銷存或是一般企業的專案軟體 若是 大型ERP,SCM 等系統,我想一個人可能就搞不來,應該是團隊的工作 所以 文件的製作應是一個溝通的重要依據/證據....等 發表人 - 小蚊子 於 2003/05/06 00:13:50

有時候的確是需要面對現實 像我們公司小小的，也不大，全部不超過15個 研發的只有2個，規畫、設計、coding、測試…全自己來 我當初也是堅持要做文件，要規畫，(我也曾經待過數百人的軟體公司，也有SA/SD 經驗) 這個都知道 但是前提下：要有足夠的人與足夠的時間 案子一直進，程式堆到寫不完 小公司有小公司的悲哀 如果公司規模大一些，文件工作仍是很需要的    致於妳所說的部份，也許是環境造成，也許是個人習慣，但是不要以偏概全 技職體系出來的，不見得都是庸材 反觀，資訊部門的主管有沒有專案管理的能力，才是值的商確的    不要去抱怨環境，學學"理論"與"實務"的差異，如果可以的話，妳也能成為改變環境的人，這才是妳學習的方向    

曾做過一個大案子,就是正規正矩來的,有五六個人, 從系統分析,各使用單位一一訪談,畫系統流程圖, 開Table,正規化,畫資料表關聯圖, 作資料字典,還作中英詞句對照, 資料庫效能分析報告... 所作成的文件約有十幾本,疊起來有近一公尺高, 經過一年半後,最後因為團隊默契不足,進度嚴重落後而宣告案子流產, 公司還因此差點吃上官司,也一度面臨倒閉命運! 事後參與研發的主要組長對我說,其實他覺得如果當初是他一個人寫的話, 可能還會順利完成! 對公司來說,能夠把案子結掉,驗收完成收到款項,這是最重要的事了! 這也是軟體設計師不得不面對的現實面! ～～～Delphi K.Top討論區站長～～～

------
～～～Delphi K.Top討論區站長～～～

如果你有在程式有註解的話(如果我看的懂的話)~~我就已經阿彌陀佛帶著老婆小孩去際拜祖先~~感謝祖先有保佑~~呵呵~~ -- 聰明的人，喜歡猜心；雖然每次都猜對了，卻失去了自己的心 傻氣的人，喜歡給心；雖然每次都被笑了，卻得到了別人的心

------
聰明的人，喜歡猜心；雖然每次都猜對了，卻失去了自己的心
傻氣的人，喜歡給心；雖然每次都被笑了，卻得到了別人的心

diary 也不用太灰心啦~~ 相信站上許多先進都能體會站長所說的 『先求有，再求好』 規畫與實作都很重要 記得以前在修專案管理這門課時 老師講了很多風險管理與失敗案例(不好的專案管理) 那時唯一的標準答案就是，沒有好的專案管理與前置作業，似乎注定專案一定失敗 但是實際上在這領域工作就就能體會，專案時程的壓力    在此可沒有說…專案管理，分析不需要 我以前待的公司，就有專門的工讀生負責做文件 也不是全部都ok 才開始寫程式 都是邊寫邊修正，大部份文件還是程式完成90%後，才開始去補的 甚至是要交貨了，程式還有部份功能未完成，故意用錯誤訊息跳開讓客戶以為程式錯誤而不是程式沒有寫，再利用事後修正把功能補上< > 總之…既便是大的軟體公司，實際負責專案的人還是少數 而往往會同時有好幾個專案在進行，所以通常會有一些不為人知的"技巧"< >

都很重要！ 我個人經驗，我在作微處理器開發時，通常會作分析設計，寫虛擬碼，之後，才開始寫微處理器的 C 或組語。在作 Windows 程式較大的系統時，也會先作系統分析、使用什麼架構、基本運作模式等等，都有腹案了，才會進行，而在進行中，一定會發生與原規劃不同的狀態，這時，就看時間是否許可，如果有交機的時間壓力，當然是先作完再說，如果沒有時間壓力，則可以再回頭修改原規劃，通常在 project 進行到 60％～80％ 時，如果有時間回頭看看當初的規劃，都會發現當初規劃的一些盲點，但如果要改架構，又回出貨時間在即，不可能一幅修改，只好以補破網的方式修正。 沒辦法，公司總是要以如期出貨為高最指導原則，如果，今天您可以在公司交付給您任務，可以很快擬出系統架構、分析設計，那自然是很好，也可以加快日後開發的速度，但如果這個部分花費的時間過長，我想沒有一家公司可以接受，除非您自己開一家公司當老問  <>沒空更新的網頁... href="big5.to/吃軟也吃硬">big5.to/吃軟也吃硬 dllee.adsldns.org 介紹Shells,LiteStep,GeoShell....

------
http://www.ViewMove.com

兩者都很重要,但人力不足時卻很難辦到. 光是開發就來不及了,哪有時間來分析及寫文件阿! 但是文件不寫,系統不做分析,到時候東西一多那真是有夠亂的! 由時真不知要如何取捨阿. 只能在寫程式時,多加註解吧! 且偶而寫個簡單的文件或畫個簡圖,也是一種應應之策,比什麼都沒有還略勝一籌. 寫程式是建設,除錯是破壞. 寫程式是樂趣,除錯是苦難. 哈! 哈! ....

以公司內勤人員來看這個問題，站在公司的立場來看待，當然是開發速度重要，不然公司請你來公司做什麼，就是要把案子如期的完成，能越早完成越好，公司就能順利收尾款ㄚ。 公司不是請你來這裡學東西，不是請你來理論事情的重不重要性，而是要請你把自己所學的完成工作。 對公司而言，工程師只不過是開發的工人，在外面會讓人覺得是高級的職位，但對公司而言卻只是一個勞工，一個用腦的勞工，無須有太多的怨言。 公司就是那麼自私，因為他要營運下去，他就必須如期的出貨，如期的收到貨款，不然就沒法子付大家薪水了。 就像我之前待的公司，原本說好要在去年年底要完成案子，但是還是某些因應無法完成，只好延期，就這樣後面幾佰萬的貨款無法收，股東看不好公司未來，導致於公司結束營運。 講另一個所見聞到的事情，一個朋友在大公司裡工作，手邊都是三~四個案子在跑，每一個案子結束就有另一個案子自然要他接，如果能提早完成案子，他就幫公司多賺了錢，但我聽到的是別人一直誇讚他。    所以這是業界的一個趨勢，並沒有誰對誰錯，公司所面臨一開門就要開始花錢的問題，所以能越快把案子結束，公司就能賺大錢。    以上的言論是開一家公司，常見老闆的想法坦承敘述 並沒有要爭什麼喔!!    而想鼓勵diary是，這是一種社會的趨勢，跟你是不是技職體系出生的都沒關係，因為技職體系出生比你更早體恤到，這是社會的趨勢，要記住一個生存哲學:適者生存，不適者討汰，永遠都不要認為自己的位子不可能被取代，只有向前看，好還要更好。

~~謝謝各位老大的指導~~    其實我剛進公司的時候也真的就像各位老大講的一樣，笨笨的想把所有的分析設計文件都寫好。不過，最後我發現看我的文件的人都是品管部跟營業部的同事還有公司新人。跟我同部門的同事卻沒人看，可能是因為他們覺得看這些東西是浪費時間吧。哈~所以老實說，後來我也不寫了，省得老是挨罵。< >(~可是基於良心，我還是都有寫註解~) 我們公司的系統常常在以如期交貨為優先條件下開發，所以一套相同性質的系統，會因為不同的客戶而有不同的版本。而一個工程師就負責一套系統，除了負責的人之外，就沒有人瞭解。最有意思的部分是，我們公司的產品是除了要跟別的系統整合之外，還要再搭配許多的硬體設備才是一套完整的架構。所以我們的顧客一用就可能會用很多年。(~因為要換是要花很多很多很多....的錢~< >) 而我就是老大說的那個"後面接的人"，所以如果當初寫程式的人有留分析設計的文件或是註解的話，今天我一定會幫那個人點長生燈，保佑他長命百歲。因為現在面對顧客的就是像我這樣在公司裡屬於半新不舊的人，老是被顧客罵的感覺當然很差，到最後甚至有的顧客就用動詞對我們問候。< > 其實我還滿佩服我那些同事的，因為他們只要開會時，講個兩三句話；第二天程式就寫好了。只是這樣的系統，我搞不懂為什麼我還是不能茍同其他同事的想法：只要寫出來的東西會動就好，管它什麼分析設計註解的。反正看得懂程式碼就可以了。 開發速度重要還是分析設計重要？我也想問各位老大，現在的業界的軟體開發都是這樣的嗎？如果是的話，那我可要好好想想自己未來的方向嚕~< > 還是這一切都只是因為，我太笨了~~~~ ~對於各位的指導感謝萬分~

引言: 曾做過一個大案子,就是正規正矩來的,有五六個人, 從系統分析,各使用單位一一訪談,畫系統流程圖, 開Table,正規化,畫資料表關聯圖, 作資料字典,還作中英詞句對照, 資料庫效能分析報告... 所作成的文件約有十幾本,疊起來有近一公尺高, 經過一年半後,最後因為團隊默契不足,進度嚴重落後而宣告案子流產, 公司還因此差點吃上官司,也一度面臨倒閉命運! 事後參與研發的主要組長對我說,其實他覺得如果當初是他一個人寫的話, 可能還會順利完成! 對公司來說,能夠把案子結掉,驗收完成收到款項,這是最重要的事了! 這也是軟體設計師不得不面對的現實面! ～～～Delphi K.Top討論區站長～～～

如果我是那個組長，我也會選擇自己來還比較快！ 所謂系統分析及文件交代必須要到如此精細嗎？ 我的做法是，取客戶那邊了解客戶的需求，將重點紀錄下來， 回去跟程式設計師討論一下相關流程，制定一下寫作該注意事項， 剩下的教給程式設計師自由發揮就好了！ 第一階段，先請程式設計師，設計畫面(一個星期夠了吧)，主管看過之後， 拿去跟客戶討論，然後花個一兩天，大概可以正式進入定資料庫欄位的階段。 第二階段將畫面的欄位真正與資料庫結合，這樣再花一個星期，基本編輯功能有了，可能操作不是很順暢，但是主管起碼可以試著玩玩看，看看與流程合不合， 資料對不對，數據計算正確否。 第三階段將操作的功能性及畫面美化的部分，可能就不一定用多少時間了，因為 變化很大，這時，我們就要看，客戶花多少錢，我們做到哪些友善的介面了。 我說的這三個步驟指的是一般小系統的做法，如果是類似幾百萬的大系統， 那主管系統分析的人，頭腦就要很清楚了，做做筆記，詳細了解流程， 當然，還是可以套用以上三個步驟，將程式一個一個拆開來，給不同的人作，但 是，每支子系統結合的部分，要跟程式設計師講清楚，那部份，將來要跟哪個系統結合，那部份要預留作什麼事情，這樣的做法，既有效率，也不會把程式設計師當成是程式打字員啦！ 而且，因為子系統拆開，很容易掌握每個人該有的進度，不會一支程式開發下去，只有一個結案日期，那什麼時候，進行到哪裡了？ 誰清楚呢？ 老闆很容易擔心這件事情，花錢的客戶也擔心！ 當然了，我並非資訊相關科系畢業的，說更清楚一點，我連高中都沒讀完啦！ 但是這是我寫程式十幾年，也當了二年多程式設計部門的主管的一些心得啦！ (但是，我沒在學校念過什麼資訊課程，我連在外面上過補習班都沒有啦) 大家參考參考就好！ 台灣 Delphi 俱樂部
PostgreSQL、FastReport專業討論區
http://www.delphi.club.tw

引言: 我的做法是，取客戶那邊了解客戶的需求，將重點紀錄下來， 回去跟程式設計師討論一下相關流程，制定一下寫作該注意事項， 剩下的教給程式設計師自由發揮就好了！ 第一階段，先請程式設計師，設計畫面(一個星期夠了吧)，主管看過之後， 拿去跟客戶討論，然後花個一兩天，大概可以正式進入定資料庫欄位的階段。 第二階段將畫面的欄位真正與資料庫結合，這樣再花一個星期，基本編輯功能有了，可能操作不是很順暢，但是主管起碼可以試著玩玩看，看看與流程合不合， 資料對不對，數據計算正確否。

我想,程式設計經驗還是粉重要的, 徒有再高的學歷,光有理論是無法將系統如期完成的, 經驗的累積才會讓軟體設計師寫的又快又好! 程式本身就是最好的註解! ～～～

「程式本身就是最好的註解!」，非常贊同天使的這句話。 工程師的驕傲是寫出讓人看不懂或把好幾行程式碼濃縮成一、兩行，來顯示自己的高明。 但這卻是「軟體工程」上的致命傷。 如能把寫出的程式，不需註解就能簡易讓任何人（有程式設計經驗）看的懂，那是多麼完美的程式碼阿！ 寫程式是建設,除錯是破壞. 寫程式是樂趣,除錯是苦難. 哈! 哈! ....

做個小結論 diary 寫程式不會是一輩子的 目前妳是寫程式，努力的方向：寫程式應是要"快、狠、準" 也許未來的發展妳會做管理階層，努力方向又不一樣了，如何讓專案順利如期完成 像我的方法：我給自己的目標是 > < src="http://delphi.ktop.com.tw/loadfile.php?TOPICID=8147403&CC=182217"> 發表人 - ddy 於 2003/05/07 10:09:57

論壇中的網友應有資管/資訊/電機.....等各科系 一般人的想法是,做幾年後升為管理職務,經理或科長....之類的 我當初的想法也是如此,有夢最美,但夢醒時分,我有一些經驗與各位分享 我以前很看不起業務的工作(對不起! 用比較強烈的字眼) 對自己寫程式的工作,非常非常....的以為是高級的工作 沒有錯,時下一般人對 "做電腦的" "寫程式的" .....等,總是引領高盼 因為他曾經是一種身分地位的象徵(我自己也樂在其中) 曾經轉為管理職,公司給個PM的頭銜(專案經理),也給了案子去做 而實際上呢? 很慘,各位應該也知道,進度及溝通是我最主要的工作 分配工作及開會.....等,一切沒有當初 SA 寫程式 來的單純 原本以為可以勝任的工作,後來真的很後悔接這主管的職務,原因是我的個性 並不是很適合, 如果早幾年安排自己有當主管的準備,也許會更好!! 管理與技術是完全兩碼子的事(我以前覺得技術都會了,管理算什麼) 現在我是一直往業務開發的方向,磨自己的個性及圓滑度,我並不是放掉技術,我發現光有技術只能滿足自己的求知慾,並不代表什麼,但人生還有很多的事務是我未曾嘗試的,其實做業務並不是那麼輕鬆,而且學校絕對沒有教授此門課(行銷學是大原則的方向,與業務第一線的實戰有點不同),所以由技術轉管理,未必是幸福的,供大家參考!! 記得以前聽過一段話 : 某主管拿一條領帶給技術部的員工張三, 主管 : 張三啊!! 您在公司苦幹多年,表現優異,替公司開發很多成功的產品 來,這一條領帶給您,明天開始, 您升為經理,整個產品開發部由您來負責. 可能狀況一 : 張三很有領導才幹,一樣表現優異 可能狀況二 : 張三用太堅持技術的方法來帶領員工,來不及或學不精, 管理的技能及人性的管理..... 後來張三可能壓力太大, 用這一條領帶上吊自殺. 以上是一則笑話或諷刺的短文,見仁見智,但是給人的感覺是,隔行如隔山 也許各位如我一樣的經歷過,您的思考就會不一樣. 還有有很多同事自負技術高超,刁老闆/不爽老闆,甚至自行離開創業..... 有人是成功,但我看大部分是不知去向.....我一直感覺,職務的頭銜是公司給的 您今天掛xxxx公司的技術部經理/開發部副理/資深工程師......,別忘了,離開這家公司後,除了真正的實力外, 您什麼都不是,不要以為自己很行,現在路邊隨便一問研究所畢業的多的是,人才也很多,這是我這幾年給自己上的最大一課. 大家參考參考!! .....................

引言: 現在我是一直往業務開發的方向,磨自己的個性及圓滑度,我並不是放掉技術,我發現光有技術只能滿足自己的求知慾,並不代表什麼,但人生還有很多的事務是我未曾嘗試的,其實做業務並不是那麼輕鬆,而且學校絕對沒有教授此門課(行銷學是大原則的方向,與業務第一線的實戰有點不同),所以由技術轉管理,未必是幸福的,供大家參考!!

非常贊同小蚊子的看法! 軟體是死的,人是活的! 好的業務可以把死的軟體變成活的, 完美的軟體不一定賣的出去, 擁有強大的業務團隊與售後服務團隊, 再爛的軟體也賣的聒聒叫! ～～～Delphi K.Top討論區站長～～～

引言: 非常贊同小蚊子的看法! 軟體是死的,人是活的! 好的業務可以把死的軟體變成活的, 完美的軟體不一定賣的出去, 擁有強大的業務團隊與售後服務團隊, 再爛的軟體也賣的聒聒叫! ～～～Delphi K.Top討論區站長～～～

站長這樣說太鄉愿了吧! 你的客戶如果知道你的軟體很爛, 我不相信他會對你的售後服務團隊有興趣 難道站長真以為一個活的人可以眛著良心去賣一個死的軟體 我寧願相信你講的那個業務～～才是個死人～～除了他的嘴巴 其實,我了解站長的意思,可這語病很～糟蹋～人

各位大大: 千萬別去賣自己都不想用的軟體,那會有業障!! 小妹我的意思是, 除了工程技術,若頭腦不要那麼硬 也許對工科出生的人員前途會更好!! 與同事間的相處也更佳愉快, 這過程是需要學習的,不是每天 K DELPHI 5 6 7 .....就能學會 當然了,不會 DELPHI 也是會很慘的,就我現階段來說!

Sorry,各位誤會我的意思了,那只是一個比方啦!    站長不是要大家去賣爛軟體啦! 換個說法好了, 請問大家覺得 > ～～～

------
～～～Delphi K.Top討論區站長～～～

站長我猜您的工作範圍應該不只是技術方面吧? 因為從字裡行間可看出您對 CRM 的重視! 可喜可賀!

引言: 站長我猜您的工作範圍應該不只是技術方面吧? 因為從字裡行間可看出您對 CRM 的重視! 可喜可賀!

歹勢, 請問何謂CRM?全名為何? ～～～Delphi K.Top討論區站長～～～

歹勢, 請問何謂CRM?全名為何? ^^^^^^^^ crm => 顧客 關係 管理 是資訊軟體業界,暨 erp 後,又推出的一些觀念,然後在實作系統,形成新的軟體市場(資訊軟體業,若不如此自圓其說,開發新玩意,根本就是死水一攤,大家都沒飯吃) 其它如 KM => 知識 管理 SCM => 供應 鏈 管理 BI => 商業 智慧 Data Mining => 資料 挖礦(探勘) Data Warehouse => 資料 倉儲 Data Mart => 資料 超市 XML ......等,一推不是很新的名詞,但可能對你我的未來產生影響 的相關技術或系統,所以啦!! 資軟體業是很可憐了,累! 淚!

引言: crm => 顧客 關係 管理

謝啦! ～～～Delphi K.Top討論區站長～～～