В нашем блоге на Мегамозге мы много пишем об интересных подходах к управлению проектами (которые стараемся применять в работе над облачным сервисом 1cloud) и интересных способах решения проблем, с которыми сталкиваются ИТ-компании.

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

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

Постепенно лидерство в данной нише захватил инструмент под названием Slack — он довольно удобен, имеет красивый дизайн, и им пользуется все большей компаний. А значит, их контрагенты, которые еще не перешли на Slack, вынуждены это делать, для того, чтобы общаться, к примеру, с клиентами, там, где тем удобно.

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

Этап 1: технические сложности

Старой системой для внутрикорпоративного общения в Khan Academy был сервис HipChat. В нем были созданы комнаты для обсуждения конкретных тем, распределены права доступа в диалогам, администраторы привыкли к работе с интерфейсом управления, были налажены интеграции со сторонним софтом (например, для отправки обновлений в проектах Asana в конкретную комнату).

Фактически, вся наша система развертывания софта была завязана на HipChat.



Поэтому, чтобы избежать проблем в будущем, инженеры Khan Academy изучили все точки контакта HipChat с внутренней системой проекта (она работает на собственной открытой библиотеке alertlib) и внешними сервисами вроде GitHub и Asana. Здесь плюс перехода на Slack заключается в том, что из-за его популярности, команде проекта не пришлось переписывать собственные коннекторы к чату — все интеграции уже созданы разработчиками внешних систем.

Система развертывания софта Khan Academy называется Sun Wukong и главной задачей был перевод ее на рельсы общения со Slack. Здесь возникло две трудности. Чтобы облегчить переезд, сначала было решено выделить небольшую команду разработчиков, которые работали бы с двумя мессенджерами одновременно, чтобы понять все узкие места. Однако внутренние механизмы Sun не позволяли одновременно подключить ее к двум чат-приложениям.

Кроме того, Sun использовал для интеграции с HipChat Hubot, однако делал это только номинально, не применяя никаких методов Hubot API. А значит, даже то, что Hubot отлично работает с API Slack, никак не помогало делу.

Команде Khan Academy пришлось модифицировать задачи (jobs) системы развертывания таким образом, чтобы они публиковали свое состояние в JSON-файл, расположенный на билд-сервере, а затем научить Sun полагаться в работе на данные, представленные на билд-сервере.



В итоге инженерам удалось добиться желаемого — в конце концов все заработало и в Slack.

Этап 2: Организационные проблемы

В Slack довольно богатые возможности по отображению и форматированию сообщений, поэтому при переезде с менее утонченного инструмента, изначально перенесенные оповещения будут выглядеть не очень.

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

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

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

Этап 3: Переписывание документации

Самый «механический» этап, однако работы здесь нужно проделать много — следует обновить описания того, в какие комнаты какие программы и что публикуют, описать способы подключения и правила общения в определенных комнатах и т.д.

Khan Academy нашла неплохой лайфхак, помогающий сразу испытать новую документацию в деле — переход на новую чат-систему и внедрение новых описаний совпал с выходом на работу группы новых сотрудников. Так что новые члены команды сразу начали использовать обновленную документацию.

Заключение: Подготовка позволяет избежать проблем

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

В случаях масштабных технологических переездов очень важно сохранить возможность одновременного использования двух систем — при возникновении серьезных проблем это позволит быстро «откатиться» на старую работающую версию.