前言提起豌豆莢可能很多人第一印象都會想到那個白白胖胖的創始人王俊煜吧，然后可能會是“硅谷范”、“極客范”這些字眼。 作為創新工廠投資的最早、最為人熟知且比較成功的項目，豌豆莢自始至終都處在大家的眼中，慢慢地由十幾個人變成幾十個人，再到現在一百多人。在團隊成員逐漸增多的情況下效率卻并沒有降低，每天 1500 萬個應用下載，用戶數超過 1.5 億的豌豆莢僅僅憑借 100 多人和 3 只貓就做到了。從這個數據來看，效率不可謂不高。
那么在這高效的背后是如何實現的呢？王俊煜曾經在極客公園年初的創新大會上分享了如何巧用工具提高團隊生產力（文字整理版），但對于如何使用這些工具，以及如何利用這些工具配合團隊協作并沒有展開細述。因此極客公園現場走訪了豌豆莢團隊里的三位職位不同的團隊成員（產品設計師張濤，開發工程師丁吉昌以及負責運營的文振華）來了解這個團隊高效率的背后是如何利用這些工具工作的。可能有人會問，為什么沒有極客公園最比較看中的產品經理呢？答案在后面。
豌豆莢團隊的架構改組為項目制要想了解一個團隊的工作流程，必須先要了解團隊的架構。可能和你想的不一樣，豌豆莢團隊的架構并不是比較普遍的部門制，而是項目制。這種管理架構是去年六月份改組的，改組的原因是之前采用的部門矩陣管理制度使得同一位設計師或工程師會同時負責多個項目，不僅溝通成本大，排期優先級也混亂難以協調。
新的項目制的流程是這樣的，當一個新的項目確定后，便會確定對應的設計、開發、運營人員臨時組成一個項目團隊。項目完成后該項目團隊解散，再重組進行下一個項目或進入其他項目中（中間過程，項目成員每過3個月也可以申請調換到其他項目）。 沒有產品經理另外一個你可能意想不到的是，豌豆莢是沒有專門的產品經理的。當一個項目組建后，如果該項目產品是以設計為主導的，就由產品設計師整體負責，如果該項目產品是以開發為主導的，就由開發工程師主導。主導人相當于該項目臨時的產品經理。 對工程師能否負責起這個角色的疑問，張濤告訴極客公園，在豌豆莢，很多產品都是由工程師自己做出來的，包括產品的原型、界面設計等，剛剛又有一位工程師從開發轉崗到產品設計，這在豌豆莢并不是第一例。年初王俊煜在接受 infoQ 采訪的時候也有提到過，“有不止一位豌豆在工程師和產品設計師之間有過相互轉換的經歷”。 基礎了解后，下面就來從一個項目的流程（從設計開始到開發、測試、上線、后續的運營、反饋迭代）來看看豌豆莢是如何利用工具增加工作的效率，減少那些“為了能夠完成工作而需要做的工作”的吧。 產品設計前期設計通過團隊頭腦風暴討論，然后用便簽把 idea 分類，然后作為一個個的任務歸類到項目管理工具 Asana 里，并指派給負責的人。以后這件事情只和這個人相關，后續的進度、流程都通過 Asana 的郵件通知去了解和安排。另外在 Asana 中默認所有人都能看到所有項目，如果想和該負責人一樣實時跟進的話只要 follow 一下就可以收到郵件提醒，保證透明性。
原型設計張濤告訴我們，豌豆莢的設計流程一般都是直接出高保真的原型圖，手繪或 Mockup 那種保真度比較低的原型圖做得比較少。這樣通過減少中間流程可以提高不少效率。
而使用的工具大多是 Photoshop（之前有兩位設計師用 Axure 但最近也都拋棄了），但最近有從 Photoshop 轉投 Sketch 的趨勢，因為 Sketch 解決了很多設計上的痛點。 產品開發開發的進度管理也是使用 Asana，就像前面提到的那樣，最早人少的時候開發進度是通過 Excel 管理的，后來使用一個類似微軟 Visio 的工具，但因為比較臃腫且無法跟蹤 BUG 所以很快就被拋棄。再后來轉向使用 Jira，因為 Jira 對 BUG 跟蹤以及進度控制得很好，分配也比較細，還可以統一協調。但后來因為使用成本太高，也被拋棄。Jira 之后開始試用 37signals 的 Basecamp，后來因為進度不明確、速度慢也被拋棄。 最后開始試用 Asana，當時豌豆莢是 Asana 的第一批用戶，也是第一個完整地將團隊切換到 Asana 平臺上的（現在使用的團隊還有Foursquare,Airbnb,DISQUS等）。 繼續接著上面的流程，當設計輸出高保真原型圖后，將包括每一個像素點是多少等在內的具體細節描述都寫在 Google Docs 文檔上，稍后工程團隊會跟進，在這份文檔上與設計溝通確定好（中間會有改動），然后工程團隊這邊也會出一份和設計文檔類似的實施文檔。這份文檔會給工程師以及一些技術大牛們過一遍，大體指出哪些地方應該是什么樣，中間可能會面臨哪些風險及遇到哪些問題，做一些技術上的指導。然后就是最后的 Coding 編碼了。Coding 過程中也是使用 Asana 進行管理，哪些功能完成了就勾選一下選擇完成，之后工程師會收到通知，確認這一塊已經完成。后續每周有一個周會來檢查回顧上周碰到什么問題并確定本周來做什么，整個研發的過程就是這樣。
產品測試及發布上面關于產品的設計和開發都是圍繞在 Asana 這條線上，而后續的產品測試以及產品發布則是在豌豆莢自己研發的工具系統 Wandou Labs 這條線上。
在 Wandou Labs 上會標明每個產品要發布的功能列表、這些功能發布的時間點以及相應的設計開發的完成進度。然后測試團隊就會根據 Wandou Labs 上的功能列表以及在 Google Docs 上的設計稿及工程稿進行一一測試和審核。為了保證效率，在測試團隊進行測試之前其實設計和開發那邊已經對產品有了基本的使用測試，因此測試團隊只是做基本的回歸工作。
客戶端（Windows,Android）產品的發布相對比較正式，發布團隊在測試完之后發布報告，確定沒有一級、二級BUG 之后召集所有負責人開一個評審會議，討論并確認要發布的產品的功能、產品文檔、產品 BUG 情況、發布策略、發布后對服務器帶寬影響等各方面，如果全部ok就確認發布，發布之后再由運營團隊接手。而 Web 服務端如果有新版本后會先過一遍單元測試，確保大功能不會出現問題后再進行重要指標的測試，之后回滾，然后上線（先在內網上線再到外網）。 所有發布文檔也都在 Google Docs 上。 產品運營之前產品的設計和開發都是內部這些人的管理，那么當產品發布出去后，面對擁有各種各樣想法的用戶，豌豆莢又是如何收集問題以及意見的呢？ 需求反饋收集在豌豆莢，處理用戶及開發者反饋的問題以及需求建議等都是使用 Zendesk，如豌豆莢的用戶反饋是將 Zendesk 嵌入在網站幫助頁面上的，當用戶提交需求反饋后 Zendesk 會自動匯聚到其平臺上并通過郵件通知有用戶反饋了，并說明問題是什么。而負責這一塊的員工直接在郵件里就可以回復用戶除了這個需求，隨即用戶會收到相應的郵件提醒。后面用戶也可以通過直接回復郵件就可以更新自己的反饋需求，豌豆莢和用戶（開發者）之間完全通過郵件就可以實現溝通交流。
如果用戶反饋的是產品 BUG 的話，還可以通過 Zendesk 上面的插件和專門負責跟蹤 BUG 的工具 Jira 打通，隨后工程師會收到提醒并去解決，當 BUG 解決后，工程師會在 Jria 上確認已解決，然后系統會自動同步回 Zendesk 并發郵件提醒用戶該 BUG 已解決（此部分為之前使用Jria時候的流程）。 此外 Zendesk 還可以提供包括反饋數目、反饋類型、滿意度、響應時間以及用戶評價等在內的數據報表，清晰地反映出各個方面做得怎么樣，以及哪些地方還有可以改進的空間等等。
另外在使用 Zendesk 處理用戶提交的反饋（ticket/工單）的時候有一個標簽統計功能，后續 Zendesk 會將標簽同步到數據分析報表中，當拿到數據報表后看到一個標簽被打了 10 次以上就說明這個問題比較重要，運營人員會人工地去分析討論，然后再去詢問用戶的使用場景、對比其他用戶、對需求進行分析研究，然后將討論結果匯總與團隊共同討論決定。 用戶意見調查在豌豆莢收集用戶需求、產品使用反饋和用戶意見建議時，使用的國內的調查派。比如在迷你豌豆莢中，用戶可以在使用過程中隨時點擊“和豌豆們聊聊”在軟件界面中直接打開意見反饋表，向豌豆莢提出自己的問題和意見。 此外用戶在卸載豌豆莢軟件時，頁面都會自動跳轉到一個卸載問卷調查（支持圖片和HTML），詢問用戶為什么要卸載豌豆莢軟件。除了可以在了解用戶為什么卸載軟件之外，還可以記錄一系列的用戶系統配置參數，以便于對產品進行有針對性的調整，更好的滿足用戶需求。
其他招聘招聘方面豌豆莢使用的是 37signals 的另外一個產品 Highrise 。 數據在豌豆莢所有的數據都是透明的，而包括當前業務量多少、截止目前公司總共賺了多少錢、網站的相應速度等在內的數據都是通過 Geekoboard 實時公布出來的，無論是在飯廳吃飯還是在電梯過道都可以隨時看到。 遠程在不得不進行遠程會議的時候，之前一直用 Google+ 的 Hangout，后來因為有些時候網絡會不正常以及QQ有了分享桌面的功能后，就經常用QQ。 推廣產品設計師劉亞平曾在極客公園進行過主題演講，談豌豆莢如何和用戶“談戀愛”，以舉案齊眉的態度去推廣和分發應用。 訂餐你沒看錯，是的，訂餐如果順利的話也是可以提高效率的。為了方便管理阿姨以及所有人訂餐，豌豆莢自己開發了一套自動訂飯系統喂豌豆（開源在GitHub上），它會在每天下午兩點會發郵件詢問每個人吃什么，然后自動匯總到阿姨那去。
如果你對這個訂餐系統感興趣的話，可以去優酷看看這個視頻。目前喂豌豆已經正在重構，馬上發布可以組合菜單的 2.0版。 結語
就像之前王俊煜在創新大會上所說的那樣，生產力像是一門副科，你平時不會關心，但又不能不及格。通過本文介紹或許你也會發現很多工作流程以及工具都是需要多次摸索試用后才能找到最合適的，所以如果你的團隊是一個小而分散的團隊那就不能照搬了，可以參考 Fuubo 的經驗。 但無論怎樣，通過工具的幫助提高工作效率絕對是值得做的，因為很多情況下“只有用了好的產品，才能做出更好的產品”。 |
|
|
