為什麼這篇sd文件範例鄉民發文收入到精華區:因為在sd文件範例這個討論話題中,有許多相關的文章在討論,這篇最有參考價值!作者FantasyRyu (眩惑之龍)看板Soft_Job標題Re: [請益] 遇到不懂程式亂開規格...
※ 引述《serica (銀月奔流)》之銘言:
: 這個你只能越級呈報
: 跟上級說SA不懂程式
: 很多東西是程式寫不出來的
: 今天如果SA寫得出來,就是你的問題
: 問題是SA也寫不出來
: 要嘛換SA,要嘛你走
: 不然你們就註定是個充滿悲劇的地獄組合
: 所以說SA最好還是由PG出身
: 不然老是答應一堆有的沒有的
: 跟本作不到的事情
: 出了問題還搞不清楚狀況
: 不過話說上面的若不挺你
: 你還是趕快另尋高就吧
: 良禽擇木而居
System Analyst本來就可以不用會寫程式,
之前跟不少純SA合作過,也沒出什麼問題。
但前提有三個:
①SA起碼要把他的角色做好
②如果他程式真的完全不會寫也沒有概念,那麼要有SD罩他,分進合擊才行。
③如果他對UI/UX也沒有概念,那原型設計也要有人檢核過(最好是F2E)
SA的角色在談需求,而且是甲乙雙方都認可的可行需求,而不是那種甲方亂幹一通,
不管有沒有道理就通通收回來叫底下做的那種。這種的唯唯諾諾SA也不夠合格。
接下來他必須要好好研究流程、研究有哪些畫面、畫面上有哪些按鈕、哪些功能,
欄位有哪些、驗證規格是什麼、例外狀況是什麼、錯誤操作步驟下,會出什麼警示
訊息。
(是的你可以不會寫 <input type="password"> 但不要給我連這頁上要不要密碼欄、
客戶希望密碼欄多長、用什麼密碼驗證方式、要不要大小寫混用要不要符號什麼的
都一問三不知、最後還叫開發人員隨便選一個)
UML圖如果懶得用Microsoft Visio畫漂亮版本也沒差,你可以畫在白板上跟客戶溝通、
取得客戶簽名認可,白板上的圖大不了拍下來參考即可。
如果客戶要這些文件,事後叫文案助理幫忙把白板拍的照片畫成漂亮文件即可。不
用浪費時間叫SA畫。
由於大部份時間都在做文件、做需求單位與實現單位的溝通,所以溝通、文件能力
絕對是首要。接下來他在該領域的知識,絕不能太弱。如果要支援ERP的SA,結果連
ERP是幹嘛的都不曉得,這樣的SA太危險,絕對會因為什麼產業例外狀況沒想到、流
程沒設計完善而出包。
最後,完全不會寫程式的SA,如果剛好他的UI / UX也沒有概念,不清楚Web上與
手機上一般都用什麼元件來實現他的流程設計,那麼最好也有F2E(前端工程師)
幫他看一下原型設計,避免由SA自己做Mockup Prototype,畫了一堆很難用、很
不好實現的脫離現實UI。
你覺得你的SA很難配合,只是因為他根本連自己的本份都沒做到,他不會做的東西
也沒有人幫忙(當然或許他也根本也沒有自覺),主管根本也不知道一個軟體工程
案子究竟有哪些工作要做,如此而已。
你可以不掛這個職稱,小公司或小專案也不可能把什麼F2E、SA、SD全都分給不同人
做。但是上述提到的工作,一定要有人做,不是分工做就是兼職做,而不是推來推
去最後放空。一堆案子的時程管理放空、研究需求叫甲方做甲方說啥就做啥、原型
設計根本跳過,為啥?因為PM每天在應酬沒空,然後SA忙著在開Table、協助修Bug……
台灣人對SA的要求通常希望他全包,最好可以管時程、研究需求、出漂漂亮亮接近
實際狀況的原型設計、最好連資料表都會開、做做正規化……
然後一堆PG想說我翅膀硬惹、老惹就可以升SA惹。
靠夭,再說一次,SA的本職是先做好溝通能力、文件能力、強大領域知識
開發人員的本職是開發程式、技術深入研究、精研設計模式、良好單元測試
PG待久惹、老惹,突然就可以學會SA的本職?
先看看自己程式註解上有多少錯字跟病句好嗎……再想想自己去到客戶端嚇得
屁滾尿流,一切唯唯諾諾、皆曰可行的樣子好嗎……還想跟我說這樣要轉SA……
難怪台灣職場常常碰到不合格的SA。你叫SA去補強非必備的技能,就等於讓他放任
自己原本該做的事,更有理由做不好了。最後大家害來害去,專案倒掉。
SA的本職沒做好而害慘團隊的效果,可比PG本職沒做好遠遠大多了。因為他負責的
可是房子的藍圖。
(SD負責地基與樑柱、PG負責往上蓋一路蓋到好、QA負責監工)
要是隨便就能碰到能獨立蓋整棟的強者SA,靠北惹,去這種白爛職場被整幹嘛,
一起來做SOHO就好惹,歡迎寄站內信給我(?)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 220.135.200.163
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1448249222.A.6FB.html