Сергій Тишинський працює в Laba проєктним менеджером IT-відділу півтора року. Він курує роботу команди з 19 людей та 27 продуктів, серед яких ордер-сервіс, юзер-сервіс, банк-репорт, аналітика, LMS-системи та 21 продуктовий сайт Laba Group на українському та закордонних ринках.
У колонці для Laba Сергій пояснює:
— як подружити тривалий SDLC з високою швидкістю розвитку продукту
— чому пакувати спринт на 100% — не найкраща ідея
— чому якщо задача займає три години роботи, він віддає її за три дні
В Asana отримую таски, у Jira — делегую на виконавців
Для планування я використовую лише дві платформи — Asana і Jira. Я сам приймаю задачі, пріоритизую їх та делегую далі у виконання. Крім того, я ніколи не пропускаю обговорення задач, бо маю бути в контексті всього, що відбувається.
Asana зручна, бо має багато інструментів саме для пріоритизації. Не останній аргумент на її користь — наявність історії за кожним таском, що дозволяє уникнути непорозумінь.
Колись був випадок: ми зробили задачу, а замовник прийшов і каже, що працює не так. Я кажу: «Гаразд, давай в Asana дивитися. Ось цей пункт, ми виконали його саме так, як написано у завданні». Мені відповідають, що не те мали на увазі й задачу ми зрозуміли неправильно. Але ж над таскою працювало кілька людей, і якщо всі зрозуміли неправильно, значить, проблема була з формулюванням.
У Jira я пакую завдання по спринтах, делегую та моніторю виконання. Це внутрішня кухня з командою розробки, вона зручна, бо має інструменти, розроблені спеціально для програмістів.
Пріоритет отримують або невідкладні, або глобальні задачі
У нашому продукті часто трапляються «пожежі», а ціна навіть однієї хвилини простою — дуже висока. Це диктує умови для пріоритизації завдань.
По-перше, ми розв’язуємо проблеми, які зупиняють роботу бізнесу. Наприклад, нещодавно банк перестав видавати оплати частинами. Ми три години намагалися в телефонному режимі зрозуміти, в чому проблема. І з’ясувалося, що банк релізнув оновлення, тож нам відповідно теж треба було оновити в коді два рядки. Але вони не анонсували змін — і ми кілька годин грались у детективів. Тому перший пріоритет для нас — розв’язати проблему, коли така виникає. А далі ми виконуємо ті таски, що є у спринті.
Масштаб та цінність задачі теж формують її пріоритетність. Мені можуть приносити таски й з глобального, і з окремих ринків. Тут пріоритет завжди буде на стороні глобалу, бо це те, що принесе користь усім нашим командам.
6 моїх особистих лайфхаків у проєктному менеджменті
#1. Пакую спринт на 80%, а не на 100%
Формально у нас діє фрейм Agile та його підвид — Scrum, але насправді у нас Франкенштейн. Якщо Scrum реалізовувати правильно, потрібно пакувати спринт на 100%.
Коли я тільки прийшов, спринт пакувався набагато щільніше. Але постійно траплялися термінові речі, які треба було пофіксити якомога швидше, вони забирали час. І через це ми не могли вчасно віддати те, що було в плані. Спринт скасовувався, бізнес втрачав цінність. Так бути не має, тому ми перейшли на суміш Scrum і Kanban — це дозволяє не пакувати спринти повністю, але водночас зберігати їхню цінність.
Високопріоритетні задачі я пакую так, щоб у спринті лишалося до 20% флюгера під термінові таски. В такий спосіб у нас є value спринту, просто вона становить не 100%. Якщо вдача посміхнеться й у нас буде спринт, коли нічого термінового не прилетить, ми знайдемо, чим зайнятися. Але якщо щось прилетить, ми встигнемо і з терміновим, і з запланованим.
#2. Якщо задача займає три години — я кажу, що віддам її за три дні
У нас тривалий SDLC: написання коду, код-рев’ю, тестування, тестування в середовищі, перенесення на сервер. В усіх процесах залучені різні люди.
Деколи я чую: «Ну чому так довго, це ж усього 3 цифри поміняти». А тому, що я не хочу, щоб через ці дрібниці ми втрачали гроші. Навіть найкрутіший розробник помиляється, часом пропускає пробіл або ще якусь деталь — це нормально, всі ми люди. Але щоби похибки не приносили збитків, потрібна підстраховка та додаткові балансери. Так довше, але надійніше.
Тривалий SDLC — не єдине пояснення того, чому ми не робимо швидко. Друга причина — черга. Людина приходить до мене з запитанням «Скільки часу потрібно, щоб це зробити?». Я можу відписати: «Три години», і це буде правда, хоча задачу ми все одно віддамо за три дні, бо перед нею теж маємо роботу.
Запитуючи, скільки часу потрібно, людина цікавиться не абстрактною тривалістю роботи над таскою, а конкретним часом, в який задачу буде закрито. Тому я відповідаю одразу на два запитання і кажу: «Це робити три години, але ми віддамо за три дні». Це дозволяє уникнути непорозумінь та забезпечує прозорість комунікації.
#3. Одна задача, виконана на 100%, краща за 10, виконаних на 90%
Одна з найбільших помилок у ролі PM — боятися топменеджменту. Я багато працюю з country managers, глобальним керівництвом та усвідомлюю, що за статусом і повноваженнями вони стоять вище. Водночас розумію, що підлаштовувати робочий процес команди під кожного топменеджера лише тому, що він топ і вважає свою задачу терміновою, — погана ідея. У нас є план, і він — важливіший.
Раніше ми робили інакше: воркфлоу був, але якщо хед якогось відділу приносив свою дуже пріоритетну задачу, команда кидала запущені процеси та починала робити новий. Ми відійшли від цього і зараз працюємо інакше. Якщо моя команда має задачу в роботі й паралельно з’являється нова, ми не перестрибуємо. Спершу доробляємо те, що вже запущено, а потім беремося за наступне.
У мене є простий принцип: одна задача, виконана на 100%, краща за 10, виконаних на 90%. Бо ці 10 — не завершені. До того ж процес перемикання між тасками — тривалий, купа додаткового часу йде на те, щоб налаштуватися, пригадати контекст, увійти в процес.
#4. Не кіпішую, навіть якщо все пропало
Почалася війна? Ми без паніки продовжуємо робити свою роботу. Впав сайт? Ми без нервів розбираємося в причинах та лагодимо. Кіпіш не допомагає. Тим більше якщо перекладати його на команду.
У мене працюють дорослі люди, яким я довіряю та знаю, що вони роблять усе настільки швидко, наскільки це можливо. Щоб людина почала розв’язувати проблему, мені достатньо написати їй лише один раз. Якщо я приходитиму кожні 10 хвилин і питатиму «Ну що?», це лише нашкодить. Тому відповіді «Ок, дивлюся» під таскою мені цілком достатньо.
У дитинстві та юності я був дуже нервовим, багато стресував. Але якось слухав подкаст на тему «Що б я порадив собі 18-річному». І серед десятків порад типу «Вчіться», «Не опускайте руки» тощо, я почув ту, що змусила мене переглянути свої реакції. Насправді є дуже мало речей, які варті переживань. Я замислився, провів внутрішню ревізію та побачив, що насправді доволі часто хвилювався дарма, бо зараз усі ці проблеми видаються абсолютно несуттєвими.
Стресостійкість — це лише 50% характеру. Інші 50% — робота над собою. Головне — тримати у фокусі те, що паніка ніколи нікому не допомогла.
#5. Тримаю горизонти широкими
Я часто бачу вакансії, де шукають вузьких фахівців із бекграундом у конкретній вертикалі бізнесу. Наприклад: «Потрібен PM із досвідом у фінтех-проєктах». Як на мене, це неправильно.
Я працював у багатьох напрямах, цей досвід дозволяє мені краще розв’язувати й стратегічні, і тактичні задачі зараз у Laba. Крім того, з широким горизонтом знань краще починаєш розуміти людей: їхні болі, мотивації, проблеми та задачі.
Ще один бонус — це допомагає побудувати більш довірливі стосунки з командою. Одного разу в іншій команді у нас була проблема з деплоєм. Сайт не може лежати довше хвилини, бо це величезні збитки. А синьйори казали, що деплой оновлення займе мінімум пів години. Ми сіли розбиратися, і я запропонував ідею, яку колись вичитав у книзі. Ми зможемо задеплоїти так, щоби падіння тривало 16–17 секунд: для цього треба лише скопіювати базу, задеплоїти все, що треба, і перемкнутися на нову.
Пригадую, як команда почула цю ідею та була здивована: «А таке реально може спрацювати». Після цього ставлення змінилося: мене перестали сприймати як людину без сенсу (бо саме так синьйори часто бачать PM), я здобув довіру і певний авторитет.
Коли я кажу про широкий кругозір, маю на увазі буквально. Я зачитуюся Поттеріаною так само, як і новими виданнями з проєктного менеджменту, а разом із профільними подкастами вмикаю під час пробіжок History Hour від BBC.
#6. Прокидаюся раніше за команду і не боюся деколи овертаймити
Є байка про хлопця, якого запитали: «Чому ти працюєш у неділю?», а він відповів «Та тому, що це єдиний день, коли мене ніхто не відволікає». Я не працюю в неділю, цей час присвячую родині. Але можу на кілька годин відкрити ноут у суботу або попрацювати зайву годину в п’ятницю. Для мене це легше, ніж усі вихідні ходити й думати про те, що лишилося незавершеним.
Також я починаю робочий день раніше, ніж команда, щоби підготуватися, оглянути прогрес по задачах, сформувати список справ на день, перевірити пошту. До слова, пошту читаю знизу, від старіших листів — до свіжих. Колись читав зверху, але потім зрозумів, що так нові листи ніколи не закінчуються.
Все це дозволяє заощадити мій час і час колег на дейлі-мітингу. У нас два дейліки, але вони тривають у середньому 15–20 хвилин. Зазвичай ми добре йдемо за флоу — і мені приємно бачити, як задачі рухаються по дошці.
Бажаєте отримувати дайджест статей?
