涅槃重生:我的技術(shù)轉(zhuǎn)管理之路

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

我從畢業(yè)就一直做技術(shù)，開始一年是做 Java 語言的服務(wù)器開發(fā)，開發(fā)過網(wǎng)易郵箱和微博的后臺，后來轉(zhuǎn)而做 iOS 開發(fā)。

因為喜歡，我?guī)缀醢盐宜械姆枪ぷ鲿r間也投入到技術(shù)中去。當(dāng)然，并非是把工作帶回家，而是專研技術(shù)或者從事技術(shù)寫作。

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

我做得很開心。

我一直以為，我會是一個好碼農(nóng)，我會一直在技術(shù)上深入下去。

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

涅槃重生

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

于是，我開始了技術(shù)轉(zhuǎn)管理之路。

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

現(xiàn)在經(jīng)過了一年半，我們不但組建成了一支充滿戰(zhàn)斗力的團隊，成收獲了不小的成績：

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

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

技術(shù)管理的總結(jié)

在我的工作中，我慢慢總結(jié)出在創(chuàng)業(yè)公司中做技術(shù)管理工作的「方法論」。我把我的技術(shù)管理工作分成以下幾個部分：管理業(yè)務(wù)，管理團隊，管理技術(shù)。

管理業(yè)務(wù)

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

• 任務(wù)分解和分配

• 制定大概的開發(fā)排期

• 每天了解開發(fā)進度

• 討論和跟進各種具體的技術(shù)問題

• 協(xié)調(diào)一些產(chǎn)品需求變更

• 響應(yīng)一些市場同事的需求

• 跟進相關(guān)功能上線

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

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

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

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

對于產(chǎn)品需求變更和市場同事需求的響應(yīng)，我主要利用自己在 Sprint 執(zhí)行過程中的時間來展開。我會根據(jù)當(dāng)前需求的大小和緊迫程度，來決定是否插入到當(dāng)前的 Sprint 中。如果插入到當(dāng)前的 Sprint 工作量太大，我會適當(dāng)做一些 Sprint 內(nèi)容的調(diào)整。

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

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

在每周的工作中，我的管理業(yè)務(wù)的工作大概花費是 2 天左右。

管理團隊

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

1.招人

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

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

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

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

2.帶人

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

• 平時多交流溝通。

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

• 引導(dǎo)新人熟悉公司的工作方式。

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

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

適合一對一溝通的內(nèi)容有很多，包括：

• 不成熟的看法

• 迫在眉睫的問題

• 精彩的想法

• 傾訴焦慮

• 抱怨

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

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

在《創(chuàng)業(yè)維艱》一書中，也介紹了一些適合用來引導(dǎo)的問題：

• 當(dāng)前產(chǎn)品還有哪些可以提高的地方？

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

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

• 你覺得誰的工作最優(yōu)秀，為什么？

• 我們的產(chǎn)品哪方面不盡如人意？

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

• 哪些是我們應(yīng)該做而沒有做的？

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

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

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

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

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

什么是領(lǐng)導(dǎo)力

關(guān)于管理團隊，我也特別喜歡《成為技術(shù)領(lǐng)導(dǎo)者》一書中的觀點，關(guān)于本書，更多的請見《成為技術(shù)領(lǐng)導(dǎo)者》讀書心得。書中是這么說的：

“所謂領(lǐng)導(dǎo)力，就是創(chuàng)造這樣一個環(huán)境，每個人都能在其中發(fā)揮出更多的能力。”

我想：在強調(diào)平等、創(chuàng)新、自由的互聯(lián)網(wǎng)公司里面，這可能就是領(lǐng)導(dǎo)力最好的定義吧。

管理技術(shù)

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

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

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

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

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

• 推進技術(shù) wiki 的使用

• 推進 iOS 端每周一次的技術(shù)分享

• 推進 Code Review 以及代碼質(zhì)量

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

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

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

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

產(chǎn)品負責(zé)人

除了技術(shù)負責(zé)人的管理業(yè)務(wù)，管理團隊，管理技術(shù)工作外，我另外還是小猿搜題的產(chǎn)品負責(zé)人，所以我還承擔(dān)著技術(shù)負責(zé)人之外的一些工作。這些工作最主要的就是對產(chǎn)品的管理工作。

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

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

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

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

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

我每周花在產(chǎn)品評審和美術(shù)評審大概是半天到一天，每周花在關(guān)注產(chǎn)品各項指標數(shù)據(jù)上的時間大概是半天到一天。
 

我做得不好的地方

做為一個技術(shù)轉(zhuǎn)管理的新人，我覺得我的工作還是有挺多問題。

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

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

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

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

總結(jié)

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

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