Привіт!

Мене звати Роман. Після 12 років професійного ІТ (та ще стільки ж хоббі-програмування) я вирішив, що вже пора. І подавася в управління.

Тут писатиму про всілякі управлінські-і-не-тільки штуки з ІТ-світу.
So let's go!

Скрам (не) працює?

Цій тезі, напевно, стільки ж років, скільки Скраму 🙂. Відверто кажучи, я також колись залюбки дискутував коло кавомашини, чому Скрам не працює саме в нашій команді.
Адже методологія нескладна, там гайд на півгодини почитати — не те, що з якимось мануалом по реактивності розбиратися.
Якщо ми, такі розумні й красиві, вміємо в Angular/Helm/алгоритми, а Скрам в нас не заводиться, то це ж не в нас проблема, правда?

Диявол, як завжди, в деталях. В визначеннях, в називанні речей правильними термінами. В дотриманні клятих процедур, навіть коли "нашій команді це не потрібно" ©️

Мені підвернувся курс по Скраму; дай-но, думаю, пройду. А в курсі крім лекцій ще є тести. І ось на тестах виявилося, що деталі насправді важливі. І базворди, на кшталт Transparency-Adaptation-Inspection, не базворди, а цінності. Якщо подивитися на процеси з точки зору цінностей, то багато речей стають очевидними.

Напр.,
▷ Sprint goal — це тупа формальність, тут і так все зрозуміло
🤷 Ну, не закінчили цих 2 user story — перенесемо в наступний спринт
🤔 Нууу, ми можемо це включати в реліз, але там немає ще X, Y, Z.
😠 Які нові фічі? Нам стільки всього треба доробити!
🤬 Піздєц, дикі плани поставили, ми стопудово проїбем дедлайн.

А все через те, що в кузні не було цвяха ©️.
Якби був Sprint goal і всі його поважали, то було би чітке розуміння, що є releasable, а що — ні. Прозорість в delivery/release дає можливість планувати гнучко і не потонути в techdebt та нереалістичних очікуваннях.
Ось так цінності Скраму стають цінностями бізнесу. При цьому, всі у виграші: бізнес має прогнозований delivery; до девелоперів прислухаються.

Скрам працює, коли команда робить Скрам.
По техніках Скрам, поважаючи цінності Скрам.

Скрам не працює, коли команда робить хер-зна що, але називає це Скрамом. Такий бидло-"скрам" і є суб'єктом пліток коло кавомашини. Адже про працюючий Скрам нема чого особливо пліткувати 🙃

Програміст вирішує задачі фреймворком.
А керівник — програмістом.

Проект vs. Продукт

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

Управління проектом (традиційний PM) — то бізнес-задача. Дуже спрощено то виглядає якось так:
1️⃣ Авантюра: було би класно керувати телевізором з телефона.
2️⃣ Нахера: Чи буде з цього профіт? (порівняння потенційної вартості та потенційного доходу)
3️⃣ Проект: Робимо аплікацію для телефона, з ось таким функціоналом. Робитиме ось ця команда, від завтра і до першого вересня.

👥 Проект для команди — то тимчасова штука до першого вересня. Як студенти: здали й забули (ну ок, виділили 4 годино-джуна на тиждень для підтримки). Проект має (більш-менш) фіксований розмір (скоуп). Звісно, in real life, скоуп зі скрипом міняється і терміни сунуться (також зі скрипом, або з лубрикантом — залежно від стосунків PM з інвесторами).

🗣️ Роль PM — управління бізнес-авантюрою зі всіма допусками та ризиками. Команда може не справитися зі скоупом до першого вересня (ніколи такого не було, і ось знову!). Зрештою, ринок може не оцінити геній нашої авантюри і не купити проект взагалі ☹️ Або фортуна посміхнеться і проект виявиться новим disrupt-ом і завіруситься ТікТоками в Метаверсех.

Тоді Проект промоутиться до Продукту.
Продукт, в свою чергу, живе довго. А з ним живе Product Backlog. Ми радісно приносимо нові захцянки в наш улюблений продукт і реалізовуємо їх: декотрі тепер, інші восени. Ми любимо продукт за його передбачуваність: Sprint must go on і мітинг-рум по п’ятницях зарезервований без кінцевої дати.

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

Проте інтенція постійності продукту вимагає від PO постійного уточнення (рефайнменти), постійного внесення нового функціоналу (як бізнесового, так і технічного) та постійної роботи з беклогом. В цьому роль PO та PM відрізняються.

—————————————————

З життя: я працював у компанії, котра розробила доволі функціональний двигун для роботи з гео-даними. Компанія дуже хотіла, щоби той двигун став Продуктом: з’явився новий клієнт — ось форма для реєстрації, ось рахунок для оплати. Як в Нетфліксу 🙂
Проте, кожен новий клієнт стає Проектом, не зважаючи на те, що використовує той же двигун. Чому? — бо в клієнтів дуже специфічний і складний бізнес; кастомізація двигуна під нового клієнта займає декілька місяців роботи потужної скрам-команди.

Більшість таких Проектів стали Продуктами для свого єдиного клієнта: новий функціонал додається, сервери крутяться і фідбек-форми ліниво заповнюються.
Але деякі Проекти “не злетіли”. Щож, то є ризики бізнесу.

Так і живуть 🙂

Навіщо н'рмальним пацанам-і-пацанесам місія компанії?

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

Місія потребує чесності та прозорості процесів від всіх учасників процесу. Якщо на стіні девіз про нові технології та відкритість, а кодова база — Java 6 на SVN, то в колективі поширюється лицемірство з легким флером найобу.

Олдскули згадають останні роки Союзу: слюсар лошарико-підшипникового заводу бачить на стіні за прохідною атлетичного комсомольця з трьохелектронним атомом в одній руці і повногрудою дояркою в інший; той комсомолець велично дивиться в космос (у майбутнє) і пророкує комунізм, “где, по моему, вообще не надо будет умирать” ©️
Слюсар, вроді би й радий відповідати цьому іміджу, але, озирнувшись навколо, він бачить йобаний 1980-й з чергами-дефіцитами і всіма решту атрибутами вмираючої імперії.

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

⚖️ В принципі, організація може довго існувати, якщо справжні цілі власників будуть ортогональні декларованим. Колектив там буде геть нездоровий, з плинністю кадрів, історіями на EbanoeIT та киданнями на зарплату, як modus operandi. Але власники закриватимуть якісь свої потреби (найчастіше — фінансові).
Такі організації рідко роблять щось велике. Аутсорсити техпідтримку — так, а спроектувати новий девайс — не осилять. Якщо власників то задовольняє, то show will go on.

—————————————————

🤨 В компаніях зі справжньою місією також є свої підводні камені. Бажання фанатично слідувати букві закону місії може суперечити здоровому глузду (то зустрічається там, де фанатизм домінує над досвідом). Амбасадори великої місії нерідко допускають тільки один вид мотивації, “працювати в нас — велика честь” і вони насправді в то вірять! Переговори про премію можуть зустрітися зі щирим (!) нерозумінням, або й розчаруванням: невже ти тут ради бабла? А ми думали, що ти дійсно <…>.

😎 Це, звісно, крайнощі. Безсумнівними плюсами компаній з місією є передбачуваність, (як правило) толкове планування, та ідейна однорідність колективу: мудацтво там не приживається.

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

Чи не хуйньою я займаюся?

Наскільки це наближає мене до цілі?

Звісно, передумовою є наявність особистої цілі 🙂

Ідеально було би задавати таке запитання перед тим, як приступити до роботи (або, перед тим, як взяти на себе зобов’язання). Зрештою, рефлексія в процесі також потрібна, бо робота/проект часто розвивається не по сценарію.

Друзі, я писатиму не тільки тут, але й на standalone-платформі.
Щоби двічі не бігати, пропоную глянути ось тут про софт- і хард-скіли. Давайте спробуємо подивитися на стару проблему по-новому!

Коменти вітаються!
// поки що тільки тут,
// інтеграцію на сайті ще не зробив 🫤

https://melnyk.site/post/11/soft_vs_hard_abo_i_byku_i_yupiteru

ви йобані пітекантропи
грали б вас вовки цілу ніч
подумав юра але вголос
сказав спасибі за фібдек

В одних колективах пропонувати нову ідею — лютий напряг. В інших — початок цікавої дискусії. Давайте подумаємо,

▸ В яких командах вам хотілося пропонувати нову ідею, а в яких — "та ну нахер"?
▸ Чому так?

https://melnyk.site/post/12/nova_ideya_krytykuvaty_vs_pidtrymuvaty

Кар’єрний шлях від Джуна до Міда більш-менш очевидний. Проте, за бажаним званням Сіньйора ховаються ряд хитрих аспектів.

https://melnyk.site/post/23/chomu_ya_ne_sokil_chomu_ne_litayu

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

Задумайтеся над семантичною різницею між
🇬🇧 "can / cannot ↔ may / may not"
— vs. —
🇺🇦 "можна ↔ не можна".

А тепер уявіть, що може статися, якщо цією семантичною різницею знехтують в переписці. Не будемо драматизувати і уявляти, як shit can hit the fan в операційній палаті. Давайте прикинемо, які наслідки це може мати для командної розробки.

https://melnyk.site/post/25/za_movyty_chy_ne_zamovyty

Ви помічали, що ми часом питаємося Для чого?, а отримуємо відповідь на запитання Чому?

Продовжуємо лінгвістичні вправи: https://melnyk.site/post/27/chomu_vs_dlya_chogo

До речі, я трохи оновив двигун бложика. Тепер він розрізняє контент українською та англійською та має чуть кращі стилі.
Якщо побачите баги, дайте, будь ласка, знати!

Парадоксально, але коли ми довго варимося в якомусь процесі, то втрачаємо об’єктивність. Погляд ззовні допомагає, але не на 100%.

Як бути в умовах необ’єктивності?

https://melnyk.site/post/28/akvarium_poglyad_zzovni_ta_zseredyny

Як правильно українською мовою:
• мáркетинг,
чи
• маркéтинг?

Застосуємо прийом фалічної редукції. Слово "хуя'ркетинг" милозвучніше, ніж "хуяркéтинг".

Таким чином, мáркетинг.

Недавно дискутували з колегою на тему виховання дітей. Ось основні тези:

▸ Дисципліна — розуміння різниці між наявним станом справ і бажаним. Напр., між відсутністю Ламборджині і наявністю Ламборджині. Коли таке розуміння формує мотивацію, ми говоримо про традиційну дисципліну.
▸ Дисципліна, як метанавик, потрібна. Без неї досягнути Ламбор поставлених цілей дуже важко.
▸ Навряд, чи можна привити дисципліну (ззовні). Найефективніше маніфестує дисципліна, до якої людина сама прийшла.
🤒 Хвилинка дитячих травм: коли чистити зуби змушують, то ти ненавидиш це. Проте, після першої самостійно оплаченої пломби, ти стаєш чемпіоном з чищення зубів.
▸ Схоже, що роль дисципліни в XXI ст. дещо послабилася. В XIX ст. skin was in the game дуже буквально: їблуєш весною → помреш з голоду взимку.
▸ Feedback loop дисципліни в XXI ст. дуже довгий. Ми, як цивілізація, розвинулися настільки, що з голоду взимку померти важко. Тому зворотний зв'язок приходить настільки пізно, що його важко прилінкувати до причини (король/королева нічних клубів в 20 → херова робота в 30 → низька якість життя в 40+).
▸ На рівні відчуттів: якщо створити середовище, в якому людина побачить важливість дисципліни, то є вищі шанси, що людина розвине цей навик.
🤔 Як побудувати таке середовище (напр., для дитини) — ХЗ. Всіляки ідеї вітаються в коментах.

——————————

Ну і наостанок:
📊 З дисциплінованими колегами класно працювати.
🎉 З розпиздяями весело тусити.
Але не навпаки.

🎯 Шукаєте ціль в житті?
🪦 Придумайте собі епітафію.

На надгробку не так багато місця, поема не поміститься. Тому треба бути лаконічним і вмістити все в декілька слів. Не спішіть, придумайте собі кльову епітафію. Таку, щоби внукам було не соромно.

Придумали? — Чудово! Тепер живіть так, щоби втілити сказане в життя 😎

——————————

Це працює так само і з product goal.

🏆 Achievement unlocked:
Використав цитату зі Slipknot, Duality на нараді по архітектурі 🤘

Контекст: ми обговорювали те, що користувач може (і що не може) робити зі своїми та з чужими даними.

Цитата:

You cannot kill what you did not create

https://www.youtube.com/watch?v=6fVE8kSM43I