職業相談

抱怨結束...

不過我在這種工作狀態的期間也覺醒了想要成為SA的念頭，但覺得自己好像又不是很夠格，尤其是業務層面的知識，雖然在寫程式時因為大量接觸有稍微懂依些業務層面的知識，但其實也只是那種不上不下的懂的程度，真的要跟客戶談而且還可以引導客戶從中斡旋我個人是覺得目前尚沒辦法。

想問問島民如果已經有這樣的目標了，除了多多補充業務知識外，還要做些什麼準備才能培養自己成為SA呢？
或者說，從目前做的這些雜事中，特別去牽住什麼點，讓自己可以朝那個方向更邁進一步？

>SA跟PM
先說 別把這兩個搞混了喔

先問 原po所認定的SA的工作內容是什麼?
一般來說 System Architecture 其實 SA的價值在於 處理程式架構
與 對客人的需求 去選擇/組織 程式的架構層面
EX 要不要用SPA or 用傳統的mutiple page / 要用microservice架構嗎? / server"群"怎麼架 後續保守與發展怎麼做
這是SA的核心價值 (後面還有人轉成SRE就是了)

>業務層面的知識 / 真的要跟客戶談而且還可以引導客戶從中斡旋
這其實比較是PM的工作
PM的主要價值在於 搞懂對方的business model 甚至去改善對方的商業模式
在搞懂神麼東西能對對方公司有用後 定義出 能達成對方要求的 程式需求(要件定義/規格定義)
需求出來後 平衡 對方公司的預算 / 自己公司的預算 (這兩塊 通常是衝突的) 再來是 平衡其他性質的政治需求(團隊對團隊間的公司內部資源爭奪)
最後才是 計畫執行面的 management 又其實PM管的是management 而非管 leadership 這兩管理 其實方向性不一樣
對PM來說 程式是很旁枝末節的事情 了不起管管架構(SA的領域) 又哪個MVP工程師要鬧退職(跟不退職)之類 PM會在乎這種關鍵resource的in/out

區別先拉開之後 第一個問題是 到底目標是SA還是PM ?

PM的核心問題是business modeling/ 利害關係人管理 與Plans are nothing, planning is everything上
SA的問題還是在技術上 不過 SA一決定一個架構 一推的SE跟PG要按照這個架構走

然後
PM的技能基本上 比較是針對一家公司的性質 也就是到別的公司不見得通用(轉職上 不見得被直接評價)
SA的技能基本上 到處都可以用(轉職上 那邊都會有差不多的評價)
雖說PM因為懂錢跟政治 看得懂之下 比較不會自己跳到 沒錢沒權的坑就是了

走PM來說 客人公司的業務要懂 要會打關係 社內政治/資源調整(爭奪)會是日常工作 再來要懂預算(錢) 資源(人員?)管理
走SA 技術能力如何?
基盤的議題: server(Linux)問題/ AWS與GCP與Firebase/ 一堆server製品(apache/nginx)/ Docker與vagrant/ CDN與varnish ...etc
稍微架構的議題: SPA v.s mutiple page/ microservice/ 前端那該死的架構生態圈/ Repository pattern與DDD ...etc

原po對哪塊有興趣(與職涯打算怎麼走) 要先定下來說 不然方向性不會對的
不過 遇一個問題 填一個坑(+該翻的書好好翻一翻) 也是一種走法 坑填多了 該有的能力應該也都有了 到時再去選也行

>>No.78337
>對客人的需求 去選擇/組織 程式的架構層面
目前我做的是以建置銀行金融系統為主的工作，主要是偏資料庫的架構建置、存取與SQL查詢寫入的工作。
就我觀察我們這裡的SA在金融面的業務背景比較雄厚，
所以除了只是接客戶提出的需求外，也能適時的提出客戶的需求在實作資料存取時可能會出現的問題，並且適度的引導客戶怎麼做會更好。

>PM的主要價值在於 搞懂對方的business model 甚至去改善對方的商業模式
嗯，這個又是另一個層次了，我所指的業務邏輯是指產業背後的龐大業務知識。
以金融來說就是存款、貸款、擔保品、聯徵、會計帳.....等等等不同業務的知識面，
比如：今天要做擔保品額度相關的報表或批次，
SA勢必要清楚擔保品的特性，是有擔還是無擔？
每個額度下對應的擔保品是要依據什麼原則或什麼分類做加總計算？是要用貸款帳戶當Key值？還是要用額度號做Key值？
如果大部分的報表針對某些Table用的共同資料較多，需不需要做中間檔？.....之類的

>>No.78338
>基盤的議題: server(Linux)問題/ AWS與GCP與Firebase/ 一堆server製品(apache/nginx)/ Docker與vagrant/ CDN與varnish ...etc
稍微架構的議題: SPA v.s mutiple page/ microservice/ 前端那該死的架構生態圈/ Repository pattern與DDD ...etc
看到這邊的時候又不經想，如果只做單一產業的SA的話，SA的價值似乎就被那個產業鎖死了，好像不能做到很廣義層面的SA，這樣感覺跳到別的產業馬上就死了Orz
這麼看來對架構議題的層面也要有一定的知識背景才行呢
雖然不確定只以資料庫為基礎的架構議題來學習會不會又把路走死了XDDD

>雖然不確定只以資料庫為基礎的架構議題來學習會不會又把路走死了XDDD
啊，當然，我做的PG的工作不是只有資料庫部分啦(只是目前比較多......多到從JAVA工程師變成DB工程師的感覺)

如果需求複雜一點的話就會寫JAVA來輔助，架構面的話Spring Framework跟MVC多少有碰一點

只不過，最近點開104的職缺來看，就覺得自己的技能學得很不夠的感覺......Orz

>>No.78339
恩...No.78339所寫的工作內容與其說是SA 不如說是SE(System Engineer)
SA的核心議題是 基盤跟架構層 SE的核心議題是 設計
SA的問題 會比SE的問題還要難 又 SE的設計解決方案會受限於 SA所架好的基盤與架構

>擔保品的特性 / 擔保品加總計算 / key選擇 / Table -> DB設計
這些是很典型的 設計問題 這是SE的工作內容
設計的重點在於 要做的東西的方向性已經大概出來後 解決方案的"辦法" 是什麼? 還有那個作法會比較順
又規模夠大來說 SE設計好後 程式碼可以丟給PG去寫
PG則是 解決方案的實作 又這種實作 並不值錢w

SE所需求的業務知識其實滿片面的 也不會要到很深 一個系統區塊一份知識 遇到問題後去查 能跟客戶談就行了
但要升到PL(project leader)跟PM來說 那會是晉升的關鍵 又 如果No.783395真的打算待"金融業IT一輩子"來說
靠的是業務知識 不是靠程式技術 -> 這點來說 或許某方面到最後之下 哪邊都差不多
程式並不值錢 重點是拿程式去做什麼才值錢

>DB工程師
恩...DBA很大喔 基本上不會比SA小 不過如果只是做做CRUD議題來說 其實只是SE
DBA會去管DB的access權限 與 實際資料出問題時 基本上 要動都要DBA蓋章才行
真的爬得上DBA來說 這位子可以吃一輩子 要不要往這位子爬爬看XD
SQL antipattern 23: Diplomatic Immunit 這已經說明了 DBA有多肥了w

>核心問題
根本的問題還是 原po打算怎麼走吧
打算長待金融業來說 把業務知識補一補/想辦法去更大的客人談/搞定公司內部的政治-管理-人員問題
這些大概會是主要的晉升標竿 (又基幹系的系統體系 大概就這個樣子) 技術能力問題 其實不太重要
又金融業來說 該有的預算會有 待遇基本上還可以

但論從外面看來說 雖然DB工程的深度沒寫清楚 不過(大概?)原po技術是不太夠的
(當然如果能去處理 很深的oracle製品問題 那或許是另一件事)
不過真的技術不夠來說 這也不是原po的問題 而是基幹系本身不太靠技術
再來 基幹系本身的基盤已經不太動了 那是非常上層的事情 真的要動來說 下面絕對雞飛狗跳

論java技術面來說 SpringBoot + 隨便一個三大前端
有沒有辦法搞個簡單RESTful SPA + deploy到AWS上 的玩具
多一點在綁個junit unit test寫一寫 有沒有辦法做得到?
然後 java6/java7/java8的差異 又java8的lamda式 寫的了嗎? java9先放一邊了 (java9以後是偉~~大~~Oracle的問題)

跳躍一點 如果還對技術有興趣 早點離開java的圈子可能比較安全
java的圈子 不進步的環境不少 SSH的老環境(spring/struts/hibernate) / struts則是爛到不能再爛的東西(現今的時間點來說)
雖然說 springBoot + spring cloud 會是相當神通廣大的環境 又spring cloud的技術生態圈背後好像是 Netflix在撐
不過 會用到springBoot就已經很少了 更別提spring cloud

又JAVA(真的)會寫來說 基本上要換跑道又願意學新東西 那邊都會滿願意給機會的
不過基幹系出身 要去換到比較活潑的web圈來說 環境的性質與議題 會完全不一樣就是了

例如 基幹系 按照環境構築文件 架環境架不起來 該工程師一判斷 文件有問題後 向上呈報 文件有問題 就不管了(常有的事)
web來說 SA動了個什麼基盤設定 導致自己得local環境炸了
自己trooble shooting 找出關鍵問題去問SA後 自己把local環境給搞活 這種事 家常便飯

剛下班就看到5jXhQYoE大大滿滿的回覆QQ
非常感謝5jXhQYoE大大的指引！！

>但論從外面看來說 雖然DB工程的深度沒寫清楚 不過(大概?)原po技術是不太夠的
確實，大概頂多就是SELECT、INSERT、DELETE、TRUNCATE、Temp套娃，或者複製資料庫這種程度吧QQ
(因為都在做銀行報表)

至於什麼ER Model、正規化......都還處於學生時代學過但從未在工作中應用的階段QQ

但也很感謝大大提供的建議，感覺努力的方向又多了一些，
現在是想說在金融產業也待了1、2年，技術能力普普如我，覺得把重心放在充實Domain Know how上會更好

也因為快30了，也差不多該思考下一個10年該走哪條路了，所以才會開始想PG的下一步該往哪走
DBA跟SE感覺都是可以努力的方向，而且都是目前可以在實務上盡量去努力實踐的內容

再次感謝大大的建議~~~

>>No.78344
不是我想說,如果講的是軟體,說SA是System Architecture就已經是大失無誤了.
能講這麼多還沒發現哪裡奇怪真的很奇怪,不過不愧是大失,不裝就夠像了

這個字非常容易誤導引出大失自爆,用SDLC會好很多

回到正題,先來講SA
最大跟唯一的問題就是,
你能拿你公司的產品去套客戶
,或是,
還是客戶拿他們的流程套你

之後所有的問題都會從這裡產生,所以說是唯一的問題
我個人支持後者,所以我會想去當公司的軟體部門 (>軟體公司的__(職位隨便填))

我看你講的情況應該是前者....前者的話,除非能開一個完全的新專案(注意,這個發生的話就變成後者了),
SA基本上是做不了的,就算是號稱能隨便客製化的SAP都做不到(除非有超級鈔能力)
內部要面對上面要你不改,外部要面對客戶叫你改
這時候要做的是找出平衡點

SA其實所有人都應該要參與,就算你不想,為了防止談出神奇的結果還是得去
看大失就知道見鬼說鬼話見妖說妖話,講了一大堆其實還是沒講SA,實在是太厲害了
遇到這種你不去後果你就得背

(續)
SA(前者)我大致分三點需求
1.需要完全了解公司軟體以及流程,你才能預估能改多少,改多少不會被老闆婊

2.需要相當的業界經驗,才能用最短的時間了解客戶的流程,
就算是同行業的客戶也都會有他們自己的習慣跟方式,要理解他們為啥要做這些才能預估要花多久改

3.最後就是外交能力,說嘴炮也行,
你能炮到客戶直接投降用你的軟體還要不用改話你會最輕鬆,是不是最好的我不予置評
中間怎麼談,談多少,都需要交際能力,然後,這不只對外,也要對內

SA(後者)的好處是幾乎不會有1(改的部分)
是3可能會變多,因為會更容易聽到不同的使用者對於同一個功能的要求(抱怨?)

除非自創公司/新公司/完全新專案,前者跟後者的使用跟開發環境都是確定的
講有的沒的只會讓人知道完全沒有經驗啊,我要講的是閣下沒發現的話的確要檢討

再來講SE跟DBA
基本上都是入門容易上手難
也不是挑哪一個,重點是你兩者分不開,看起來你是系統類軟體
在這個假設下,你一邊起來了另外一邊就不會差到哪去

真要說的話DBA是不會去管軟體開發或是使用的問題的,真的管到的話那就是出大事了
換個方式說,你開發軟體的時候不可能整天等DBA回答你為啥抓不到資料,你自己不上誰上?

稍微談一下真正的DBA應該做啥
這些還只是初中級的
(我只是想講這句->問DBA為啥這query沒資料只會讓他想打你)

設定Mirror,本體分身加證人(建議大失,這行看不懂的話我建議不要再依靠幻想去婊人了...)

設定Master Key,S-Key,A-Key,還有生相對應的憑證檔給別台電腦用
(黑暗面就是這些弄丟的時候要怎麼辦)

DBA應該管的是"資料庫"不是"資料"

吊到專業的DBA了XDDD

論DB跟DBA領域來說 的確 在下認栽 No.78345才是對的
技術領域就這樣 正確的人說話w

>SA認定問題
先說 我不覺得System Architecture為SA這個觀點 是錯的
我會覺得 各個環境有自己的需求 會去自己定義 並擴張SA作業領域

>軟體以及流程 / 客戶的流程 / 外交能力
我所在的國家(?) 整個的IT基幹系統業界的環境 這會是PM(project manager)的工作

>前者跟後者的使用跟開發環境都是確定的
又某方面 基幹系之下 就如同你所寫 因為是固定的 其實沒有什麼基盤與架構的工作
這類基盤與架構 也不太會改 真的改來說 不知道要動到那裏去了
在這類的環境之下 把SA拿去當PM 我也不會感到奇怪就是了

再來是比較 web 也就是偏startup/創新企業的環境
這種環境來說 使用的製品 更新版本 / 加幾台server / 調整server設定
/ 一個新business domain切一個新的 docker container / 又新的container 貨櫃內容的技術與架構"全新"
/ 因為奇怪的需求去導入AWS的新工具 ...etc
常有的事情 這些不會給SE(水平)來做 要給有SA能力的人做判斷or實做 不然桶問題是 關聯的開發者全部一起飛

實體例子來說
又最近因為COVID-19來說 remote作業 SA把VPN給廢了 導入了google zero trust 這也非得他們做不可
再來 APP開發要不要用flutter 這是前年 我家ios工程師在推 後來到了CTO跟SA上討論過了的案子(也就是舊的native APP全部重寫)
我個人小有興趣的議題 serverless怎麼用? 用在什麼東西上?
我們家有一小塊的serverless 這大概也是之前SA蓋章後 SA搞出來的東西 又後面綁bash的處理 然後當然拿AWS lamda來用

我們這邊做CtoC的環境下 SA是不管business的 business的部分由product manager(PdM?)決定
這邊的SA不太處理技術以外的問題 當然你可以說 我們這邊的SA 混了一大堆其它的工作進去(server與NE的工作之類...etc)
但我會覺得 那就是SA跟SE的技術水平差 SE可以處理設計與開發 但沒有support之下 對於基盤的問題不好自己解決
SA來說 基盤的問題要能夠自己料理掉 差別在這

當然繞回
>軟體以及流程 / 客戶的流程 / 外交能力
是不是SA的工作內容來說 至少我現在公司不是
我也不覺得web圈一天到晚在用奇怪的玩具之下 適合把商務判斷歸給SA管 會合適

我比較偏好把這塊切到PM/PdM/PL(project leader)手上
畢竟能有不錯的技術能力 還要能有一定的政治與預算管理能力 的工程師 其實並不多
大多的工程師(特別是技術好的?) 對政治能力與對預算的判斷 大多較為脆弱
要能雙修來說 人不好找 又就算找到 留不留的下 又是另一件事

恩...話題篇掉了 總結一下 我會偏好這樣認知
QA < PG < SE = PL < SA(DBA在這邊?) <= PM(PdM)

每個階層有每個階層該會的事情 沒對應的技能(不用技術兩字了) 就是上不去
然後每個環境 重視的方向性 多少有些出入
但並不是不能 SE or SA兼PM的工作 跑去跟客人談要件/預算/吵政治..etc

有那個能力能搞定事情 IT業界就會把該人抓去做那個位子的事情
這是IT業界萬年人才不足會有的現象

>>No.78348
一大堆英文簡稱然後連自己都不知道在講啥會怎樣,嗯,就是這樣

我沒講仔細是為了大師的顏面,以前也是,沒發現也很神奇
好歹注意到我已經挑了不會很丟臉的東西來婊
System Architecture這個字基本上就是連直銷等級都不到的才會用,就是那種以為很帥可以拐到人..

要用這個字也可以
System Architecture軟體當然有,但是以原PO形容的狀況會發生嗎?
我那兩篇只面這句話是重點而且是實際已經發生的重點
>>SA基本上是做不了的,就算是號稱能隨便客製化的SAP都做不到(除非有超級鈔能力)
是"賣軟體給客戶"的時候就已經受到先天限制了,這個情況下主要流程已經不會變了(客戶套公司產品)
基本上可以假設客戶不會使用鈔能力,願意砸錢的會自己開發,或是直接換掉

我應該講的是"沒經驗就不要亂說",
只有不會做的人,跟沒在做事的人才會咬文嚼字
像大師你又講了一堆, PM?認真的?到現在還認為程式永遠只需要寫程式?

用我的話來講,大失你真的有做過能寫超過一百行程式或是超過兩個人作的程式嗎?(+有使用者)
只出張嘴啥都不做那種不算,就是做完連流程都講不出來的那種
如果理由比"簽了保密合約所以不能講"還好笑...不,是還更爛的話那麻煩不要回,太好笑的文章會被我拿去作宣導

簡短版,一個問題就能涵蓋上面所有的狀況
>>我們這邊做CtoC的環境下 SA是不管business的 business的部分由product manager(PdM?)
那你們PM會推翻掉公司現有的產品照新流程重做嗎?

或是,大師你還沒發現我講的SA不是你講的SA嗎?
>>去年做專案的時候因為SA不夠，老闆拉我們這些PG兼職SA跟客戶談需求
這邊你覺得"System Architecture"填得進去嗎?"談需求"這三個字都出來了

這篇就是說教了 可以不看

>>身兼管理(我覺得已經算PM了...)、PG、SA、QA的活
基本上我是看到這句才會想回的,只是大失誇張到會讓我想先婊...

工作就是這樣,對岸牛叔有一句至理名言,同時也是基本知識:
工作就是,
能解決大問題,就能拿大錢
能解決小問題,就能拿小錢
解決不了問題,就拿不到錢
**跟原文不同但是意思一樣

我補充
1.你"應該解決的問題"不是"問題",那個叫"份內工作"
2."應該解決的問題"跟"誰應該解決"是你主管/老闆決定的,不是你決定的
3.當你解決了"不是你應該解決的問題",怎麼讓上面知道是你做的

原PO跟大失其實超像,拘泥在職稱上(當然不止這點,不過我一點都不想研究,所以不用跟我說)
真的以為工作只就只是做職稱相關的?
不用幻想了,這不可能的,做得到的只有不做事的人或是只出嘴的人

不用我舉例吧?工作只要扯上這種人就是整天拖

要不要到深入研究的等級見人見智,但是能扯上關係的東西最好能到理解的地步
到這種地步你解決的問題就會是"別人的問題"=人情甚至功勞

當然這需要相對應的時間跟經驗,不是一蹴可幾
有花腦袋在工作上自然都能到這種地步,但是得是花在"正確推進工作"上

題外話:最大的好處是能把主動權拿在手上

>>No.78350
>大師你還沒發現我講的SA不是你講的SA嗎?
很根本的問題是 我們所認定的SA 是不一樣的東西
然後 的確 我是現在才發現XD

>"賣軟體給客戶"
我們這邊根本 沒有賣軟體給客戶 這個議題
這裡是直接做網站面對使用者 從使用者的金流上 抽取一定百分比的費用
前提條件根本不同啊w

>大失你真的有做過能寫超過一百行程式或是超過兩個人作的程式嗎?(+有使用者)
恩...在下寫過batch / 寫過SEO google analysis / 做過全新的服務 / 也做過Server冗長化的東西 ...etc

基幹系來說
隨便抓個 以前還在基幹系的案子 某警察局的勤務管理系統的50%以上的Batch是在下寫的
沒那些Batch整個勤務管理系統是不會動的 然後你覺得 寫batch我要去跟多少人敲事情?
你覺得我沒寫過東西是吧? XDDDD
不過 你可以繼續認定 沒差 我下周還是要繼續回去 搞設計/寫程式碼 踢基盤的坑 與 跟PdM橋規格就是了w

>那你們PM會推翻掉公司現有的產品照新流程重做嗎?
恩...PM....與其說PM不如說是SA+PM共同決議的結果吧

那時是要多加信用卡付款的機能 打算把舊付款的機能給整個整合進來
所以要把舊付款機能 整個打掉重做 後來因為 工數不足 沒打掉就是了(這個沒打掉 導致後面出了不少事情)
又Flutter的例子 我寫了 把舊的native APP打掉 全部重做
當然這是現在Web的公司 以前待業務係來說 沒人願意這樣幹的w

>拉回原po的話題
就原po的例子 與 原po的環境來說 我用外界的"SA"去帶入原po家的[SA]位子 仔細想想的確是不太合適
我反倒好奇 你們那邊的[SA]的全文是什麼?
我個人是認為 看全文多少可以去認清楚 那個工作的(最初的?)本質議題是什麼

再來就整個IT業界吧
廣義的"SA"來說 是有基盤與架構 得意義的 用[SA]的概念來解讀之下 我是覺得把能走的路給狹隘化了
docker/ vagrant 與 server群 + AWS/GCP/Firebase 是個很大的坑 (M$家的東西 我丟一邊去 那邊是獨立的生態系w)
又這個坑(技能) 非常的值錢 現在甚至是花錢 聘不到會的人的程度

例子來說
最近踢到的坑是 Brower cache -> CDN server -> varnish cache -> 然後varnish崁在ansible裡面 綁server的組合問題
這要架好 不是SE能搞定的問題 議題是網頁呈現速度 又 這類問題在基幹系中 不存在這類的需求

要討論SA來是 至少先懂有"SA"跟[SA]兩條路的存在 知道了之後 決定放棄走"SA" 向[SA]發展 那一點問題都沒有
但至少思考上要先認知有"SA"這條路 而非因不知道有"SA"而直接不放入思考範圍內

又就我個人與我這邊的環境來說 我會覺得 如果真的要走[SA] 不如直接去走 PL跟PM
權利與管理的預算/人員 膨脹速度會更快 當然壓力也更大就是了

>>No.78352
>>這裡是直接做網站面對使用者 從使用者的金流上...
請你解釋一下,我這句話有沒有問題
這種情況是:使用者=客戶
真要我反過來講,客戶=使用者?

>>恩...PM....與其說PM不如說是SA+PM共同決議的結果吧
承上,那,每個給使用者的東西都是砍掉重練?
你沒講是啥我就用"東西"這個字

>>恩...在下寫過batch / 寫過SEO google analysis / 做過全新的服務
不可能沒有遇到過關我屁事的問題吧?
前面需求亂寫,看沒或是根本是火星文,造成部分~全部不知道怎樣做的情況?
後面不知道怎樣搞爆反過來被燒到這種的?
->這是就是原PO抱怨的事情

>>要討論SA來是 至少先懂有"SA"跟[SA]兩條路的存在 知道了之後....
>>很根本的問題是 我們所認定的SA 是不一樣的東西
這個時候就不應該用簡稱,繼續用其實只是給自己挖坑,我是故意的不提的沒錯啦
雖然這樣講,其實上面已經給過答案了,你狗下去馬上就能看到

請務必理解我不講的原因是,答案講出來話你上面這一大堆馬上變搞笑(搞笑這個字已經很好聽了)
在其他人沒發現的情況下,就算是凹的很硬,還是可以凹回來相當程度的
只要不是又又又又是亂講我是不會去婊的

>>最近踢到的坑是 Brower cache -> CDN server -> varnish cach...
用你的例舉個例,我不會知道你工作細節你自己想答案給自己就好
這是那哪時候發現的?誰去發現是誰的錯的?然後花多少時間?
如果發現的人有其他部分的知識能不能更快鎖定要給誰修?

再來就是我一直重複提到的"沒在做事或是只出嘴",如果是這種人摻在裡面會發生啥

我不想開新的戰場,例如這個"PM"
你整天提PM,你真的做過嗎?做過的話我提過的問題會沒遇到?
(我建議你沒有200%把握不要回答這個問題)

>>No.78354
>使用者=客戶 / 客戶=使用者?
恩...CtC來說 微妙
比喻來說使用者A(供應商)賣東西給使用者B(買家) 產生金流下抽成 比較算planform(平台)商

但 以承包商製作來思考來說 使用者不是傳統軟體的客戶
我們自己的定位來說 我們是跟供應商平起平坐 說是客戶 也很奇怪...
又就買家來說 買家是供應商的客戶 我們只能算撮合

>每個給使用者的東西都是砍掉重練?
"每個"是到哪個程度 某方面來說 這討論過細了
不過flutter來說 APP native部分 (android+ios) 全部打掉重練
舊付款+信用卡來說 舊DB動不動 我是不太清楚 但開新docker container 加實體業務的金流改了 一開始應該是打算整個付款打掉重練

>關我屁事
當然遇過啊XD 不過這塊你是要提什麼?

要說鳥事來說 以下全部以前的案子
1 與其說關我屁事 不如說根本沒人可以問(全走光了) 只剩下個活的LAMP線上環境 + 測試環境
2 設計完全沒考量實裝的案子也遇過了 那個設計會自動生成 10w行以上的html碼 頁面幾乎卡到不會動
3 整個案子根本沒打合約 到了最後鬧 在吵要不要上法庭之時 客人那邊偷偷在補文件 打算鬧上法庭時 能有比較好的立場 都遇過了

>CDN server + "沒在做事或是只出嘴"
簡單來說 這玩意要根本的修 要權限 因為這玩意一動 會影響到20幾個人的測試環境
不過因為最終不會影響到本番的CDN環境 只在測試環境產生 所以最後是不處理
簡單帶過技術議題來說 nginx server上對http header的rewrite規則 與 http options method開不開放的問題
最後是靠跟QA PdM講清楚狀況 去繞過這個問題

然後 你要開什麼坑 我是搞不清楚就是了 我只是覺得 這問題很有趣 又這問題 很難
拿這個例子只是要說明 "SA"程度來說 應該要有能力去搞定這問題 又不要期待PG程度能解決這樣的問題 不切實際
又要聘"SA"跟PG 動用的預算是不同的預算

>你整天提PM
被抓到了XD 我還沒爬到PM過 基本上沒掛PL 但常常實質上在做PL的人
幹到最大 大概就 發包公司+設計公司+製作公司 3社間的利益則衝 就這了(差點鬧上法院的案子w)
又之前待過所有的公司 我的直屬上司全部都是PM

>我大致分三點需求 1.完全了解公司軟體以及流程 / 2.業界經驗 / 3.外交能力
認真在想一想這1 2 3 你到是讓我想起了以前PM聊過的一些事情(跟老闆的有趣事情)
EX1 A公司是沒預算的 不能多開工數(預算) / 藥局進銷存專案 的對客戶文件要另外處理
EX2 老闆沒打合約 就把2000~3000wJPY左右的案子給帶回家了(這案子就是差點吃上官司的案子就是了w)
...etc

>搞笑
阿 在下終於搞懂這搞笑是什麼意思了w
"Systems architecture" V.S "Systems architect" XDDDD

"Systems architecture" Wiki
>A system architecture is the conceptual model that defines the structure, behavior, and more views of a system.
>An architecture description is a formal description and representation of a system,
>　organized in a way that supports reasoning about the structures and behaviors of the system.
>A system architecture can consist of system components and the sub-systems developed,
>　that will work together to implement the overall system.
...(以下略)
by ttps://0rz.tw/kDp3g

"Systems architect" wiki
>Systems architects define the architecture of a computerized system in order to fulfill certain requirements
>Such definitions include: a breakdown of the system into components, the component interactions and interfaces
>　and the technologies and resources to be used in its design and implementation
...(以下略)
by
https://0rz.tw/7Ychk
又 Systems architect: topics 中有相當多 我個人所認定為PM工作的層面

看來有空應該把 各個職稱的定義內容好好認一認w
不過 現實考量 如果基盤+架構層工作也包到SA中 SA真的有辦法處理如此多的工作嗎? 抑或是這應該放到SE去?
但SE中 能處理基盤+架構層 的人 真的不多...
又那基盤+架構層工作的工程師 又必須用什麼概念名去說明呢?

不過考慮到這邊就會變成在凹了w
有空在下好好把定義翻一翻 感謝指教XDDDD

>>No.78358
關鍵字是SDLC.....
WIKI雖然列再一起,SA跟SD是不同的兩件事這不需要我多嘴說吧?

>>No.78355
>>恩...CtC來說 微妙...
你這段話你自己看不看得懂阿?

簡化,
使用者就是會有需求叫說"要加這個""那個要改"
客戶就是出錢講幹話的
兩者可以是同一個(人/組織)可以不同

說難聽一點,
除非是故意,要不請務必確定是"別人看得懂的",才能叫"說明"
別人不會知道你公司的客戶的情況

>>"每個"是到哪個程度 某方面來說 這討論過細了
這不是細不細的問題,這是對應的怎麼談需求
要客戶套你有的
還是
你去套客戶有的
無論是哪種SA,再談需求的時候這兩種方向是完全不一樣的

>>當然遇過啊XD
承上,對應是第一步有多重要,不會有人反對說越後面冒出來的修改越容易做吧?

假設你有理解到我講的SA是哪個的話
(*婊人的確就是婊)
我講的其他東西都是沿著原PO的問題講的"如何培養成為SA？"
上面講的所有都是SA需要的("好"SA必須的)

你講的SA的第一步就是我講的SA(也可以說是第0步),所以我講這些:
-兩種開始走向
-為啥很重要->相關人員能去就去
-這需要全面的知識,所以不是你做的也要知道能怎樣

最後的最後,不會需要我解釋我為啥要婊你了吧?

>不會需要我解釋我為啥要婊你了吧?
東西不清楚來說 被婊一婊應該阿XD
某方面來說 網路上被婊一婊來說 不是什麼大問題 現實出事才是真麻煩w

某方面來說 環境吧
這邊整個業界來說 沒有SA這種位子 但PM會實際接下SA的工作內容
只能說是一種環境上的習慣

又對於SD來說 一樣沒這個稱呼 但SE的用詞會過度擴張
然後擴張無論對上與對下 都有過度擴張的傾向
又經驗上 看到職稱為SE的人來說 我個人一直都不期待SE對SD的判斷能力
特別是踢過了滿滿的 一堆SE產生的"關我屁事" 的基盤問題之後

不過就像 你寫的
>最大的好處是能把主動權拿在手上
真的懂來說 對事情要怎麼辦 會有很大的控制權

>使用者 / 客戶 / 我的公司
我的公司的話題就丟一邊了吧 說實在話怎麼去分 很奇妙

我們的需求是自己開的 / 錢是自己對自己公司出的 不太能用 承包的角度去思考
例如 信用卡付款 這需求是我們公司自己開的(當然事前做過市場分析) 但要說使用者最後用不用來說 微妙
有愛死了信用卡付款的供應商 / 也有營業跟供應商溝通了老半天 但打死不用信用卡付款的供應商
我也不知道該怎麼說明(認知?)才是對的

>拉回原po的話題
對一開始的原po來說 比起SA來說 我會覺得要先認知有SD的位子吧
雖然寫了寫之後 原po的確是在認知了SD之後 放棄走SD 往SA方向走過去就是了

最後 關於SD與SA(PM)來說? (這塊大概就不是原po要的東西了)

我會覺得年輕來說 就去闖闖看SD的路吧 SD的技能來說 大多是技術為主 要換公司比較方便
當然接觸到的人越多 管理與政治的議題會越來越多 有需要那方面的技能 自然就會去點
走向 PL與SA(PM?)來說 管理與政治的比重會加重 甚至會是主要的位子
但這塊地技能來說 就會比較不太能動了 依存於 業界or公司or客戶關係 之類

不過 因為程式能不能寫一輩子 與 年齡產生的各式各樣問題
大致上 多數人最後走去PL與SA(PM?)的位子就是了

在日本工作七八年的肥宅來聊聊

給原PO
當SA/PG/SE話題在剛畢業的Junior階段想想就算了
快30了還在煩惱這問題的就危險了
代表你這幾年根本沒成長
業界在說十個一年的工程師
就是這種沒在動腦渾渾噩噩當個碼農東碰西碰不知道在碰什麼
幾年下來沒有任何積累
多想想怎麼在某個領域成為expert
能不能貢獻除了source code的以外的東西
這樣不管career還是薪水才能往上爬

沒有強大學歷
鎖定目標工作幾年
找個適合且薪水輾壓GAFA的位置
或是退而求其次直接到GAFA
再回頭看你就會發現現在這個問題有多蠢

抱歉 在下跑去玩golang跟docker了
golang滿有趣的 不過 一看到這玩意 翻了翻覺得跟JSON不好接
google了一下 果然很麻煩XD (相對php跟python)

>以職務上做的事情來講PL跟PM有差嗎?
這邊的環境來說 至少我是用下面的想法去做切割的
最簡單一句話 要用PL跟PM 企業要動用的預算不一樣
PM來說 一人月 企業預算要100~120 PL來說80~90(掛上職稱之下來說)

再來PL主要處理 對project內部的事情
例如team building/ menber care/ 直接的技術指導商談...etc
比較偏leadship的工作內容
但 PL不太可能去動 加人or處理project之外的資源調度/ 與更動Schedule

PM來說 主要是預算 與 最終目的管理
這塊然後包括了 客戶關係 客戶內部的政治要素的管理...etc
PM會有 加人/更動schedule/跟客人敲預算的權限
又當然 PM要有這種本事 利害關係人管理 與 調整會是主要核心技能

能力夠的PL(或者SE?) 很自然的會去處理(分擔?)"一些"PM的事情
接多了 處理上位事務能夠漂亮的 自然會往上升
(沒往上升來說 大概就會被別家公司給挖走or跳去別的地方)

又PM做team building來說 滿少見的 基本上 比較小的team有可能
不過 大多的PM都是以 命令的方式在處理project member的問題
PL比較會去考量個人的情況 去切割project內的事務

比喻來說
有好得PL 在帶整個團隊 就算要往死境闖進去
這整個團隊會願意枉死境去 並且在死境中(心情上)過的滿快樂的
有好的PM來說 所有的戰略/戰術會很清楚 做大多事情 都可以在適度的壓力中 完成要完成的事情
但有不有趣/開不開心 就不一定了