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

Завязка

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

С Google Drive всё прошло гладко. С Evernote – нет. О том, что пошло не так и как нам это удалось преодолеть, читайте под катом.



Задача была простая:

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

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

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

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

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

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

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

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

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

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

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

Конечно же, клиент после такого отношения был в ярости и уже начал опускать руки. Но мы очень болели за этот проект и не хотели оставлять его на финальной стадии в таком состоянии.

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

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

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



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

Вывод

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