Re: [討論] 我是資管人 我的定位

[TonyQ (沉默是金。)]

※ 引述《yinia (沒有暱稱)》之銘言：
: 我是資管人
: 做完專案後 最近再從新唸完一遍"系統分析與設計"
: 而有了一些感想  希望與同是資管系的前輩討論一下
: --------------------------------以下正文--------------------------------
: (ㄧ)資管≠資工+管理
:     唸資管最大的困惑就在於資管的定位，每當我們被質疑時，往往都會回答：「
: 資管才不是你們想的那樣！」，但問題是資管究竟是怎樣？
:     就我覺得，資管跟資工企管一樣要念程式語言、資料庫、網路與管理學等等，但
: 最大的不同就在於"系統分析與設計"這門課，就我所知資工似乎沒有這門課。

        我對你這篇文章也有興趣，我先說背景大家加減參考就好，
        我自己是資管出身，但是我除課業外，主力還是在程式設計的鑽研，

        所以經歷大多是系統程式的撰寫跟網站、程式核心的撰寫，
        比較沒有接觸到管理的部份，不管對管理還算是有一點點基本sense。


        工作經驗...就算有在公司上班的一年好了，
        雖然不是很資深不過有針對這些問題去想過。
        -------------------------------------------------------------


        基本上系統分析和設計在你進行程式設計的時候，
        不可避免會去碰觸到的，也就是說這其實是coding的延伸。


        在這點上我不認為是資工跟資管的差異化，
        不過資管跟資工在SA層面的差異，
        最主要是會更專注在成本跟時程管控的部份。


        但是實務上我自己參與課程的經驗，
        我認為資管人因為對於coding的實務並不熟練，

        無論在評估或分析，難免會抓不到真實的面貌。


        （當然這是討論課程OK，學得人也學得很OK的前提下，
          混學分搞笑的就不提了，後面就不另註這但書了。）

: (二)系統分析與設計是什麼?
:     系統分析與設計(SA)是資管的必修，而且是在修完程式和DB.DS.網路等等以後才
: 會出現的必修，
:   1.根據系統的實體架構而需要畫出實體關係圖(ERD)
:   2.根據企業流程而要有清楚的資料流程圖(DFD)
:   3.根據使用者介面而有使用者案例(USE CASE)
:     如果沒有DB.DS的概念，就做不出擁有實體、屬性、關係的實體關係圖，沒有網路
: 或是程式的底子根本就也不知道資料要怎麼流，學SA要資料塑膜、流程塑膜、使用者
: 塑模，更要針對每個塑模去描述成程式邏輯，以供往後程式書寫的方便，更要有企管人
: 的特質，去了解使用者的需求，也就是作為使用者和程式撰寫者之間的介面與橋樑。


        其實你只說了一半，而且順序有些問題。

        你應該要先針對 user 去蒐集他們的user case跟資料流程，

        然後再跟據這些資料去拆 ERD 跟拆程式結構 (class diagram)，


        拆ERD跟程式結構需要豐富經驗，因為很多實務的細節純理論是看不到的。
        （這個部份雖然例子很重要，但是要舉舉不完就簡單帶過了，
          舉個簡單的例子來講，有個註冊後要email驗證的會員功能，
          可能就會需要多開一個驗證碼欄位，但不一定每個人都會注意到。
          因為你沒去作那個功能，開出來的東西可能就還是多少會遠離一點現實。）

        （雖然是說我自己也很少ERD一次就到位的啦（遮臉））

: (三)SA的能力真的重要嗎?
:     我也不知道SA的能力到底重不重要?但我只知道，SA的工作真的不好做，要去了解
: 使用者的需要，了解後更不能一味的贊同，更要提出系統可行性的建議，有時也要幫使
: 用者想一些他們沒想到的功能，需求分析過後要把它翻譯成具有程式邏輯的敘述，開始
: 寫程式後還要持續跟使用者互動，以了解是否有達到使用者的需求，這一來一往的過程
: 中往往比寫程式本身還耗時與耗力。

        這部份正常來講應該要切兩塊，一塊是需求分析，另一塊是系統規劃，

        但是程式設計其實也包含這兩塊，說穿了角色是這樣。


        商人 ---- 客戶
        PG  <--->  SA  <----> user
                  商人 ------ 客戶


        所以你說比寫程式還耗時費力，我覺得這是要取決於這個SA的能力，
        如果這個SA 只會把 user 的話轉述，那寫程式的人就死定了這樣。


        大家其實都有溝通方面的損耗，多和少的問題。

: (四)專案開發的力不從心
:     前面講得這麼好聽，問題是，在專案開發時，我一心一意想要朝資管人的特質去發
: 展，但是誰在乎這些?專案企劃書?SA?使用者是誰?管它去死，把系統寫得"看起來"很厲害
: 就好了阿!就算系統再小，那就結合硬體麻!多個RFID、手機，評審老師就把你捧上天了，
: 說你很認真、做得很好！問題是，難道我就不會結合硬體嗎?結合硬體很難嗎?可是，老
: 師，你沒看他根本沒有做需求規劃嗎?專案做完，可是這個專案要給誰用，這個方面的專
: 業有需要這套系統的存在嗎?況且，他們系統好小耶!為什麼只是結合個RFID就飛上天了?
: 不懂，我至今還是不懂。


        你做的不是業界的實務專案，真正的專案都是目標明確的，
        可能規格很不明確，但是目的會很明確。

        這種事情我只能跟你說不是正規的東西，所以當然你看起來會覺得鬼打牆。

: (五)資管= =資工
:     老師說:「讀資管的要有coding技術當背景。」，我想根本不是背景吧，而是要把資
: 管當資工讀，因為需求分析固然重要，但是一開始技術就不好，根本沒有練習管理的機會
: ，我是還沒進過業界啦，但至少在看職缺時，好像沒有"系統分析與設計"的職位；有MIS，
: 但依舊定位不清楚，常被說得好像只是打雜的工作；有PM，但是要正妹才能當阿哭哭Q.Q，
: 所以，唸資管要進業界，還是努力寫程式吧，精通至少一種程式還是能混口飯吃的(淚)。


        我是認為在這行 , coding 技巧是基礎且必備的 ,
        但是要到多深就還是有空間 , 還是老話一句看工作需要.


        但是妄想唸 IM 就可以不用寫一行程式搞分析......
        也不是說沒看過能這麼幹的人啦，但是這麼幹早晚會碰到門檻的。

: --------------------------------以上正文--------------------------------
: 不知道我的觀點有沒有太偏?  因為畢竟我沒去過業界  所以別戰我麻  我是小妹耶^.<
: 但這是我身為資管人四年來的心得
: 有沒有也同是資管人的前輩大大願意跟我分享討論一下的?
: 對了，這種文章能PO在這個版上嗎?  不能的話版主砍一下文章囉!


        我個人是認為現在資管的角色其實比較偏向于系統整合的角色，

        要懂得連結各種資源來達成目標，
        像是外包、規劃、甚至自己coding解決問題都是個方向，


        其實不要把 coding 當成資工跟資管的分界，
        畢竟程式語言就是資訊人的手腳，不去玩等於是自費武功。

        （至於dba或網管，我覺得某種程度上，
          設定config去控制程式跟配出穩定線路，可以加減算是coding的一環啦...）


--
話說回來我認為目前的資管人很多對於資管專業都還達不到一定程度的標準，
我的意思說更清楚些，上課打混跟「只達到課堂要求」的人，不能算是達到標準，

根據我過去的經驗，這類型的人應該保守估計會高於50%。

只要你能突破成為這類型人的困境，工作就不會是問題。（賺大錢就要看機運了）
--
        What do you want to have ?  / What do you have?            
        從書本中，你可以發現我的各種興趣。
        從ＣＤ中，你可以瞭解我所喜歡的偶像明星。

        或許從文字你很難以瞭解一個人，但從物品可以。
        My PPolis , My past. http://ppolis.tw/user/Tony            

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.133.218.161
※ 編輯: TonyQ           來自: 220.133.218.161      (03/13 00:06)
推 Sany:這篇的原po有沒有sd或sa的好書可以推薦呢?3q^
→ TonyQ:對於SA新手的話我覺得 uml4sa 這本書可以簡單一窺個中奧妙。
→ TonyQ:我有買過那本書，簡單的例子應該還算好懂，可以抓到一個實務
→ TonyQ:專案的面貌這樣。（不過還算是蠻片面的啦，因為說真的拆程式
→ TonyQ:結構跟跑時程是蠻吃經驗的東西。）
→ TonyQ:目前窘境主要是因為跑專案最大的麻煩不是在架構，而是在人。
推 Sany:所以sd和sa主要還是要工作有作才能成長嗎? 書的幫助不大嗎?
→ Sany:感謝推薦書,我會去看的3q^^
→ Sany:請問這本也是用uml嗎? 有沒有不用uml的呀,我公司都沒用uml
→ TonyQ:我個人的經驗1.對專案生命流程要有基本認識 2.對你要解決的
→ TonyQ:user背景和問題背景有認識  3.對解決人的突發問題要有認識
→ TonyQ:4.對於自己的角色要先定位清楚
→ TonyQ:看書有用的部份在1.2.(問題背景) 這部份，但是不一定能夠
→ andymai:很簡單~隨便捉個產業流程來設計~拿出去給人家用看看就知道
→ TonyQ:看得到全貌，所以很多東西你還是要去作才會知道。
→ TonyQ:至於uml , 我覺得其實那只是個描述問題的方式 , 不一定需要
→ TonyQ:真的用uml圖，但是在心裡有一些對問題的基本處理方式有概念
→ TonyQ:是很重要的.
→ andymai:看看一堆公司的ERP就知道了~一天到晚改~不要說SA、SD~搞不
→ andymai:好連使用者自己都搞不清楚自己要什麼?反正你就做來用看看
→ andymai:再說嘛~但是有sense的SA、SD就能盡量把改的幅度弄到最小~
→ andymai:不然夾在機車的使用者和資深PG之間~其實也沒多好受...
推 hukhuk:原po是在系統整合商工作嗎？
→ TonyQ:以前曾經是 , 這篇算是我過去在SI跟自己作soho的經驗.
※ 編輯: TonyQ           來自: 220.133.218.161      (03/13 00:47)
推 hukhuk:感謝你的經驗...