SD文件?! 抑或SOP文件?!

最近一直在思考一個問題
以開發者的角度，技術是整個系統的主軸,沒有技術系統是沒法完成的
以管理者的角度，文件是整個系統在還沒開工前、開發進行中、系統上線時、進入維護期,所需要的最重要的引導
開發者覺得只要看程式碼，即可以了解想做什麼，寫文件根本就不需要，又或著看文件都不是太需要，只要對他引述即可清楚想要做的事是什麼?!(這往往就是造就了後來的死無對證)
自己的經驗中，有文件做為一個指引，確實在執行中可更容易的在作業過程中，要想要完成的事做了較正確的執行(CODING)，沒有文件也確實不是不能做事，只是這中間確實有太多需要自己去拼湊的部份。自己拼湊也不是無法完成想要的功能，只是在最後驗收時，是很有可能有很多功能跟實際想要的會有所落差，可想而知在最後就是一再做更改。
所以，文件是不是很重要。不可否認文件確實是很重要。
不過，要開發者去寫文件，著實是讓大多數開發者都很頭痛，開發者的專長是如何以自己所熟悉的技術去完成所需的功能，而不是如何去製定規則(因為則規都是在他的腦中)。這時要開發者去作一份文件，該如何才可以達到文件的產出?!
待過工廠或較大的公司的人，常看到一種文件-SOP，這種文件看似就是一堆的圖文。不過我卻覺得這種文件，對於引導確實起了很大的作用。一般SOP文件看似很DUMMY，只不過是Step-By-Step，在導引過程讓使用者，可以按著這個文件，一步一步的完成想要的工作。
關於SA/SD文件，文件寫的好壞，見人見智。不過，個人接觸過的文件中，有的寫這些文件的可以交待的巨細靡遺,把所有使用者交待的都說的清清楚楚，有的寫出來就只是把資料表做成整理。或許當中各有好壞，在使用者解讀過程中,我卻認為理解力高的在解讀時看過一遍就可以了解，理解力差的需要邊執行時返復再來跟寫文件的人理解。
曾在過去的公司的講師訓練課程中，有一句話深刻的在我心裡

文不如表，表不如圖，圖不如示範

在製作簡報時，我一向以這個原則來制作，確實收到不錯的廻響。對於，簡短的簡報中要能報答想要給聽眾，在這麼短的時間內就可以知道想要表答的內容是一件不容易的事。（看過蠻多讀書會或座談會中，講者想把東西講仔細，但往往是講得愈仔細，聽者聽得愈糢糊）
所以若是可以把SA/SD文件做的讓一般使用者都看得懂，是較讓系統設計者及開發者，可更精確的去做執行的動作。若把SA/SD文件做成SOP格式般的簡約，是我值得去思考的，專案不能準時結案，我想確實是在每個案子成員都不樂見的狀況。

需求?!需要先分析還是直接硬幹

從事IT業這麼多年

有一半以上的時間都是在開發中的日子度過

其中開發的熱情當然是自己對於這個工作能做這麼長的其中一個原因

剛入行時對於 PG=>SD=>SA=>PM  這個歷程似乎覺得是理所當的路程

不過似乎又不是這麼一事*註

最近這份工作個人掛的頭銜是系統分析,做的事情卻是當初剛入行時所做的UI Coding

按照了一份美編的版面設計,一份Protocal(server端會傳什麼格式資料過來,client該傳什麼格式資料過去)

然後按圖索冀,開始寫吧

似乎別的案子都是這麼做的,每一款都是也還能正常上線,營運賺錢

這樣的流程也沒什麼不對的地方,總之能賺錢最重要,是吧~~

在前一陣子,接觸到了一個詢問,開了頭就問”你會不會做什麼什麼網站?報價是多少?”

個人按第一時間所聽到的感覺是要做沒什麼不能做的 ?!

問題是這個網站的需求內容到底是多少內容或多大的規格?

接著對方給了我一張圖(心裡早有底,因為對方也不過只是會美工的工作室)

若是按現階在工作上的流程,不就是如此,有一張圖按圖索冀,理當可以按這個圖去做出系統分析的事情

早在先前的公司,我給使用者一個這樣的保證”資料需求交給我,包您馬上得結果”順口溜(我)

對於需求,今天早上浮現了,需求應該會分成三種

1. 客戶的需求
2. 透過問題所產生的需求
3. 自發性創造的需求

這三種需求是否都要透過分析才可以包您馬上得結果?!

硬幹就沒法馬上得結果嗎?

其實多數系統也是透過不斷的堆疊功能才成就一個系統的

(又讓我想到若是不斷的產生的只有分析,卻缺少了功能的實現,是如何成為系統 ?!)

上述的三個需求發生點,似乎變成了如何把需求變成營利的前期練功步驟

(是的對於那個評估的邀約,必然是對方無法接受我不想硬幹的說法,我還說明從PM到PG的流程)

 

*註 a.用了一個非該技術專業(.Net)的人來領隊不同技術專業(JAVA)的團隊

          (是低現在公司也有這樣的事,事實證明這樣想法是一個很大的錯誤,二個採這個想法專案,最終都是讓專案不斷的延誤)

     b.在之前工作的經歷中有主管找SA是她不在乎有沒有技術背景

     c.另一個工作PM也是沒有寫過任何一行CODE