Artem Bykovets

22/03/2025

обіцяний пост із серії MLC (Mentorship LifeCycle)

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

Ось сім основних стадій життєвого циклу менторства, які я рекомендую:

1️⃣ Запит (Request) – усе починається з усвідомленої потреби. Менті (або його лінійний менджмент) визначає, що йому потрібна підтримка, і шукає ментора.

2️⃣ Брифінг (Briefing) – перша розмова, де обговорюються очікування, контекст, теми й формати взаємодії. Важливо перевірити, чи є взаємна “хімія” та розуміння.

3️⃣ Контрактування (Contracting) – чітке визначення цілей, зон відповідальності, форматів та тривалості співпраці. Це своєрідний договір, який допомагає уникнути розмитих очікувань. Складаємо план. заносимо в календар.

4️⃣ Старт (Kick-off) – налаштування процесу й первинне оцінювання. Тут встановлюються основні ритми та підходи до роботи.

5️⃣ Менторинг у процесі (In Progress) – основний етап, де відбуваються регулярні зустрічі, зворотний зв’язок і спільне вирішення викликів. Процес зачасту ітеративний, включає використання різних інструментів, технік й каналів та має адаптуватись під контекст. (якщо цей пост набере багато реакцій, коментарів й репостів - я зроблю ще один пост про цю фазу, коли на каналі буде 3+тис підписників)

6️⃣ Фінішна пряма (Finish line) – завершення основного менторського циклу, підведення підсумків і оцінка досягнень.

7️⃣ Рефлексія (Post-mentorship reflection) – важливий, але часто недооцінений етап. Аналіз отриманих уроків та їх впровадження в досвід Ментора.

бо хороше менторство — це не просто обмін досвідом, а процес, який трансформує і менті, і ментора. 🚀

#менторство #розвиток #Лідерство

03/03/2025

Другий пост із серії: Agile Метрики: ✅Do and ❌Don’t

Сьогодні поговоримо про:
🕖 Lead Time (час виконання: час, який проходить від моменту, коли клієнт «замовив» роботу, до моменту поставки готового результату) та ♻️ Cycle Time (час циклу: час, потрібний команді для виконання завдання від старту робіт над нею до повного завершення). Отже:

🕖 Lead Time
Рекомендації:
✅ Визначайте вузькі місця (bottlenecks) у погодженнях, залежностях та циклах зворотнього звʼязку.
✅ Заохочуйте кращу взаємодію "бізнесу" та "розробки" (кращі PBR, Sprint Review, постійна взаємодія замість сезонної і тд...).
✅ Використовуйте для оптимізації робочих процесів, забезпечуючи своєчасне постачання важливих задач.

Помилки:
❌ Не змушуйте команди поспішати лише для скорочення Lead Time.
❌ Не ігноруйте зовнішні фактори (наприклад: затримки від стейкхолдерів, повторні переузгодження, зміни регуляторки і тд).
❌ Не сприймайте Lead Time як статичний показник – він змінюється залежно від складності задач. (це ок що він може як скорочуватись так і рости. головне - аналіз причин та робота з ними)

♻️ Cycle Time
Рекомендації:
✅ Відстежуйте для виявлення неефективності у процесі розробки.
✅ Баланс між швидкістю та якістю – паралельно відстежуйте рівень дефектів.
✅ Використовуйте як інструмент навчання, а не як показник продуктивності!!!

Помилки:
❌ Не змушуйте команди пришвидшувати роботу штучно.
❌ Не жертвуйте якістю продукту заради швидкості.
❌ Не ігноруйте переробку (rework) та блокери.

p.s.: довго думав чи робити це двома окремими постами, але вирішив, що для мене ці метрики настільки важливі разом (ще й з Throughput про котрий буде наступний пост, що таки поклав їх разом). Чекаю на фідбек: чи корисно? чи не перегруз інформації для сьогоднішніх "правил ведення блогів"? що ще цікаво було би по темі?

27/02/2025

Перший пост із серії: Agile Метрики: ✅Do and ❌Don’t

Velocity («Швидкість») – кількість Story Points, що завершені (Done) за Sprint

✅ Рекомендації:
- Використовуйте для планування основаного на місткості (capacity based planning), а не для оцінки продуктивності.
- Переконайтесь, що оцінка Story Points залишається реалістичною та послідовною.
- Орієнтуйтесь на бізнес-цінність (business value), що принесе завершення роботи, а не на кількість виконаних пунктів у задачі.

❌ Помилки:
- Не змушуйте команди штучно збільшувати Velocity – це призведе до неякісної роботи.
- Не порівнюйте Velocity між командами – кожна оцінює роботу по-різному.
- Не допускайте "інфляції" Story Points для покращення метрик.

10/02/2025

ті з вас, хто бував на моїх тренінгах чи виступах на конференціях могли багато чути тим, як сильно я захоплююсь Професором Дейвом Сноуденом (Professor Dave Snowden) так-так.. прізвище співпадає, але він не має нічого спільного з серійний вбивцею з Швеціії… хіба тільки те, що теж бував за гратами 🤪 (в цьому відео є фрагмент де про це згадується)

минулого четверга у Youtube зʼявилось неймовірне миле і не менш цікаве відео, де Професор Сноуден пояснює про те чим займається і як до цього прийшов максимально простими словами і прикладами, бо це подкаст для школярів 11 років 😇 є там і згадка про його нещодавний візит в Україну і про його дитинство в горах на фермі і про те, як АІ впливає на навчання та розвиток когнітивних здатностей, якщо його «занадто багато вживати» і звісно про рентгенологів і горилу ;)

🧐дуже рекомендую (зайде, як тим, хто знайомий із діяльністю Сноудена, так і тим, хто хоче познайомитись вперше і рівень англійської дозволяє)

Цікавого перегляду!

https://youtu.be/xglqa_8yP5k?si=CruacKYrwbPqPlZc

p.s.: мені також сподобалось, як діти реагували емоційно на його історії та приклади! Один хлопчина - прям майбутній професійний подкастер чи ведучий, якщо звісно захоче і це ще буде затребувано)))

25/10/2024

вже зовсім скоро у новому революційному форматі (на основі ваших фідбеків):
1) дивитесь записи доповідей у зручному темпі та форматі
2) спілкуєтесь з іншими Учасниками та задаєте питання Спікерам та Експертам в закритих чатах конференції
3) 14 грудня збираємось на офлайн в Києві з тими хто зможе: обговорюємо найгарячіші теми, слухаємо пару доповідей вживу і камерні панельні дискусії (без запису відео) та проводимо день у форматі "не-конференції"

Сьогодні додали трохи ще спікерів на сайт конференції Day: Розвиток крізь виклики, що підтвердили участь і зараз узгоджуємо з ними тему доповіді та починаємо поступово публікувати деталі :)

Відповідно після відкриття доступу до записів доповідей - ціна зміниться з Early на звичайну ;)

До скорої зустрічі 😉

online | offline Agile Конференція в Києві, 14 грудня 2024 року. Цього року в нас буде НЕ–Конференція Simplicity Day: Evolving Through Challenges – простір для обміну досвідом, підтримки та зростан...

14/09/2024

Поговоримо про технічний борг?

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

(Про всяк випадок: Технічний борг виникає, коли в розробці обирають простіші або швидші рішення замість оптимальних, щоб прискорити процес або зекономити ресурси🫰)

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

Так от, звісно часом варто слідувати принципу Done is better than Perfect (зроблено краще ніж ідеальне, але не завершене...) і розробка через MVP (мінімально життєздатний продукт) це чудові підходи швидшого запуску і валідації гіпотез з меншими ризиками та витратами на старті, але є одне але..😉задоволення від отриманого "пришвидшення" може затягнути в певну залежність і рішення про "зрізання кутів" вже стають normal way of working, а не усвідомленим необхідним компромісом (із плануванням того, як ми цей борг будемо повертати з відсотками).

Тож рекомендую обов'язково відслідковувати техборг, що ми генеруємо при новій роботі чи появі нових процесних стандартів (наприклад додаванні в Definition of Done пунктів про обов'язкову актуалізацію документації чи написання інтеграційних текстів). Задачі мають бути створені одразу і лежати в спільному єдиному беклозі Продукту на рівних із іншими бізнес задачами й покращеннями, щоб не загубитись, як цей стікер на картинці десь в коментарях кодової бази😂

І так, на ці задачі "завжди не буде часу" і буде щось "терміновіше" й пріорітетніше🔥 задача девелоперів - пояснити своїм Стейкхолдерам і особливо РО наслідки "несвоєчасного погашення технічного кредиту"😉 та переваги для якості розробки та підтримки продукту, від усунення всіх тих грабель та милиць. Вважайте це необхідною гігієною вашого процесу і знайдіть той підхід, що краще запрацює у вашому контексті з вашими людьми (напр. Фіксований буфер часу в кожному Спринті чи окремий WiP limit під такі задачі чи пріоритезація через wsjf подібний метод...).

А як це працює у вас? Діліться успішними (і не тільки) кейсами в коментарях🤝