Как мы сдвинули Evernote

Временами в нашей работе возникают истории, которые должны обязательно попасть в отраслевые блоги или разойтись по различным тематическим сообществам, потому что они вдохновляют и придают уверенности в себе. Цель этого поста – рассказать, что при плотной работе с клиентом можно сдвинуть даже бюрократические структуры и сильно поднять свою самооценку. Речь пойдёт о компании Evernote.

Завязка

В 2015 году мы стартовали проект для наших друзей из Австралии. У клиента был сторонний бизнес и небольшой бюджет по сравнению с Evernote. За 1 год работы над проектом мы прошли с клиентом несколько стадий изменения концепции и кропотливой работы над каждым новым изменением, которое вносил клиент уже на этапе разработки. Конечная стадия проекта предполагала глубокую интеграцию с сервисами GoogleDrive, Evernote и Toggl: по сути проект копировал часть функциональности этих сервисов и создавал новую механику.

С GoogleDrive всё прошло гладко. С Evernote – нет. Задача была простая:

1. Клиент авторизуется в Evernote при помощи нашего мобильного приложения;
2. Создаёт блокнот с заметками внутри нашего приложения;
3. Находит список пользователей, с которыми он хочет поделиться этим блокнотом;
4. Нажимает кнопку "Поделиться" и пользователям приходит email с приглашением воспользоваться этим блокнотом;
5. Пользователи подтверждают приглашение и у них в интерфейсе нативного приложения Evernote появляется блокнот клиента.

Проблема происходила на шаге 4. Оговорюсь, что обнаружить проблему на этапе проектирования было сложно, так как документация Evernote выглядела полной. После реализации всех необходимых запросов к API Evernote нужный нам метод шаринга не работал. Вот тут, на StackOverflow, мы спрашиваем об этом и один из представителей компании Evernote отвечает нам, что:

а) метод и документация есть, но вам его использовать нельзя, можно только представителям компании Evernote;

б) официальная документация Evernote неактуальна и этот метод вообще не будет работать, так как уже существует новый метод shareNotebook, к которому необходимо обращаться после обновления SDK. Иными словами SDK существует в открытом доступе, но оно неактуальное.

Все мобильные и веб SDK Evernote используют фреймворк Thrift. Он позволяет интерпретировать свой код почти в любой язык. Я заметил, что при необновлённых SDK, Evernote почти сразу обновляет свой Thrift код на GitHub. И в новом Thrift коде конечно же был метод shareNotebook. Мы решили обновить текущий код сами и даже сделали pull request. К сожалению, даже так метод работал только наполовину. Пользователь, который расшарил блокнот, видит, что блокнот расшарен. Но пользователи, котором был расшарен блокнот, его не видят.

Попробовав это, мы приняли решение поставить разработку на паузу и подождать пару месяцев с ожиданием, что уж за пару месяцев такая большая компания как Evernote сможет произвести обновления своих мобильных SDK. К сожалению, компания Evernote – один из лидеров заметочных приложений с годовым доходом в ~120млн. $, за 2 месяца так и не сделала официального SDK для новой версии API с реализацией метода, описанного выше. Почему это произошло остаётся только гадать.

Как мы добились изменений в API?

Тут начинается история нашей маленькой победы. У нас было два варианта:

1. Отступить, сказав клиенту, что мы не можем ничего не сделать, так как не можем сдвинуть такую машину как Evernote;
2. Действовать и добиться обновления всех SDK, а также обновления API.

Мы решили не отступать и всеми путями добиться от Evernote решения. Пути было три:

1. Найти людей, которые принимают решения через LinkedIn. Дело в том, что это в какой-то степени это связано с репутацией и мы сделали ставку на то, что менеджмент постарается быстро это замять;
2. Связаться с поддержкой Evernote напрямую, периодически подключая клиента;
3. Взять всё в свои руки и найти инженера, который занимается релизом SDK в Evernote, узнать планы по выпуску нового релиза и возможно предложить какую-то помощь.

LinkedIn не дал почти никаких результатов. Связавшись с поддержкой Evernote, мы тоже не смогли многого добиться. Указав на их явные ошибки и объяснив им нашу позицию, они покорно нас выслушали. Однако, сказав, что будут держать нас в курсе, похоронили наше предложение где-то в стенах своих уютных офисов. Конечно же клиент после такого отношения был в ярости и уже начал опускать руки. Но мы очень "болели" этим проектом и не хотели оставлять проект на финальной стадии в таком состоянии.

Выход был один – найти открытые данные инженера из Evernote, который с нами связывался и узнать как мы можем ему помочь. Из открытой информации о нём, я нашёл только его Twitter (тогда я впервые за 5 лет воспользовался функциональностью чата в Твиттере :)) После небольшой переписки он поделился со мной своей болью от того легаси, который в данный момент находился на бэкенде.

Как я уже говорил выше, мы, как разработчики приложений, не могли воспользоваться этой функциональностью. Это связано с тем, что ключи third-party разработчиков и ключи, которые используются в официальных приложениях Evernote (веб-клиенте, мобильных приложениях и проч.), сделаны по-разному. Это очевидно с точки зрения безопасности и конечно же Evernote не мог предоставить нам такие же мастер-ключи для нашего приложения. Помимо этого, эти мастер-ключи умели генерировать так называемый sharedKey, который был связующим между SharedNotebook клиента и LinkedNotebook пользователя, которому этот блокнот был расшарен. Я думаю, основной проблемой было то, что открытый sharedKey мог позволить злоумышленникам получать доступы к чужим блокнотам и эта функциональность была не в приоритете.

Результатом нашего общения был официальный ответ, что в открытой документации этот метод есть, но его использовать могут только сотрудники Evernote, а также понятные причины почему это именно так. Но в отличии от инженеров поддержки, Амар (так звали разработчика) смог назвать нам сроки по реализации этой функциональности, почему она в данный момент не является приоритетной, и смог благополучно скоординировать релиз этой части API.

Через неделю я получил очередное письмо о том, что функциональность выкатили на продакшн и мы можем использовать её в приложении. Это было победой!

Вывод

В работе над этим проектом члены команды несколько раз опускали руки по разным причинам. Однако важно то, что мы всегда верили в проект и в то, что мы способны приблизить клиента к успеху. Эта маленькая история показала, что плотная работа с клиентом, вера в проект и самое главное коммуникация между разработчиками может приводить к приятным результатам. Спасибо всем участникам за то, что дали почувствовать себя классными. Мы ценим это.