В нашем блоге на Мегамозге мы много пишем об интересных подходах к управлению проектами (которые стараемся применять в работе над облачным сервисом 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 нашла неплохой лайфхак, помогающий сразу испытать новую документацию в деле — переход на новую чат-систему и внедрение новых описаний совпал с выходом на работу группы новых сотрудников. Так что новые члены команды сразу начали использовать обновленную документацию.
Заключение: Подготовка позволяет избежать проблем
Как это часто бывает при работе над ИТ-проектами, все решает правильная подготовка. Использование метода первоначального тестового внедрения новой чат-системы, позволило локализовать самые узкие места будущего переезда и решить все технические и организационные проблемы без риска коллапса работы всей компании.
В случаях масштабных технологических переездов очень важно сохранить возможность одновременного использования двух систем — при возникновении серьезных проблем это позволит быстро «откатиться» на старую работающую версию.
Автор: 1cloud.ru
