Перспектива перехода на удаленную работу обескуражила меня не меньше остальных. За 15 лет существования нашей небольшой IT-компании, у нас было несколько "подходов к этому снаряду". И все оканчивались неудачей.
В каждом отделе были свои на это причины:
Продажники начинают нести полную чушь клиентам. И потеря клиента здесь не самое страшное. Куда дороже обходились купившие клиенты, если продажник их дезинформировал.
В разработке слишком высок порог вхождения, а если у вас еще и строгие правила к архитектуре и оформлению кода, удаленному сотруднику проще сдаться и забить, чем разобраться. А перед этим поимитировав какое-то время деятельность за наш счет.
Техподдержка объединяла обе эти проблемы.
Технические писатели либо просто пропадали, столкнувшись с необходимостью написать инструкцию к инструменту в неведомой им системе, либо потратив кучу времени (и ожидая оплаты за него) выдавали документ, который надо переписывать чуть меньше, чем полностью.
Поэтому, каждый раз мы в итоге возвращались к расширению площади офиса и найму дополнительных сотрудников в штат.
После того, как мы прошли все пять стадий принятия неизбежного, вдруг, стало ясно, что мы уже сделали наше домашнее задание и сотрудники, хоть и находятся в офисе, технически, уже давно на удалёнке.
Продажи
Процесс продаж у нас организован в Битрикс24: звонки, письма, заполненные формы, чаты поступают прямо туда и сохраняется в архив, прикрепленный к клиенту. Из каждой коммуникации создается лид. Менеджер либо конвертирует лид в сделку, либо закрывает, указав статус (например, у нас есть статусы "Спам" и "Поставщик"). Сделка движется по воронке продаж в форме канбан-доски. Руководитель отдела получает не только подробные отчеты, но и может прослушать каждый звонок, прочитать чат или письмо. На основе этого он может создать задачу к разбору ситуации на внутреннем тренинге. Для того, чтобы начать принимать звонки, чаты и письма, менеджеру достаточно открыть Битрикс24 в браузере и одеть наушники.
Единственное, что мне не нравится в Битрикс24: система позволяет "закрыть" звонок, письмо или чат, не обработав его толком. Когда наши продажники работали в osTicket, каждое обращение клиента требовалось обработать в явной форме, либо явным образом подтвердить, что ответ не требуется. Зато я понял, почему чужие продажники так легко забивают на вопросы клиентов: похоже, никого больше на рынке не волнует, чтобы клиенты получали ответы на все свои обращения.
Управление проектами
В том же Битрикс24 мы используем функцию управления задачами: любой сотрудник может создать другому задачу, прикрепив к ней исполнителя, соисполнителей и наблюдателей. В задаче можно оставлять комментарии, создавать подзадачи и суб-делегировать. Можно отобразить задачи в форме Канбан-доски, как в Трелло. Я сортирую задачи на неразобранные, срочные, перспективные, делегированные и неважные. Без этого в неразобранных образуется свалка и список задач перестает работать. Самое удобное то, что можно быстро просматривать не только свои задачи, но и назначенные тобой коллегам.
Там же сотрудники фиксируют начало и конец рабочего дня и пишут отчет за день. Отчет за день пишут не все сотрудники. Например, работа продажников в Битрикс24 налажена так, что система сама сообщает им, что и с каким клиентом делать, поэтому общий показатель - обнулить все счетчики "дел" к концу рабочего дня.
Разработка
Разработку мы ведем в Easy Redmine. Вообще, также, как и Битрикс 24, Easy Redmine претендует на то, чтобы закрыть все потребности по информатизации. Но нам оттуда подошла только организация итеративной разработки и база знаний. Easy Redmine позволяет отобразить задачи в виде интеллектуальной карты (графа), SCRUM-доски, диаграммы ганта, календарного плана, либо таблицы. Можно создать свои типы задач и для каждого из них создать свои наборы дополнительных полей, статусов и полномочий. Для разработки мы создали карточки: «пользовательский сценарий», «промежуточный сценарий», «объект», «ошибка» и «технический долг».
С интеллектуальной картой, в основном, работаю я как Product Owner. Левая часть дерева задач представляет собой пользовательские сценарии, которые переходят от общих у ствола, к частным. Например: "Жизненный цикл пользователя" -> "Жизненный цикл слушателя" -> "Изучение курса" -> "Тестирование" -> "Ответ слушателя на вопрос типа "Кейс"". Правая часть дерева соответствует программной архитектуре продукта. Например: "Moodle" -> "Плагины типов вопроса" -> "Кейс". Это может казаться избыточным, но далеко не всегда сценарий затрагивает только один плагин, как и плагин может быть задействован во-множестве сценариев.
Разработчики, в основном, работают со SCRUM-доской. Мы разделяем проект на ежемесячные релизы и еженедельные спринты. В начале спринта разработчики выкладывают из бэклога карточки сценариев и объектов на доску. Карточки движутся по стадиям "Ожидает выполнения"->"Разработка"->"Ожидает проверки"->"Проверка"->"Ожидает демонстрации"->"К релизу"->"Эксплуатация"->"К выводу из эксплуатации"->"Архив". Все выложенные карточки должны быть передвинуты в стадию "К релизу" или "К выводу из эксплуатации" до конца итерации. Если сценарий слишком велик, то он разбивается на подсценарии, которые не несут самостоятельной пользы клиенту, но могут быть продемонстрированы. Работая над каждой карточкой, разработчики фиксируют свои трудозатраты с помощью встроенного счетчика времени.
В конце итерации разработчики демонстрируют Product Owner-у сценарии и он их принимает, либо отклоняет.
Принятые в релиз сценарии поступают техническому писателю. Он видит их в специальном отчете, структура которого соответствует будущему анонсу релиза. Для каждого сценария и объекта он выбирает раздел релиза, вписывает текст анонса и прикрепляет скриншеты. Это позволяет начать работу над анонсом еще пока идет разработка и не терять сценарии. Затем, Product Owner принимает анонс галочкой по каждому сценарию. Аналогично принимается обновление пользовательской документации.
Поддержка пользователей
Для технической поддержки мы используем osTicket: клиент направляет заявки через личный кабинет, выбрав тип заявки. Например: "Консультация", или "Изменение режима резервного копирования", или "запросить акт сверки", или "заказать доработку". Для каждого типа заявок открывается своя форма, в которой могут запрашиваться дополнительные данные.
Необработанные заявки попадают в соответствующий отдел, где должны быть либо обработаны, либо - для длительных задач - отложены на конкретную дату с уведомлением клиента. За ходом обработки заявки и комментариями сотрудников клиент может следить через личный кабинет или по уведомлениям в электронной почте. Также он может комментировать заявку и предоставлять дополнительную информацию.
Мы считаем очень важным, чтобы клиент обязательно получил ответ на все свои сообщения в прогнозируемые сроки, поэтому в конце каждого дня менеджер проверяет в специальном отчете, что не осталось ни одной просроченной заявки, а также что даже для отложенных заявок последним было письмо нашего сотрудника, а не клиента. Эти данные, вместе с просрочкой по внутренним задачам, собираются в отчет, который влияет на премиальный фонд соответствующего отдела.
База знаний
Для организации внутренней базы знаний мы используем Easy Redmine, а для клиентской нам больше подошел phpMyFAQ, который мы интегрировали с Moodle для сквозной авторизации, передачи прав на чтение определенных разделов базы знаний и использования статей из базы знаний в качестве материалов учебных курсов Moodle.
Обучение сотрудников
Мы являемся разработчиками среды электронного обучения 3KL Русский Moodle, поэтому, конечно же и сами ее используем. Наша компания пока не достаточно велика, чтобы иметь отдел обучения, поэтому мы создаем только микро-курсы: когда в базе знаний появляются статьи, которые должны прочесть сотрудники определенных отделов, мы добавляем их в учебный курс и ставим правило регулярного напоминания, пока статья не будет прочитана. Там же мы формируем банк вопросов, из которого каждую неделю случайным образом формируется тест для каждого сотрудника.
Если появляется информация, которую обязательно нужно до всех донести, мы создаем для нее один или несколько вопросов. В таком формате нам не нужно даже скрывать правильные ответы, потому что единственное, что нам нужно – это, чтобы сотрудники запомнили правильные ответы.
Контроль сотрудников и общение
Для поддержания визуального контакта мы используем видеорегистратор Trassir. В каждом кабинете, включая удаленные, установлена камера и монитор. На мониторе сотрудники видят своих коллег из других комнат. Это очень важно для сохранения общности в коллективе. Кроме того, это упрощает общение, например, можно отправить вопрос или даже шутку в чат коллеге и увидеть, как изменилась его мимика.
Для чатов мы используем Google Hangout: во-первых, он есть в каждом телефоне с Android, во-вторых, он встроен в Gmail, и, в третьих, там видно, кто именно прочел сообщение в групповом чате. Возможно, когда-нибудь мы перейдем на встроенные чаты в Битрикс24. Но пока не планируем.
Решая совершенно другие бизнес-задачи, мы, попутно, подготовились и к переводу офиса в карантин. И осталось только раздать сотрудникам гарнитуры и камеры.
Что дальше
Теперь мы задумались, а не попытаться ли нам снова нанять удаленщика - сотрудника, который будет работать удаленно и после окончания карантина. Например, из другого города. Хотя, цыплят по осени считают. Прошло еще слишком мало времени, чтобы анализировать результат.
Вынужденная удаленка
В этом плане, для нас ничего не изменится. Команда на удаленке будет работать, как работали. С тех пор, как мы пробовали работать с удаленщиками, мы уже поменяли все процессы, внедряя эти инструменты. Теперь они подходят и для удаленки, хотя мы этого не планировали и не для этого вводили изменения.
Единственное заметное изменение - проводим еженедельный стендап и остальные совещания по Скайпу. Это оказалось даже удобнее - компьютер под рукой у каждого, можно ссылку закинуть или вывести на экран и показать. Плюс запись доступна для менеджеров, которые по итогам совещания назначают задачи.