专访豌豆荚：团队如何高效率工作？
?
那么在这高效的背后是如何实现的呢？王俊煜曾经在极客公园年初的创新大会上分享了如何巧用工具提高团队生产力（文字整理版），但对于如何使用这些工具，以及如何利用这些工具配合团队协作并没有展开细述。因此极客公园现场走访了豌豆荚团队里的三位职位不同的团队成员（产品设计师张涛，开发工程师丁吉昌以及负责运营的文振华）来了解这个团队高效率的背后是如何利用这些工具工作的。可能有人会问，为什么没有极客公园最比较看中的产品经理呢？答案在后面。
豌豆荚团队的架构Tips：我们一般所说的豌豆荚其实指的是最早称作豌豆荚手机精灵的 Android 手机助手客户端，而豌豆实验室是团队的名字，豌豆荚（手机精灵客户端）是其第一款产品，还有豌豆荚应用搜索、豌豆荚百宝袋以及洗白白等项目产品。
新的项目制的流程是这样的，当一个新的项目确定后，便会确定对应的设计、开发、运营人员临时组成一个项目团队。项目完成后该项目团队解散，再重组进行下一个项目或进入其他项目中（中间过程，项目成员每过3个月也可以申请调换到其他项目）。
没有产品经理另外一个你可能意想不到的是，豌豆荚是没有专门的产品经理的。当一个项目组建后，如果该项目产品是以设计为主导的，就由产品设计师整体负责，如果该项目产品是以开发为主导的，就由开发工程师主导。主导人相当于该项目临时的产品经理。
对工程师能否负责起这个角色的疑问，张涛告诉极客公园，在豌豆荚，很多产品都是由工程师自己做出来的，包括产品的原型、界面设计等，刚刚又有一位工程师从开发转岗到产品设计，这在豌豆荚并不是第一例。年初王俊煜在接受?infoQ 采访的时候也有提到过，“有不止一位豌豆在工程师和产品设计师之间有过相互转换的经历”。
基础了解后，下面就来从一个项目的流程（从设计开始到开发、测试、上线、后续的运营、反馈迭代）来看看豌豆荚是如何利用工具增加工作的效率，减少那些“为了能够完成工作而需要做的工作”的吧。
产品设计点击查看原图
原型设计张涛告诉我们，豌豆荚的设计流程一般都是直接出高保真的原型图，手绘或 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 上。
产品运营之前产品的设计和开发都是内部这些人的管理，那么当产品发布出去后，面对拥有各种各样想法的用户，豌豆荚又是如何收集问题以及意见的呢？
点击查看原图
如果用户反馈的是产品 BUG 的话，还可以通过 Zendesk 上面的插件和专门负责跟踪 BUG 的工具 Jira 打通，随后工程师会收到提醒并去解决，当 BUG 解决后，工程师会在 Jria 上确认已解决，然后系统会自动同步回 Zendesk 并发邮件提醒用户该 BUG 已解决（此部分为之前使用Jria时候的流程）。
此外 Zendesk 还可以提供包括反馈数目、反馈类型、满意度、响应时间以及用户评价等在内的数据报表，清晰地反映出各个方面做得怎么样，以及哪些地方还有可以改进的空间等等。
?
点击查看原图
另外在使用 Zendesk 处理用户提交的反馈（ticket/工单）的时候有一个标签统计功能，后续 Zendesk 会将标签同步到数据分析报表中，当拿到数据报表后看到一个标签被打了 10 次以上就说明这个问题比较重要，运营人员会人工地去分析讨论，然后再去询问用户的使用场景、对比其他用户、对需求进行分析研究，然后将讨论结果汇总与团队 共同讨论决定。
用户意见调查在豌豆荚收集用户需求、产品使用反馈和用户意见建议时，使用的国内的调查派。比如在迷你豌豆荚中，用户可以在使用过程中随时点击“和豌豆们聊聊”在软件界面中直接打开意见反馈表，向豌豆荚提出自己的问题和意见。
?
?
此外用户在卸载豌豆荚软件时，页面都会自动跳转到一个卸载问卷调查（支持图片和HTML），询问用户为什么要卸载豌豆荚软件。除了可以在了解用户为什么卸载软件之外，还可以记录一系列的用户系统配置参数，以便于对产品进行有针对性的调整，更好的满足用户需求。
?
?
如果你对这个订餐系统感兴趣的话，可以去优酷看看这个视频。目前喂豌豆已经正在重构，马上发布可以组合菜单的 2.0版。
结语没有最好的工具，只有最适合你的工具
就像之前王俊煜在创新大会上所说的那样，生产力像是一门副科，你平时不会关心，但又不能不及格。通过本文介绍或许你也会发现很多工作流程以及工具都是需要多次摸索试用后才能找到最合适的，所以如果你的团队是一个小而分散的团队那就不能照搬了，可以参考?Fuubo 的经验。
但无论怎样，通过工具的帮助提高工作效率绝对是值得做的，因为很多情况下“只有用了好的产品，才能做出更好的产品”。
除非特别声明，极客观察均为极客公园原创报道，转载请注明作者及原文链接。