Ділимося висновками конфліктної гри – онлайн-батлу «Project Manager vs Architect», що відбувся на каналі SQL.ua Data Academy. Учасники батлу – Тарас Федорук (РМ) та Дмитро Лавріненко (Архітектор). Модератор, який зіграв роль клієнта та ставив провокативні питання – Тарас Кльоба.
SQL.ua Data Academy підготувала кейс клієнта по цифровізації ланцюгів постачання, де у чотири етапи (від прісейлу, першого релізу, через розгортання платформи в Китаї до передачі документації) проєктний менеджер та головний архітектор домовлялися, як будуть вирішувати проблемні моменти, що виникають «з подачі» клієнта.
Практичні поради, гострі моменти та інструменти, які можна впровадити в своїх компаніях та проєктах вже сьогодні! – Запрошуємо подивитися повну версію батлу на Youtube-каналі SQL.ua.
Starring. У головних ролях виступили:
Project Manager – Тарас Федорук, Senior Project Manager, Ops Lead у wearereasonablepeople, переможець «Ukrainian IT Awards 2019» у номінації «Project Management». Професійна біографія Тараса Федорука.
Архітектор – Дмитро Лавріненко, Director, Technology у GlobalLogic, переможець «Ukrainian IT Awards 2018» у номінації «Software Architecture». Професійна біографія Дмитра Лавріненка.
Модератор та Клієнт – Тарас Кльоба, CEO SQL.ua, Засновник SQL.ua Data Academy. Head of Data CoE у Intellias, переможець «Ukrainian IT Awards 2019» у номінації «Software Architecture». Професійна біографія Тараса Кльоби.
Представлення учасників:
Тарас Федорук: Працює в Нідерландах вже півтора року. Починав як Senior Project Manager в невеликому сервісному агентстві. Зараз вже суміщає роботу Senior РМ та Operation Lead. Відповідає в тому числі за весь потік створення цінності в організації.
Дмитро Лавріненко: На даний момент головна задача в роботі – перетворювати бажання клієнтів на технічну реалізацію. Відповідає за європейських замовників компанії. Серед завдань – налаштувати роботу команди так, щоб всі вимоги клієнтів були виконані.
Архітектор та РМ, за сценарієм, працюють в одній сервісній компанії, до якої звернувся клієнт.
Завдання клієнта:
Створити рішення для відстеження пересування комплектуючих, побудувати оптимальні маршрути. Ринок – Нідерланди.
Вимоги клієнта:
- MVP, що працює, в найкоротші терміни (3 місяці);
- Scalable solution;
- Висока якість, ефективне управління ризиками та затратами;
- Висококваліфіковані спеціалісти в команді;
- Останні технології;
- Своєчасна доставка ПО клієнту.
Відповідь на вимогу MVP в обмежені терміни:
Архітектор (Дмитро Лавріненко): Запросить у команду найкращих людей на ринку. Щоб забезпечити масштабованість рішення та з т.з. «витрати-ризики-якість», обирає розгортання рішення в хмарі. З урахуванням коротких термінів буде використовувати готові клаудні сервіси. Перше питання до MVP буде уточнення функціоналу. Для побудови оптимальних маршрутів хоче дізнатися – ми пишемо власний двигун або будемо партнеритися з локальними сервісами у Нідерландах. Ключовий фокус у короткі терміни – закрити функціональні вимоги.
Project Manager (Тарас Федорук): Архітектор прийняв рішення обрізати функціонал, щоб вкластися в терміни постачання MVP. РМ нагадує про «повний потік цінності», пов’язаний з тим, як правильно скорочувати «функціоналку». Якщо ми не постраждаємо end-to-end по конкретному процесу у рішенні для клієнта, то можна скорочувати. В загальному, відсікання scope – це не завжди тривіальна задача. І дуже часто знайти цих «20%», щоб зекономити час, практично неможливо. РМ повністю погодився з відсіканням нефункціональних вимог на даному етапі.
Якщо все ж таки сталося, що треба відсікти частину функціоналу, щоб виконати дедлайн, РМ вказав на пораду, яка найчастіше зустрічається в літературі – збирати мітинги. При пошуку, що викинути, буде важливо, на якому документальному фундаменті Ви будуєте проєкт. Від цього буде залежати, наприклад, Ви будете обрізати функціонал по фазах або по пакетах.
Якщо ми будуємо процес по фазах, то дуже важливо, щоб послідовність з самого початку була визначена вірно. Якщо по пакетах – який між ними взаємозв’язок. Для визначення зв’язків між пакетами підходить навіть інструмент mind maps. Тут важливо, щоб було «сильне архітекторське плече», на яке можна спиратися. Обов’язково реалізовувати необхідно ті блоки, на які зав’язана найбільша кількість елементів. Від блоків з «вільними кінцями» (в схемі – ред.) можна відмовитися.
Отже, для визначення критичного функціоналу: у Вас є артефакти і певний трейс. Залежно від трейсу у Вас є дані: 1) про взаємозв’язки між роботами; 2) про оцінку цих задач; 3) є експертна думка команди та клієнта.
Чи можна починати набір в команду до того, як буде створена архітектура рішення?
Архітектор: Залежно від того, який кейс. Ми можемо використовувати декілька підходів. Якщо клієнт готовий почати платити вже зараз, тоді для певної кількості людей ми знайдемо заняття. Сучасні підходи до створення рішень не дозволяють «скинути» завдання на мікро сервіси. MVP, у більшості випадків, це не про back-end. Тому відповідь Архітектора на питання така: на якісь компоненти – можемо, на інші – ні. І наша з РМ задача – кожного дня це обговорювати.
Project Manager: Відповів з власного досвіду роботи у великих компаніях. Часто за кращих спеціалістів є серйозна конкуренція між проєктами. І іноді ця війна за ресурси дуже жорстока. Тому чекати не є можливим. Іноді, якщо РМ хоче робити проєкт з перевіреними «у боях» співробітниками, то можна їх застафити раніше, ніж того вимагає здоровий глузд. Це є реальність компаній, в яких працюють більше 100 людей.
РМ не погодився, що з самого початку ми ставимо на проєкт сильних людей, а потім їх замінюємо. Рівень спеціалістів – це один із важелів, який РМ повинен використовувати, коли йде обговорення бюджету проєкту з клієнтом.
У заміні команди по ходу виконання проєкту є ряд «підпитань». До прикладу, при старті з Senior, а потім – русі до Junior, виникають процеси та надбудови, які лягають на бюджет компанії-виконавця – knowledge transfer, architect’s review (спайки в бюджеті) та ін.
… Дивіться, як розгорталася ситуація, які інструменти пропонували тут: ВІДЕО БАТЛУ
Про функції РМ та Архітектора:
Головна функція Project Manager, яку неможливо делегувати – інтеграція, забезпечення повної прозорості проєкту. Команда в кожний момент часу знає, чим займається, для кого, навіщо… В ідеалі, всі знають, звідки прийшли (3 кроки назад) та куди йдуть (5 кроків вперед).
Архітектор є головним decision maker того, як буде виконаний проєкт. Жартома (або ні), Архітектор відмітив, що повинен навчитися «менеджерити РМ-а».
Зійшлися, що при сильному РМ, Архітектор має можливість сфокусуватися на технічній стороні. Якщо в команді є сильний Tech Lead, то Архітектор фокусується на управлінні. Основа гармонійних відносин – постійний діалог.
To-Do List. На що звернути увагу у Ваших проєктах:
Команда:
- Максимально рання алокація, але після визначення обсягів робіт;
- Не давати клієнту втручатися в призначення в команду;
- Збалансувати склад команди, відповідно до вимог етапів проєкту;
- Враховувати, що план та алокація диктують один одного, взаємозалежні.
Інструменти:
- Обов’язковий мінімальний пакет артефактів;
- Планування циклу проєкту залежить від трикутника «зміст-розклад-затрати» та факторів середовища;
- Документуйте все, неначе завтра «всі потраплять під автобус».
Обсяг робіт:
- Початок завжди з «чому?»;
- Дорожня карта проєкту має оновлюватися шляхом проактивної взаємодії з клієнтом;
- Прозора комунікація вимог до продукту, включаючи функціональність та технічний борг;
- Повертайтеся до візії проєкту, щоб прийняти рішення.
Витрати проєкту:
- Треба будувати і витрати проєкту і модель фінансування (частота та обсяги оплати від клієнта);
- Конус невизначеності завжди присутній;
- Закон Паркінсона працює (робота займе весь відведений на неї час або більше).
Мета проєкту:
- Працювати потрібно і з рівнем якості, і з грейдом (сортом) продукту. MVP взагалі не є рішенням, що можна віднести до production grade.
Щиро дякуємо Учасникам батлу – Тарасу Федоруку та Дмитру Лавріненко за час та досвід!
#SQL.ua Data Academy
Advanced Data Teaching and Learning!