Що робити, коли на дейлі-мітингу немає оновлень. Шпаргалка для менеджера та розробника
Привіт, мене звати Северин, більше шести років я працюю в ІТ та близько року в ролі Scrum Master — встиг набратися досвіду і як розробник, і як проєктний менеджер.
Часто буває, що у дуже контрольованому середовищі під час звітування новачки губляться в поточному стані завдань і не знають про що розповідати. У матеріалі хочу висвітлити цю поширену проблему та можливі шляхи її розв’язання.
Стаття розрахована на широке коло читачів, може зацікавити як початківців у менеджменті, так і розробників, тестувальників і людей, які не займаються ІТ.
Ілюстрація Аліни Самолюк
Види мітингів
Щоб відповісти на питання, «як проводити дейлі-мітинги, коли нема оновлень», варто спершу розбити його на блоки. Почнемо з дейлі-мітингів. Що це взагалі таке?
Якщо ми працюємо з класичним (Waterfall) менеджментом, дейлі-мітинг — це радше статус-мітинг, де кожний член команди доповідає проєктному менеджеру про стан виконання тої чи іншої задачі, а він уже перевіряє, чи все йде за планом і чи все гаразд. Якщо щось не так, вносяться корективи в план. Або відразу, якщо змін небагато, або вже після зібрання разом з працівником чи без нього.
Якщо ми говоримо про адаптивне (Agile) середовище, ці мітинги вже є не просто статус-мітингами. Правильніше їх назвати дейлі-синкапами. Тут уже не проєктний менеджер приймає роботу, а команда. Чому саме так? Тому що в Agile-середовищі позиція PM відсторонена від команди розробників/виконавців. Відповідальність за виконання зміщена від PM у бік команди та власника продукту. Саме команда найбільше зацікавлена в тому, щоб робота була зроблена вчасно та якісно. Тому синкап — це синхронізація насамперед колективу.
Розібралися. А тепер перейдімо до оновлень. Тут усе просто: це актуальна інформація щодо виконання завдань.
Отже, синкап-мітинг — це перевірка стану виконання завдань на проєкті усередині команди, в якому мають бути зацікавлені всі учасники. Але найголовніше — має бути розуміння, чи рухаємося ми в правильному напрямі під впливом динамічного середовища.
Що таке апдейт
Як люди прогресивні припустімо, що ми все-таки працюємо і живемо за принципами Agile (навіть якщо ви працюєте в традиційній системі). У такому разі щодня ми ставимо собі чи принаймні маємо ставити такі три запитання:
- Що зробив учора?
- Що буду робити сьогодні?
- Чи є щось, що не дає мені досягти поставленої цілі?
Ці три питання є сакральними. Вони дають базу для роздумів: чи справді мені немає що сказати на дейлі-синкапі?
Йдемо далі. Що означає «немає апдейтів»? За останню добу чи від останнього мітингу нічого не відбулося на проєкті? Чи немає оновлень, бо не просунувся далі в роботі, або немає що показати, адже ще працюю над завданням? Ось у цьому велика різниця!
Нічого не робив? Тоді в нас проблема. Або менеджмент/команда не дала роботу, або член команди нічого не хотів виконувати. Тут уже треба розбиратися, та загалом це не тема нинішньої публікації.
Задача ще не зроблена? Можливо, не просунувся в роботі, але старався і пробував варіанти? Це теж важливо. Наприклад:
- Намагався вирішити, але не вдалося.
- Не зробив, бо був заблокований чимось.
- Нема апдейтів, бо ще в роботі.
- Не готово через особисті причини тощо.
Тут висновок такий: будь-яка інформація може бути корисною, якщо на неї глянути під правильним кутом.
А тепер до кейсів
Розгляньмо вищезгадані приклади докладніше.
Намагався вирішити, але не вдалося. З цього можемо щонайменше з’ясувати, яким шляхом неможливо розв’язати задачу, та поділитися цим з іншими членами команди, додати інформацію у так званий Lesson Learned, щоб надалі розуміти, де і як не варто шукати вирішення.
Але також не треба забувати про зворотний зв’язок від розробника/виконавця. Перед виконанням будь-якої задачі необхідно впевнитися, що є мінімум три складники для роботи: чіткі вхідні дані, чітке розуміння результату й термін виконання задачі. В цьому разі треба переконатися, чи розробник розуміє, як виконувати завдання. Якщо так, ставити дедлайн. Якщо ні, варто розбити його на етапи. Можливо, в процесі чергового синкапу комусь спаде на думку ідея розв’язання питання на основі вже готового дослідження.
Не зробив, бо був заблокований чимось. Класичний випадок. Скільки разів ви були змушені чекати на те, щоб вас розблокували. Наприклад, на код-рев’ю, вхідні дані від клієнта або система не працювала тощо. Як правило, нас можуть блокати банально через те, що контрагент (людина, якій передане завдання) не до кінця розуміє пріоритет завдання або з тих чи інших причин забув його виконати. З ким не буває?
Тут можна зробити важливий висновок: ви відповідаєте за завершення задачі, яку на вас поставили. Якщо ви залежите від когось, це у ваших інтересах і ваш обов’язок нагадувати та пояснювати пріоритет завдання і наслідки, які можуть бути в разі затримки. Якщо контрагент не реагує, треба це питання передавати вище.
Ще один варіант ефективно використовувати час — мати запасні задачі, так звані Stretch Objectives. Тобто якщо ви заблокані або швидко закінчили першочергові таски, щоб не сидіти без діла, беріться до виконання запасних.
Немає апдейтів, бо ще в роботі. Всі ми працюємо в динамічному середовищі. Іноді це негативно впливає на роботу, а саме на процес виконання задач і результат.
Якщо на початку проєкту, під час планування, все виглядало по-одному, то за час виконання дещо, на перший погляд, неважливе може змінитися. Тому, якщо на дейлі-синкапі все-таки зачепити тему виконання поточної задачі, пояснити, що зараз відбувається, на якому етапі розробка тощо, тоді команда може вчасно звернути увагу на певний нюанс, який радикально змінить курс до правильного розв’язання задачі. Ця зміна може бути критичною і саме вона допоможе видати вкінці той продукт, який підходить під уже змінені, динамічні умови. Тому апдейти завжди є, але необов’язково з боку виконання.
Не готово через особисті причини. Усі ми живі люди, і кожен крутиться у своєму світі. Але, як і в попередньому випадку, оновлення можуть бути необов’язково з боку виконавця. Хтось може сказати, що взяв у роботу його завдання. І ось ця людина починає працювати над задачею та з’ясовується, що умови дещо змінилися або вже є новіша версія вихідних матеріалів для роботи тощо. Тому важливо звертати увагу не лише на себе як виконавця, а й на середовище, в якому задача буде виконуватися.
Кейсів ще є багато, але тут вирішив висвітлити ті, що першими спали на думку та які часто трапляються.
Шпаргалка для керівника-початківця
Для людини на менеджерській посаді дуже важливо бачити рух, тенденції, здорову робочу атмосферу в команді. А коли ж це побачити як не на дейлі-мітингу? На початку зустрічі зробіть перший крок, задайте тон синкапу. Наприклад, спитайте: «Як ваші справи» або «Чи бачили ви презентацію нового гаджета?». Буквально дві-три хвилини, постарайтеся розговорити людей. Цілком ймовірно, що команда підхопить ініціативу і розмова зав’яжеться, а там і синкап, і подальше обговорення.
Мені на початку менеджерської кар’єри було непросто це зробити — розпочати вдало дейлі, задати правильний тон. Особливо в молодих, ще не сформованих або тимчасових командах. Я старався все контролювати та вести мітинги — одне слово, більше говорив я. Але з часом зрозумів, що команду треба «відпустити» — розігріти та тримати в робочому тонусі, запропонувати місце, де колеги бачитимуть поточний стан справ (наприклад, Kanban-дошка та прості для сприйняття графіки, навіть в Excel), але дати їм свободу — і вони самі себе поведуть. Завдання менеджера — лише модерувати «плавання». Десь читав фразу, що менеджер має говорити менше, ніж команда. Щось у цьому є.
Створіть комфортні умови для співробітників: щоб було почуття впевненості, підтримки з боку колег і простір для професійного розвитку. Тоді команда буде ефективною та самодостатньою.
Висновок
Незалежно від того, чи ви член команди, чи перебуваєте на менеджерській позиції — завжди будьте проактивними в комунікації. Пам‘ятайте, що важливо повідомляти не лише позитивний, а й негативний результат. Будьте в курсі роботи інших учасників хоча б поверхово. Тоді завжди буде що сказати на зібраннях.
Планувати, аналізувати та адаптуватися — це правильний шлях до досягнення успіху. А без ефективної комунікації, особливо на дейлі-синкапах, не буде основи ні для аналізу, ні для адаптації.
Якщо вам цікаво спілкуватись або бажаєте бути в контакті, додавайтесь в LinkedIn або читайте мене на Medium.
Щоби не пропустити нові статті Северина Рибчинського — підписуйтеся на нього у телеграм-боті Стрічки DOU.
