涅槃重生:我的技術轉管理之路

我從高中就開始接觸計算機并開始編程，我非常喜歡編程，我一直以為我會寫一輩子代碼。

我從畢業就一直做技術，開始一年是做 Java 語言的服務器開發，開發過網易郵箱和微博的后臺，后來轉而做 iOS 開發。

因為喜歡，我幾乎把我所有的非工作時間也投入到技術中去。當然，并非是把工作帶回家，而是專研技術或者從事技術寫作。

于是這幾年，我積累了超過 150 篇原創技術文章，在 iOS 技術圈子里面也小有名氣，也出版了一本《iOS 開發進階》的書，微博和微信公眾號的粉絲數也都超過了 3 萬。

我做得很開心。

我一直以為，我會是一個好碼農，我會一直在技術上深入下去。

但是，改變有些時候就是來得那么突然。

涅槃重生

我還記得那一天，2014年 7 月 17 日，我當時受到邀請，在廣州的微信分享 iOS 開發技術。當天晚上，我接到郭常圳（我們的 CTO）的電話，知道要做小猿搜題這個項目，并且這個項目「由我負責」。

于是，我開始了技術轉管理之路。

通過從以前的項目組中抽調人手，小猿搜題這個產品技術團隊很快組建出來了。我在開發 iOS 版的小猿搜題客戶端的同時，也開始了我的管理工作。

現在經過了一年半，我們不但組建成了一支充滿戰斗力的團隊，成收獲了不小的成績：

• 小猿搜題產品一年時間獲得了 5000 萬的用戶。

• 我們團隊在開發上做到了每周一次迭代，兩周一次版本發布。

技術管理的總結

在我的工作中，我慢慢總結出在創業公司中做技術管理工作的「方法論」。我把我的技術管理工作分成以下幾個部分：管理業務，管理團隊，管理技術。

管理業務

作為互聯網公司，我們奉行簡單直接的溝通，所以我很多時候并不需要涉及人員的管理工作，更多的時候是業務的管理工作。業務的管理工作主要是圍繞著一個具體要做的技術開發功能點展開。具體包括：

• 任務分解和分配

• 制定大概的開發排期

• 每天了解開發進度

• 討論和跟進各種具體的技術問題

• 協調一些產品需求變更

• 響應一些市場同事的需求

• 跟進相關功能上線

在這方面，我們主要是采用 Scrum 的開發方式，見《適合碼農工作時玩的游戲：Scrum》。

我們在整個迭代（Sprint）過程中引入四個會議：計劃會議，每日站會，評審會議和回顧會議。通過事先簡單的計劃，再加上這四個會議中的詳細討論，我基本能夠做到：

• 通過計劃會議：比較合理的安排開發排期、分配任務。

• 通過每日站會：每天了解開發進度，會后討論和跟進各種具體的技術問題。

對于產品需求變更和市場同事需求的響應，我主要利用自己在 Sprint 執行過程中的時間來展開。我會根據當前需求的大小和緊迫程度，來決定是否插入到當前的 Sprint 中。如果插入到當前的 Sprint 工作量太大，我會適當做一些 Sprint 內容的調整。

跟進相關功能的上線主要是開發快要結束的時期，我會和產品同事一起試用最新的功能，了解 Bug 修復的進度，上線的風險情況。在大部分出現風險的情況下，我們都希望用適度加班的方式解決，所以我們上線當晚有時候會工作得比較晚。在無論如何都搞不定的情況下，我們可能會調整上線時間。

在業務涉及跨部門合作的時候，相關的進度管理會更麻煩一些。因為各部門自己的進度安排不一致，所以就會存在「等著聯調」的情況。另外聯調時出現問題也容易出現沒人主動出來解決的情況。這些都需要負責人更頻繁地溝通和推進，以保證按時上線。

在每周的工作中，我的管理業務的工作大概花費是 2 天左右。

管理團隊

剛剛也說到，互聯網公司不怎么需要管人，那么管理團隊主要是做什么事情呢？我認為主要是兩件事情：招人和帶人，所謂的搭班子和帶隊伍。

1.招人

招聘這事情實在太重要了，所以必須要團隊負責人參與。人才的招聘除了從公開的渠道收取簡歷、從獵頭或同事那里得到推薦以外，還包括定向的找一些自己熟悉的前同事或某個領域的知名大牛，這些工作都是非常花費時間的。

在招人上，我們主要用到了找前同事，內部推薦發伯樂獎，以及進行技術分享和開源代碼來獲得社區影響力的方式。

值得一提的是，我們對于開源社區的貢獻也得到了肯定，我們的基礎架構組負責人陳恒因為多次為 Hbase 貢獻代碼，所以成為了 Hbase 的 Committer，而全中國擁有 Hbase 的 Committer 的公司在此之前只有三家，而且中國的 Hbase 的 Committer 不到 10 人。

在每周的工作中，招聘大概會占用我半天到一天的時間。

2.帶人

人才招進來了，能否順利融入團隊，團隊負責人以及這個人的導師（mentor）非常重要。需要做的事情包括：

• 平時多交流溝通。

• 在新人遇到問題時，熱心地解答。

• 引導新人熟悉公司的工作方式。

一對一溝通來源于 Intel 公司，在最近很火的一本書 《創業維艱》 中里面也提到過。《創業維艱》的作者本·霍洛維茨是被譽為「硅谷最牛的 50 個天使投資人」之一，先后在初期投資了 Facebook、Twitter、Groupon、Skype。

他在書中對一對一溝通介紹到，一對一溝通最主要的意義是：可以使得信息從下而上地傳遞。從而獲得在其它渠道不易獲得的信息，保證透明。

適合一對一溝通的內容有很多，包括：

• 不成熟的看法

• 迫在眉睫的問題

• 精彩的想法

• 傾訴焦慮

• 抱怨

這些內容都不適合在別的場景中出現，比如：不成熟的看法，如果在部門的正常會議或郵件中提出，會讓人覺得未經過深思熟慮。又比如一些焦慮或抱怨，如果通過一些渠道宣泄給其他同事，其實也是不好的。一對一溝通讓這些內容有了一個不錯的出口。

5年前我剛畢業加入網易有道的時候，我的老大，也是我現在創業公司的 CTO 郭常圳就開始和我做一對一溝通。我非常享受每次溝通的過程。現在我也開始和別人做一對一溝通，我也開始關注一對一溝通的技巧。我們認為最大的技巧是：作為管理者，要多聽少說，讓員工成為溝通的中心。郭常圳有一個特別「老土」的辦法，就是：不主動說話。通過這種方式，強迫讓員工選擇他們想聊的話題。

在《創業維艱》一書中，也介紹了一些適合用來引導的問題：

• 當前產品還有哪些可以提高的地方？

• 我們部門的最大問題是什么，為什么？

• 如果有，你覺得工作中有哪一點令你感覺不舒服？

• 你覺得誰的工作最優秀，為什么？

• 我們的產品哪方面不盡如人意？

• 我們錯失的最大機遇是什么？

• 哪些是我們應該做而沒有做的？

• 你自己希望未來在哪些方面能有提高？

• 有什么我能為你做的事情？

我大概保持每個月和每個組內同事都有一次一對一溝通，有很多時候，我是通過「請他們吃飯」來完成的。一對一溝通需要一個舒適的環境，所以在咖啡廳或飯桌上，可能都比在辦公室的效果要好一些。

一對一溝通的另一個核心要素是要坦誠，這就像 Scrum 指南中用「游戲規則」來描述內容一樣，如果管理者做不到坦誠，那么同事就不會把這當作是一次有效的溝通機會。坦誠的溝通方式是：所有問題都真誠的回答，不掩飾問題，也不回避問題。如果溝通雙方能夠做到坦誠，即使是一個棘手的問題，那么雙方也會從「解決問題」的角度，盡量尋找可能的辦法。

除此之外，定期組織一些團隊活動，讓團隊每個人之間建立友誼，也是我努力在做的。這在很多大公司是 HR 部門做的事情，在我們創業公司里面，也變成團隊負責人的工作之一了。

什么是領導力

關于管理團隊，我也特別喜歡《成為技術領導者》一書中的觀點，關于本書，更多的請見《成為技術領導者》讀書心得。書中是這么說的：

“所謂領導力，就是創造這樣一個環境，每個人都能在其中發揮出更多的能力。”

我想：在強調平等、創新、自由的互聯網公司里面，這可能就是領導力最好的定義吧。

管理技術

作為一個技術負責人，產品在技術上的架構是否合理？隨著用戶量的增長，現有架構能否勝任？當運營活動發生時，突發的流量會有多少，服務器是否能夠承受住壓力？未來技術上的架構應該如何演進？除了服務器端，客戶端應該在哪些技術方案上投入研究力量？這些都是技術負責人需要考慮和決策的。

我同時做過服務器端和移動端的開發工作，不過由于最近幾年都是做移動端的開發，所以服務器端的架構技術細節我其實并不是專家。所以我在這方面做得算不上很好。可能是運氣好吧，有幾次服務器的壓力問題，我們都及時發現并且解決了，但是時間都挺緊迫的。現在，我會花時間把服務器端的架構圖畫出來，然后一塊一塊考慮，看看有沒有更優的方案，并且和服務器端的同學討論。

在客戶端上，我只是對 iOS 開發比較熟悉，對 Android 了解得并不深入。所以我會讓技術同學自己提一些技術改進方案，我參與Review，我想他如果能說得有理有據，還是可以授權他在技術上深入的。

其實每個平臺的技術管理可能都需要更多的「授權」，因為具體做事情的人，會比技術管理者更清楚地了解細節。而對細節的深入了解，才是改進技術架構的方案來源。所以，盡量招靠譜的人，那么在管理技術上的工作就只需要遵守「盡量授權」的原則來就可以了。

管理技術還包括公司技術氛圍的建立，我主要在以下這些方面下了一些工夫：

• 推進技術 wiki 的使用

• 推進 iOS 端每周一次的技術分享

• 推進 Code Review 以及代碼質量

Wiki是一個非常好用的知識管理工具，前提是每個同事都參與貢獻內容。所以作為一個管理者需要用言行來指導新同事學會用 Wiki。我會主動將重要內容記錄在 wiki 上，對于一些同事發的郵件內容，我也會要求他整理到 wiki 上。

iOS 端的技術分享也是需要管理者推進的。我之前在網易有道的時候，這方面的活動基本上是大家自愿的方式來進行。這其實對分享者要求很高，一般的人很難達到這種意識，所以當時有道 iOS 端的技術分享很少。因此，我還是認為「半強制」的分享方式更適合當前團隊。

「半強制」的分享規則需要大家認同，在一個相對輕松的環境下達成一致，為此我專門組織了一次交流會，大家相互認識一下，一頓吃喝之后，再約定分享規則。現在看起來，大家其實有很多想分享的內容，在 Wiki 上，很多一兩個月才輪到他的人，都已經把分享的主題確定了。

Code Review 也是一個需要推動的事情，我們使用 Git 和 Gerrit，做到了所有的提交必須 review 通過之后，才能 merge 進代碼倉庫。另外我們也在 wiki 上規定了詳細的代碼風格要求。Code Review 如果做得好，不但可以在代碼風格上達成一致，還能讓新同事從中學習到一些良好的編程習慣，一些潛在的 Bug 也可能在 Code Review 中被發現，實在是值得堅持的事情。

產品負責人

除了技術負責人的管理業務，管理團隊，管理技術工作外，我另外還是小猿搜題的產品負責人，所以我還承擔著技術負責人之外的一些工作。這些工作最主要的就是對產品的管理工作。

產品工作看似簡單，實則復雜，而我作為一個工作多年的程序員，在這方面的經驗非常少。所以我在參與產品討論時，一開始都比較惶恐。后來我慢慢發現，產品經理的思維還是有章可循，便開始總結和學習，我看了不少產品經理的書，而郭常圳的多次指導也對我的幫忙意義巨大。其實做產品的原則就那么多，重要的還是多思考和體會，把那些原則融入自己的理解。

「場景化思維」是我學到的第一點，我還記得郭常圳帶著我們學習喬布斯推出第一代 iPhone 時的演講，喬布斯非常會講故事，在用戶具體的場景中介紹自己的產品。好的產品經理會將自己「代入」目標用戶的使用場景中，解決用戶的主要痛點和問題。做為技術人員，我常常陷入產品邏輯完備的泥潭中，但是「場景化思維」使得我能夠重新跳出細節，關注主要功能設計是否合理。

「關注數據」是我學到的第二點，產品經理在打磨細節方面，如果能夠關注產品數據，那么就很容易找到改進的方向，并且在后期驗證自己的想法。關于這個，詳細的請看：數據的秘密（上）- 為什么要關注數據 和 數據的秘密（下）- 如何分析數據。

我曾經猶豫自己是否應該學習寫產品稿，郭常圳說不用，他說你只需要多看產品經理的產品稿，多思考和比較，慢慢就會有產品的感覺。我發現這一點還是管用的。以前用一個新的App，作為開發者，我會關注它的功能在技術上如何實現，而我現在，不光會關注技術實現，還會想它的產品設計思路。打開了這扇窗戶后，我就能在日常生活的每一天里，通過思考來提升自己的產品能力。

作為產品負責人，我主要的工作是參與產品稿的評審和美術稿的評審，同時會參與決定未來要做的功能，將其安排到產品工作中。另外，我也會關注產品的各項指標數據，保證重要的產品數據都是看過的。

我每周花在產品評審和美術評審大概是半天到一天，每周花在關注產品各項指標數據上的時間大概是半天到一天。
 

我做得不好的地方

做為一個技術轉管理的新人，我覺得我的工作還是有挺多問題。

首先，我剛開始還是太迷戀技術了，有一些開發工作我仍然主動參與。但是實踐之后發現，因為我的事情太多太雜，使得我很難保證自己承擔的開發工作的進度。所以我現在學會主動把任務交給別人做，如果一件事情不是必須我才能做的，我就交給別人。所以現在技術上，我只參與 iOS 端的 Code Review 工作了。我將更多的精力，放在一些不得不由我做的溝通和項目推進方面的工作上。

接著，我有很長一段時間沒能很好地安排好產品計劃和研發的進度。好的產品計劃應該要領先開發一個以上的迭代周期，這樣在技術開發當前版本時，下一個版本功能就在設計和評審當中，使得大家的工作都不受影響。而小猿搜題的產品計劃有一陣一直沒能很舒服地領先技術，這讓很多時候開發同事并不舒服。

解決的辦法是我們讓產品文檔的完成時間點也盡量精準，對于一個大的產品功能設計，我們會定好初版（我們內部叫做 1 版本）、詳細版（我們內部叫 5 版本）、完善版（我們內部叫 9 版本）的時間點。產品經理需要努力在時間點內保證產出，這樣其實反倒使得大家會關注產品設計的主要問題，在細節上不過分糾結。

最后，我在招聘上的成績也比較一般，沒有能夠為團隊招來很多有經驗的人，所以小猿搜題現有團隊還是新人居多。新人的好處是容易和團隊文化保持一致，但是在經驗上，還是需要更多的鍛煉。

總結

小猿搜題從2014年 7 月 17 日立項，到 10 月上線，再到元旦正式對外推廣，到現在在不到一年的推廣時間內，已經積累了超過 5000 萬的用戶。而我，也隨著小猿搜題，從一個純技術的 iOS 程序員，成長成為它的產品技術負責人，雖然也犯了一些錯誤，我感覺自己的進步還是很快的。

我也希望我的故事能夠激勵其他的技術同行，能夠勇敢地接受新的挑戰。在快速變化的移動互聯網時代，快速迭代演進的不止有 App，也包括我們自己，愿大家都能活得精彩！