豌豆荚对于Asana协作工具的应用非常值得借鉴！

从技术的角度来看。去年，豌豆荚的研发团队首先制定了应用程序搜索的技术协议，然后根据该技术协议访问了一些合作伙伴。在他们的合作下，这些内容应用于豌豆荚的主要产品，如猫眼制作的电影票，直接找到知乎的问答，以及具体场景下的一些用例。今年，R&D团队调整了具体的实施策略，但还是觉得不够快，于是探索了一些新的方法。这仍然是原来的协议，但不需要开发者进来，不需要他们的合作，而是做最快的数据访问。这是今年的变化。这主要是从效率上考虑的：如果开发人员需要合作，他们应该考虑开发人员的响应时间和沟通协议的具体情况。可能是一周，两三个月就过去了。其他方向都是一样的，接入的内容还是会和开发者沟通的，一定是他们愿意接入的东西。进展确实很明显，改变策略后，目前已接入500个左右的应用内容。还有一件非常重要的事情，豌豆荚有一个非常重要的技术，叫做Chana(瞬间)，集成到列表中。基于Akka开发的实时计算框架是豌豆荚的邓草原老师，是用Scala语言编写的。研发团队在应用程序的底部进行了搜索架构升级，包括引入这样一个实时和可扩展的实时计算平台，以及对底部Storm等平台的升级，这可能是用户看不见的，但可以大大扩展数据处理能力。从产品的角度来看。产品也很清楚，在去年年初，研发团队主要对豌豆荚的主要产品进行了大量的创新探索，看看如何最大化用户的价值。今年，基于应用内部搜索技术，推出了“豌豆荚清单”、“Snap效率锁屏”等产品。研发团队还在产品中添加了很多应用场景，如用户购买电影票，可以很快告诉用户，你的电影立即开始，可以选择坐出租车，或者附近有什么好餐厅，这些是通过应用搜索技术服务和内容与当前产品结合的具体例子。这两种产品也是豌豆荚在应用中搜索产品化的阶段性答案。协议：应用搜索基石开始时，研发团队将明确定义每个类别的特殊细节，希望每个类别下的访问内容，这些字段应该非常清楚，所以效率相对较低，现在倾向于尽可能结构化，一些不能结构化的东西首先半结构化。通过这种方式，我们可以平衡高效、最结构化的信息和未来结构化信息的使用。此外，R&D团队还在不断优化一些细节。就像上面提到的今年的变化一样，开发者不再需要积极的合作，所以内部应该考虑如何与协议匹配各种不同和奇怪的应用程序内容。说白了，怎样才能更聪明地做适配，怎样才能更智能地提高适配效率，在这方面做了很多工作。这项工作可能不是为了重新制定协议，而是为了简单地升级协议，以便更好地提高其普遍性。这里还要提一下Deeplink。这个概念之所以存在，是因为移动互联网的发展是基于HTTP、实现超链接互联的互联网被切割成以应用为中心的信息孤岛。要解决这个痛点，很多厂商都提出了自己的Deeplink，但目前还没有实际的行业标准。比如谷歌做了Appindexing，Facebook做了Applinks，大家的协议或多或少都不一样。目前，Facebook协议更有可能成为事实标准，因为它考虑得更全面。但无论如何，这种模式仍然非常混乱，我们更多地从自己的应用场景，自己的应用需求，制定这样一套规则。豌豆荚去年做这件事的时候，更多的是从自己和用户的角度来考虑，主要从三点来考虑，一是普遍性，二是经济性，三是实时性。先看普遍性。豌豆荚做这件事的时候，市场上已经有谷歌和Quixey的两个协议，所以想兼容这两个协议。如果开发人员支持这两种协议，可以直接访问。从经济角度来看，豌豆荚采用的方案是Microdata，一个非常成熟的技术方案，开发人员可以通过这些技术快速、轻松地提交内容。最后，看看实时性。如果你在手机上看到豌豆荚接入的应用程序内容，它能更快地接触用户是非常重要的。因此，开发者可以通过实时API快速提交内容。当时整个协议的思路主要是从这三点出发。在应用调动方面，国内开发人员对调动支持不是特别友好，有一种高效的方法，首先看看开发人员如何支持调动，因为好的支持将直接调动应用程序打开页面，如果不是，将调动H5页面。如果所有的开发商和制造商都能更加关注这一块，可以做得更好，希望应用程序中的每个页面都能在未来被标准调整，这样应用程序中的搜索就可以像网页搜索一样。但这是下一步要做的工作，目前还不是最重要的。最重要的是让用户看到这里的价值，用户喜欢使用，开发人员会看到里面的价值。团队：在小而美的应用搜索中，豌豆荚一直保持着一个小而精细的工程团队，工程师没有特别大的增长，但工程师匹配更合理，搜索专家，工程能力强的软件工程师，以及非常创新的精神，有勇气探索年轻人。另外，这个团队的工作并不是完全自成一套，也不是说完全从零开始，还会使用很多成熟的第三方开源软件。就像公司里的Codis和Chana一样，认为做得好的东西会有机地结合到产品和项目中。团队也很开放。此外，搜索团队实际上负责豌豆荚的应用搜索和应用搜索。要想了解一个团队的工作流程，就必须先了解团队的结构。豌豆荚团队的结构可能与你想象的不同，不是一个常见的部门系统，而是一个项目系统。重组的原因是之前采用的部门矩阵管理系统使同一设计师或工程师同时负责多个项目，不仅沟通成本高，而且安排优先级混乱，难以协调。新项目体系的过程是这样的。当确定新项目时，相应的设计、开发和运营商将暂时组成项目团队。项目完成后，项目团队将解散，然后重组下一个项目或进入其他项目（中间过程，项目成员也可以每3个月申请转移到其他项目）。如果没有产品经理，你可能会想不到的另一件事是豌豆荚没有专门的产品经理。项目成立后，如果项目产品以设计为主，产品设计师将负责整体工作。如果项目产品以开发为主，则由开发工程师主导。领导者相当于项目的临时产品经理。张涛告诉极客公园，在豌豆荚中，许多产品都是由工程师自己制作的，包括产品原型、界面设计等。刚才又有一个工程师从开发到产品设计，这不是豌豆荚的第一个例子。年初，王俊宇在接受infoQ采访时也提到，“不止一个豌豆在工程师和产品设计师之间有过相互转换的经历”。在基本了解之后，让我们来看看豌豆荚如何使用工具来提高工作效率，减少“为了完成工作而需要做的工作”，从项目的过程（从设计到开发、测试、在线、后续操作和反馈迭代）。产品设计的早期设计通过团队头脑风暴进行讨论，然后用笔记对idea进行分类，然后将其作为项目管理工具Asana的任务逐一分类，并分配给负责人。这件事以后只和这个人有关，后续的进度和流程都是通过Asana的邮件通知来理解和安排的。此外，在Asana，默认情况下，每个人都可以看到所有的项目。如果你想像负责人一样实时跟进，你可以收到电子邮件提醒，以确保透明度。Asana也用于产品开发的进度管理。正如前面提到的，最早人少的时候，开发进度是Excel管理的，后来用了一个类似微软Visio的工具，但是因为臃肿，跟不上bug，很快就被抛弃了。然后转向使用Jira，因为Jira很好地控制了BUG的跟踪和进度，分布也很好，可以统一协调。但后来因为使用成本太高而被抛弃。之后，Jira开始尝试37signals的Basecamp，后来因进度不明确、速度慢而被抛弃。最后，我开始尝试Asana。当时豌豆荚是Asana的第一批用户，也是第一个将团队完全切换到Asana平台(Foursquare现在使用的团队，Airbnb,DISQUS等。).继续上述流程。当设计输出高保真原型图时，在谷歌文档上写下包括每个像素点在内的具体细节描述。稍后，工程团队将跟进并与设计沟通（中间会有变化），然后工程团队将发布类似于设计文档的实施文档。这份文件将再次给工程师和一些技术牛，一般指出应该是什么，可能面临什么风险和问题，并做一些技术指导。然后是最后的Coding编码。在Coding过程中，Asana也被用于管理。检查哪些功能已完成，然后工程师将收到通知，以确认该部分已完成。每周都有一周的时间来检查和回顾上周遇到的问题，并确定本周要做什么。整个研发过程就是这样。

以上就是关于豌豆荚对于Asana协作工具的应用非常值得借鉴！的相关介绍，更多豌豆荚对于Asana协作工具的应用非常值得借鉴！相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对豌豆荚对于Asana协作工具的应用非常值得借鉴！有更深的了解和认识。