※ 本文為 terievv 轉寄自 ptt.cc 更新時間: 2016-06-08 21:58:46
看板 Soft_Job
作者 標題 [請益] SA是否必須具備開規格的能力？
時間 Sun Jun 5 03:09:51 2016
不好意思，因為最近工作上遇到瓶頸，所以想上來請益一下。
所待的軟體公司，規模約500人左右，目前工作為實際Coding人員。
內部的SA，雖然在職責上，是必須要具備開規格能力的。
但大多數SA，並不具備該能力，甚至有許多不會寫程式。
但大多數SA，並不具備該能力，甚至有許多不會寫程式。
在這種情況下所開出來的規格，可以說大多數是不切實際的。
這時候會產生幾種狀況：
1. 東西直接做錯，反覆修改耗費時間。
2. Coding的人再次做分析，並再向SA確認，如此一來需耗費2次分析時間。
3. SA在開規格上權責下放，實際開規格與分析人員為Coding人員。這樣分工
雖然看似對專案最好，但會有SA領乾薪，Coding人員多做工少領薪問題。
雖然看似對專案最好，但會有SA領乾薪，Coding人員多做工少領薪問題。
雖然多次向上層提出公司內這種SA問題，並提出開規格與支薪的權責靈活分配，
不過似乎礙於更上層的壓力而無法實行。請問是否有更好的方式，來建議公司改
善目前機制的嗎？
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.182.68.53
※ 文章代碼(AID): #1NKoU2Iu (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1465067394.A.4B8.html
推 : 多請一個SD1F 06/05 04:07
目前公司沒有該職位，SA通常兼SD職責(Cost Down？)→ : SA爛 SA的老闆無能 SA老闆的老闆識人不明 你一槍打三個.2F 06/05 04:33
→ : 這樣會過 除非這些上層人品超級好......
確實據推測，擋的高階上層，通常底下SA問題也比較大。(業務導向)→ : 這樣會過 除非這些上層人品超級好......
但這些高階的業績通常也就比較好，聲音比較大...(成本都轉嫁到底層人員了)
推 : 台灣就是不會寫才去當sa的 會寫還能讓你當sa 呵呵4F 06/05 10:10
不會寫，去當SA，談需求，我不排斥阿？不過不會寫，卻去開規格，這種邏輯是不是怪怪的？
所以才主張開規格職責拆出來，如果不想多請一個SD負責的話。
推 : 推一槍打三個5F 06/05 10:42
推 : 軟工的存在就是為了盡量減少需求與實作的差異；治本的6F 06/05 10:44
→ : 方法就是所有人抓去上軟工+溝通與表達
推 : 不然永遠都在打掉輪迴...
請問可以告知是軟工哪方面的知識嗎？→ : 方法就是所有人抓去上軟工+溝通與表達
推 : 不然永遠都在打掉輪迴...
不過如果宅宅工程師也學會溝通與表達，其實就不怎麼需要這些SA了...
※ 編輯: johnson28 (175.182.68.53), 06/05/2016 11:01:11
推 : SA開規格，PG身兼SD，最後SA身兼QA，這樣沒啥好吵了吧！XD9F 06/05 12:07
公司SA身兼QA沒錯，PG也常兼部分SD，不過開規格的權責卻是在SA身上推 : 會寫code就會被抓去當pg~10F 06/05 12:19
→ : 學生的時候我一直覺得不會寫程式的 SA 是一個玩笑，出11F 06/05 12:19
→ : 來才知道是真的
→ : 來才知道是真的
→ : 在台灣 會去當SA的都是__13F 06/05 12:40
可是這些__，卻常常是影響專案成敗的關鍵Use Case Driven Object Modeling with UML - Free Download eBook - pdf Use Case Driven Object Modeling with UML: Theory and Practice shows how to drive an object-oriented software design from use case all the way through ...
→ : 看懂就有機會改善了15F 06/05 13:20
推 : 軟工沒有哪方面，就只是確保如何讓系統實現需求的抽象
→ : 化過程方向正確
推 : 你要會用uml表達；但你不懂oo,你就畫不出合乎邏輯的clas
→ : s diagram,sequence diagram
推 : 所以要很全面...無論是domain or 技術面都要夠敏銳
感謝CS大的分享，已經下載下來瀏覽了一下<(_ _)>推 : 軟工沒有哪方面，就只是確保如何讓系統實現需求的抽象
→ : 化過程方向正確
推 : 你要會用uml表達；但你不懂oo,你就畫不出合乎邏輯的clas
→ : s diagram,sequence diagram
推 : 所以要很全面...無論是domain or 技術面都要夠敏銳
CS大分享的東西為透過UML以OOAD的方式做專案的分析，
如果說SA/SD能夠透過UML來告知Coder該如何實作出所需功能，
理想上實際成果與預期應該是不會差太多。
這本書對我這樣的Coder是很有幫助的(再次感謝)，
但在於公司的現實層面，SA因不會or不擅長Coding，
會與Domain和技術面都要夠敏銳這點有所衝突....
不過我會在建議中加上導入UML這個點，感恩。
→ : 正常的SA兩邊都要懂 現實的SA只是業務換TITLE而已21F 06/05 13:39
(我也這麼覺得)※ 編輯: johnson28 (175.182.68.53), 06/05/2016 14:04:07
推 : 推樓上 啊就軟體業務 說什麼sa22F 06/05 14:01
推 : 連oo都不會可以當sa? 笑死
推 : 業務能力強就該掛業務 不然就請sd
推 : 否則sa真的只是好聽
推 : 連oo都不會可以當sa? 笑死
推 : 業務能力強就該掛業務 不然就請sd
推 : 否則sa真的只是好聽
→ : 業務要背業績 SA不用26F 06/05 14:56
→ : 疑?!我以為開規格這東西是一定要畫UML的27F 06/05 15:31
推 : 如果只是做做樣子導入...千萬不要導入；不然到時候專案28F 06/05 18:29
→ : 失敗又要說幹uml根本沒用...
→ : 不懂的人最愛用這種方式開脫
→ : 失敗又要說幹uml根本沒用...
→ : 不懂的人最愛用這種方式開脫
→ : 其實這個基本上是政治問題 不是技術問題了.....31F 06/06 02:01
推 : ="= SA兼RD已哭哭(中間還兼啥已懶得說)32F 06/06 09:45
→ : 只要薪水過得去...自己開的規格自己做也不錯啊！33F 06/06 20:40
推 : 自己開的規格自己做，以後作品集會比較完整嗎？34F 06/06 23:42
推 : 一條龍就解決惹，你就是那條龍35F 06/07 15:37
推 : 龍が我がの敵を喰らえ！36F 06/07 20:28
--
※ 看板: terievv 文章推薦值: 0 目前人氣: 0 累積人氣: 628
回列表(←)
分享