為什麼這篇SA文件 怎麼寫鄉民發文收入到精華區：因為在SA文件 怎麼寫這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者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
→ felixgugu: 他是在傳產偶爾還要兼MIS的那種公司 =,= 11/23 11:32
※ 編輯: FantasyRyu (220.135.200.163), 11/23/2015 11:46:19→ a47135: PG久了應該不怕客戶端才對吧，不管是系統還是運作邏輯都很 11/23 11:54
→ a47135: 熟了，哪有什麼好怕的 11/23 11:55
→ a47135: 一切唯唯諾諾、皆曰可行的樣子 <-- 而且這跟PG、SA屁關係 11/23 11:56
→ a47135: 都沒，這是人的問題 11/23 11:56
→ a47135: 有些人就是賤，反正死的不是他 11/23 11:57
→ testPtt: 想得太美好 一堆奧客就喜歡先做看看再說哪裡要改怎麼樣 11/23 12:28
噓 Masakiad: 胡言亂語 11/23 12:40
噓 ihon822: 網站跟軟體系統SA差很多好嗎... 11/23 13:32
推 chuegou: 我這個韌體工程師到剛剛才發現原來我兼職SA... 11/23 16:38
→ leolarrel: 只能推敏捷開發了(淚) 11/23 19:01
→ superpai: 就好像講師本來就不一定要會說話，他的工作是傳遞知識 11/23 20:40
→ superpai: 是個啞巴的話，找個會講話的代講就好了 11/23 20:41
→ viper9709: 台灣的SA好像很少這麼專業的XD 11/23 23:45
推 leicheong: 你說的是PM不是SA吧... 或者該說是掛SA名的PM? 11/24 19:09
→ leicheong: SA至少應該具備合理選擇系統架構的能力, 沒有這個甚麼 11/24 19:11
→ leicheong: 都不用想. 11/24 19:11
噓 locklose: 我反對你所述的,SA起碼要會寫程式,但不必達該語言顛峰 11/25 18:45
→ locklose: 既然是談需求談架構,大量軟體的解決方案與使用案例 11/25 18:46
→ locklose: 範例程式,這些都是SA起碼要提供出來的 11/25 18:47
→ locklose: 剩下的技術驗證/實作/調整/追蹤 才輪到 SD PG 11/25 18:48
推 dnzteeqrq: 推樓上惹 11/25 19:58
→ shanishani: lock大的論點我比較贊同..我本身也是PG做上來的 11/26 23:31