Как структурировать десятки проектов и сотни задач с помощью одного софта
Я работаю в компании .io, мы создаем систему аналитики для медиа и интернет-магазинов. Количество пользователей, которые посещают сайты наших клиентов, превышает 100 млн человек в сутки. Trello стал именно тем инструментом, который позволил из b2b воронки получить «Макдональдс» — вы оставляете на кассе свой заказ, он попадает на кухню, где его приготовление происходит максимально быстро. Как мы прокачали Trello Trello известен своей простотой, и любой необходимый для работы хак нужно искать на стороне — в плагинах или интеграциях с их API. Мы же столкнулись с пулом задач, решения для которых создавались нами самостоятельно: 1. Создание новых задач с новыми проектами Когда на сайте нашего клиента появляется код для трекинга, карточка в Trello появляется автоматически — для этого мы используем API Trello и собственного бота — он проверяет появление данных с сайта клиента, которому был отправлен код для установки и который ранее нами не отслеживался. Новая задача — это зеленая карточка, к которой автоматически крепится менеджер и разработчик, добавляется дата (+1 день к текущей дате) и приоритет (важнее остальных). На выходе: у разработчика в пуле появляется заказ на проект, который нужно приготовить максимально оперативно. И разработчик, при фильтрации по себе, будет видеть именно свой стол заказов: Эх, не успел заскринить задачу в плане Джона, так как она уже в работе: И когда Джон закончит, то перетянет задачу на следующий этап — тестирование. Чертовски удобно! 2. Приоритеты для задачи По всем перечисленным ранее атрибутам мы считаем индекс важности задач. То есть красная карточка будет выше желтых пожеланий, а проблема проекта с посещаемостью 10+ миллионов будет более критичной, чем фикс проекта с посещаемостью до миллиона. А если у карточки еще и срок сдачи просрочен, то она будет пищать от необходимости быть сделанной. Используем следующие инструменты: API Trello и улучшение «Custom Fields», в которое пишем число приоритета. А дальше финал — запускается бот, который все задачи сортирует сверху вниз в зависимости от размера оценки. И эта перетасовка происходит каждые 10 минут, чтобы исправить то, что менеджеры и разработчики двигают задачи на свое усмотрение. 3. Автоматизация работы над задачами Да, мы, как и все, пытаемся избавиться от ручной работы над задачами, особенно когда настраивается новый проект с типичным набором отчетов в кабинете. Для этого мы реализовали команду ботов, которые работают так: Да, наши боты справляются не всегда, и мы всегда готовы им помочь. 4. Сдача кабинета клиенту Когда задача реализована и разработчик хотел бы ее протестировать, карточку с проектом переносят в список «Need to test». В этом списке за нее отвечает менеджер и принимает задачу с точки зрения клиента: сделано ли все корректно, не сломано ли все остальное. Если все действительно сделано правильно, то он переносит задачу в Done, как бы оставляя просьбу на выкатку решения. На данном этапе ответственность человека заканчивается. В этот момент просыпается еще один бот, разбуженный появлением новой карточки в своем логове. Он использует наше API и по названию проекта находит настройки этого проекта в коде и выкатывает свежие обновления на живой сайт. И да, еще один бот собирает письмо для клиента о том, что в его проекте были сделанные ранее согласованные изменения. Информацию про клиента он находит в нашей админке, где по названию проекта можно найти пользователей этого проекта и кто из них является администратором. Кстати, теперь, кажется, стало понятно, почему в названии задачи мы используем имя сайта, а не тайтл самой задачи. На последнем этапе бот архивирует карточку, и она пропадает с доски. 5. Аналитика Да, у Trello просто нет аналитики. Даже больше — он под это не заточен, так как не рассматривает задачу, отправленную в архив, как сделанную. А поскольку мы работаем с цифрами, и нам важно любой процесс измерять, нам было критично увидеть такие цифры: Какое количество проектов попадает в план, и сколько из них мы реализуем, Сколько времени мы тратим на выполнение задач, особенно по типам — зеленые, желтые или красные, Кто из разработчиков сколько делает задач и как быстро. В общем, все перечисленные вопросы — мелочи по сравнению с главным для нас вызовом: наш клиент должен получать решение в течение 1 дня. И любые препятствия на пути — менеджеры или разработчики, размер очереди задач или снижение скорости реакции — должны быть обнаружены раньше, чем они начнут влиять на конечный результат. Для измерения Trello мы использовали следующие инструменты: Google Spreadsheet Zapier Zapier — крутой сервис, который позволяет сделать интеграцию между различными системами, не обращаясь к разработчикам. Для мониторинга цифр по задачам мы сделали следующее: При появлении задачи в Trello в Spreadsheet приходит новая запись с названием проекта, именем автора задачи, датой создания задачи и ее цвет, При выполнении задачи (переносе ее в статус Done) запись с задачей обновляется, куда добавляется инфо о дате события и именем разработчика, который работал над задачей. А потом этот лог обрабатываем на уровне стандартных формул экселя, где по каждой задаче считается срок выполнения, а по каждому менеджеру и разработчику пишется их результативность. Пример графиков, которые получаются на выходе Количество задач, которые каждый день попадают в план и улетают из плана выполненными: Плохо, когда синий не перекрыт красным Количество задач каждого типа, которые попадают в наш план. Красный — это всегда плохо. Много красного — причина обратить внимание на всплески. А еще в нашем офисе висят мониторы, на которые выведено количество просроченных задач наших клиентов, причем по каждому разработчику. Статья со всеми советами → https://rb.ru/opinion/kak-ya-ispolzuyu-trello/ (Илья Рабчёнок) Зачем нужны Kanban-доски, когда есть Trello...
Клуб директоров: патриотические предприниматели
https://rb.ru/opinion/kak-ya-ispolzuyu-trello/
Как структурировать десятки проектов и сотни задач с помощью одного софта
Я работаю в компании .io, мы создаем систему аналитики для медиа и интернет-магазинов. Количество пользователей, которые посещают сайты наших клиентов, превышает 100 млн человек в сутки.
Trello стал именно тем инструментом, который позволил из b2b воронки получить «Макдональдс» — вы оставляете на кассе свой заказ, он попадает на кухню, где его приготовление происходит максимально быстро.
Как мы прокачали Trello
Trello известен своей простотой, и любой необходимый для работы хак нужно искать на стороне — в плагинах или интеграциях с их API. Мы же столкнулись с пулом задач, решения для которых создавались нами самостоятельно:
1. Создание новых задач с новыми проектами
Когда на сайте нашего клиента появляется код для трекинга, карточка в Trello появляется автоматически — для этого мы используем API Trello и собственного бота — он проверяет появление данных с сайта клиента, которому был отправлен код для установки и который ранее нами не отслеживался.
Новая задача — это зеленая карточка, к которой автоматически крепится менеджер и разработчик, добавляется дата (+1 день к текущей дате) и приоритет (важнее остальных).
На выходе: у разработчика в пуле появляется заказ на проект, который нужно приготовить максимально оперативно. И разработчик, при фильтрации по себе, будет видеть именно свой стол заказов:
Эх, не успел заскринить задачу в плане Джона, так как она уже в работе:
И когда Джон закончит, то перетянет задачу на следующий этап — тестирование. Чертовски удобно!
2. Приоритеты для задачи
По всем перечисленным ранее атрибутам мы считаем индекс важности задач. То есть красная карточка будет выше желтых пожеланий, а проблема проекта с посещаемостью 10+ миллионов будет более критичной, чем фикс проекта с посещаемостью до миллиона. А если у карточки еще и срок сдачи просрочен, то она будет пищать от необходимости быть сделанной.
Используем следующие инструменты: API Trello и улучшение «Custom Fields», в которое пишем число приоритета. А дальше финал — запускается бот, который все задачи сортирует сверху вниз в зависимости от размера оценки. И эта перетасовка происходит каждые 10 минут, чтобы исправить то, что менеджеры и разработчики двигают задачи на свое усмотрение.
3. Автоматизация работы над задачами
Да, мы, как и все, пытаемся избавиться от ручной работы над задачами, особенно когда настраивается новый проект с типичным набором отчетов в кабинете. Для этого мы реализовали команду ботов, которые работают так:
Да, наши боты справляются не всегда, и мы всегда готовы им помочь.
4. Сдача кабинета клиенту
Когда задача реализована и разработчик хотел бы ее протестировать, карточку с проектом переносят в список «Need to test». В этом списке за нее отвечает менеджер и принимает задачу с точки зрения клиента:
сделано ли все корректно,
не сломано ли все остальное.
Если все действительно сделано правильно, то он переносит задачу в Done, как бы оставляя просьбу на выкатку решения. На данном этапе ответственность человека заканчивается.
В этот момент просыпается еще один бот, разбуженный появлением новой карточки в своем логове. Он использует наше API и по названию проекта находит настройки этого проекта в коде и выкатывает свежие обновления на живой сайт. И да, еще один бот собирает письмо для клиента о том, что в его проекте были сделанные ранее согласованные изменения.
Информацию про клиента он находит в нашей админке, где по названию проекта можно найти пользователей этого проекта и кто из них является администратором. Кстати, теперь, кажется, стало понятно, почему в названии задачи мы используем имя сайта, а не тайтл самой задачи.
На последнем этапе бот архивирует карточку, и она пропадает с доски.
5. Аналитика
Да, у Trello просто нет аналитики. Даже больше — он под это не заточен, так как не рассматривает задачу, отправленную в архив, как сделанную.
А поскольку мы работаем с цифрами, и нам важно любой процесс измерять, нам было критично увидеть такие цифры:
Какое количество проектов попадает в план, и сколько из них мы реализуем,
Сколько времени мы тратим на выполнение задач, особенно по типам — зеленые, желтые или красные,
Кто из разработчиков сколько делает задач и как быстро.
В общем, все перечисленные вопросы — мелочи по сравнению с главным для нас вызовом: наш клиент должен получать решение в течение 1 дня. И любые препятствия на пути — менеджеры или разработчики, размер очереди задач или снижение скорости реакции — должны быть обнаружены раньше, чем они начнут влиять на конечный результат.
Для измерения Trello мы использовали следующие инструменты:
Google Spreadsheet
Zapier
Zapier — крутой сервис, который позволяет сделать интеграцию между различными системами, не обращаясь к разработчикам. Для мониторинга цифр по задачам мы сделали следующее:
При появлении задачи в Trello в Spreadsheet приходит новая запись с названием проекта, именем автора задачи, датой создания задачи и ее цвет,
При выполнении задачи (переносе ее в статус Done) запись с задачей обновляется, куда добавляется инфо о дате события и именем разработчика, который работал над задачей.
А потом этот лог обрабатываем на уровне стандартных формул экселя, где по каждой задаче считается срок выполнения, а по каждому менеджеру и разработчику пишется их результативность.
Пример графиков, которые получаются на выходе
Количество задач, которые каждый день попадают в план и улетают из плана выполненными:
Плохо, когда синий не перекрыт красным
Количество задач каждого типа, которые попадают в наш план. Красный — это всегда плохо. Много красного — причина обратить внимание на всплески.
А еще в нашем офисе висят мониторы, на которые выведено количество просроченных задач наших клиентов, причем по каждому разработчику.
Статья со всеми советами → https://rb.ru/opinion/kak-ya-ispolzuyu-trello/ (Илья Рабчёнок)
Зачем нужны Kanban-доски, когда есть Trello...