Как создать идеальный бизнес-процесс для сервисной компании по обслуживанию e-commerce-решений, сделать его удобным для заказчиков и разработчиков и отгружать 2,5 тысячи оплачиваемых часов в месяц.
Меня зовут Александр Крылов, я - владелец компании KDTeam. Мы занимаемся поддержкой сложных e-commerce-решений на базе 1С-Битрикс по модели T&M. В среднем мы отгружаем заказчикам около 2 500 рабочих часов в месяц, на обслуживании находится более 300 сайтов.
Компания основана в 2010 году. Портфолио и пул заказчиков был очень разнороден, выполнялись любые приходящие заказы от планирования IT-инфраструктуры до визуальных конструкторов интерьера в зависимости от текстуры стены и цвета краски. Было интересно, опыт был огромен, но бизнесом я бы это не назвал. Это была совместная деятельность команды друзей с целью заработка на жизнь.
Для перехода к бизнесу нам пришлось выбрать для себя специализацию и разработать бизнес-процессы, которые позволяли зарабатывать деньги силами наемных сотрудников.
Специализация
Вопрос выбора специализации был очевиден - поддержка e-commerce решений, а также всевозможных сервисов на платформе 1С-Битрикс.
Выбор специализации основывался на пуле существующих клиентов и следующих соображениях:
- низкая конкуренция
маржа при поддержке сайтов гораздо ниже, чем при разработке новых, поддержка часто является слабым местом разработчиков - стабильно большой объем рынка
очень много сайтов, периодически с каждым из ним что-то происходит - перспективность работ
начиная с поддержки сайта со временем получаешь заказы и на разработку от тех же заказчиков - относительная стабильность платежей
в большинстве случаев, вне зависимости от общей ситуации по стране и рынку, платежи за поддержку сайтов проходят без проблем - возможность совмещать ведение нескольких (десятков) заказчиков
работы по поддержке обычно не очень регулярны, пока одни заказчики "засыпают", другие активизируются
Обратной стороной медали была относительно высокая сложность и ответственность выполняемых работ. Часто приходят "франкенштейны", после 3-5 команд разработчиков разного уровня с десятками нерешенных проблем. Необходимо - нечего не поломав! - аккуратно решить эти проблемы и рассеять негативный предыдущий опыт заказчика.
Каналы взаимодействия с заказчиками
Взаимодействие с представителями заказчиков происходит по 2 каналам: мессенджеры и таск-треккер.
Основным мессенджером для работы с заказчиками является Skype. Мы постоянно ищем более удобное решение, но пока не один другой мессенджер нашим потребностям не удовлетворяет. Этот канал используется для оперативных обсуждений рабочих вопросов. Основными используемыми возможностями является кросс-платформенность, возможность проведения конференций с большим количеством участников, демонстрация экрана, нативная запись конференций. Трансляции с веб-камер мы не практикуем, хотя сейчас это модно :)
В качестве таск-треккера используется Jira с прикрученным к ней хелпдеском. Хелпдеск позволяет уйти от ограничения в количестве лицензируемых пользователей системы. В итоге каждая из команд в составе компании имеет собственную Jira за $10 в год. Все экземпляры абсолютно идентичны между собой по настроенным бизнес-процессам и составу расширений, администрирование осуществляется автоматически через REST API.
Jira - очень мощный конструктор бизнес-процессов. "Из коробки" она приходит абсолютно пустая и все можно собрать под себя. В результате анализа нашей деятельности и ожиданий клиентов наш основной бизнес-процесс получился следующий.
Бизнес-процесс обработки задач
- Новая задача.
Задача создана заказчиком через хелпдеск или по электронной почте. Может быть создана проджект-менеджером по заданию заказчика. Может быть создана QA-специалистом если он выявил баг в ходе проверки сайта.
Максимальное время обработки задачи проджектом - 1 рабочий день.
Проджект-менеджер должен определить приоритет задачи, назначить ответственного за оценку, дополнить информацией или декомпозировать задачу (при необходимости). - Оценка задачи.
Оценка задачи выполняется исключительно разработчиками, проджект-менеджер самостоятельно не оценивает задачи. В 99% случаев задача попадает к разработчику, хорошо знакомому с проектом, это позволяет сильно улучшить точность оценки. Оценку выставляет не только разработчик, в нее закладывается также время проджект-менеджера и QA-специалиста на проверку задачи. Оценка происходит всему участниками процесса последовательно.
Как только последний участник установил оценку, задача переводится в статус "Согласование оценки", заказчику улетает письмо о необходимости подтверждения оценки. - Согласование оценки.
Каждый заказчик хочет контролировать работы и понимать сколько он заплатит за ту или иную задачу. Задача с установленной оценкой "висит" в этом статусе и ждет согласования. Если задача провисит более 1 рабочего дня, проджект-менеджер напомнит заказчику о необходимости согласования.
Мы работаем по T&M, следовательно, заказчик в любом случае оплатит факт затраченных часов (даже если мы не "попадем" в собственную оценку). Нам важно гарантировать прозрачность и честность всего процесса, поэтому заказчик через веб-интерфейс видит оценку каждого сотрудника индивидуально, а не только общую. - Планирование работ.
Это, наверное, самый сложный из всех статусов. В него попадают задачи с согласованными оценками. Как только заказчик согласовал оценку - он ожидает от нас максимально быстрого выполнения задачи (желательно в тот же день). К сожалению, это невозможно, ресурсы разработчиков всегда ограничены и расписаны на 1-2 неделю вперед. Поэтому нам нужно было придумать win-win решение, которое удовлетворило бы и нас и заказчиков.
Таким решение стало календарное планирование с жесткой привязкой к датам: мы сообщаем заказчику что задача сегодня не может быть выполнена, но будет выполнена через N дней. Далее мы прикладываем максимум усилий (на самом деле) к тому, чтобы задержек выполнения более 1-2 дней не было. Это решение устраивает всех: заказчик спокойно ожидает своей очереди, мы спокойно работаем по плану. - Ожидание выполнения задачи
Тут все просто: ответственный за выполнение установлен, граничная дата выполнения проставлена. Задачи разбрасываются по дашбордам разработчиков с сортировкой по календарю, разработчики последовательно выполняют задачи начиная с самых срочных.
Проджект-менеджер контролирует загрузку разработчиков (дневную), а также осуществляет контроль плана (всегда есть вероятность что выполнение задачи займет больше времени, чем ожидалось).
Как только разработчик выполнил задачу - он нажимает кнопку и задача улетает в следующий статус. Все время выполнения задачи фиксируется автоматически, к каждой записи времени разработчик обязан написать короткий комментарий. - Ожидание тестирования
Пропущенные на боевые сайты ошибки несут нам репутационные и финансовые потери, поэтому к вопросу качества мы относимся очень серьезно. Ежемесячно рассчитывается показатель количества багов в общем количестве выработанных часов. Верхняя граница этого показателя составляет 5%, в мае 2020 года этот показатель составил 3,62% (для сравнения, в мае 2019 года он составлял 7,03%).
Организационно работа QA-специалистов построена так же, как и работа разработчиков: каждый из них видит список задач, которые необходимо проверить с сортировкой по хронологии. Кроме проверки самой задачи, они выполняют несколько заранее подготовленных тест-кейсов чтобы гарантировать что выполнение задачи не поломает важный функционал.
Тестирование производится на специальной отладочной площадке - stage. Процесс выстроен таким образом, что мы можем построить stage для каждой задачи индивидуально, на нем мы репетируем автоматическую публикацию задачи на "боевой" сайт. - Ожидание публикации на "боевой" сайт
В этом статусе все автоматизировано. Как только QA-специалист подтверждает корректность выполнения задачи, мы готовы к ее публикации. Публикация задачи - это техническое действие. Не один заказчик не хочет платить (а мы не хотим тратить часы специалистов) на перенос подготовленного кода на "боевой" сайт. Одновременно с этим, завал на этом этапе сводит к нулю все пройденные этапы, человеческий фактор тут недопустим.
Поэтому публикация изменений происходит полностью автоматически, одновременно с этим мы автоматически закрываем задачу в Jira и добавляем в нее комментарий о дате и времени публикации задачи.
Механика публикации изменений в зависимости от типа хостинга и сути задачи - тема для отдельного поста. Главным является то, что мы можем автоматически публиковать любые изменения вне зависимости от типа хостинга (виртуальный/выделенный сервер, виртуальный хостинг), сразу по факту готовности задачи и без вмешательства человека.
При необходимости после публикации на сайт заходит QA-специалист и выполняет пост-проверку сделанных изменений.
На этом бизнес-процесс задачи заканчивается и она автоматически попадает в счет клиенту. Счета на основании факта затраченного времени высылаются клиентам 1 раз в месяц проджект-менеджерами.
Далее архивные данные из всех экземпляров Jira сгружаются в хранилище и визуализируются относительно ключевых показателей деятельности в Microsoft Power BI.
Спасибо за внимание! Буду рад комментариям.