前言
提起豌豆莢可能很多人第一印象都會想到那個白白胖胖的創始人王俊煜吧，然後可能會是“硅谷範”、“極客範”這些字眼。
作爲創新工廠投資的最早、最爲人熟知且比較成功的項目，豌豆莢自始至終都處在大家的眼中，慢慢地由十幾個人變成幾十個人，再到現在一百多人。在團隊 成員逐漸增多的情況下效率卻並沒有降低，每天 1500 萬個應用下載，用戶數超過 1.5 億的豌豆莢僅僅憑藉 100 多人和 3 只貓就做到了。從這個數據來看，效率不可謂不高。
那麼在這高效的背後是如何實現的呢？王俊煜曾經在極客公園年初的創新大會上分享瞭如何巧用工具提高團隊生產力（文字整理版），但對於如何使用這些工具，以及如何利用這些工具配合團隊協作並沒有展開細述。因此極客公園現場走訪了豌豆莢團隊裏的三位職位不同的團隊成員（產品設計師張濤，開發工程師丁吉昌以及負責運營的文振華）來了解這個團隊高效率的背後是如何利用這些工具工作的。可能有人會問，爲什麼沒有極客公園最比較看中的產品經理呢？答案在後面。
Tips：我們一般所說的豌豆莢其實指的是最早稱作豌豆莢手機精靈的 Android 手機助手客戶端，而豌豆實驗室是團隊的名字，豌豆莢（手機精靈客戶端）是其第一款產品，還有豌豆莢應用搜索、豌豆莢百寶袋以及洗白白等項目產品。
豌豆莢團隊的架構
改組爲項目制
要想了解一個團隊的工作流程，必須先要了解團隊的架構。可能和你想的不一樣，豌豆莢團隊的架構並不是比較普遍的部門制，而是項目制。這種管理架構是 去年六月份改組的，改組的原因是之前採用的部門矩陣管理制度使得同一位設計師或工程師會同時負責多個項目，不僅溝通成本大，排期優先級也混亂難以協調。
新的項目制的流程是這樣的，當一個新的項目確定後，便會確定對應的設計、開發、運營人員臨時組成一個項目團隊。項目完成後該項目團隊解散，再重組進行下一個項目或進入其他項目中（中間過程，項目成員每過3個月也可以申請調換到其他項目）。
沒有產品經理
另外一個你可能意想不到的是，豌豆莢是沒有專門的產品經理的。當一個項目組建後，如果該項目產品是以設計爲主導的，就由產品設計師整體負責，如果該項目產品是以開發爲主導的，就由開發工程師主導。主導人相當於該項目臨時的產品經理。
對工程師能否負責起這個角色的疑問，張濤告訴極客公園，在豌豆莢，很多產品都是由工程師自己做出來的，包括產品的原型、界面設計等，剛剛又有一位工程師從開發轉崗到產品設計，這在豌豆莢並不是第一例。年初王俊煜在接受 infoQ 採訪的時候也有提到過，“有不止一位豌豆在工程師和產品設計師之間有過相互轉換的經歷”。
基礎瞭解後，下面就來從一個項目的流程（從設計開始到開發、測試、上線、後續的運營、反饋迭代）來看看豌豆莢是如何利用工具增加工作的效率，減少那些“爲了能夠完成工作而需要做的工作”的吧。
產品設計
前期設計
通過團隊頭腦風暴討論，然後用便籤把 idea 分類，然後作爲一個個的任務歸類到項目管理工具 Asana 裏，並指派給負責的人。以後這件事情只和這個人相關，後續的進度、流程都通過 Asana 的郵件通知去了解和安排。另外在 Asana 中默認所有人都能看到所有項目，如果想和該負責人一樣實時跟進的話只要 follow 一下就可以收到郵件提醒，保證透明性。
自改組爲項目制後豌豆莢先後試用了 Basecamp,Jira 以及 Asana 等不同的比較專業的項目管理工具，最後選擇了 Asana，除了作爲記錄整理頭腦風暴 idea 之外，Asana 還用於豌豆莢其他所有項目管理，是團隊協作的主線。
原型設計
張濤告訴我們，豌豆莢的設計流程一般都是直接出高保真的原型圖，手繪或 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 進行管理，哪些功能完成了就勾選一下選擇完成，之後工程師會收到通知，確認這一塊已經完成。後續每週有一個週會來檢查回顧上週碰到什麼問題並確定本週來做 什麼，整個研發的過程就是這樣。
Google Docs 是豌豆莢所有文檔的承載體，是 Asana 外的另外一條協作主線。
產品測試及發佈
上面關於產品的設計和開發都是圍繞在 Asana 這條線上，而後續的產品測試以及產品發佈則是在豌豆莢自己研發的工具系統 Wandou Labs 這條線上。
豌豆莢的產品有三種：Windows版、Web網頁版以及 Andriod版，每種產品的發佈都是週期性的，因此豌豆莢專門有一個負責管理髮布的團隊來控制這些產品應該在什麼時間發佈出去。
在 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 的經驗。
但無論怎樣，通過工具的幫助提高工作效率絕對是值得做的，因爲很多情況下“只有用了好的產品，才能做出更好的產品”。