首先从技术角度看。去年，豌豆荚的研发团队首先拟出了应用内搜索的技术协议，然后基于这个技术协议接入了一些合作伙伴的内容。在他们的配合之下，这些内容被应用到豌豆荚主产品里面，比如跟猫眼做的电影票，再比如可以直接搜到知乎的问答，还有具体场景底下的一些用例。

今年，研发团队调整了具体的执行策略，但觉得还是不够快，所以又探索了一些新的方式。仍然是原来的那一套协议，但是不用开发者进来，不用他们配合，而是自己做最快的数据接入的工作。这是今年的改变。这主要是从效率方面考虑的：需要开发者来配合的话，要考虑开发者的响应时间，来来回回去沟通协议具体是什么样的，可能一个来回就是一个星期，有两三个来回一个月就过去了。其他的方向都是一样的，接入的内容还是会跟开发者沟通，一定是他们愿意接入的东西。

进展确实很明显，改变了策略之后，目前已经接入了500家左右的应用内容。

还有一个很重要的事情，豌豆荚有一个很重要的、叫做Chana（刹那）的技术，集成到了一览里面。Chana是豌豆荚的邓草原老师基于Akka开发的一个实时计算框架，是用 Scala语言编写的。研发团队在底层做了应用内搜索的架构升级，包括把这样一个实时性和扩展性都很棒的实时计算平台引入进来，以及对于底层的Storm等平台的升级，这些可能是用户看不见的，但是能很大地扩展数据处理能力。

再从产品角度看。产品方面也很清楚，在去年一开始的时候，研发团队主要是在豌豆荚的主产品里做了很多创新的探索，看一下如何将提供给用户的价值最大化。今年又有了更进一步的全新的探索，基于应用内搜索技术，推出了“豌豆荚一览”和“Snap效率锁屏”这样的产品。研发团队也在产品中加了很多的应用场景，比如用户购买了电影票，可以很快地告诉用户，你的电影马上开始了，可以选择打车过去，或是附近有什么好的餐厅，这些都是通过应用内搜索的技术把服务和内容跟用户当前的产品结合在一起的具体例子。这两个产品也是豌豆荚在应用内搜索产品化上给出的阶段性答案。

协议：应用内搜索的基石

在刚开始的时候，研发团队会把每一个门类特别细节的东西都定义得很清楚，在接入的时候希望接入的内容在每个门类下，这些字段都应该很清楚再接入，这样效率会比较低，现在会倾向于尽可能结构化，一些不能结构化的东西先把它半结构化地拿进来。这样达到一个效率和最结构化的信息和将来结构化信息的利用有一个平衡。

另外，研发团队也在不断地做一些细节的优化。像前面提到的今年的变化，不再需要开发者主动的配合，所以内部要考虑怎么能够把各种各样不同的、千奇百怪的应用内容跟协议搭进来。说得通俗一点，是怎么样才能够更聪明地去做适配，怎么样才能更智能化地提高适配效率，在这方面做了很多工作。这个工作可能不是重新制定协议，而是对协议进行一些简单的升级，让它能够普适性做得更好。

这里还要提一下Deep Link。之所以有这个概念，是因为移动互联网发展起来，原来那套基于 HTTP、超链接实现互联互通的互联网被割成了以应用为中心的信息孤岛。要解决这个痛点，所以很多厂商纷纷提出了自家的Deep Link，但是目前还没有一个事实上的行业标准。比如说谷歌做了一个 App Indexing，Facebook 做了一个 App Links，大家的协议都会有或多或少的差异。目前看来，Facebook的协议因为考虑得更全面一些，所以成为事实标准的可能性会更大。但不管怎么样，这个格局还是很纷乱的，大家更多是从自己的应用场景、自己的应用需求出发，制定这样的一套一套的规则。

豌豆荚去年做这件事的时候，更多是从自己和用户的角度去考虑这件事情，主要是从三个点来考虑，一是普适性，二是经济性，三是实时性。先看普适性，豌豆荚做这件事情的时候，市面上已经有谷歌和 Quixey的两种协议，所以想兼容这两种协议。如果开发者支持这两种协议，可以直接接入进来。再看经济性，豌豆荚采用的方案都是 Microdata 这种很成熟的技术方案，开发者可以很快地、比较容易地通过这些技术提交内容。最后看实时性，对于豌豆荚接入的应用内容，如果在手机上看到一个内容，它能够更快地触达用户，还是很重要的。所以开发者可以通过实时API，快速提交内容。当时整个协议的思路主要是从这三个点出发。

在应用调起方面，国内的开发者其实对调起支持都不是特别友好，有一个效率比较高的方法，先去看开发者到底对调起的支持怎么样，对于支持好的会在产品里直接调起应用去打开这个页面，如果不行的话，则会调起H5页面。如果所有的开发商和厂商都能够更重视调起这一块，能够把 Deep Link 这一块做得更好，将来有希望做到应用里面的每一个页面都能够被标准的调起，这样以后应用内搜索可以做成跟网页搜索一样。不过这是下一步要做的工作，当前还不是最重要的。最重要的是先让用户看到这里的价值，用户喜欢用，反过来开发者就会看到里面的价值。

团队：小而美

应用内搜索方面，豌豆荚一直保持着一个小而精的工程团队，工程人员一直没有特别大的增长，但是工程师搭配比较合理，有搜索领域的专家，也有工程能力很强的软件工程师，还有很有创新精神、勇于探索的年轻人。另外，这个团队的工作也并不是完全自成一套，不是说完全从头开始做的，也会用到很多外界成熟的第三方开源软件。像公司里的Codis和Chana，觉得做得很好的东西，都会有机的结合到产品和工程里面来。团队也是挺开放的。

另外，像搜索团队，其实负责了豌豆荚的应用内搜索和应用搜索等工作。

改组为项目制

要想了解一个团队的工作流程，必须先要了解团队的架构。可能和你想的不一样，豌豆荚团队的架构并不是比较普遍的部门制，而是项目制。改组的原因是之前采用的部门矩阵管理制度使得同一位设计师或工程师会同时负责多个项目，不仅沟通成本大，排期优先级也混乱难以协调。

新的项目制的流程是这样的，当一个新的项目确定后，便会确定对应的设计、开发、运营人员临时组成一个项目团队。项目完成后该项目团队解散，再重组进行下一个项目或进入其他项目中（中间过程，项目成员每过3个月也可以申请调换到其他项目）。

没有产品经理

另外一个你可能意想不到的是，豌豆荚是没有专门的产品经理的。当一个项目组建后，如果该项目产品是以设计为主导的，就由产品设计师整体负责，如果该项目产品是以开发为主导的，就由开发工程师主导。主导人相当于该项目临时的产品经理。

对工程师能否负责起这个角色的疑问，张涛告诉极客公园，在豌豆荚，很多产品都是由工程师自己做出来的，包括产品的原型、界面设计等，刚刚又有一位工程师从开发转岗到产品设计，这在豌豆荚并不是第一例。年初王俊煜在接受 infoQ 采访的时候也有提到过，“有不止一位豌豆在工程师和产品设计师之间有过相互转换的经历”。

基础了解后，下面就来从一个项目的流程（从设计开始到开发、测试、上线、后续的运营、反馈迭代）来看看豌豆荚是如何利用工具增加工作的效率，减少那些“为了能够完成工作而需要做的工作”的吧。

产品设计

前期设计

通过团队头脑风暴讨论，然后用便签把 idea 分类，然后作为一个个的任务归类到项目管理工具 Asana 里，并指派给负责的人。以后这件事情只和这个人相关，后续的进度、流程都通过 Asana 的邮件通知去了解和安排。另外在 Asana 中默认所有人都能看到所有项目，如果想和该负责人一样实时跟进的话只要 follow 一下就可以收到邮件提醒，保证透明性。

产品开发

开发的进度管理也是使用 Asana，就像前面提到的那样，最早人少的时候开发进度是通过 Excel 管理的，后来使用一个类似微软 Visio 的工具，但因为比较臃肿且无法跟踪 BUG 所以很快就被抛弃。再后来转向使用 Jira，因为 Jira 对 BUG 跟踪以及进度控制得很好，分配也比较细，还可以统一协调。但后来因为使用成本太高，也被抛弃。Jira 之后开始试用 37signals 的 Basecamp，后来因为进度不明确、速度慢也被抛弃。

最后开始试用 Asana，当时豌豆荚是 Asana 的第一批用户，也是第一个完整地将团队切换到 Asana 平台上的（现在使用的团队还有Foursquare,Airbnb,DISQUS等）。

继续接着上面的流程，当设计输出高保真原型图后，将包括每一个像素点是多少等在内的具体细节描述都写在 Google Docs 文档上，稍后工程团队会跟进，在这份文档上与设计沟通确定好（中间会有改动），然后工程团队这边也会出一份和设计文档类似的实施文档。这份文档会给工程师以及一些技术大牛们过一遍，大体指出哪些地方应该是什么样，中间可能会面临哪些风险及遇到哪些问题，做一些技术上的指导。然后就是最后的 Coding 编码了。Coding 过程中也是使用 Asana 进行管理，哪些功能完成了就勾选一下选择完成，之后工程师会收到通知，确认这一块已经完成。后续每周有一个周会来检查回顾上周碰到什么问题并确定本周来做什么，整个研发的过程就是这样。