Как правило, для управления работой в рядовой IT-компании используются только баг-трекинговые системы и системы для управления проектами. В этом отрасль достаточно консервативна — эти продукты используются чаще всего и ставятся в первую очередь.
Но по факту продуктовая разработка уже давно доросла до того, чтобы в полной мере использовать BPM-решения — системы для управления бизнес-процессами. Рассказываем про примеры использования BPM.
В статье умышленно не говорим о кейсах IT-аутсорса — только про продуктовые компании. Хотя BPM подойдет и в аутсорсе, отличия в процессах будут значительные, поэтому это тема для отдельной статьи.
Не разработчиком единым живет продуктовое IT
В продуктовых IT-компаниях кроме разработчиков, менеджеров, тестировщиков работает значительный штат сотрудников, которые непосредственно взаимодействуют с разрабатываемыми продуктами и их пользователями:
— Несколько линий технической поддержки — консультируют клиентов по продукту, обрабатывают запросы об ошибках;
— Системные администраторы (dev ops) — отвечают за работу серверов и работоспособность оборудования, не всегда входят в команду разработчиков;
— Маркетологи различных специализаций: общий маркетинг, таргетинг, PR и event маркетинг и т.д. В отделе маркетинга очень много потенциальных активностей, мы даже вынесли их в отдельную статью — о бизнес-процессах маркетинга.
— Копирайтеры – пишут тексты о продукте для блога и внешних площадок по заказу маркетологов;
— Технические писатели — пишут пользовательские инструкции и материалы в справочный портал при выходе нового функционала, обновляют старые справочные статьи при изменениях существующего функционала;
Получается, что в компании может работать значительное количество сотрудников, которые непосредственно разработкой не занимаются. При этом они пользуются каждый своим софтом. Маркетинг работает в своих программах, если вообще не в экселе, поддержка в своих, копирайтеры и технические писатели становятся заложниками CMS-систем и онлайн-редакторов вроде Google Docs.
Отсутствие единой системы при постоянной итеративной разработке приводит, например, к таким ситуациям:
- Разработчики выпустили новую важную функцию, а о ней забыли рассказать в рассылке или соц. сетях. Результат: потерян инфоповод.
- Клиент просил напомнить, когда выйдет важная для него функция, а ему забыли написать. Результат: клиент не конвертировался в активного или платящего клиента, или даже ушел.
- Новый функционал вышел, а справочные материалы ко дню релиза еще не готовы. Результат: пользователи читают, что вышла новая функция, а как использовать ее не знают. Из-за этого они штурмуют техподдержку, нагружая ее вопросами, которых можно было избежать.
В этих и многих других случаях виноваты разрывы в коммуникации между командами компании. Что-то можно компенсировать почтой или мессенджерами, если есть ответственный менеджер по продукту, который за всем следит. Но управлять всем вручную или не всегда возможно, или это съедает много времени, которое квалифицированному специалисту всегда есть куда потратить.
Правильнее всего будет по максимуму организовать бизнес-процессы ИТ-компании в единой системе и автоматизировать их. Вот тут как раз и пригодится BPM-система с возможностями проектного управления как намного более емкий сервис для управления компанией. Мы, конечно, будем рассматривать это через призму нашего продукта Neaktor, но все описанное ниже будет актуально в целом при использовании процессного подхода к продуктовой разработке.
Бизнес-процессы IT-компании продуктового направления
С одной стороны, может показаться, что имеет место большое противоречие —BPM-системы поддерживают процессный подход, тогда как разработка IT продуктов это преимущественно проектная работа. Но в случае продуктовой разработки это совсем не так.
Проектный подход — это когда у вас есть конечный набор уникальных задач по проекту, завершив которые, весь проект завершится. Задачи, по большому счету больше не повторятся, и следующий проект нужно будет заново продумывать. То есть у проекта есть изначально оговоренные сроки, бюджет и необходимые работы, уникальные именно для этого случая.
Когда компания разрабатывает свой собственный продукт, допустим какое-то веб-приложение, то разработка уже представляет собой условно бесконечный процесс итеративных улучшений, а задачи начинают выполняться по одинаковым алгоритмам. Это значит каждая из следующих задач легко описывается бизнес-процессом:
— Реализация новой функциональности
— Учет дефектов (багов)
— Запуск нового сервера
— Покупка / аренда нового оборудования
— Учет серверов и оборудования
— Отработка тикета в тех. поддержку
— Анализ конкурентов
— Написание статьи в блог или SMM
— Запуск рекламы
— Ведение email-рассылок
— Организация мероприятий
— Создание и обновление справочной статьи
И так далее. Список может содержать более 50 возможных бизнес-процессов, связанных непосредственно с продуктом. Из этой большой массы задач в очень многих IT-компаниях автоматизированы только 2: создание нового функционала и баг-трекинг. И, хотя ведение проекта и баг-трекинг — это одни из главных процессов в IT компании, получается, что они составляют менее 5% того, что стоит автоматизировать.
Каждый же из десятков бизнес-процессов состоит из своих этапов, заполняемых данных, своих исполнителей, затрагивает несколько отделов. Автоматизация и описание бизнес-процессов для IT-компании не менее важны, чем для любой компании из реального сектора.
Взаимосвязь задач и отделов друг с другом
Для менеджеров по продукту и проектных менеджеров важно видеть всю картину целиком. Поэтому то, что все активности будут вестись в одной платформе, априори имеет свои преимущества.
Но еще большую пользу принесет автоматизация и связывание процессов между собой. Как правило, это означает, что одна задача своевременно автоматически на нужных этапах может создавать новые задачи для других отделов. Кроме этого автоматом могут отправляться письма, ставиться напоминания, отправляться запросы в сопутствующие системы вроде репозиториев кода. Именно это не позволит случаться проблемам, которые мы описывали выше — вроде не анонсированного вовремя функционала или невыпущенной справочной статьи.
Наша компания тоже продуктовая, и мы, конечно, сами вовсю используем автоматизацию в Neaktor. Давайте рассмотрим несколько возможных, но не единственных сценариев автоматизации, которые можно реализовать:
- Когда вы разрабатываете параллельно и веб- и мобильное приложение, вы, скорее всего, ведете их в двух проектах. Но часть задач может быть актуальной для обеих версий. Это означает, что тестировщику придется не забыть продублировать тикет в оба проекта. Это можно автоматизировать так: при создании задачи вы выбираете галочку «Актуально для мобильной версии» и задача автоматом дублируется в проект по мобильной версии. Понятное дело, что «тикет для мобилки» может отличаться из-за UI, но, когда тикет уже поставлен, его всегда можно релевантно дополнить. А если вы спохватились уже после релиза, что забыли добавить какой-то функционал в мобильную версию, то это эпичный провал.
- О больших изменениях продукта обязательно нужно писать статьи и рассказывать в рассылке. Начать писать текст, когда функционал уже вышел – это слишком поздно. Поэтому намного эффективнее будет при создании задачи заполнить атрибут «Требует поста в блог», чтобы в момент, когда задача будет взята в работу или перейдет в тестирование, автоматически поставилась задача для копирайтера на написание статьи. Притом в этой задаче будет добавлена ссылка на сам тикет, и копирайтеру не придется много переспрашивать своих коллег о том, что же это за функционал, о котором он должен написать.
- Если в поддержке клиенту пообещали, что какой-то функционал скоро появится, то, конечно, обещание стоит выполнить. Однако если у вас тысячи клиентов, а изменение может выйти не на следующей неделе, а через полгода, то забыть про обещание довольно легко. Можно, конечно, поставить напоминание, но оно не спасет, так как объективно релизы продуктов неминуемо смещаются и редко выходят в строго запланированные даты. Зато этот кейс можно запросто автоматизировать, если отметить в тикете клиентов, которые просили узнать о выходе функции, а потом система автоматически отправит им шаблонный email о выходе функции.
Уверены, что вы сможете придумать намного больше специфических вариантов автоматизации и взаимосвязей процессов с учетом особенностей вашей компании. Стоит только начать. Легко можно добавить и постановку тикетов для создания и обновления справочных статей, записей в соцсети, обновление планирования и многое другое.
Бонус: бэк-офис
В предыдущих разделах статьи мы специально говорили только про те бизнес-процессы, которые связаны непосредственно с разработкой продукта.
Но в любой компании, включая IT, имеются также поддерживающие процессы. Это такие, которые не генерируют прибыль напрямую, но без них существование компании невозможно: бухгалтерия, IT-отдел, отвечающий за внутреннюю инфраструктуру, HR, офис-менеджмент и т.п.
Хорошая новость в том, что эти отделы могут тоже работать в единой BPM-платформе. Напрямую с разработкой продукта они, конечно, пересекаться не будут, но в целом вся информационная сеть компании будет собрана воедино.
Про процессы бэк-офиса мы уже довольно много писали, поэтому подробно мы описывать не будем, вы можете найти информацию по ссылкам: рекрутинг, организация онбординга, управление внутренней тех. поддержкой, учет оборудования, учет корреспонденции, ведение отпусков.
BPM для IT
Полноценную организацию бизнес-процессов в ИТ сложно переоценить. Мы уверены, что будущее IT-компаний за BPM.
Если вы еще сомневаетесь, напишите нам на contact@neaktor.com и мы расскажем вам подробнее.
Оставьте комментарий