Cіпласпластик: post #520 — TG.ME

Пан К. у своєму каналі «Мамкін Архітектор» написав днями про довіру в команді, зокрема довіру керівника до виконавця. Історія там така, що гіпотетичний(?) чувак заестимейтив та зробив задачу, але в керівника лишився осад. «Телефон чорно-бєлий, а довжен буть цвітний. Шо мені робить?»

Ну й висновок автора, що варто будувати «zero trust», де кожен завжди під ковпаком (причому так, щоб ніхто цьому не дивувався й не ображався), хоча конкретних методів не дає. Я з певними твердженнями погоджуюся, але загалом маю альтернативний погляд на все це, про який і напишу.

Значить ситуація:
[…] розробник ставить оцінку на тиждень, зникає на чотири дні, і повертається з пул-ріквестом, де коду на три години з перекурами. […] Лишається відчуття, що тебе трошки намахали…


У мене тут картинка якось не склалася. Якщо манагер оцінив, що «коду на три години», то він, певно, тямить. Тоді як він прийняв початкову оцінку в тиждень? А якщо не тямить, то чому зараз береться оцінювати самотужки?
🧐 (До речі, статистично доведено, що люди значно більше поважають керівників, якщо думають, що ті здатні виконувати їхню роботу.)

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

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

Ідемо далі. «Розробник зникає на тиждень» — це очевидна дурня. Ті ж дейліки винайшли саме для того, щоб такого не було. Взагалі даю пораду програмістам: менеджери завжди мають значно більше задач, ніж фізично можна виконувати. І єдине, про що вони мріють з боку команди — щоб усе йшло за планом. А значить ви як виконавці маєте два обовʼязки: робити все можливе, щоб виконувався план, і повідомляти одразу, щойно він перестав. Тоді керівник має більше простору для маневрів з вищими менеджерами або замовником, а отже відносно задоволений.

Додаткова порада, як уникати зайвих питань «чим займався?»: робіть більше комітів!
💡 Почали робити задачу — одразу створили гілку, запушили на ремоут і створили чернетку PR; далі щовечора докидаєте туди те, що встигли зробити. Перший раз манагер спитає, а на другий — піде й сам гляне. Всі задоволені.

Ну й нарешті дійшли до теми про zero trust. Якщо ваша команда — це циферки на дашборді, то може воно й норм, але загалом вважаю такий підхід украй шкідливим. Навіть девіз щойно вигадав: zero trust — zero thrust
😮‍💨

Все йде з культури. В якийсь момент (мабуть, після книжок No Rules Rules та «Принципів») мене осяяло, що якщо ставитися до кожного як до спеціаліста своєї справи, котрими вони і є, (а не як до баранів, котрих треба за мотузку тягати), то вони раптом починають працювати збс, беруть на себе більше відповідальності тощо. В українському айті, на жаль, найчастіше зустрічаються два типи «менеджерів»: учора-програміст, на якого навалили купу задач з керування командою за додаткові пів гривні на рік, або той, хто дорвався до влади й починає всіх дойобувати. Школа менеджменту фактично відсутня. Мені ж більше імпонує тема про servant leader й оце все.

Щоб це працювало, керівники мусять давати більше інформації. (Згадайте, як ваш менеджер відміряє вам крихти інфи, наче в аптеці). Коли в людей є достатньо даних, щоб сформувати ширшу картину того, що є й чого треба досягти, вони починають знаходити значно ефективніші рішення. Окрім інформації треба давати ще відповідальність+авторитет. Перше треба для того, щоб працівник був умотивований досягати результатів (і отримував за це дофамін), а друге, щоб у нього були потрібні засоби. Очевидно, що на «нульовій довірі» це все не працюватиме. Навіть навпаки: треба дуже багато довіри.

А от куди zero trust добре пасує — так це до себе. Щоразу, як вам здається, що ви знаєте щось краще, спитайте себе, а чи дійсно ви довіряєте своєму судженню і чи не сліпа це довіра.

Тепер якщо ще раз перечитати оригінальний допис, на який я посилався на початку, то можна побачити дуже багато спільних рис і висновків з декількома важливими відмінностями. Та в одному, я думаю, ми б точно дійшли згоди: треба вибудовувати здорові взаємини в команді. Це важко й довго, але воно точно окупиться. А бракованих цеглин краще позбуватися
🙂
Telegram
Мамкін Архітектор
Буває таке: розробник ставить оцінку на тиждень, зникає на чотири дні, і повертається з пул-ріквестом, де коду на три години з перекурами. Потім дуже ображається, коли у нього запитують пояснення, розказує, шо там було складно, він багато думав, і взагалі…
🔥30👍12❤‍🔥33😁1🤣1
June 29, 2026 875 33 13