軟體工程師根據所在的環境不同，通常有不同的職稱頭銜。例如：程式設計師，工程師，技術經理，架構師，策劃工程師，平台工程師等等。對應於英文可能會有：programmer, engineer, technical manager, architect, principle engineer, platform engineer。 在大組織中，升遷可能是職稱上的轉換，例如在前面加個「資深」，大家就都知道你被升遷了。
對於轉換新的工作來說，職稱頭銜是否重要呢？
1.以工作的本質來說不重要
就技術為主的軟體工程師來說，(假設並沒有直接負責管理員工)，職稱頭銜幾乎不重要，更重要的是做事情的內容和能力的展現。
假如在一個組織裡，一位新進員工的職稱是「sr architect資深架構師」，但他的工作內容實質上是對客戶提案，撰寫業務報告。則其實他是做接近pre-sales或者sales-consultant的工作。在未來無論是組織內部還是他要對外尋找工作，通常還是評估實際做的事情為主，並非職稱。
2.以團隊角度來說可能很重要
職稱是公開的，一個團隊組織裡如果有工程師，資深工程師，資深架構師這三種不同職稱的人：一般來說，大部分的人會傾向遵循同意資深架構師的意見。特別是剛組成的團隊或者互相不認識的團隊。畢竟，職稱的功能有時候類似制服，當你在路上看到穿著警察制服的人，在需要協助的時候自然而然會傾向找穿警察制服的人幫忙。
然而，就軟體開發組織成長來說，職稱的重要性是伴隨組織成長的缺點。這個缺點和人類的認知偏誤有很大的關係：團隊貢獻中，絕大部分的人會認為自己佔比重比較大，因而，在決定升遷或者其他公開獎勵時，一定會有很大比例的人覺得自己沒被升遷是不公平的。
團隊貢獻中，大部分的人會認為自己佔比重比較大：許多實驗（參考這裡）都說明，假設一個團隊的總貢獻是100分，有10個人自己評估自己佔的比重，並且加總起來，很容易就超過150甚至250，但這實際上是不可能的。
也因為大部分的人都有這種偏誤，導致於職稱很多時候對軟體開發團隊有負面影響。如果有重新建立軟體開發團隊的機會，可以採用「無職稱」或者「自選職稱」的方式。
3. 無職稱頭銜讓團隊與夥伴的三贏
當組織沒有職稱時，無論是中期還是短期發展，組織成員會更專注於「實質工作產出」而非「表面變化」。這對組織，對團隊成員，甚至對組織外的人都有好處：
- 對組織的優勢
在組織內，成員都知道自己「做出的事情」才是決定自己的「職稱頭銜」，而非「職稱頭銜」決定自己「做出的事情」。自然而言，團隊成員就會以提高自己的能力和對組織的影響力，並且使用的方式不會是以頭銜和權威。升遷和加薪兩者同時都變成機密，再也不會影響其他人的心情。
當組織要招募人才時，組織會更專注於了解應徵者「過去做的事情」，而不是過去有的頭銜職稱。過去我們面試的時候，常常在履歷表中看到非常驚人的頭銜，但是實際上做的事情可能非常基本。
無職稱會讓面試的效率提高，錯誤率降低很多。
- 對團隊成員的優勢
當團隊成員想要換工作時，在他對外面試的時候，很容易就專注於展現自己的產出。而非說明自己的頭銜。
同上一小節之說明，團隊成員專注於工作的本身而非頭銜的表面公平性不足時，更能發揮自己的潛力和提高產出。
- 對組織外部的優勢
其他外部組織在遇到沒有職稱的人前來面試時，更容易專注於尋找人才得要件。換言之，本來評估能力和是不是適合，本就不應該和職稱有關。已經有人自己不帶著職稱頭銜前來面試，就更容易避免錯誤。
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專家不難，但要實際應用於專案中，並取得可重複成功的結果就不這麼容易了。
是故勝兵先勝而後求戰，敗兵先戰而後求勝 - 孫子兵法
軟體工程師：換工作時如何談判薪資
已經拿到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在新創和有對消費性市場服務的公司就是個很大的缺口，此外，大數據在銀行產業似乎也是同樣缺口。
