※ 編輯: chermany (118.170.23.96), 11/22/2015 22:59:53

---

※ 引述《chermany (qq)》之銘言：
: 來到一家傳產做機械的想要我寫一套生管系統然後上面開規格的是一個生管人員
: ，開會的時候由他去了解user的需求，然後叫我寫出來…問題來了：
: 他很了解生產流程沒錯，可是開規格完全不行比如生產流程系統化，生管資料怎
: 麼控管之類的，還好我本身有寫過資訊系統，也管理過erp，大約知道資料流控
: 管。
: 但是這個老大，老把他在excel上key資料算資料的那一套想要搬到資料庫來
: 比如說某欄金額=單價*數量，但是其中有幾筆金額=單價*數量*3.1416，而
: 這系數是沒來由的經驗法則判斷，他們也不想去維護，反正你pg就是想辦法
: 給我自動判斷出來…對搞過erp的人來說他的要求幾乎是和excel差不多，
: 資料沒有規則性和關連性。
: 對data schema也完全不懂，主鍵，資料流更不用說了…寫程式的方式就是
: 他跟user問一下需求，然後跟你講講，就要生出來給他…
: 然後最氣的是，跟他說他開的規格有問題，程式沒辦法寫的話，他就直接
: 跟最上頭的主管說你故意不配合，寫不出來…公司其他網管、維修的雜事
: 也叫我去處理，也不管你程式的進度需不需要趕…
: 來這裡大約半年了，更上頭的主管也是製造出身的…也是挺他…但是想到
: 自己也是年屆不惑，看這種情勢不太可能在這裡升官發展，是否該早早換
: 跑道…

這個你只能越級呈報
跟上級說SA不懂程式

很多東西是程式寫不出來的
今天如果SA寫得出來，就是你的問題
問題是SA也寫不出來
要嘛換SA，要嘛你走
不然你們就註定是個充滿悲劇的地獄組合

所以說SA最好還是由PG出身
不然老是答應一堆有的沒有的
跟本作不到的事情
出了問題還搞不清楚狀況

不過話說上面的若不挺你
你還是趕快另尋高就吧
良禽擇木而居

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 58.115.127.77
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1448243621.A.A71.html

---

※ 引述《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
※ 編輯: FantasyRyu (220.135.200.163), 11/23/2015 11:46:19

---

※ 引述《FantasyRyu (眩惑之龍)》之銘言：
: ※ 引述《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就好惹，歡迎寄站內信給我（？）

一個系統有好的SA真的受益許多

版上很多人對於非本科又想轉職的，我誠心建議可以考慮以SA為首個職涯目標。

你們可以發現東西寫出來非常重要，突破技術瓶頸更是超級重要，但是這都建立在你做的
東西是客戶或是老闆要的。

我遇過中文系出身的SA雖然不會寫code，只要能清楚描述需求，人能溝通，我都覺得系統
已經完成了，剩下的時間只是證明這件事而已。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.214.21.116
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1448327074.A.CDF.html


--
※ 作者: terievv 時間: 2015-11-27 14:34:46