Автоматизация рутинных инженерных задач с помощью правил и интеграций Asana

Инженерные команды находятся под постоянным давлением, чтобы быстрее выполнять высококачественную работу. Тем не менее, большая часть их времени тратится на повторяющиеся административные задачи - назначение ошибок, обновление статусов, отправку напоминаний, погоню за одобрением. Эти обязанности, в то время как это необходимо, разрушают фокус и замедляют инновации. Asana, ведущая платформа управления работой, предлагает две мощные функции, которые могут вернуть потерянное время: правила и Интеграции . Автоматизируя рутинные инженерные рабочие процессы, команды могут уменьшить ручные накладные расходы, минимизировать ошибки и удерживать свое внимание на решении сложных проблем. В этой статье рассматривается, как проектировать, внедрять и масштабировать автоматизацию в Asana для создания более эффективной инженерной операции.

Понимание правил асан и их роль в инженерии

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

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

Помимо базовой автоматизации, Asana поддерживает многошаговые правила, которые объединяют действия в цепочку. Например, одно правило может создать последующую задачу, назначить ее рецензенту, добавить дату, а затем перенести оригинальную задачу в раздел «Обзор в прогрессе». Эта возможность позволяет командам кодифицировать целые процессы, не полагаясь на внешние скрипты или сторонние инструменты.

Ключевые инженерные рабочие процессы для автоматизации с помощью правил Asana

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

Сортировка и назначение жуков

Когда новый отчет об ошибках попадает в ваш проект, вы хотите, чтобы он сразу попал в руки правильного инженера. Создайте правило, которое запускает Задача Добавлено , когда задача имеет тег «Bug». Действие может автоматически назначить задачу ответчику ошибок по умолчанию (или члену команды на основе пользовательских значений поля, таких как «Приоритет» или «Компонент»). Вы также можете установить дату на основе тяжести — например, критические ошибки получают 4-часовой срок, в то время как низкоприоритетные получают 5 рабочих дней. Это гарантирует, что отчет не останется неназначенным.

Code Review - последующие действия

Узкие места в обзоре кода являются общим источником разочарования. Используйте правило, которое запускает, когда задача перемещается в раздел «Обзор». Правило может назначить задачу назначенному рецензенту, добавить дату 24 часа и отправить уведомление рецензенту через пользовательскую интеграцию (или сообщение Slack, если настроена интеграция Asana-Slack). Когда рецензент перемещает задачу на «Одобренное», другое правило может автоматически изменить статус на «Слияние» и назначить оригинальную задачу разработчику для развертывания.

Планирование спринта и подготовка к задаче

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

Выпущено: Note Generation

Сбор заметок о выпуске из разрозненных задач утомителен. Настройте Правило, которое запускает, когда задача перемещается в раздел «Сделано» или «Выпущено». Правило может автоматически скопировать заголовок задачи и описание в задание на выпуск документа или добавить его в запущенный список в отдельном проекте. Вы также можете установить условие для захвата только задач, помеченных «Фаурочность» или «Исправление», гарантируя, что ваши заметки о выпуске остаются чистыми и актуальными.

Автоматизированные напоминания о Standup

Ежедневные стендапы часто полагаются на ручные обновления, отправленные через Slack или по электронной почте. Вместо этого настройте Правило, которое работает каждое утро (используя Правила синхронизации с расписанием), чтобы создать задачу в проекте «Standup» для каждого члена команды, с надлежащим временем встречи стендапа. Задача может содержать такие подсказки, как «Что я сделал вчера», «Что я сделаю сегодня» и «Блокеры». Инженеры заполняют свои обновления непосредственно в Asana, и менеджер проекта получает единое представление о прогрессе команды, не преследуя никого.

Интеграция Asana с инженерными инструментами

В то время как Правила обрабатывают автоматизацию в Asana, интеграции подключают Asana к внешним инструментам, которые уже использует ваша команда — GitHub, GitLab, Jira, Slack, Bitbucket, CircleCI и т. д. Эти интеграции позволяют синхронизировать данные двунаправленно, поэтому действия, предпринимаемые в одной системе, автоматически отражаются в Asana и наоборот.

GitHub и интеграция GitLab

Официальные ссылки Asana для интеграции GitHub (и его аналог GitLab) фиксируют, ветвляют, вытягивают запросы и развертывают в задачи Asana. Когда разработчик передает сообщение, которое включает URL задачи Asana, интеграция автоматически добавляет комментарий к задаче со ссылкой на обязательство. Когда запрос на вытягивание объединен, Правило может затем переместить задачу на «Готов к QA» или «Сделано». Это устраняет необходимость в том, чтобы инженеры вручную обновляли статусы задач после изменения кода. Например, разработчик, работающий над функциональной задачей, просто ссылается на задачу в своем сообщении о выполнении, а интеграция делает остальное.

Slack интеграция для уведомлений

Slack является коммуникационным центром для многих инженерных команд. Интеграция Asana + Slack позволяет получать напоминания о задачах, запросы на одобрение и обновления статуса непосредственно в ваших каналах. Используйте его для уведомления всей команды при подаче приоритетной ошибки или отправки прямого сообщения инженеру при назначении задачи обзора кода. Вы также можете создавать задачи Asana из сообщений Slack, превращая специальные запросы в отслеживаемую работу, не выходя из чата.

Подключение через Zapier или Make (ранее Integromat)

Для более сложных интеграций, не охваченных встроенными разъемами Asana, используйте платформу автоматизации без кода, такую как ]Zapier или . Эти сервисы позволяют запускать действия Asana на основе событий в тысячах других инструментов — например, автоматически создавать задачи Asana для каждой новой проблемы GitHub или обновлять поля задач Asana, когда развертывание завершается в CircleCI. Zapier и Make также поддерживают условную логику и преобразования данных, позволяя выполнять расширенные рабочие процессы, которые не могут обрабатываться только правилами Asana.

Jira и Asana Sync

Команды, мигрирующие из Джиры или поддерживающие гибридную среду, могут использовать двухстороннюю интеграцию Джиры Asana. Она синхронизирует статусы задач, комментарии и правопреемников между двумя системами. Когда разработчик обновляет билет Джиры, соответствующая задача Asana обновляется автоматически и наоборот. Это особенно полезно, когда разные команды (например, разработка и продукт) предпочитают разные инструменты, но нуждаются в одном источнике истины для отслеживания проекта.

Пошаговое руководство по установлению правил и интеграции

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

Создайте свое первое правило

  1. Перейдите к проекту, где вы хотите запустить Правило.
  2. Нажмите на вкладку Правила в верхней части страницы проекта (возможно, вам потребуется включить его в настройках проекта, если он не виден).
  3. Нажмите + Добавьте Правило и выберите шаблон (например, «Задачи автоматического назначения») или начните с нуля.
  4. Определите триггер : Общие триггеры включают в себя «Task add», «Task completed», «Task moved to section» или «Task due date assigned».
  5. Необязательно добавлять условия: Например, выполняться только тогда, когда задача имеет конкретную метку, значение пользовательского поля или цессионария.
  6. Установите действия : Вы можете назначить задачу, установить дату, добавить шаблон подзадачи, изменить пользовательское поле, перенести задачу в раздел или отправить уведомление.
  7. Назовите Правило и переключите его. Проверьте его, добавив задачу образца, которая соответствует условиям запуска.

Связывание интеграции (например, GitHub)

  1. Из меню профиля Asana перейдите в Настройки моего профиля > Приложения и усилители; Интеграции > Добавить приложение .
  2. Нажмите кнопку «GitHub» и нажмите Добавить .
  3. Следуйте по потоку авторизации, чтобы подключить свою учетную запись GitHub.Возможно, вам нужно будет выбрать, какие репозитории или организации подключить.
  4. После подключения любое сообщение о совершении, которое включает в себя URL задачи Asana (например, ), автоматически добавит комментарий к этой задаче.
  5. Для более глубокой автоматизации, объедините интеграцию с Правилом: например, когда комментарий задачи добавляется из GitHub pull request merge, переместите задачу в раздел «Обзор кода».

Продвинутые: многошаговые правила и условная логика

Asana теперь поддерживает ветви в Правилах, позволяя выполнять различные действия в зависимости от данных задачи. Для создания многоступенчатого правила используйте опцию «Добавить другой триггер или действие». Например, если отчет об ошибке помечен «Критический», назначьте его инженеру по вызову и установите дату до 4 часов; если помечено «Низкий», назначьте его владельцу заднего ряда и установите дату до 30 дней. Вы также можете добавить промежуточные шаги, такие как «Ждите обновления пользовательского поля». Проверить эти правила с различными входами, чтобы убедиться, что все пути работают правильно.

Расширенные схемы автоматизации для инженерных команд

Как только вы будете довольны основными правилами и интеграцией, рассмотрите эти шаблоны, чтобы нарастить ваши рабочие процессы.

Утверждение рабочих процессов с пользовательскими правилами

Многие инженерные процессы требуют одобрения — например, архитектурные решения, изменения базы данных или развертывание производства. Создайте правило, которое запускает, когда задача перемещается в раздел «В ожидании одобрения». Правило присваивает задачу группе одобрения, добавляет дату (например, 2 рабочих дня) и публикует уведомление в специальном канале Slack. Когда задача перемещается в «Одобренное», второе правило может перенести задачу на «Готовность к выполнению» и назначить ее обратно запрашивающему. Если дата выполнения проходит без действий, правило может обостриться, переназначив менеджеру.

Отпуск и развертывание Gates

Чтобы предотвратить релизы без всех проверок, установите Правило, которое отслеживает контрольный список релизов. Например, когда задача релиза перемещается в «Готов к развертыванию», Правило может потребовать, чтобы все подзадачи (например, «Прошло QA», «Проверено безопасность», «Обновлен блог») были завершены, прежде чем разрешить задачу двигаться дальше. Если какая-либо подзадача остается открытой, Правило может автоматически переместить задачу обратно в «Предварительное развертывание» и уведомить менеджера релиза.

Автоматическая посадка на борт для новых инженеров

Когда присоединяется новый инженер, вам нужен постоянный опыт входа. Создайте проект, который содержит все задачи входа (например, «Установить среду разработки», «Читать командную книгу», «Встреча с наставником»). Затем установите правило, которое запускает, когда новый член добавляется в команду (через пользовательское поле или изменение членства), чтобы автоматически назначить эти задачи входа на новый прокат и установить относительные сроки. Это гарантирует, что ни один шаг не пропускается, даже в периоды занятости.

Межпроектные зависимости

Правила Asana в настоящее время работают в рамках одного проекта, но вы можете имитировать автоматизацию кросс-проекта с помощью правил + пользовательских полей в сочетании с Многодомашняя (задача, появляющаяся в нескольких проектах). Например, если у команды бэкэнда есть задача, которая блокирует функцию интерфейса, добавьте бэкэнд-задачу в проект интерфейса через Multi-Home. Затем установите правило в проекте интерфейса, которое запускает, когда пользовательское поле задачи «Блокировка статуса» изменяется на «Решено» — перемещая задачу интерфейса на «Готов к интеграции».

Лучшие практики для устойчивой автоматизации

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

  • Начните с малого и повторите. Автоматизируйте один рабочий процесс за раз. Проверяйте тщательно перед развертыванием всей команде. Сложные автоматики могут иметь непредвиденные последствия, поэтому внимательно следите за ними в течение первых нескольких недель.
  • Документируйте каждое Правило и интеграцию. Сохраняйте живой документ (либо в самой Асане, либо в вики), который объясняет, что делает каждое Правило, почему оно существует и кто его поддерживает. Это помогает новым членам команды понять систему и предотвращает запуск правил «призрака», не зная, почему.
  • Использовать соглашения об именах. Применять Правила к категории или ответственному лицу (например, «Сортировка ошибок: автоматическое назначение критических ошибок»).
  • Проверка автоматизации ежеквартально. По мере развития процессов вашей команды некоторые правила могут устареть или нуждаться в корректировке. Запланируйте повторный обзор для очистки неиспользуемых правил и обновления условий или действий в соответствии с текущими рабочими процессами.
  • Настройка мониторинга и оповещения. История правил Asana показывает вам каждый раз, когда выполняется правило. Проверяйте это периодически, чтобы поймать ошибки (например, правило, которое срабатывает тысячи раз из-за цикла). Для автоматизации с высокими ставками рассмотрите возможность использования выделенного канала Slack для выполнения правил журнала.
  • Вовлеките всю команду. Автоматизация должна быть прозрачной. Спросите инженеров о правилах — экономят ли они время или вызывают путаницу? Когда вы вводите новое правило, объявляйте его на собрании команды и предоставляйте простой способ отключить его, если это вызывает проблемы.

Измерение влияния автоматизации

Чтобы оправдать продолжающиеся инвестиции в автоматизацию и определить области для улучшения, вам нужно измерить ее эффекты.

  • Время, сэкономленное за неделю. Оцените ручное усилие, которое заменил каждый автоматизированный рабочий процесс. Например, если сортировка ошибок занимала 30 минут в день, а теперь это мгновенно, это 2,5 часа, сэкономленных за неделю. Умножьте все правила, чтобы получить общую сумму.
  • Сравните частоту неправильно назначенных задач, пропущенных сроков или неполных передач до и после автоматизации. Даже небольшое улучшение может оказать большое влияние на моральный дух команды.
  • Время цикла. Измерьте время от момента создания задачи до момента её завершения. Автоматизация часто ускоряет передачу данных между инженерами, рецензентами и QA, поэтому вы должны увидеть сокращение времени цикла для автоматизированных рабочих процессов.
  • Удовлетворенность команды. Периодически обследуйте своих инженеров. Спросите, сколько времени они тратят на «накладные расходы» против «реальной работы». Снижение жалоб на административные задачи является сильным показателем того, что ваша автоматизация работает.
  • Ошибки выполнения правил. Мониторинг истории правил Асаны на наличие сбоев. Если правило последовательно терпит неудачу (например, из-за отсутствующих полей или неправильных тегов), это создает разочарование, а не экономит время. Следите за ними и исправляйте их быстро.

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

Начало работы: быстрый план действий

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

  1. Оцените текущие рабочие процессы. Перечислите все повторяющиеся задачи, которые ваша команда выполняет ежедневно или еженедельно. Определите, какие из них основаны на правилах и предсказуемы (идеально подходят для автоматизации) по сравнению с теми, которые требуют человеческого суждения.
  2. Приоритизируйте быстрые победы. Начните с простой, высокоэффективной автоматизации, такой как автоматическое назначение новых входящих ошибок. Это дает вашей команде немедленное облегчение и создает бай-ин.
  3. Установите необходимые интеграции. Подключите Asana к GitHub, Slack и любым другим инструментам, которые ваша команда использует ежедневно. Используйте официальные разъемы, где это возможно, и добавьте Zapier/Make только при необходимости.
  4. Обучите свою команду. Покажите инженерам, как работают правила и как они могут создавать свои собственные. Наделите их полномочиями автоматизировать свои повторяющиеся задачи, не всегда полагаясь на менеджера проекта или администратора.
  5. Итерировать и расширять. Как только начальная автоматизация стабильна, перейти к более сложным шаблонам, таким как рабочие процессы утверждения или зависимости от кросс-проекта.

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

Для дальнейшего чтения обратитесь к официальной документации и . Если вам нужно подключить инструменты, которые не поддерживаются нативно, ]Интеграция с использованием Zapier Asana предоставляет пошаговые инструкции для тысяч комбинаций приложений.