4月15日，hrbp組織了研發團隊的述職；在這次述職中，除了了解大家的業務產出外，也還有一件非常有意義的事情，述職過程中體現出了各個leader目前所處的階段、遇到的問題。針對他們所在的階段和遇到的問題，一一給了建議。令人欣慰的是，研發團隊的leader都在進步的路上，相信他們在未來的職業之路上，會有很好的提高和發展。
stage 1:
技術leader一段，個人貢獻者or團隊貢獻者
有兩個同學述職時，提到自己在工作裡，遇到比較大的困惑；主要的問題，是自己忙不過來，精力不夠用。可是也不敢把手頭的工作，大膽的放手給團隊的其他人，擔心其他人接不過來核心的、有困難的、時間緊張的任務。把自己的大部分精力，投入在專案的研發任務攻關上。
僅從上面的情況看，對於愛好技術的人來說，這樣對技術工作的付出和努力，並不會讓人覺得厭煩和沮喪。讓他們感到沮喪的，是自己覺得專案做的不好，對專案**現的目標不明確、團隊合作不順暢，感到困難和無力解決。從而擔心團隊的整體產出和持續發展。
這是典型的技術leader把自己當作團隊的技術產出主力、其他事輔助的情況，他們個人勤奮、技術好、價值觀正；這些技術工作上很優秀的人，如果不能調整自己的工作方法，就會成為團隊提公升的障礙，在技術leader這個崗位上碰壁，不能在新的崗位上，持續保持優秀。
對專案的目標感到不明確的原因，和團隊合作不順暢的原因，主要都是leader沒有完成角色的轉換，把代表團隊進行對外溝通、對外協作的工作，作為乙個重要的工作。溝通和協作是要高成本的投入，尤其是leader的投入；同時也是leader的槓桿作用體現的乙個重要方法。
給他們的具體建議，是把技術工作時間的比例，降低到30%以下，大量的專業工作交給團隊的成員。其餘的時間，主要用來：
通過這4個工作，來完成自己由個人貢獻者，向團隊槓桿作用者的角色轉換，成為乙個真正意義上的leader：崗位是leader、職責是leader、行為方法是leader。
stage 2:
技術leader二段，專案管理思維的疊加
做述職後的提問環節裡，我問到這乙個q，覺得自己做的比較好的地方是什麼時，有4個同學提到「在產品的進度跟進」上，有了比較大的進步，體現在專案交付的時效性更好了。當leader感受到這一點時，在不知不覺中，他們已經意識到專案管理思維的重要了。
專案管理不僅僅是研發進度的跟蹤。專案管理是乙個成熟的、完成的體系，從需求管理、資源配置、流程管理、風險控制、投入產出分析等多方面，來為乙個專案的成功做保駕護航。僅僅自發的從「研發進度」這乙個點上發揮，是不能具備比較好的專案管理思維的。研發leader要讓團隊的專案成功，那麼他必須向前、向後看，向前觀需求管理，向後觀專案價值（收益），同時在執行中關注資源、風險和流程。具體的產品過程中，根據專案的規模、複雜度，leader去按專案管理的知識去做實踐，摸索出自己積累的專案管理經驗，逐漸形成自己的專案管理思維。
專案管理的思維是非常重要的，在以後團隊帶到一定規模後，公司非常看重團隊的執行力，能不能把公司規劃的產品成功的乙個個落地。為leader個人未來的職業成長，鋪墊一條業績之路、信任之路。
給這幾位同學的具體建議，是：
a. 看一本專業的專案管理書，了解專案管理的理論和常規實踐。
b. 在自己的工作裡，靈活應用專案管理，通過實踐形成自己的專案管理思維。
stage 3:
技術leader三段，團隊的教練
有兩位同學在回答q1做的最好的方面時，提到了團隊成員的成長，他們在團隊成員的輔導、指導上，做了很好的實踐。其中一位同學，帶了3個adc做主資料管理系統，非常大的挑戰，但是結果做的很好。
他個人是乙個很好的工程師，技術能力、寫**效率都很高。但是他沒有以自己為中心來組織團隊開展工作，而是把專案拆分成模組、任務，大量分給幾個adc同學，讓adc去做超過他們當前能力的事；他自己在專案過程中，輔導和支援adc同學。半年時間就把adc帶成了團隊產出的主力（這和貝殼招聘了一批優秀的adc有很大關係，素質好，能夠快速培養起來）。
這樣的帶人方式，我在高德工作的時候，也使用過一樣的方法。團隊成員通過自己的努力和leader的指導，完成了超過自己能力的任務，他們的成就感、自信心、實際的工作能力，都會有很大的提高。整個團隊的產出，遠超過以leader為中心產出能力的模式。能夠帶出乙個優秀的隊伍，是技術leader進一步在管理上進行發展的必要條件。
stage 4:
技術leader四段，產品思維的疊加
這次的述職中，沒有體現出產品思維有疊加的技術leader。這可能是乙個副本，不是每個技術leader都有機會去嘗試做產品、帶產品，不做產品基本建立不起來產品思維，也很難去帶產品。從長期的發展來看，這會束縛技術leader的發展空間。不過這也是一條難路，從技術思維的主線裡，去理解和接受乙個相差很大的產品思維，非經過大折磨難以合成。
我過去因為技術團隊帶的比較好，公司為了培養我，而給我機會，讓我去帶產品團隊、業務團隊。剛開始帶產品團隊時，對產品經理們估計是個很痛苦的過程，我們很難有效的交流，無關對錯、無關是非，僅僅是因為思維模式不一樣，看待同一件事時，關注的點是不一樣，難以有共鳴，難以有共識。理解乙個事情，最好的辦法是自己去做一下，參與設計幾個產品，看他們是怎麼工作的，努力在和他們的交往、配合中，把自己轉換成乙個產品經理，用共同的語言、共同的思考模式、共同的視角去發現、分析和解決問題。實踐上來說，細緻的review產品經理的prd，把自己理解不一致、認為有問題的地方提出來，和pm一起**，是技術leader比較快的搭建產品思維的乙個方法。
僅僅從做好技術團隊的工作本身出發，具備一定的產品能力和產品思維也是很有必要的。技術團隊的專案**於產品經理的輸出，如果不具備一定的產品思維，很難和產品經理一起對prd進行深入的有效溝通。知道prd說明了要做什麼，為什麼這麼做、有沒有更好的辦法做，卻是不能理解的。不能理解產品經理的思考和產出prd過程，研發就容易降級為產品經理實現目標的資源，而不是夥伴關係。
stage 5:
技術leader五段，業務思維的疊加
在這次述職裡，技術leader的okr裡，大部分有一條：100%實現產品經理的需求；或100%實現產品經理有價值的需求。研發實現產品經理的產品設計，這是職責的一部分。但是我不認為這樣寫研發的okr合適。我更希望他們的okr，是實現業務的某個目標，和產品經理是保持一致的。
這兩者的差異，在於是否擁有業務思維。okr定義為實現產品經理的訴求，是乙個技術思維；定義為實現業務的某個目標，是業務思維。研發做的好不好，最終是看有沒有體現出業務的價值。有一些研發leader認為，技術團隊的職責就是實現產品規劃，這是沒有錯的。但是更進一步，產品規劃是為了實現業務目標，所以研發工作的最終目標，是實現業務目標。只有研發的目標和關鍵結果，和業務結果關聯起來時，才能對產品的規劃、方案，進行有深度的review。只有團隊目標定義為業務目標，技術leader也才會有意識去和業務進行深入的交流和溝通，去理解業務的目標，培養更高的格局和對長期目標的理解。
「對於公司來說，無論技術幹部、產品幹部還是管理幹部，都是業務幹部，為公司的業務目標負責」。這是高德老領導董振寧先生的一句話，對我影響久遠。無論身在技術、還是身在產品，心永遠在業務；以達成業務目標為自己的職責。
這五個階段，非一層層的公升級關係，每個leader因為工作環境、團隊環境的場景，可能會早接觸或晚接觸某個階段。在接觸到某個階段時，希望能夠有意識的去建立這方面比較全面的思維，在知識上先學、仿其他人，逐漸在工作實踐中形成自己的認知，最後用自己的認知，形成自己的方法，去指引自己工作。
這五個階段，不是覆蓋的關係。思維的疊加，更像多維空間的延展，每一種思維都來之不易，也有無限的提公升擴充套件空間。在我們的整個職業生涯和生命中，我們都應該在持續的昇華自己的復合思維。
注：本次沒有提到架構思維，對於技術leader來說這是非常重要的乙個思維。在述職過程中，主要述職內容是業務okr和團隊建設，沒有對專業技術、架構方面進行講述。
【歷史文章推薦】
程式設計之美Q1
題目 和數書頁有點類似，就直接數吧 includeusing namespace std class q1 size t q1 func size t num num return count int main size t q1 func size t num num return count s...
菜鳥刷題之路 Q1
寫乙個函式，求兩個整數之和，要求在函式體內不得使用 四則運算符號。一開始考慮轉化成位來計算，但是這樣 結構非常複雜且當出現負數時就難以計算。之後轉化思維，從十進位制數字計算的本身上來看 兩個數 ab cd 的計算過程可以看成是 a c e，b d f，如果e,f大於10，就保留ef 的個位數。如果出...
台積電 10nm製程研發順利 Q1流片
今天，台積電召開財報會議，董事長 被譽為台灣半導體教父的張忠謀親自出席，執行ceo劉德音和魏哲家聯席。2015年，台積電合併總營收額為 8434.97億元新台幣 約為1662.53億元人民幣 同比增長10.6 稅後淨利3065.74億元新台幣 約為604.26億元人民幣 同比增長16.2 成績可喜。...