※ 引述《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://webptt.com/m.aspx?n=bbs/Soft_Job/M.1448249222.A.6FB.html ※ 編輯: FantasyRyu (220.135.200.163), 11/23/2015 11:46:19