不好意思，因為最近工作上遇到瓶頸，所以想上來請益一下。
所待的軟體公司，規模約500人左右，目前工作為實際Coding人員。
內部的SA，雖然在職責上，是必須要具備開規格能力的。
但大多數SA，並不具備該能力，甚至有許多不會寫程式。
在這種情況下所開出來的規格，可以說大多數是不切實際的。
這時候會產生幾種狀況：
1. 東西直接做錯，反覆修改耗費時間。
2. Coding的人再次做分析，並再向SA確認，如此一來需耗費2次分析時間。
3. SA在開規格上權責下放，實際開規格與分析人員為Coding人員。這樣分工
雖然看似對專案最好，但會有SA領乾薪，Coding人員多做工少領薪問題。
雖然多次向上層提出公司內這種SA問題，並提出開規格與支薪的權責靈活分配，
不過似乎礙於更上層的壓力而無法實行。請問是否有更好的方式，來建議公司改
善目前機制的嗎？

多請一個SD

SA爛 SA的老闆無能 SA老闆的老闆識人不明 你一槍打三個.這樣會過 除非這些上層人品超級好......

台灣就是不會寫才去當sa的 會寫還能讓你當sa 呵呵

推一槍打三個

軟工的存在就是為了盡量減少需求與實作的差異；治本的方法就是所有人抓去上軟工+溝通與表達不然永遠都在打掉輪迴...

SA開規格，PG身兼SD，最後SA身兼QA，這樣沒啥好吵了吧！XD

會寫code就會被抓去當pg~

學生的時候我一直覺得不會寫程式的 SA 是一個玩笑，出來才知道是真的

在台灣 會去當SA的都是__

http://it-ebooks.info/book/2872/看懂就有機會改善了軟工沒有哪方面，就只是確保如何讓系統實現需求的抽象化過程方向正確你要會用uml表達；但你不懂oo,你就畫不出合乎邏輯的class diagram,sequence diagram所以要很全面...無論是domain or 技術面都要夠敏銳

正常的SA兩邊都要懂 現實的SA只是業務換TITLE而已

推樓上 啊就軟體業務 說什麼sa連oo都不會可以當sa? 笑死業務能力強就該掛業務 不然就請sd否則sa真的只是好聽

業務要背業績 SA不用

疑?!我以為開規格這東西是一定要畫UML的

如果只是做做樣子導入...千萬不要導入；不然到時候專案失敗又要說幹uml根本沒用...不懂的人最愛用這種方式開脫

其實這個基本上是政治問題 不是技術問題了.....

="= SA兼RD已哭哭(中間還兼啥已懶得說)

只要薪水過得去...自己開的規格自己做也不錯啊！

自己開的規格自己做，以後作品集會比較完整嗎？

一條龍就解決惹，你就是那條龍

龍が我がの敵を喰らえ！