Внедрение Asana для лидера рынка московского девелопмента

Строительство жилой недвижимости – сфера, в которой результат во многом зависит от того, насколько качественно компания управляет ходом проектов, рисками, сроками и бюджетом.

‍

Застройщики часто используют несколько инструментов для работы проектных команд, но сервисы и платформы для проектирования далеко не всегда синхронизированы между собой. Это создает дополнительные сложности в коммуникациях между проектными командами и подразделениями компании.

‍

К нам обратились Level Group – один из лидеров рынка московского девелопмента – с запросом на внедрение Asana для проектного управления. На тот момент в компании уже был инструмент для совместной работы инженеров и проектировщиков. Будем называть его сервис B, чтобы не путать вас. Так вот, важно было синхронизировать Asana с сервисом B.

‍

Особенности сервиса B

‍

Платформа, которую уже использовали в Level Group, обрабатывала тысячи задач по проектам. Нюанс заключался лишь в том, что она лишена возможности собирать аналитику. 

‍

Чтобы понять, кто в этом месяце молодец, а кто срывал дедлайны, нужно вручную внести статусы всех задач в Excel. Сотни и даже ТЫСЯЧИ задач… Звучит страшно, выглядит внушительно:

Логичный вопрос: можно ли связать сущности задач в текущем инструменте с задачами в Asana, чтобы смотреть аналитику по задачам в Asana? 

‍

Но реальность – жестока. У популярной платформы для проектировщиков есть API, но в нем нет необходимого для синхронизации функционала. 

‍

В компании более 500 сотрудников. На одной из встреч с командой ROCKET клиент поделился слайдом, иллюстрирующим работу всех, кто управляет проектированием на данный момент:

Картинка смешная, ситуация – не очень. Необходимо внедрить связующий инструмент, разработать кастом по интеграции сервисов Asana и сервиса B и, в итоге, выстроить работу основных подразделений Level Group в едином инфополе. 

‍

Боль образовалась без посторонней помощи, запрос силами команды клиента мы тоже сформулировали. Следующим шагом стало предпроектное обследование. Оно похоже на медицинское. Без тщательного осмотра пациента невозможно поставить диагноз и назначить лечение. Такой подробный «осмотр» необходим и в нашей сфере при внедрении новых инструментов в бизнес-процессы компании.

‍

Качественное обследование – половина дела

‍

Срок предпроектного обследования: 10 рабочих дней.

Менеджер проекта: Елена Андреенкова.

Цель проекта: оценка внедрения Asana (бизнесовой и технической частей), исследование возможных способов кастомной интеграции Asana и сервиса B.

‍

В компании Level Group 8 проектных групп, обособленных друг от друга и несинхронизированных внутри. Основная боль – отсутствие возможности постановки задач и работы над ними в едином инструменте. Большая часть задач приходит из почты, а контролировать их статус группам приходится в Excel. 

Чтобы актуализировать статус задачи, необходимо запросить данные у сотрудников в сторонних сервисах (почта, мессенджеры). Внести показатели можно только  вручную, статус конкретной задачи отследить невозможно.

‍

Со временем некоторые группы устали от неудобных таблиц и начали осваивать новые инструменты управления проектами. Так, например, одна из групп стала  применять ToDo: 

Здесь сотрудники хотя бы могли видеть свои задачи в виде списка, контролировать сроки и загруженность. Несмотря на явные преимущества ToDo перед таблицами Excel, инструмент не прижился. Не хватило возможности качественно контролировать ход проекта. 

‍

Другая группа для ведения задач по проектам стала применять Planner:

Но и данный инструмент имел свои недостатки:

• отсутствие вида отображение список/диаграмма Ганта,
• отсутствие возможности выводить отчетность по задачам,
• отсутствие возможности верхнеуровневого контроля проекта.

Руководитель департамента не мог оценить загруженность специалистов и снова возвращался к необходимости считать данные по задачам вручную. 

‍

Эксперты ROCKET выстроили последовательность шагов по внедрению Asana в подразделение по управлению проектированием:

Отдельным блоком выделили кастомную интеграцию. Нужно было реализовать решение, способное собирать аналитику по задачам, полученным сотрудниками из сервиса B на почту. 

‍

Задачи имеют 3 статуса, после перехода на новый статус в сервисе B на почту приходит уведомление. Мы предложили создать парсер писем с единого ящика. Интеграция  получает письма и, в зависимости от стадии, ответственного и должности в письме, создает в Asana задачи.

‍

Перейдем к внедрению Asana

‍

Срок внедрения: 40 рабочих дней.

Цель проекта: оцифровка деятельности подразделения по управлению проектированием с помощью Asana.

‍

Шаг 1: Создали оргструктуру подразделения в Asana

‍

Здесь один из важнейших шагов – анализ внешней и внутренней деятельности сотрудников. Потому что можно создать любую структуру проектов, но если распределение проектов некорректное, то команда в ней работать не будет. 

‍

Важно и то, что при правильном распределении проектов по группам будет легко настроить конфиденциальность этих проектов и распределить права доступа между сотрудниками.

‍

Шаг 2: Проработали шаблоны проектов в Asana

Единый шаблон для любого проекта. Где невозможно упустить важные детали или потеряться в последовательности конкретных задач. Все участники проекта видят прогресс по объекту и коммуницируют в одном инструменте.

Шаг 3: Создали проекты отделов

‍

С введением проектов такого типа появилась возможность контролировать и отслеживать:

• нагрузку отдела на текущий момент времени,
• загруженность специалистов отдела в сравнении друг с другом,
• огрузку по задачам  за определенный период,
• необходимость привлечения дополнительных ресурсов (сроки/бюджет/сотрудники).

Так, например, проект архитектурного отдела позволяет сотрудникам видеть задачи в разрезе необходимых периодов, фиксировать зависимости между задачами и оценивать нагрузку:

‍Шаг 4: Создали внутренние проекты подразделения

‍

Здесь были выстроены следующие проекты: проект совещаний/планерок, проект адаптации нового сотрудника к Asana, проект по обучению специалистов, база проектных документов.

‍

Шаг 5: Настроили автоматизации и дополнительный функционал в проектах

‍

Большое количество введенных кастомных полей позволяет видеть подробную информацию по статусу задачи/согласованию, бюджетам, времени. Правила автоматизируют перемещение задач в необходимую секцию в зависимости от статуса работ.

‍Шаг 6: Обучили сотрудников и взяли систему на сопровождение

‍

Данный шаг всегда предполагает проведение ряда обучающих семинаров для каждого из отделов. Первая часть – базовое обучение функционалу Asana. После этого мы проводим вебинары по методологии ведения проектов в Asana. 

Безусловно, после того, как бизнес-процессы отстроены и оцифрованы, мы упаковываем регламенты для команды клиента. Чтобы сотрудники могли быстро найти правильные ответы на возникающие у них вопросы. Все регламенты, инструкции и полезные материалы были объединены нами в базу знаний в Notion.

‍

Осторожно, кастом!

‍

Срок реализации кастома для Asana: 20 рабочих дней.

Цель проекта: разработка модуля «Парсер почты с Review».

‍

Какой бы сложной не была проблема синхронизации сервисов, всегда можно найти обходной путь. Наш кастом для сервиса B должен был получиться функциональным и простым в использовании. 

‍

Отвергнув несколько версий, мы пришли к простому, но максимально удобному решению: связать интеграцию и Asana через Google-таблицу. Чтобы наш клиент без привлечения разработчиков, мог самостоятельно вносить изменения в логику распределения задач в Asana:

Как это работает? Если кратко: каждые 2 минуты приложение с помощью парсера запрашивает письма, которые отвечают определенным критериям.

‍

После получения писем приложение отмечает их прочитанными, чтобы не отреагировать на них повторно. Далее каждое полученное письмо фильтруется на наличие в нем необходимой для создания задач информации.

‍

В отдельно вынесенную секцию в Asana интеграция помещает все задачи из сервиса B по объекту. Автоматически проставляется ответственный, его должность и стадия Review. В задачу добавляется описание и ссылка на саму задачу в сервис B:

Review может иметь 3 последовательных значения: Initial Review 1, Initial Review 2, Final Review. 

‍

Как только приходит задача с последующим типом Review, интеграция ищет все задачи с тем же названием и предыдущим типом Review. И автоматически закрывает их в Asana. А это значит, что несмотря на появление нового инструмента дублировать выполнение задач не нужно. Если задача закрыта в основном инструменте работы – сервисе B, она автоматически закроется и в Asana. 

Это позволяет по каждому проекту объекта собирать в Asana аналитику выполненных в сервисе B задач. 

‍

Кроме того, по каждому проекту появился набор настраиваемых дашбордов: 

В отдельных проектах можно видеть все входящие/исходящие задачи из сервиса B и их распределение по отделам. Это необходимо для контроля общего потока задач из Сервиса B: 

Что Было Дальше? 

‍

Внедрение, которое началось с одного подразделения, стало масштабироваться. Каждый в команде нашел в Asana свои плюсы. Отдел маркетинга, коммерческий отдел тоже обратились в ROCKET за обучением и советами по переходу в Asana. 

‍

Компании, использующие специальные программы для проектных работ зачастую не понимают, зачем внедрять дополнительные инструменты.  Да и сотрудники, радостно встречающие новый сервис, это что-то на фантастическом. 

‍

Как сказал один умный человек: «Неважно, насколько хороша ваша команда или как эффективна методология, если вы не решаете правильную проблему, то проект провалится». 

‍

Asana позволяет Level Group быть в курсе работы всей команды, расставлять приоритеты и контролировать процессы. А это значит, что компания может оперативно реагировать на критические изменения и поддерживать свою работу на самом высоком уровне.