Организовать бизнес-процессы в компании с помощью Asana - опыт Mobio
Генеральный директор мобильного агентства Mobio Алексей Писаревский рассказал vc.ru, как его команда приспособила Asana для своих задач, почему Due date - это не дедлайн, а срок начала работы над проектом и для каких нужд лучше подходят другие сервисы.
В мире огромное количество систем управления проектами, корпоративных таск-менеджеров и прочего софта для совместной работы команд. Споры о том, какая система лучше, можно вести бесконечно, но каждая команда в итоге выбирает то, что подходит конкретно ей. Многие так и не находят подходящего для себя решения и начинают «пилить» свое. По нашему опыту, значение имеет не столько сам сервис, сколько философия и использование бизнес-процессов в нем.
Хочу поделиться опытом, как мы в Mobio используем Asana - лучший, как нам кажется, инструмент для совместной работы команд. У нас довольно классический бизнес по B2B-обслуживанию, поэтому, думаю, наш опыт организации совместной работы многим будет полезен.
Немного расскажу про наш бизнес, чтобы было понятно, для кого это релевантно. У нас классическое рекламное агентство, мы занимаемся продвижением мобильных приложений. Есть менеджеры по продажам, аккаунт-менеджеры и менеджеры проекта. Есть подразделения, отвечающие за трафик, есть отдел внутренней разработки.
Asana у нас используют все отделы. Биздевы и аккаунты - в качестве CRM-системы. Отдел разработки - для планирования еженедельных спринтов и для багтрекинга. Даже удаленную бухгалтерию подключили для взаимодействия с менеджерами. Свои личные задачи я тоже ставлю себе в Asana: очень удобно, когда все в одной системе.
Всего в команде сейчас 35 человек. Начинали использовать Asana, когда было 15. Слышал мнение, что командам из 100 человек и больше Asana уже не хватает. Но думаю, что это вопрос подхода и организации работы. За 35 сотрудников мы платим $400 в месяц (когда их было меньше 30, платили $200). Кажется, что дорого, - но по сравнению с фондом оплаты труда или с арендой офиса это копейки.
Конечно, все компании разные, но Asana - настолько гибкий инструмент, что почти любая компания сможет его у себя внедрить и использовать. Вот ключевые принципы, которые используем при работе с Asana мы:
- У любой задачи, требующей действия, должен быть срок исполнения - Due date.
- Эта дата не должна быть в прошлом.
- Не успел сделать сегодня - переносишь дедлайн и пишешь комментарий.
Due date, вообще говоря, переводится как дедлайн, но в нашем случае это не день, когда задача должна быть сделана, а день, когда мы собираемся к задаче приступить.
Мы так решили потому, что у большинства задач нет строгого дедлайна. Написать письмо, заключить договор с клиентом, сделать новую презентацию - на самом деле, нет четкого срока, когда это надо сделать. Никто не умрет, если все это сделать завтра, а не сегодня. Поэтому поле Due date у нас в Asana логичнее было бы назвать Start date.
Поясню на примере, как это работает. Допустим, я познакомился на конференции с клиентом A и мы договорились запустить рекламную кампанию. Я ставлю аккаунт-менеджеру задачу с заголовком «Начать работать с клиентом A» и ставлю Due date на завтра. В теле задачи коротко описываю суть.
На следующий день аккаунт-менеджер открывает компьютер и видит у себя в списке Today мою задачу «Начать работать с клиентом А». Понятно, что задача «Начать работать» не делается за один день. Это целый процесс, который состоит из этапов: заключить договор, прояснить детали рекламной кампании, запустить кампанию и так далее.
Аккаунт-менеджер делает первый шаг - отправляет клиенту договор и бриф и пишет об этом в комментарии к задаче. Переносит Due date на два дня вперед. Через два дня эта задача снова будет у него в списке Today. Если клиент к этому времени не ответит, то аккаунт-менеджер отправит напоминание или позвонит. Если ответит раньше и завяжется переписка - менеджер добавит комментарий «Согласовываем договор и детали рекламной кампании» и снова перенесет Due date на несколько дней вперед.
Что дает такой подход
У меня не болит голова о том, чтобы контролировать поставленную задачу. Я точно уверен, что про нее не забудут и в итоге договор будет заключен. Если по ходу возникнут какие-то трудности, я буду в курсе.
Кроме того, в своем инбоксе я вижу, как идут дела по поставленной задаче. Эта информация приходит в виде push-уведомления - мне не надо помнить, что нужно куда-то зайти и узнать, что там с задачей, которую я поставил две недели назад. Если захочется остановить поток новостей по этой задаче, я всегда могу нажать Unfollow. Аккаунт-менеджеру тоже очень удобно: все его задачи находятся в одном месте, и он не забывает ничего важного.
С этим методом мы вообще перестали пользоваться электронной почтой для внутренней коммуникации. Любое письмо или сообщение легко оформляется в виде задачи. Приведу примеры, как мы это делаем для разных типов задач.
CRM. Воронка входящих лидов
Задачи в Asana очень удобно организовывать в проекты и секции. Когда аккаунт-менеджер получает от меня задачу «Начать работать с клиентом А», он должен поместить эту задачу в проект «Входящие лиды», в секцию «Входящие». В эту воронку автоматически попадают все заявки с сайта. Вот как это выглядит:
Разумеется, подобная CRM-система выполняет только функции таск-менеджера. Все данные о рекламных кампаниях клиентов, закрывающие документы и прочие цифры у нас хранятся уже не здесь, а в отдельной системе, которую мы написали сами.
Организация встреч, совещаний и брейнштормов Планирование разработки
В начале каждого квартала мы определяем для отдела R&D, что нам важно сделать. Затем отдел разработки раскидывает задачи по еженедельным спринтам.
Прелесть Asana в том, что одна и та же задача может быть сразу в нескольких проектах. Например, задача на скриншоте находится в еженедельном спринте, и в то же время это стратегическая задача на квартал. Когда мы отметим, что она выполнена, или внесем в нее изменения, она поменяется сразу в обоих проектах.
Справочная информация
Любая информация, не требующая конкретного дейтствия, оформляется в виде задач без дедлайнов, которые ни на кого не назначены. Благодаря структуре проектов и секций получается что-то вроде вики-разметки.
Справедливости ради стоит сказать, что совсем большие массивы информации мы выносим в отдельные интеллект-карты.
Просьбы ознакомиться с информацией
Любое письмо, предложение, сообщение ставится в виде задачи на конкретного человека с дедлайном. После того как человек ознакомился с информацией, он пишет комментарий и возвращает задачу.
Регулярные задачи
Например, у аккаунт-менеджера есть еженедельная задача - подготовить отчет по качеству трафика у своих клиентов. После каждой проверки он пишет комментарий и переносит дедлайн на неделю вперед.
Что мы выносим за рамки Asana
Конечно, Asana - очень гибкий и мощный инструмент, но все-таки мы делаем в ней не все. Вот несколько примеров, как мы используем другие сервисы:
- Оперативные обсуждения ведем в Slack. При этом у нас принципиально бесплатная версия Slack, которая не сохраняет историю. Это сделано не только в целях экономии, но и для того, чтобы не дублировать сущности. Хочешь, чтобы данные сохранились, - пиши в Asana, там не пропадет.
- Храним документы и совместно над ними работаем в Google Drive. Отдельная тема - как с помощью табличек в Google Drive мы построили целую систему управленческого учета и довольно долго с ней жили, пока не автоматизировали. Календарь мероприятий у нас раньше был в Asana, а потом мы решили вынести его отдельно, а заодно сделать общедоступным.
- Созваниваемся в Google Hangouts, встречи назначаем в Google Calendar. Многие люди у нас несколько дней в неделю работают из дома, а некоторые сотрудники - полностью удаленно из других городов.
Вместо заключения
Основное преимущество Asana - это, конечно, безумная простота использования. Создать задачу тут так же быстро и легко, как написать сообщение в мессенджере. Не надо никого заставлять ей пользоваться - это происходит само собой.
Благодаря гибкой системе проектов и подзадач Asana превращается в очень мощный и универсальный инструмент коллаборации, который при правильном использовании подойдет почти любому бизнесу.
