极客公园走进豌豆荚实际考察豌豆荚实验室都是使用哪些工具，如何高效率协作工作。
前言
提起豌豆荚可能很多人第一印象都会想到那个白白胖胖的创始人王俊煜吧，然后可能会是“硅谷范”、“极客范”这些字眼。
作为创新工厂投资的最早、最为人熟知且比较成功的项目，豌豆荚自始至终都处在大家的眼中，慢慢地由十几个人变成几十个人，再到现在一百多人。在团队成员逐渐增多的情况下效率却并没有降低，每天 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 的经验。
但无论怎样，通过工具的帮助提高工作效率绝对是值得做的，因为很多情况下“只有用了好的产品，才能做出更好的产品”。
