[請益] SA是否必須具備開規格的能力？

[johnson28 (星界)]

不好意思，因為最近工作上遇到瓶頸，所以想上來請益一下。



所待的軟體公司，規模約500人左右，目前工作為實際Coding人員。

內部的SA，雖然在職責上，是必須要具備開規格能力的。

但大多數SA，並不具備該能力，甚至有許多不會寫程式。

在這種情況下所開出來的規格，可以說大多數是不切實際的。

這時候會產生幾種狀況：



1. 東西直接做錯，反覆修改耗費時間。

2. Coding的人再次做分析，並再向SA確認，如此一來需耗費2次分析時間。

3. SA在開規格上權責下放，實際開規格與分析人員為Coding人員。這樣分工

   雖然看似對專案最好，但會有SA領乾薪，Coding人員多做工少領薪問題。



雖然多次向上層提出公司內這種SA問題，並提出開規格與支薪的權責靈活分配，

不過似乎礙於更上層的壓力而無法實行。請問是否有更好的方式，來建議公司改

善目前機制的嗎？





--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 175.182.68.53
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1465067394.A.4B8.html
推 chuegou: 多請一個SD
目前公司沒有該職位，SA通常兼SD職責(Cost Down？)
→ iFEELing: SA爛 SA的老闆無能 SA老闆的老闆識人不明 你一槍打三個.
→ iFEELing: 這樣會過 除非這些上層人品超級好......
確實據推測，擋的高階上層，通常底下SA問題也比較大。(業務導向)
但這些高階的業績通常也就比較好，聲音比較大...(成本都轉嫁到底層人員了)
推 ECMA: 台灣就是不會寫才去當sa的 會寫還能讓你當sa 呵呵
不會寫，去當SA，談需求，我不排斥阿？
不過不會寫，卻去開規格，這種邏輯是不是怪怪的？
所以才主張開規格職責拆出來，如果不想多請一個SD負責的話。
推 dnabossking: 推一槍打三個
推 comesuck: 軟工的存在就是為了盡量減少需求與實作的差異；治本的
→ comesuck: 方法就是所有人抓去上軟工+溝通與表達
推 comesuck: 不然永遠都在打掉輪迴...
請問可以告知是軟工哪方面的知識嗎？
不過如果宅宅工程師也學會溝通與表達，其實就不怎麼需要這些SA了...
※ 編輯: johnson28 (175.182.68.53), 06/05/2016 11:01:11
推 LINGZ: SA開規格，PG身兼SD，最後SA身兼QA，這樣沒啥好吵了吧！XD
公司SA身兼QA沒錯，PG也常兼部分SD，不過開規格的權責卻是在SA身上
推 solamb: 會寫code就會被抓去當pg~
→ iamshiao: 學生的時候我一直覺得不會寫程式的 SA 是一個玩笑，出
→ iamshiao: 來才知道是真的
→ remmurds: 在台灣 會去當SA的都是__
可是這些__，卻常常是影響專案成敗的關鍵
推 comesuck: http://it-ebooks.info/book/2872/
→ comesuck: 看懂就有機會改善了
推 comesuck: 軟工沒有哪方面，就只是確保如何讓系統實現需求的抽象
→ comesuck: 化過程方向正確
推 comesuck: 你要會用uml表達；但你不懂oo,你就畫不出合乎邏輯的clas
→ comesuck: s diagram,sequence diagram
推 comesuck: 所以要很全面...無論是domain or 技術面都要夠敏銳
感謝CS大的分享，已經下載下來瀏覽了一下<(_ _)>



CS大分享的東西為透過UML以OOAD的方式做專案的分析，

如果說SA/SD能夠透過UML來告知Coder該如何實作出所需功能，

理想上實際成果與預期應該是不會差太多。

這本書對我這樣的Coder是很有幫助的(再次感謝)，

但在於公司的現實層面，SA因不會or不擅長Coding，

會與Domain和技術面都要夠敏銳這點有所衝突....

不過我會在建議中加上導入UML這個點，感恩。

→ iFEELing: 正常的SA兩邊都要懂 現實的SA只是業務換TITLE而已
(我也這麼覺得)
※ 編輯: johnson28 (175.182.68.53), 06/05/2016 14:04:07
推 femlro: 推樓上 啊就軟體業務 說什麼sa
推 femlro: 連oo都不會可以當sa? 笑死
推 femlro: 業務能力強就該掛業務 不然就請sd
推 femlro: 否則sa真的只是好聽
→ iFEELing: 業務要背業績 SA不用
→ moelin2007: 疑?!我以為開規格這東西是一定要畫UML的
推 comesuck: 如果只是做做樣子導入...千萬不要導入；不然到時候專案
→ comesuck: 失敗又要說幹uml根本沒用...
→ comesuck: 不懂的人最愛用這種方式開脫
→ iFEELing: 其實這個基本上是政治問題 不是技術問題了.....
推 chenxiaowoo: ="= SA兼RD已哭哭(中間還兼啥已懶得說)
→ johnson28: 只要薪水過得去...自己開的規格自己做也不錯啊！
推 pizzahut: 自己開的規格自己做，以後作品集會比較完整嗎？
推 lovelycateye: 一條龍就解決惹，你就是那條龍
推 Beersheep: 龍が我がの敵を喰らえ！
感謝各位的參與討論。


更上層回覆的原話為：

「每個專案有不同的Work Model，

  為了專案，當然在各方面，要互相Cover。」

然後再加上一個大絕做結尾。



不過我個人更願意將這些話翻譯為：

「為了皇城的和諧與專案的執行，這些東西，你就自己吞了吧！」

然後我就被大絕打趴了。


願大家日後不要遇到這種沒什麼Sense的SA or PM，阿門。
※ 編輯: johnson28 (175.182.58.184), 06/10/2016 16:58:58
推 sevend30: 只能推了，偷偷問大絕是甚麼 wwwwwwwww