1. Ми і Trello
2. Стандарти роботи з планувальником завдань
3. Кожна картка - це проект зі своїми завданнями, і у кожної картки є свої атрибути. це:
4. Як ми прокачали Trello
5. 1. Створення нових завдань з новими проектами
6. 2. Пріоритети для завдання
7. 3. Автоматизація роботи над завданнями
8. 4. Здача кабінету клієнта
9. 5. Аналітика
10. Приклад графіків, які виходять на виході
11. Післямова

Я працюю в компанії .io , Ми створюємо систему аналітики для медіа та інтернет-магазинів. Кількість користувачів, які відвідують сайти наших клієнтів, перевищує 100 млн осіб на добу. А нашими клієнтами є такі відомі сервіси, як Business Insider, Рамблер, Vogue, Elle, De Telegraaf і інші.

Саме тому для управління завданнями нам потрібен Trello.

Ми і Trello

Всі питання, запити та побажання при кількості клієнтів в 1000+ проектів утворюють неслабкий потік завдань і запитів, які потрібно контролювати, делегувати на команду розробки і доводити до повної готовності.

Trello став саме тим інструментом, який дозволив з b2b воронки отримати «Макдональдс» - ви залишаєте на касі своє замовлення, він потрапляє на кухню, де його приготування відбувається максимально швидко.

Все це транслюється в статистику для подальшої оптимізації процесу. Нижче ми розповімо про свій досвід роботи з Trello - такий простий, але ефективною системою для вирішення наших завдань.

Стандарти роботи з планувальником завдань

Trello - це онлайн-дошка, яка використовується для ведення завдань у виробничій воронці.

Наша воронка містить наступні статуси:

• New / Update / Fix - це різні види завдань, подробиці будуть нижче,
• In progress - завдання, над якою йде робота в даний момент,
• Need to test - завдання на етапі тестування,
• Done - завдання готова,
• Live - завдання викачано на продакшн і відправлена ​​клієнтові.

Виглядає це так:

Кожна картка - це проект зі своїми завданнями, і у кожної картки є свої атрибути. це:

• Колір - маркер самого завдання:

1. Зелений - це новий проект, який встановив наш код, і його потрібно налаштувати і віддати клієнтові на тріальний період,
2. Жовтий - побажання клієнта по кабінету, тобто будь-який ви запросили оновлення,
3. Червоний - баг або скарга клієнта, які вимагають оперативного виправлення (хочемо жити без них, але не завжди виходить)

• Учасники - пара людей, які працюють над завданням в особі менеджера (постановника завдання) і розробника (виконавця).

• Термін - коли задача повинна бути зроблена,

• Кількість завдань за проектом - так, всередині кожної картки може бути пекельний список з пунктів,

• Пріоритет - є завдання, які потрібно зробити протягом 1 години.

Загалом, уявіть собі систему, яку ви використовуєте. І несподівано вам в голову приходить ідея чи побажання (гірше, якщо ви знаходите баг). Ви відкриваєте онлайн-чат, пишіть менеджеру свій запит, вам відписують стандартну відповідь в стилі «спасибі, розберемося». І ви думаєте про те, що відправили свої думки в нікуди, хоча продовжуєте мріяти про нове оновлення (або про виправлений баг). Але, раптово для вас, через 1-2 дня вам відповідають: «Готово, заходите - дивіться». Так, ідеальний світ існує!

Коротше, наш екран завдань не буває порожнім, сьогодні ми розібрали майже всю чергу. Але бувало в нашому житті і так:

Як бачите, ми використовуємо класичну в проектному менеджменті схему. Але далі - більше.

Як ми прокачали Trello

Trello відомий своєю простотою, і будь-який необхідний для роботи хак потрібно шукати на стороні - в плагинах або інтеграція з їх API . Ми ж зіткнулися з пулом завдань, вирішення для яких створювалися нами самостійно:

1. Створення нових завдань з новими проектами

Коли на сайті нашого клієнта з'являється код для трекінгу, картка в Trello з'являється автоматично - для цього ми використовуємо API Trello і власного бота - він перевіряє поява даних з сайту клієнта, якому був відправлений код для установки і який раніше нами не спостерігалося.

Нове завдання - це зелена картка, до якої автоматично кріпиться менеджер і розробник, додається дата (+1 день до поточної дати) і пріоритет (важливіше інших).

На виході: у розробника в пулі з'являється замовлення на проект, який потрібно приготувати максимально оперативно. І розробник, при фільтрації по собі, буде бачити саме свій стіл замовлень:

Ех, не встиг заскрініть завдання в плані Джона, так як вона вже в роботі:

І коли Джон закінчить, то перетягне завдання на наступний етап - тестування. Страшенно зручно!

2. Пріоритети для завдання

З усіх перерахованих раніше атрибутам ми вважаємо індекс важливості завдань. Тобто червона картка буде вище жовтих побажань, а проблема проекту з відвідуваністю 10+ мільйонів буде більш критичною, ніж фікс проекту з відвідуваністю до мільйона. А якщо у картки ще й термін здачі прострочений, то вона буде пищати від необхідності бути зробленою.

Використовуємо наступні інструменти: API Trello і поліпшення «Custom Fields», в яке пишемо число пріоритету. А далі фінал - запускається бот, який все завдання сортує зверху вниз в залежності від розміру оцінки. І ця перетасування відбувається кожні 10 хвилин, щоб виправити те, що менеджери і розробники рухають завдання на свій розсуд.

3. Автоматизація роботи над завданнями

Так, ми, як і всі, намагаємося позбутися ручної роботи над завданнями, особливо коли налаштовується новий проект з типовим набором звітів в кабінеті. Для цього ми реалізували команду ботів, які працюють так:

Так, наші боти справляються не завжди, і ми завжди готові їм допомогти.

4. Здача кабінету клієнта

Коли завдання реалізована і розробник хотів би її протестувати, картку з проектом переносять в список «Need to test». У цьому списку за неї відповідає менеджер і приймає завдання з точки зору клієнта:

1. зроблено все коректно,
2. не зламано чи все інше.

Якщо все дійсно зроблено правильно, то він переносить завдання в Done, як би залишаючи прохання на викочування рішення. На даному етапі відповідальність людину закінчується.

У цей момент прокидається ще один бот, розбуджений появою нової картки в своєму лігві. Він використовує наше API і з назви проекту знаходить настройки цього проекту в коді і викочує свіжі оновлення на живий сайт. І так, ще один бот збирає лист для клієнта про те, що в його проекті були зроблені раніше узгоджені зміни.

Інформацію про клієнта він знаходить в нашій адмінки, де з назви проекту можна знайти користувачів цього проекту і хто з них є адміністратором. До речі, тепер, здається, стало зрозуміло, чому в назві завдання ми використовуємо ім'я сайту, а не тайтл самого завдання.

На останньому етапі бот архівує картку, і вона пропадає з дошки.

5. Аналітика

Так, у Trello просто немає аналітики. Навіть більше - він під це не заточений, так як не розглядає завдання, відправлену в архів, як зроблену.

А оскільки ми працюємо з цифрами, і нам важливо будь-який процес вимірювати, нам було критично побачити такі цифри:

• Яка кількість проектів потрапляє в план, і скільки з них ми реалізуємо,

• Скільки часу ми витрачаємо на виконання завдань, особливо за типами - зелені, жовті або червоні,

• Хто з розробників скільки робить завдань і як швидко.

Загалом, всі перераховані питання - дрібниці в порівнянні з головним для нас викликом: наш клієнт повинен отримувати рішення протягом 1 дня. І будь-які перешкоди на шляху - менеджери або розробники, розмір черги завдань або зниження швидкості реакції - повинні бути виявлені раніше, ніж вони почнуть впливати на кінцевий результат.

Для вимірювання Trello ми використовували такі інструменти:

1. Google Spreadsheet

2. Zapier

Zapier - крутий сервіс, який дозволяє зробити інтеграцію між різними системами, не звертаючись до розробників. Для моніторингу цифр за завданнями ми зробили наступне:

1. При появі завдання в Trello в Spreadsheet приходить новий запис з назвою проекту, ім'ям автора завдання, датою створення завдання і її колір,

2. При виконанні завдання (перенесення її в статус Done) запис із завданням оновлюється, куди додається інфо про дату події і ім'ям розробника, який працював над завданням.

А потім цей лог обробляємо на рівні стандартних формул екселя, де по кожній задачі вважається термін виконання, а по кожному менеджеру і розробнику пишеться їх результативність.

Приклад графіків, які виходять на виході

Кількість завдань, які кожен день потрапляють в план і відлітають з плану виконаними:

Погано, коли синій не заблоковано червоним

Кількість завдань кожного типу, які потрапляють в наш план. Червоний - це завжди погано. Багато червоного - причина звернути увагу на сплески.

А ще в нашому офісі висять монітори, на які виведено кількість прострочених завдань наших клієнтів, причому по кожному розробнику.

Післямова

Як бачите, Trello знайшов відмінне застосування для вирішення поставлених цілей. Так, бували моменти, коли хотілося піти, попрощатися, взяти платні інструменти для ведення workflow і потонути в їх функціонал, благо на ринку їх безліч.

Але виявилося, що для рішень, які в Trello відсутні, можна знайти власні. А проста канбан-дошка, придумана для використання на заводах, може бути застосовна для ведення сучасних b2b проектів. Особливо коли постановниками задач є тисячі клієнтів.

Матеріали по темі:

Як визначити ціну IT-продукту, по якій його захочуть купувати все

Як виступати перед незнайомою публікою, щоб вас любили

Наш мозок створений не для того, щоб запам'ятовувати

Як перестати радитися ні про що, але бути в курсі всього

Зі старих батарей від ноутбуків можна зібрати акумулятор потужніший аналога від Tesla

Знайшли друкарську помилку? Виділіть текст і натисніть Ctrl + Enter