顯示具有 軟體工程師換工作 標籤的文章。 顯示所有文章
顯示具有 軟體工程師換工作 標籤的文章。 顯示所有文章

12/23/2018

軟體工程師的職稱頭銜重要嗎?



軟體工程師根據所在的環境不同,通常有不同的職稱頭銜。例如:程式設計師,工程師,技術經理,架構師,策劃工程師,平台工程師等等。對應於英文可能會有:programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中,升遷可能是職稱上的轉換,例如在前面加個「資深」,大家就都知道你被升遷了。

對於轉換新的工作來說,職稱頭銜是否重要呢?

1.以工作的本質來說不重要


就技術為主的軟體工程師來說,(假設並沒有直接負責管理員工),職稱頭銜幾乎不重要,更重要的是做事情的內容和能力的展現。

假如在一個組織裡,一位新進員工的職稱是「sr architect資深架構師」,但他的工作內容實質上是對客戶提案,撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作,通常還是評估實際做的事情為主,並非職稱。

2.以團隊角度來說可能很重要


職稱是公開的,一個團隊組織裡如果有工程師,資深工程師,資深架構師這三種不同職稱的人:一般來說,大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟,職稱的功能有時候類似制服,當你在路上看到穿著警察制服的人,在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。

然而,就軟體開發組織成長來說,職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係:團隊貢獻中,絕大部分的人會認為自己佔比重比較大,因而,在決定升遷或者其他公開獎勵時,一定會有很大比例的人覺得自己沒被升遷是不公平的。

團隊貢獻中,大部分的人會認為自己佔比重比較大:許多實驗(參考這裡)都說明,假設一個團隊的總貢獻是100分,有10個人自己評估自己佔的比重,並且加總起來,很容易就超過150甚至250,但這實際上是不可能的。

也因為大部分的人都有這種偏誤,導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會,可以採用「無職稱」或者「自選職稱」的方式。


3. 無職稱頭銜讓團隊與夥伴的三贏

當組織沒有職稱時,無論是中期還是短期發展,組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織,對團隊成員,甚至對組織外的人都有好處:

- 對組織的優勢


在組織內,成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」,而非「職稱頭銜」決定自己「做出的事情」。自然而言,團隊成員就會以提高自己的能力和對組織的影響力,並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密,再也不會影響其他人的心情。

當組織要招募人才時,組織會更專注於了解應徵者「過去做的事情」,而不是過去有的頭銜職稱。過去我們面試的時候,常常在履歷表中看到非常驚人的頭銜,但是實際上做的事情可能非常基本。

無職稱會讓面試的效率提高,錯誤率降低很多。

- 對團隊成員的優勢

當團隊成員想要換工作時,在他對外面試的時候,很容易就專注於展現自己的產出。而非說明自己的頭銜。

同上一小節之說明,團隊成員專注於工作的本身而非頭銜的表面公平性不足時,更能發揮自己的潛力和提高產出。

- 對組織外部的優勢

其他外部組織在遇到沒有職稱的人前來面試時,更容易專注於尋找人才得要件。換言之,本來評估能力和是不是適合,本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試,就更容易避免錯誤。









8/15/2018

Scrum: 三件不能少的事



Scrum是敏捷開發原則下,目前在軟體產業裡常見的方法論。而由於Scrum只是個方法論,並沒有所謂的標準,各個組織的應用方式皆有不同。常見的應用(practice),例如:spint-kick-off-meeting, daily standup, burn down chart, planning poker, retrospective。

零零總總的practice中,哪些最為重要當然眾說紛紜。考慮到Scrum的真正精神,以下三件事情是「最基本要有的」。也就說,如果這三件事情做不到,那麼其他事情做到也沒有用。


(1) 每個Sprint有交付具體產出


Scrum的Sprint都要有具體「可交付」的產出。sprint的開始,就應該以「結果」為計畫的導向,而此結果必須要是可交付的產出。

有些團隊會以Sprint長度不夠為理由,設定一個「並不能交付」的milestone作為該sprint的產出。如此一來會有幾個問題:(1) sprint結束的檢討,並不基於產出的事實 (2) kick-off下一個sprint的意義不大,因為前一個sprint並沒有真正可在市場衡量的產出 (3) PO會有充足的理由不參加demo以及下一個sprint的kick-off,畢竟這個sprint沒有有意義的產出,而如此一來PO就很容易不真正加入團隊。

Sprint不見得要固定長度,請參考這裡。 


(2) PO有確實加入Scrum團隊


Scrum團隊成員有三個角色,team member, scrum master, product owner。其中最容易不在的人,就是product owner。許多軟體開發團隊,product owner就是PM。但無論如何,Product owner必須要真實參與團隊。

所謂真實,指的是所有standup應該參加,在團隊運作過程,能夠回答該sprint的需求問題,並確實知道sprint中間「不應該做的事情」以及sprint開頭結尾「應該做的事情」

更重要的是PO加入團隊之後,DOD(definition of done)的標準才會具有「市場一致性」。舉例來說,不成熟的軟體研發人員常會對事情做完有不同的定義:
「程式寫完只是還沒review,所以還沒merge」
「程式寫完測試也沒問題,只是QA還沒通過」
「功能搞定了,QA也沒問題,只是還沒...」

PO確實加入後,可以讓事情做完的定義,統一在於「可準備交付到市場」。換言之,所有和程式設計相關的工作:測試,相關文件,環境設定,certificate等等都會以「可準備交付到市場」為原則。沒有這個原則,跑Scrum很難達到預計效果,要達到這個原則,最基本的就是PO需要確實投入團隊。


(3) 每個Sprint結束之後有確實地檢討(Retrospective meeting)


這世界上沒有完美的團隊,也沒有不用修正的軟體開發方法論。每個sprint的確實檢討,是修正團隊,讓團隊趨於一致的唯一方式,而非強加訴諸任何規矩。請參考這裡

確實的檢討並不容易,要做到兩件事情:
(a) 基於事實檢討   
(b) 不檢討不在場的人事物 


基於事實的檢討


檢討的內容必須基於事實,不是基於感覺與想像。感覺和想像的情況如下:
「我感覺好像有點慢」
「不知道怎麼講耶 但這個事情不應該這樣做」

事實的情況舉例如下:
「這個sprint我們沒有按照當時說好的DOD的定義,所以有XX與XX項目,本來說完成了,後來隔幾天又說沒完成」


不檢討不在場的人事物 


檢討確實是對事不對人,然而,事情都是人做的,不可能不檢討「人的做法」。不檢討「人的做法」只是鄉愿。

不過,要避免檢討不在場的人。
例如「因為UI/UX之前給的東西不正確,導致我們要重做某些事情」如果UI/UX是同一個scrum團隊,那麼檢討此項目當然可以。但要是不是同團隊就沒有意義。
因為,Scrum的檢討會議目的是產生「團隊要改善的項目」,而不是去讓非團隊的人改善。

Scrum的學習必然是從實際的經驗獲得,但經驗的獲得又必須從知識學習的取得為基礎,要成為看似不錯的Scrum專家不難,但要實際應用於專案中,並取得可重複成功的結果就不這麼容易了。





6/24/2018

軟體工程師:換工作時如何談判薪資



是故勝兵先勝而後求戰,敗兵先戰而後求勝 - 孫子兵法

軟體工程師:換工作時如何談判薪資


已經拿到Offer就沒啥好談了

軟體工程師在經過繁瑣面試之後,一旦從某公司HR(人資)拿到offer,其實薪資談判已經結束。在台灣,無論是本土還是外商,大多數都會由既有資訊:也就是履歷,面試評核,薪資市場參考,工作本身價值等等,給出一個數字,這個數字在給出之後,就表示此公司認定的市場價值。

薪資福利經過「談判爭取」有可能改變嗎?當然有,也因此許多企業巫醫,都會提供一些意見,例如包裝。但以軟體工程師而言,頂多是幾個%的差距,這樣的差距,遠不如這工作本身的意義來得重要。

另外一方面,倘若拿到offer時,無論經過什麼方式爭取,竟然可以取得15%以上的薪資差距,通常表示這個組織並不確定這職位應該帶給組織什麼樣程度的「價值」,換言之,組織裡面很可能因人設事。如果是在研究機構,這可能是一件好事。但如果是在盈利企業,可能是個警訊,表示用人主管與人資並不確定公司政策,更有甚者,公司其實沒有政策!

談判薪資的兩方向


因此,所謂談判薪資,其根本在於:在還沒談之前,就已經站在談判成功的立場。


方向一:人才市場。


同樣是軟體工程師,即便在同個城市,也因不同產業有極大的差別。在台北,如果求職的方向是傳統產業的IT部門,其薪資就大概不如銀行業的IT部門。

同樣的產業,在不同的地理環境也有極大的差別。同樣是智慧手機應用程式開發,在印度外包城市班加羅爾,其薪資就遠不如新加坡。

同樣的產業,同樣的城市,同樣類型的工作,也會因為企業組織的市場定位而有所不同。組織急於擴張,自然就會提出高於市場的薪資水準。

方向二:個人價值

所有人都知道,「自己很厲害的話,薪水自然就會高,就容易找到薪資高的工作」。然而,許多軟體工程師常忽略價值的兩個重點:

(a) 其他人所認定的價值才是個人價值

自己認為自己很有價值,不見得是真的,很有可能是自我感覺良好。根據其他人所「實質認定」的價值才是真的。舉例來說,一個有N年工作經驗的軟體工程師,過去9個月,都只能找到月薪3.5萬的工作,那麼他在市場上實質價值就是月薪3.5萬。反過來說,如果一個有N年工作經驗的軟體工程師,他已經在目前的公司服務N年,最近的薪水是月薪10萬,然而,過去9個月他四處尋找更好的機會時,始終都沒拿到offer,或者拿到offer但是遠少於月薪10萬。這就表示他很有可能在現在的工作薪資是overpay,也就是目前企業可能高估其價值。

(b) 對組織有意義之產出才是個人價值

在徵才的過程中,偶有軟體工程師會覺得「自已都做一些沒有成長性的工作」或者透露「這工作無法讓自己持續成長發展」

這當然表示龍游淺池,組織可能受限於先天環境,沒辦法給這個軟體工程師更大空間。然而,這必須是此軟體工程師對組織已經有「大幅超乎期待」的產出,並且有「實質事實」才行。


建議的行動


作為軟體工程師,如果對你現有的薪資不滿,或者在目前工作領域上做得極度不開心。建議有以下實質行動

(A)  面試自己想去的公司



面試會讓你有機會知道「其他人」對你的價值判斷

(B)  把現在的工作做到超乎所有人的期待

如果無法做到這點,怎麼會知道自己的價值是提升的?又怎麼會知道下次換工作時,薪資談判已經處於不敗之地?

(C)  找到自己喜歡的市場缺口

這幾年來許多軟體工程師會前往中國,或其他成長中市場。這當然也是一種薪資成長的方式。然而,市場的缺口不見得只有成長中市場,即便在台北,也有許多職位和產業有明顯的軟體人才缺口。

找到自己喜歡的市場缺口,或許是個突破的行動。

舉例來說:過去半年來,DevOps在新創和有對消費性市場服務的公司就是個很大的缺口,此外,大數據在銀行產業似乎也是同樣缺口。