請停止招聘軟體工程師,取而代之招聘“産品工程師PE”:有業務産品意識的工程師。
我遇到過了不起的工程師,他們中的一些人在技術上很了不起,比任何一個産品工程師PE都要有能力,但他們中沒有一個人能夠像産品工程師PE那樣接近于提供價值。
我認為PE才是10倍的工程師。在我從業的15年中,在多個行業工作,我遇到的可以說是産品工程師PE的人不到30個。
産品工程師
軟體工程師有一個子集:這些是(軟體)産品工程師,最有可能的是你真正應該尋找的人。
産品工程師(從現在開始是PE)在面試過程中很容易被識别出來,我們稍後将讨論一些共同的特征。
作為軟體工程師,我們很少在技術領域工作;我們大多數人最終會進入其他領域,改進技術以支援業務,其中包括金融科技、汽車、保險、航空航天、醫療、旅遊、電子商務等。當一個軟體工程師進入一個新的領域時,他會帶來一套能力工具:程式設計語言、算法、架構、工具、模式等。
很可能在面試時,你評估了某人是否精通Scala(如果那是你公司的程式設計語言),或者他們是否知道Kafka、Redis和Cassandra(如果你正在使用它們);事實證明,很多時候你最終雇用的人都擁有技術團隊所需的技能。恭喜你,你很可能為你的團隊雇傭了一個偉大的軟體工程師,但也許值得檢查一下是否有PE的特征。
那麼,什麼是PE?這與資曆或年資無關,也與技術無關:這都是關于産品開發和所有權。一個真正的PE明白,他的主要精力必須放在産品的改進上,是以會專注于該領域,試圖了解其動态、流程和核心概念。
傳遞價值!
PE對傳遞價值非常着迷;他們已經(或将獲得)對技術産品和相關流程的完全所有權。
除非這背後有業務價值,否則PE不會真正關心從一種技術遷移到另一種技術。
私營企業不會在孤島上思考,他們希望有一個完整的畫面來了解哪裡需要改進。他們會去和公司的其他職能部門交談:從市場部到客戶服務部,以便收集完整的産品知識(是的,即使他們在有邊界的DDD工作,他們也會這樣做)。
PE會照顧生産環境,就像沒有比這更重要的事情一樣:在發生事故的情況下停止任何其他活動。
提出大量的問題
想象一下,在積壓的工作中,有這樣一個條目,被标記為技術債務。
"通過對K進行索引,将函數X的執行時間減少三分之一"
這很重要嗎?這是 "真正的 "技術債務嗎?任何工程師都很可能會告訴你,修複它很重要,因為作為工程師,我們對改進、重構等很着迷。
一個産品工程師很可能會試圖了解它是否能帶來價值
"這個時間的減少是否對任何利益相關者産生了積極的影響?"
"這是否會讓我們的客戶生活得更好,減少他們的等待時間?""這是否會大幅降低平台成本?"
如果優化是純技術性的,那麼它的優先級是最低的
不要誤會我的意思。PE非常關心代碼的可維護性、設計原則和重構等概念--但他們總是會平衡每一項改進,以實作上述的 "價值傳遞"。
"這個變化是一個促成因素嗎?"
"如果我們轉向這種模式,我們是否能更快地适應其他業務需求?"
兩行代碼
我一直在幾個行業工作,寫了幾千行代碼,并開發了幾個我引以為豪的産品和功能,反正下面這兩行代碼是我最大的共鳴之一。
if (text.trim().length() <= 2)
text = ""
最初級的開發人員,甚至是第一次接觸程式設計的學生,都能寫出這樣的代碼。有一點背景。
我當時在一家線上旅行社(OTA)工作,作為一個團隊,我們負責航班的結賬階段。有一天,我組織了一次與客戶服務團隊的電話會議,試圖了解他們的痛點,客戶服務主管準備了一張幻燈片,上面有他們面臨的所有問題:其中一個條目是 "手動預訂"。
作為一個OTA,你的目标是,隻要客戶購買東西,向航空公司或任何其他第三方完成的過程不需要任何人工幹預。無論如何,一些預訂最終會以手動模式結束(例如,沒有更多的可用性,價格增加,等等),是以你需要一個營運商來處理這些。其中15%的手動預訂,被标記為 "特殊要求:來自終端客戶的錯誤輸入" - 在網頁上,有一個文本框的标題。
"在這裡寫下關于您的航班的任何特殊要求"。
當你預訂航班時,你可能有一些特殊要求,比如運送動物或貴重物品,是以你希望有人在購票前确認你被允許這樣做。
長話短說:一些使用者感到困惑,他們在文本框中寫下 "NO",或者加上". "或一系列的空白。
把訂票放入手動模式的邏輯是。"如果文本框裡有内容,就把它配置設定給一個操作員"。
會議結束後,我立即來到我的筆記本電腦前,添加了這兩行代碼,引入了幾個測試來驗證,并在生産中釋出。一個月後,我被邀請參加一個行政會議,在會上我被授予了一個獎項,因為我高效地解決了一個巨大的公司問題,還節省了很多錢,提供了更好的客戶體驗。
是的,這兩條線就是在做下面的事情。
- 減少了人工預訂的數量
- 改善客戶體驗,在結賬完成後立即确認。
- 減少人工處理時間所帶來的漲價或無法使用的風險
這不是我的問題,是别人的問題
在會議結束前,我試圖向客戶服務主管了解,她是否在過去聯系過任何人來解決這樣的問題,我對這個答案感到非常驚訝"這不是一個工程問題。這是一個使用者體驗問題,使用者體驗團隊應該處理這個問題",她回答說,但是當她試圖聯系使用者體驗團隊時,他們正在重新設計整個結賬過程,是以沒有空間對目前的設計進行任何改進。
一個公司的問題已經存在了幾個月,卻沒有人去解決它。
那兩行代碼在網上停留了幾個月,當新的設計釋出後,這個問題就用一個複選框解決了。
"如果你對你的航班有任何特殊要求,請點選這裡"
點選該複選框會使文本框出現。
範圍和邊界之間的差別
前面提到的例子為區分範圍和邊界設定了空間。
解決問題的方法是否在純工程範圍之外?是的,這一點毋庸置疑。
從公司的角度來看,這個 "正确 "的解決方案可以接受嗎?
我個人認為不是。再等幾個月讓使用者體驗部來解決這個問題,從每個角度來說都會付出很大的代價,但對工程部來說,1個人花了30分鐘就解決了這個問題。一個人的邊界遠遠大于他們所參與的角色的範圍,不管他們是在軟體開發、資料或測試,還是平台工程。這是一種心态,你總是關注你的産品和你的客戶,而不是關注技術和範圍。這個概念對公司的每一個職能部門都有效,而不僅僅是對技術。
10x工程師
在我從業的15年中,在多個行業工作,我遇到的可以說是産品工程師的人不到30個。
我遇到過了不起的工程師,他們中的一些人在技術上很了不起,比任何一個PE都要有能力,但他們中沒有一個人能夠像PE那樣接近于提供價值。
我認為PE是10倍的工程師。
我們真的應該停止招聘軟體工程師嗎?
這取決于:一切都要根據情況而定。
如果你的公司正在開發一個産品,你也許應該尋找PE的特征,無論如何,許多開發人員選擇這個職業是因為他們喜歡技術,他們對其他領域沒有真正的興趣。他們想建立管道,建立基礎設施,做自動化,并與尖端技術棧一起工作。
在許多現實中,這些軟體工程師要麼在平台領域工作,要麼在 "開發體驗 "領域工作,做着純粹的技術工作,試圖改善開發者的生活。
我們是如何改變我們的面試過程
尋找PE是非常困難的,是以你不應該減少你的初始漏鬥。
在iptiQ,我現在的雇主,我們改變了我們的面試流程,以便有最好的機會找到頂尖的選手。
- 我們不要求任何特定的技術知識(沒有Spring Boot、DynamoDB、Redis等,盡管我們在使用這些堆棧)。
- 我們接受來自任何程式設計語言的開發人員,即使我們的代碼庫是用Kotlin編寫的(我們做了一個編碼測試,要求對方用他們最喜歡的程式設計語言解決這個問題)。
- 我們評估一般的問題解決能力
- 我們尋找一個關心産品的人的特征,詢問技術領域以外的問題。
我們這樣做是因為我們認為每個人都可以學習一種新的程式設計語言或架構,但很難教人如何成為一名PE。
原文:請停止招聘軟體工程師 - Carlo