Re: [請益] 遇到不懂程式亂開規格的SA怎麼辦

看板Soft_Job作者 (眩惑之龍)時間10年前 (2015/11/23 11:27), 10年前編輯推噓0(3317)
留言23則, 13人參與, 最新討論串3/4 (看更多)
※ 引述《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

11/23 11:32, , 1F
他是在傳產偶爾還要兼MIS的那種公司 =,=
11/23 11:32, 1F
※ 編輯: FantasyRyu (220.135.200.163), 11/23/2015 11:46:19

11/23 11:54, , 2F
PG久了應該不怕客戶端才對吧,不管是系統還是運作邏輯都很
11/23 11:54, 2F

11/23 11:55, , 3F
熟了,哪有什麼好怕的
11/23 11:55, 3F

11/23 11:56, , 4F
一切唯唯諾諾、皆曰可行的樣子 <-- 而且這跟PG、SA屁關係
11/23 11:56, 4F

11/23 11:56, , 5F
都沒,這是人的問題
11/23 11:56, 5F

11/23 11:57, , 6F
有些人就是賤,反正死的不是他
11/23 11:57, 6F

11/23 12:28, , 7F
想得太美好 一堆奧客就喜歡先做看看再說哪裡要改怎麼樣
11/23 12:28, 7F

11/23 12:40, , 8F
胡言亂語
11/23 12:40, 8F

11/23 13:32, , 9F
網站跟軟體系統SA差很多好嗎...
11/23 13:32, 9F

11/23 16:38, , 10F
我這個韌體工程師到剛剛才發現原來我兼職SA...
11/23 16:38, 10F

11/23 19:01, , 11F
只能推敏捷開發了(淚)
11/23 19:01, 11F

11/23 20:40, , 12F
就好像講師本來就不一定要會說話,他的工作是傳遞知識
11/23 20:40, 12F

11/23 20:41, , 13F
是個啞巴的話,找個會講話的代講就好了
11/23 20:41, 13F

11/23 23:45, , 14F
台灣的SA好像很少這麼專業的XD
11/23 23:45, 14F

11/24 19:09, , 15F
你說的是PM不是SA吧... 或者該說是掛SA名的PM?
11/24 19:09, 15F

11/24 19:11, , 16F
SA至少應該具備合理選擇系統架構的能力, 沒有這個甚麼
11/24 19:11, 16F

11/24 19:11, , 17F
都不用想.
11/24 19:11, 17F

11/25 18:45, , 18F
我反對你所述的,SA起碼要會寫程式,但不必達該語言顛峰
11/25 18:45, 18F

11/25 18:46, , 19F
既然是談需求談架構,大量軟體的解決方案與使用案例
11/25 18:46, 19F

11/25 18:47, , 20F
範例程式,這些都是SA起碼要提供出來的
11/25 18:47, 20F

11/25 18:48, , 21F
剩下的技術驗證/實作/調整/追蹤 才輪到 SD PG
11/25 18:48, 21F

11/25 19:58, , 22F
推樓上惹
11/25 19:58, 22F

11/26 23:31, , 23F
lock大的論點我比較贊同..我本身也是PG做上來的
11/26 23:31, 23F
文章代碼(AID): #1MKeU6Rx (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1MKeU6Rx (Soft_Job)