Как отказаться от сервисов Google

Ситуация в мире складывается так, что одни отечественные компании целенаправленно уходят от Google-сервисов, другие пока думают над вопросом, будут ли эти сервисы работать в России?

По одной из версий, они всё-таки останутся в нашей стране, но с некоторыми ограничениями. Хотя судя по последним новостям может произойти всё что угодно. Но уже точно известна проблема с оплатой бизнес-аккаунтов у отдельных пользователей Google. И по некоторым прогнозам, аккаунты могут стать недоступны с августа. Что делать российским компаниям, какие есть аналоги и как создать свое решение, рассказывают специалисты frontend-направления IT-компании SimbirSoft.

Почему это важно? Google Docs – отличный (почти) бесплатный инструмент для моделирования потоков данных в реальном времени в любом удобном для пользователя месте. Вы просто создаете табличку и вносите необходимую информацию. Затем она обрастает множеством полей, формул, ссылок. К ней вы настраиваете разграничение прав, пишете скрипты, используете готовые интеграции или свои собственные. И самое главное – всё это делается гибко, легко и в нужный вам момент.

Но реалии меняются, и вдруг вы понимаете: в любой момент доступ к инструменту может быть перекрыт и нужно срочно решать задачу по его замене. Хорошо, что у вас уже есть таблица и конкретный бизнес-процесс, с которым она связана. А что делать дальше, расскажем чуть позже.

Практически у каждой компании, будь то корпорация или небольшой стартап, есть и всегда были Google Документы или Google Таблицы. Но что сейчас делать бизнесу, который использует сервисы Google для совместной работы, хранения документов и отчетности? Этим вопросом несколько месяцев назад задались не только мы.

Самый очевидный вариант – перейти на российские аналоги: Яндекс.Документы, Яндекс.Почта и прочие. Но достаточно ли они покрывают функционал, используемый в Google сервисах? Наша практика показывает, что нет.

Конечно, у российского сервиса есть схожие функциональности с Google. Например, редактирование в режиме реального времени, основной функционал word (работа с документами, шрифты, стили и т.д) и excel (таблицы, формулы и т.д) – в этом, несомненно, его огромный плюс. Яндекс предоставляет пользователям большое количество функционала, который есть в сервисах Google. Он вполне подойдет для ежедневного использования. Но что делать крупным компаниям, у которых достаточно серьезные требования к сервисам, особенно к безопасности и конфиденциальности данных?

Здесь мы уже замечаем недостатки. В частности, Яндекс.Диск не позволяет атомарно назначать права на документы с указанием конкретных пользователей. Этот момент критичен при рассмотрении вопросов сохранения данных. А если раздавать доступ непосредственно в редакторе, файл будет доступен всем пользователям, в том числе вне вашего домена. И это небезопасно! В связи с этим мы стараемся не расшаривать документы с помощью кнопки «Настроить доступ» в редакторах.

Если ссылка на документ уже сгенерирована, её необходимо удалить. В итоге – чтобы предоставить доступ к документу конкретным пользователям, нужно использовать «Общие папки». Только так все документы будут в безопасности, но, как вы понимаете, это не всегда удобно. Также у решения Яндекса на сегодняшний день нет API и функций импорта из других таблиц. То есть по сути отсутствует механизм гибкого разграничения прав и области видимости для пользователя.

Второй вариант – использовать опенсорсные решения. Открытое ПО зачастую можно найти для широкого круга задач. Например, онлайн-магазин, система мониторинга и учета ПК, система управления знаниями, тестирования и прочее. Заменой Google-сервисов для системы управления знаниями и системы тестирования в нашей компании стала Moodle. Однако, мы не нашли готовых решений, подходящих под некоторые наши процессы – в частности, пресейл. Это процесс, который охватывает предпроектную работу, от оценки до подбора свободных специалистов с нужными компетенциями.

Поэтому выбрали третий вариант – создать альтернативный сервис. Мы подумали, а что если разработать для одного из наших процессов удобную и безопасную MVP, минимально жизнеспособную версию продукта, благо у нас было что взять за основу. К тому же, мы давно хотели это сделать, поскольку Google превратился в сложно поддерживаемую систему. Так и поступили, а сейчас уже тестируем собственную разработку. Далее расскажем об этом подробнее.

Сразу отметим, что не ставили задачу разработать полный аналог Google sheets. Это альтернатива для собственного использования, разработка которой пока заняла 1,5 месяца. Она помогает обезопасить один из наших важных внутренних процессов.

Немного предыстории. Большое количество бизнес-процессов компании ведется в наших внутренних системах. Но иногда возникает необходимость в быстром агрегировании данных из разных систем. Так, для удобства у нас родилась Google-таблица.

Все данные в таблице показаны исключительно для примера

Основной процесс пресейла мы ведём в другой системе (Jira): в частности, оцениваем потребности клиентов, чтобы сформировать подходящую проектную команду. Однако здесь у производственных направлений бывают свои особенности, поэтому многие из них используют вспомогательные инструменты – в том числе, такую таблицу. В ней есть краткая информация по каждому специалисту (компетенции, опыт, занятость на проектах и прочее), что позволяет ускорить процесс формирования команд.

Такой способ управления данными позволил снизить временные затраты на рабочие совещания и число ошибок при планировании загрузки, а также повысил производительность пресейл-менеджера.

Со временем таблица обросла сквозной аналитикой и импортами из других таблиц. Всё это позволило вывести KPI для пресейла и дало начало системе прогнозирования (это уже тема отдельной статьи). При этом всё безопасно и бесплатно.

Но выбор готовых сервисов имеет свои риски. Как пример – угроза блокировки Google-аккаунтов создает опасность блокировки целого бизнес-процесса. Рисковать этим мы не могли. И нам пришла идея быстро разработать свою систему, которая покроет необходимый функционал.

На старте делали на основе готовой таблицы:

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

В итоге взяли наш «обкатанный» готовый шаблон для старта проектов с React, выбрали UI-Kit, собрали команду из свободных разработчиков, распределили роли и создали свой продукт.

Да, это не Google-сервис, а система, в которой зашита жесткая логика, но именно это нам и было нужно для решения повседневных задач. Нам не требовалось копировать весь функционал Google Sheets, лишь тот, который мы использовали для нашего процесса, и цель была достигнута. И более того, мы еще и минимизировали ручной труд путем интеграции. А если потребуются изменения, мы всегда сможем доработать эту систему. Поскольку при ее разработке мы применили лучшие на сегодня процессные и кодовые практики – CI/CD, gitflow, проект в Jira, в коде: prettier, husky, linter, typescript, а также react и node.js с использованием nest.js.

Эта система помогла нам не только уйти от использования сторонних сервисов и автоматизировать ручной труд за счет интеграции с внутренними системами, но и повысить безопасность, а также удобство в работе. Многое, о чем мы мечтали, пока у нас был Google, стало реальным. К слову, последнее мы организовали за счет LDAP-авторизации под нашим vpn, а также разграничили роли и права доступов, то есть решили проблему, с которой столкнулись при переходе на другие действующие сервисы.

Трудности в процессе разработки, безусловно, были. В частности, без полноценного технического задания некоторые моменты приходилось переосмысливать и исправлять, поскольку иногда приходилось сталкиваться с ситуациями, которые трудно предусмотреть на старте. Например если бы мы изначально продумали интеграцию с другими системами, нам не пришлось бы переписывать некоторый функционал, т.к он уже существовал в другой системе. Но благодаря слаженной работе команды это не заняло много времени.После релиза мы не хотим стоять на месте и понимаем, как эту систему можно сделать еще лучше. Уже сейчас у нас есть задачи по развитию продукта. Но об этом расскажем в другой раз.

Итак, как понять, что аналоги вам не подойдут и нужен свой продукт. Предположим, что в вашей компании есть какая-то табличка по управлению чем-нибудь где-нибудь. Например, система таблиц по управлению фондом оплаты труда, специалистами, производством и распространением мерча и т.п.

Потребность в разработке собственной системы можно оценить с помощью краткого опросника:

Есть ли у вас система Google Таблиц с Importrange?
Ваш документ содержит более трех таблиц?
С документом работают более 3-5 сотрудников из разных направлений?
Реализована ли в таблице сквозная аналитика?
Написаны ли у вас скрипты автоматизации?
Используете ли вы importrange?
Реализовано ли в документе разделение прав?
Вы думаете, что в Google-сервисах небезопасно хранить все эти данные, а специфика вашей деятельности не позволяет полагаться на открытое ПО или вам не удалось настроить доступы так, как нужно?
Были ли у вас случаи утечки информации?

Если хотя бы на половину вопросов вы ответили «Да», в вашем случае, скорее всего, уже нужно задуматься о создании отдельного сервиса.

При оценке затрат на разработку необходимо учесть объем работ. Тут есть одно НО, которое мы ощутили на себе, переписывая Google Sheets: «гугл-табличка ≠ сервис» т.е. аналитик в аутсорс разработке будет нужен.

Например, ранее мы вносили данные, основываясь на опыте пресейл-инженера. Как это происходило? Собирались на митинге, решали, как будем заполнять табличку, и приступали к работе. Через 3-5 таких митингов появилась супер-таблица, где колонками и цветами мы разделяли логику. Контроль был на пресейле и руководителях, которые работали с этой табличкой. Это нигде не документировалось. В связи с чем иногда случались недопонимания и ошибки. Но так мы получили модель процесса для нашей деятельности.

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

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

Если у вас есть процессы, которые на текущий момент завязаны на сторонних сервисах, и некому помочь с написанием сервиса, сообщите нашему боту, и мы с радостью поможем.

Больше кейсов и полезных материалов для владельцев продуктов - в нашем ВК и Telegram.