Всем привет, меня зовут Константин Кузнецов, я — генеральный директор и основатель компании RocketSales. В IT-сфере довольно часто встречается история, когда отдел разработки живет в своей вселенной. В этой вселенной есть увлажнители воздуха на каждом рабочем столе, куча гаджетов и клинеров для мониторов и клавиатур и, скорее всего, своя система управления задачами и проектами.
Что в этом такого?
Возможно, для кого-то — ничего. Но мы столкнулись с проблемой. Мы занимаемся построением и автоматизацией систем продаж, внедряем CRM, создаем облачную инфраструктуру для бизнеса. В клиентские проекты помимо отделов разработки и производства часто включаются маркетологи, продавцы, бухгалтер, другие сотрудники. И мы стали думать, как организовать эффективный процесс управления проектами.
Если процесс разработки и производства организован в платформе типа Jira или GitLab, то никто, кроме разработки, не понимает, что там к чему. Чтобы подключить к проекту стороннего сотрудника, с ним нужно встретиться, объяснить контекст, где-то зафиксировать задачу, потом контролировать степень готовности в рабочих чатах, через чат же получить результат, внести в Jira. И так каждый раз.
Разработка отрезана от других отделов компании, они не знают, как привлечь нас, а мы не знаем, нужно ли им наше участие.
Пару лет назад мы открыли для себя платформу Asana. В этом материале я хочу рассказать, как мы организовали процесс управления разработкой и производством, чтобы:
- вся компания работала в единой экосистеме,
- всем хватало функционала,
- можно было оценивать стоимость каждого проекта в часах и деньгах,
- работа с клиентами была долгосрочной: не в рамках одной задачи, а в рамках целого проекта с постоянным бэклогом идей.
Немного о знакомстве с Asana
На поиск удобного софта для проектного управления я потратил 10 лет. Trello, Jira, Планфикс, Мегаплан, Битрикс24 и десятки других таск-трекеров не прошли тест на прочность. Потом я нашел Asana. И все сложилось.
На наш взгляд, это лучшая и самая быстро развивающаяся платформа для управления задачами и проектами. Сегодня Asana является мировым лидером по популярности и удовлетворенности пользователей. Об этом говорит график рейтинга g2.
Мы фанаты Asana, даже прошли сертификацию, чтобы иметь возможность внедрять ее клиентам.
Коротко опишу процесс от продажи до реализации проекта
Так как мы продаем IT-услуги, воронка у нас довольно длинная и, ближе к концу, она заходит в отдел производства и, иногда, разработки.
Отдел продаж проводит стандартные манипуляции: аудит, согласование КП, подписание договора, передача сделки в производство. Производство может не принять договор: в нем обязательно должны быть указаны бюджет, дата передачи в производство, расчетный фонд времени на реализацию проекта.
Благодаря связке amoCRM + Asana, при передаче сделки из отдела продаж в производство и обратно, работа нигде не прерывается. Голубым цветом обозначена зона ответственности отдела продаж, оранжевым — отдела производства, розовым — отдела разработки.
Важно, что отдел разработки, в отличие от проектного отдела, участвует не в каждому проекте. Иногда настройка системы не требует кастомных решений.
Итак, когда руководитель принял проект в производство, менеджер по продажам в 1 клик переходит в Asana (скриншот). Из amoCRM проект автоматически создаётся в Asana.
Таск (задача) с картой проекта, коммерческими предложениями автоматически создается на общей доске проектов клиентов. Здесь отображаются все клиенты, которые сейчас находятся в производстве. Здесь назначается ответственный менеджер, ставятся дедлайны, выбирается тип работы и меняются статусы задач.
Менеджер может запустить в задаче любой из предложенных автоматических бизнес-процессов:
- Найти/Создать проект Клиента + Прикрепить туда задачу
- Заполнить задачу информацией по сделке
- Создать сделку из текущей задачи
Проект заполняется всеми данными, указанными в amoCRM. В зависимости от типа услуг сразу создается набор подзадач для реализации актуальных блоков работ. Менеджеру проекта остается декомпозировать детальные задачи, расставить ответственных и дедлайны.
Эта доска помогает принимать новые проекты в работу. Но контролировать на ней актуальные статусы и наличие проектов в зоне риска — неудобно.
Как мы группируем задачи и проекты клиентов
Из общей доски всех проектов менеджер добавляет проект еще на 3 доски:
- персональная доска клиента;
- портфель активных клиентов;
- портфель менеджера.
Разберемся, для чего нам каждая из сущностей.
На скриншоте вы видите персональную доску клиента.
Зачем эта доска?
Раньше мы мыслили задачами. Сделал задачу, пошел делать другую. Получалось, что мы делаем для клиента ровно тот объем работ, который он попросил. Но мы хотели строить долгосрочные отношения, поэтому ушли от работы с задачами в работу с клиентами.
Мы обязательно записываем все идеи по доработкам для клиента. Даже если это мысль, случайно брошенная клиентом в воздух, фиксируем и добиваем. Так формируется бэклог задач, работа с клиентом не заканчивается.
Что есть на этой доске?
Наша Asana связана с несколькими сервисами:
- CRM-система (для взаимодействия с отделом продаж),
- TimeDoctor (для учета времени),
- ERP-система (для агрегации всех данных в едином интерфейсе).
Мы вывели в Asana панель быстрого контроля ресурсов. Наводишь на плашечку над задачей и видишь, кто и сколько работал над задачей, какую премию заработал.
Работа отдела производства оценивается по часам, поэтому нам было важно строго отслеживать, сколько времени ушло у каждого сотрудника на решение задач клиента.
Что дает использование доски?
В итоге в ERP-системе мы видим Отчет по проектам. Статус сделки, участники проекта, бюджет на проект, количество отработанных часов и сроки.
Мы можем прогнозировать стоимость аналогичных проектов по разработке, подсчет KPI становится абсолютно прозрачным и не остается места иллюзиям, что разработка — это всего пару часов. При необходимости у нас всегда есть интерфейс, который мы можем показать клиенту для отчетности.
Портфели Asana
Эта функциональность реализована в Asana уже давно. Но мы не сразу ее оценили. Сперва мы просто собрали в портфели все проекты наших менеджеров. Оказалось, что за время работы в компании Денис Киселев поработал с 61 клиентом.
Знать это прикольно, но недостаточно, чтобы оправдывать потраченное на сбор время. И мы забили на портфели. Все поменялось, когда мы приравняли проект в Asana к одной сделке в CRM-системе.
Раньше руководитель подписывался на все проекты и получал уведомления по всем изменениям в Inbox (ленту уведомлений). Каждое обновление статуса, новый комментарий отображались в ленте, начиная с самого нового. В понедельник руководитель садился и выполнял задачи из инбокса последовательно. О приоритетах речи не шло, до важных задач порой не доходили руки.
Теперь есть портфель сотрудника и портфель проектного отдела. В первом менеджер управляет своими проектами, второй дает руководителю контролирующий функционал по текущей загруженности всех сотрудников.
Портфель проектного отдела
На скриншоте вы видите отсортированные по сотрудникам проекты.
Раз в неделю проектный менеджер обновляет статус каждого проекта. Пишет, что было сделано за прошлую неделю и что планируется на следующей. Устанавливает один из трех тэгов: под контролем, в зоне риска, есть проблемы.
Руководитель быстро может оценить:
- текущий объем клиентов в проектном отделе,
- количество проектов в работе у каждого менеджера,
- число просроченных задач по проектам,
- наличие проблем и потребности включиться в проекты,
- дедлайны проектов, затраченное время, этап воронки и приоритетность проекта.
Портфели также помогают нам составлять отчетность. После обновления статуса проекта, отчет о проделанной и запланированной работе автоматически отправляется в чат с клиентом.
Портфель сотрудника
Собственный портфель есть даже у руководителя проектного отдела. Если, тьфу-тьфу-тьфу, он снимет с себя полномочия, новый человек увидит все подконтрольные проекты, которые он должен продолжать отслеживать.
Линейные сотрудники также оценили удобство планирования нагрузки в портфеле. В табе “Нагрузка” Asana анализирует объем задач с учетом дедлайнов и предупреждает, если сотрудник запланировал неподъемный объем задач. Менять дедлайны и корректировать детали можно не уходя из этой вкладки.
Решение багов и кастомная разработка
Отдельная команда отвечает у нас за разработку. К ней в рамках бизнес-процесса поступают задачи двух типов:
- баг,
- новая разработка.
Баги проверяет, оценивает на критичность и передает в работу служба техподдержки.
Задачи на разработку поступают либо из бэклога по внутренним продуктам компании, либо от проектного менеджера при наличии соответствующего запроса от клиента.
Процесс разработки, в целом, выглядит так.
Задачи падают на доску разработки в Asana. Вот она.
Постановщик задачи выбирает тип “Баг” или “Фича”, устанавливает степень критичности, указывает заказчика, внутренние отделы компании, которые затрагивает задача. Когда задача соответствует всем требованиям внутреннего регламента, постановщик нажимает на значок молнии в верхней панели над задачей и запускает автоматический бизнес-процесс “Оценить в разработке”.
Руководитель отдела разработки получает уведомление о новой задаче на оценку, сама задача на время оценки перемещается на отдельную одноименную доску.
После оценки руководитель перемещает задачу в спринт, соответствующий месяцу планируемого завершения. Задачи всегда находятся на нескольких досках одновременно:
- на личной доске проектного менеджера,
- на доске техподдержки,
- на доске разработки.
Все участники и контролирующие задачу сотрудники видят прогресс выполнения, получают уведомления, ведут обсуждение прямо в комментариях к задаче. Когда задача выполнена — проектный менеджер или ответственный специалист техподдержки “забирают” ее на свою сторону, чтобы продолжить работу в проекте.
Что получилось, когда мы вернули отделы разработки и производства в единую среду с командой?
Во-первых, клиентские проекты стали более долгосрочными. За счет постоянно пополняемого бэклога вырос средний чек.
Во-вторых, качество проектов сильно улучшилось, так как отдел разработки в любом момент мог задать вопрос маркетингу, продажам, аккаунтинг и т.д. Мы получили возможность вовремя подключать нужные компетенции команды и предлагать решения совсем другого уровня.
В-третьих, и сотрудники, и руководители, и клиенты получили полную прозрачность в запланированных и выполненных задачах. Мы научились УПРАВЛЯТЬ проектами, осознали, что это абсолютно технический процесс, из которого можно почти полностью исключить человеческий фактор.
В-четвертых, команда стала более сплоченной. Раньше сотрудники слабо представляли, чем занимаются мифические отделы разработки и производства.
Сейчас, видя процесс разработки и технической настройки систем:
- отдел продаж находит в нем идеи и вдохновение, как продавать,
- маркетологи регулярно берут полезный контент для постов, статей, позиционирования и рекламных текстов,
- руководители анализируют потребности и поведение клиентов, корректируя стратегию.
Получилась win-win-win трансформация, в которой выиграли и мы, и клиенты, и наши партнеры. Буду рад, если вы поделитесь мнением в комментариях: было ли что-то полезное в моей статье и какие методы управления проектами вы используете в разработке!
Источник: habr.com