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

看板Soft_Job作者 (星界)時間8年前 (2016/06/05 03:09), 8年前編輯推噓21(21推 0噓 16→)
留言37則, 17人參與, 最新討論串1/1
不好意思，因為最近工作上遇到瓶頸，所以想上來請益一下。 所待的軟體公司，規模約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
推
06/05 04:07, , 1F
多請一個SD
06/05 04:07, 1F
目前公司沒有該職位，SA通常兼SD職責(Cost Down？)
→
06/05 04:33, , 2F
SA爛 SA的老闆無能 SA老闆的老闆識人不明 你一槍打三個.
06/05 04:33, 2F
→
06/05 04:35, , 3F
這樣會過 除非這些上層人品超級好......
06/05 04:35, 3F
確實據推測，擋的高階上層，通常底下SA問題也比較大。(業務導向) 但這些高階的業績通常也就比較好，聲音比較大...(成本都轉嫁到底層人員了)
推
06/05 10:10, , 4F
台灣就是不會寫才去當sa的 會寫還能讓你當sa 呵呵
06/05 10:10, 4F
不會寫，去當SA，談需求，我不排斥阿？ 不過不會寫，卻去開規格，這種邏輯是不是怪怪的？ 所以才主張開規格職責拆出來，如果不想多請一個SD負責的話。
推
06/05 10:42, , 5F
推一槍打三個
06/05 10:42, 5F
推
06/05 10:44, , 6F
軟工的存在就是為了盡量減少需求與實作的差異；治本的
06/05 10:44, 6F
→
06/05 10:44, , 7F
方法就是所有人抓去上軟工+溝通與表達
06/05 10:44, 7F
推
06/05 10:46, , 8F
不然永遠都在打掉輪迴...
06/05 10:46, 8F
請問可以告知是軟工哪方面的知識嗎？ 不過如果宅宅工程師也學會溝通與表達，其實就不怎麼需要這些SA了... ※ 編輯: johnson28 (175.182.68.53), 06/05/2016 11:01:11
推
06/05 12:07, , 9F
SA開規格，PG身兼SD，最後SA身兼QA，這樣沒啥好吵了吧！XD
06/05 12:07, 9F
公司SA身兼QA沒錯，PG也常兼部分SD，不過開規格的權責卻是在SA身上
推
06/05 12:19, , 10F
會寫code就會被抓去當pg~
06/05 12:19, 10F
→
06/05 12:19, , 11F
學生的時候我一直覺得不會寫程式的 SA 是一個玩笑，出
06/05 12:19, 11F
→
06/05 12:19, , 12F
來才知道是真的
06/05 12:19, 12F
→
06/05 12:40, , 13F
在台灣 會去當SA的都是__
06/05 12:40, 13F
可是這些__，卻常常是影響專案成敗的關鍵
推
06/05 13:19, , 14F
06/05 13:19, 14F
→
06/05 13:20, , 15F
看懂就有機會改善了
06/05 13:20, 15F
推
06/05 13:25, , 16F
軟工沒有哪方面，就只是確保如何讓系統實現需求的抽象
06/05 13:25, 16F
→
06/05 13:25, , 17F
化過程方向正確
06/05 13:25, 17F
推
06/05 13:26, , 18F
你要會用uml表達；但你不懂oo,你就畫不出合乎邏輯的clas
06/05 13:26, 18F
→
06/05 13:26, , 19F
s diagram,sequence diagram
06/05 13:26, 19F
推
06/05 13:29, , 20F
所以要很全面...無論是domain or 技術面都要夠敏銳
06/05 13:29, 20F
感謝CS大的分享，已經下載下來瀏覽了一下<(_ _)> CS大分享的東西為透過UML以OOAD的方式做專案的分析， 如果說SA/SD能夠透過UML來告知Coder該如何實作出所需功能， 理想上實際成果與預期應該是不會差太多。 這本書對我這樣的Coder是很有幫助的(再次感謝)， 但在於公司的現實層面，SA因不會or不擅長Coding， 會與Domain和技術面都要夠敏銳這點有所衝突.... 不過我會在建議中加上導入UML這個點，感恩。
→
06/05 13:39, , 21F
正常的SA兩邊都要懂 現實的SA只是業務換TITLE而已
06/05 13:39, 21F
(我也這麼覺得) ※ 編輯: johnson28 (175.182.68.53), 06/05/2016 14:04:07
推
06/05 14:01, , 22F
推樓上 啊就軟體業務 說什麼sa
06/05 14:01, 22F
推
06/05 14:02, , 23F
連oo都不會可以當sa? 笑死
06/05 14:02, 23F
推
06/05 14:02, , 24F
業務能力強就該掛業務 不然就請sd
06/05 14:02, 24F
推
06/05 14:02, , 25F
否則sa真的只是好聽
06/05 14:02, 25F
→
06/05 14:56, , 26F
業務要背業績 SA不用
06/05 14:56, 26F
→
06/05 15:31, , 27F
疑?!我以為開規格這東西是一定要畫UML的
06/05 15:31, 27F
推
06/05 18:29, , 28F
如果只是做做樣子導入...千萬不要導入；不然到時候專案
06/05 18:29, 28F
→
06/05 18:29, , 29F
失敗又要說幹uml根本沒用...
06/05 18:29, 29F
→
06/05 18:29, , 30F
不懂的人最愛用這種方式開脫
06/05 18:29, 30F
→
06/06 02:01, , 31F
其實這個基本上是政治問題 不是技術問題了.....
06/06 02:01, 31F
推
06/06 09:45, , 32F
="= SA兼RD已哭哭(中間還兼啥已懶得說)
06/06 09:45, 32F
→
06/06 20:40, , 33F
只要薪水過得去...自己開的規格自己做也不錯啊！
06/06 20:40, 33F
推
06/06 23:42, , 34F
自己開的規格自己做，以後作品集會比較完整嗎？
06/06 23:42, 34F
推
06/07 15:37, , 35F
一條龍就解決惹，你就是那條龍
06/07 15:37, 35F
推
06/07 20:28, , 36F
龍が我がの敵を喰らえ！
06/07 20:28, 36F
感謝各位的參與討論。 更上層回覆的原話為： 「每個專案有不同的Work Model， 為了專案，當然在各方面，要互相Cover。」 然後再加上一個大絕做結尾。 不過我個人更願意將這些話翻譯為： 「為了皇城的和諧與專案的執行，這些東西，你就自己吞了吧！」 然後我就被大絕打趴了。 願大家日後不要遇到這種沒什麼Sense的SA or PM，阿門。 ※ 編輯: johnson28 (175.182.58.184), 06/10/2016 16:58:58
推
08/03 14:23, , 37F
只能推了，偷偷問大絕是甚麼 wwwwwwwww
08/03 14:23, 37F
‣ 更多 johnson28 的文章
文章代碼(AID): #1NKoU2Iu (Soft_Job)