У вас виходить делегувати?

Питання до senior та lead розробників. У вас добре виходить делегування? Чи не дуже? А навчання людей?

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

За складом характеру я скоріше інтроверт, тобто щоб почати small talk з колегою, мені треба прикласти зусиль.

І тут, бачачи що ти класний програміст, начальство дає тобі падаванів (міддл рівня) — на, навчай та контролюй!

Йой! Що з ними робити? Взаємодія з людьми — це ж не в коді копирсатися.

Проблеми, які виникли у мене:

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

— Дуже часто, бачучи що людина НЕ вивозить задачу (не може зробити її півтора тижні, а естимейт був 2-3 дні), починаю робити роботу за цю людину (код пишу, який треба написати, чи замість людини йду в логи дебажити проблему, з якою він не може тиждень розібратися). Це виглядає як «Знов ти, невдаха, не можеш зробити, — дивись, як треба»

— Ступінь розжовування тасок: після роботи в команді сеньорів, звикаєш що НЕ треба розжовувати всі дрібниці в описі таски. А мідлам (моїм, при наймі) якщо не напишеш «на поле з email добав валідацію, щоб перевіряло, що строка є email-адресою» — так він і не зробить! Тобто, треба всі дрібниці писати. Але ще гірше, що ти пишеш ці дрібниці в таску — а вони їх недочитують!

Тобто, в мене три питання про делегування:

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

— Що ви робите, якщо бачите що людина явно не вивозить задачу? Берете на себе? Сідаєте робити разом, з шерингом екрану?

— Як не харитися від того, що ти вже розжував задачу до дрібниць, а її все одно зробили не так, бо «там недочули, тут недочитали». Або від того, що дав нібито просту задачу добавити валідацію email, а воно бідне сидить вже тиждень зробити не може.

Як ви навчилися навчати та делегувати?

Теми: soft skills, команда, менеджмент

Ctrl + Enter

Віктор 28.12.2022 11:10

Схоже, що випадок який ти описуєш про падавана який теж інтроверт. Щоб налагодити комунікацію слід час від часу спілкуватися на віддалені теми, футбол, кіно тощо. Раніше для цього були тімбілдінги

Відповісти

Підтримати

Dmitry Bugay 27.12.2022 02:35

Як ви підтримуєте їх в час ремоуту?

Та блін, відкриваєш чятик і питаєш «шо ти як ти?»
А далі по ситуації. Це вже питання тупо твоїх софт скіллів.

Сідаєте робити разом, з шерингом екрану?

This.
Паралельно пояснюєш процеси в свої голові, які приводять до змін у коді.

Як не харитися від того, що ти вже розжував задачу до дрібниць, а її все одно зробили не так

Люди різні бувають. Деякі хапають ідеї в польоті, а деяким треба повііііільно розжовувати по кілька разів.

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

Дмитро Дем'яненко BA/UX 26.12.2022 14:55

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

Дмитрий Мирошник Lead QA Automation Engineer 26.12.2022 12:19

то він боїться до тебе зайвий раз підійти і щось спросити

1. Объяснить, что при возникновении проблем подойти и спросить — the must. Больно бить палкой, если не подошёл и профакапил сроки. Со временем привыкнет спрашивать. Главное — не превращать в разжёвывание уровня «добавь переменную типа int и напиши тут цикл.
2. Установить промежуточные точки контроля (ну, например, таска занимает 3 дня — через полтора спросить, как таска, что уже сделано (чтоб не было п****жа — 1-е пару раз попросить показать), что планируется сделать дальше и как, нужна ли помощь). Если справляется — отлично, можно контролировать меньше. Нет — контролировать чаще.

Ти маєш бути постійно відкритим до комунікації.

Да. Установи время, когда тебя можно спрашивать, чтобы не отвлекали от работы постоянно. Но его должно быть достаточно, чтобы все, кому нужно, получили свои ответы.

якщо не напишеш «на поле з email добав валідацію, щоб перевіряло, що строка є email-адресою» — так він і не зробить!

Это не миддлы, это херня какая-то. Но миддлов из них вырастить можно, если не совсем безнадёжны. Разжёвывать не надо, но при постановке задач спроси у подчинённого, какие валидации он тут видит и как планирует проверять. Пусть думает и отвечает сам, лучше — в письменном виде сначала. Потом — в устном. Научится думать — убираем. Вообще, почитай про 7 фаз делегирования, оно тебе поможет.

Як ви підтримуєте їх в час ремоуту

Small talks. Они должны видеть в тебе не босса, а человека. Ты должен знать, чем они интересуются, их семейные обстоятельства, как прошли у них праздники и т.д. и уметь радоваться их победам и сочувствать их поражениям. Именно так и выстраиваются отношения.

Що ви робите, якщо бачите що людина явно не вивозить задачу? Берете на себе

Нет. Плохой способ.
1. Ты им показываешь, что они — говно.
2. Ты тратишь свое время, соответственно, не выполняешь свои задачи.
Что нужно делать: понять, что помешало выполнить задачу. Устранить препятствие. Именно в последнем и заключается твоя задача как манагера. Не дочитал — ткнуть носом в литературу. Непонятен кусок фреймворка — связать с человеком, который его писал, пусть объяснит ну и т.д.

Як не харитися від того, що ти вже розжував задачу до дрібниць

1. Выяснить реальный уровень людей, проведя мини-собес, если не ты их собесил на проект. Давать задачи согласно их уровню, подтягивая наверх.
2. Пересмотреть свои ожидания. «Есть 2 решения: моё и неправильное» — тоже не выход. Если предложенное решение работает и не имеет архитектурных дефектов — оно имеет право на существование.

Надеюсь, будет полезно :)

Otak 25.12.2022 23:21

якщо

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

начальство дає тобі падаванів (міддл рівня) — на, навчай та контролюй

просто скажи начальству що тобі не цікава така робота, або знайди собі іншу роботу де зможеш розвиватися у потрібному руслі

Denys Poltorak Embedded | C++ (opentowork) 25.12.2022 23:18

Найліпший варіант делегування — code ownership. Якщо таймлайн може зачекати, то кожному програмісту віддаєте один модуль, і усі задачі, що того модуля стосуються. За 3 місяці він буде добре шарити в коді модуля й швидко там усе робити, навіть без потреби код рев’ю.

Dmitry Bugay 27.12.2022 01:48

Таке можна робить тільки з людьми рівня мідл+ і вище, в яких впевнений на 100%.

Інакше — це погана ідея.
Без надзору твій підопічний може пуститися берега, і якось заглянувши в той «модуль» ти посивієш від того шо там побачиш.

Denys Poltorak

Denys Poltorak Embedded | C++ (opentowork) 27.12.2022 07:56

Якщо воно працює нормально — то пофіг, доки є хазяїн. А коли втіче — новий хазяїн перепише. Думаю, за 2-3 роки ефективність роботи окупиться.
(І то була одна з ознак мікросервісів в інтернеті: боїтеся переписати — значить, не мікросервіс)

Це в цілому. А розробка джунами без нагляду — то, взагалі, дивна ідея, як на мене.

Dmitry Bugay

Володимир Корнійчук Senior Software Engineer (C++) в Infopulse 25.12.2022 20:26

Шукати відповіді, як завжди, треба не в інших людях, а в собі. Задайте собі питання — скільки тасок різної складності я можу зробити за день. Відповідь буде типу «одну складну, чи три середніх, чи 10 легких». Далі наступне питання — мені це норм чи ні?
Якщо норм — ну то і все, йдіть до керівництва, кажіть що в гробу Ви бачили те менторство, тих джунів та мідлів, те керівництво проєктом і від сьогодні Ви тільки пишете код і все.
Якщо хочеться зробити за день не «одну складну чи три середніх» таски, а п’ять важких чи двадцять середніх, то іншого шляху окрім менторства, делегування та керівництва — нема. Треба зменшувати час на кодинг, читати книги по управлінню командами, змиритися з тим, що у поточному проєкті багато що стане написано не Вами, не швидко, і, може, гірше, ніж хотілося б. І переключатися на вирішення задач «як зробити, щоб мої підлеглі писали краще і швидше, як усунути для них перешкоди, як дати їм кращі знання та інструменти, як краще розбити і розподілити задачі», тощо. Це все важко, важче, ніж кодити. Але тільки так Ви зробите більше задач за одиницю часу.

Otak 25.12.2022 23:24

іншого шляху окрім менторства, делегування та керівництва — нема

Ніт)

Достатньо знайти роботу де потреби проекту і бажання співпадають

Володимир Корнійчук

Володимир Корнійчук Senior Software Engineer (C++) в Infopulse 26.12.2022 00:22

А чим допоможе зміна роботи? Ти або хочеш зробити більше задач, ніж фізично здатен, або не хочеш.

Otak

Olena Kizimenko Scrum Master, Agile Coach, Mentor в Kyivstar Tech 25.12.2022 18:35

1) Ці розробники примають участь у плануванні та оцінці задач? Якщо ні — спробуйте долучати, хай самі пробують зрозуміти, який спектр робіт всередині, давати оцінки виходячи з того, за скільки вони б зробили.

2) (Говорить по менеджерські) в Менеджмент 3.0 є глава про рівні делегування, корисно разочок сісти та заповнити табличку з усіма своїми активностями, і вирішити, що з ними далі робити) Буває багато інсайтів.

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

4) Парне програмування — супер, код ревʼю не тільки вами за ними, але і навпаки — супер.

5) Якщо є можливість — пошукати ментора ще десь в компанії, якщо самому не хочеться. Але змиритися, що вони приходити з чужим «уставом» в ваш монастир

6) Прощатися, якщо реально не вигрібають навіть після менторинга і всіх спроб, що були здійснені

7) Дати відверту відповідь на питання, чи воно вам треба. Якщо так — качатися в софт скілс, без того ніяк і там море всього, починаючи від фасилітації зустрічей до побудови команд, стосунків, вирішення конфліктів і т.і. Ще й емпатію прокачаєте)

Taras 25.12.2022 13:08

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

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

Дуже часто, бачучи що людина НЕ вивозить задачу (не може зробити її півтора тижні, а естимейт був 2-3 дні), починаю робити роботу за цю людину (код пишу, який треба написати, чи замість людини йду в логи дебажити проблему, з якою він не може тиждень розібратися). Це виглядає як «Знов ти, невдаха, не можеш зробити, — дивись, як треба»

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

Ступінь розжовування тасок: після роботи в команді сеньорів, звикаєш що НЕ треба розжовувати всі дрібниці в описі таски. А мідлам (моїм, при наймі) якщо не напишеш «на поле з email добав валідацію, щоб перевіряло, що строка є email-адресою» — так він і не зробить! Тобто, треба всі дрібниці писати. Але ще гірше, що ти пишеш ці дрібниці в таску — а вони їх недочитують!

Чітка формалізація завдань приводить команду з різним рівнем знань і досвіду до спільного знаменника. Навіть для команди сеньйорів вона є дуже важливою. В випадку реалізації валідації поля email, варто не тільки написати, що вона потрібна, але й вказати необхідні види та методи реалізації. Неуважність падаванів — це наслідок тої таки першої проблеми.

anonymous 25.12.2022 13:14

Taras

Taras 25.12.2022 13:42

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

anonymous

Denys Morozenko Software engineer в MWDN 25.12.2022 08:39

Можна спробувати делегування в побуті, щоб швидше пройтись по всім граблям аніж на роботі, навчитися довіряти людям і вистроювати робочі відносини.
Найміть клінінг, замовте своїй половинці букет по вашому ТЗ без особистого втручання в процес, і тому подібне, врешті займіться ремонтом наймаючи не бригаду — це взагалі суцільне надбання корисного досвіду:)

Roman Gorodishcher Principal Engineer в Twilio 25.12.2022 02:51

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

Тут явно є підміна ролей. Можливо так трапилось що в вашій конкретній компанії Senior Engineer — це насправді 50% IC та 50% менеджер. Або ж прошарку компетентних менеджерів просто немає, тож ви берете цю роль на себе. Тут треба внести ясність, зокрема чи є у вас хоч якась «authority» (можете вплинути на ЗП «підлеглого»? можете самі роздавати задачі?)?

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

Що ви робите, якщо бачите що людина явно не вивозить задачу?

1. Переконайтеся що людина розуміє задачу. У тікеті мають бути посилання на всі документи або код які важливі для виконання задачі.
2. Ще до того як людина почне працювати над задачею, запропонуйте провести 30-хвилинну зустріч на якій ви представите ваше розуміння як найкраще вирішити цю задачу, та зможете відповісти на питання які не були задані раніше (а дуже ймовірно що таких «незаданих» питань є багато).
3. Просіть відкривати draft PR якомога раніше і давайте фідбек якомога раніше. Закладайте в естімейт 3-4 ітерації на ревью.
4. Обговорюйте ситуацію на 1-1 зі своїм менеджером: ситуація має бути прозорою.

Some Developer 25.12.2022 11:47

не «делегувати», а допомагати команді досягати поставлених цілей

коли 2 з 4 людей в команді навіть не приховують, що їх мрія — це зайчизм (працювати на 2 роботах за 2 зарплати по 3-4 години в день на кожній), то як я можу їм допомогти?

[sarcasm mode on]
— не давати складних тасок, давати прості та побільше часу на кожну
— не питати про прогрес, ніяк не реагувати коли робиться дуже довго
[sarcasm mode off]

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

Roman Gorodishcher

Sergii Marushchenko Працює в Ziemer Ophthalmic Systems AG 25.12.2022 13:15

Допомогти покинути компанію :)
(Голосом Джона Сільвера-Джигарханяна)
Бівер Грін зробив би за них всю їхню роботу, Уставший Архітектор звільнив би з вовчим квитком.
Голосую — викинути на мороз!

Some Developer

Oleg Grudko QA team lead в Omilia 25.12.2022 17:33

З вашого коменту випливає, що у вас не з делегуванням проблема, а з тим, що люди працювати не хочуть. Якщо запитання, як за 4 години зробити роботу на 8 годин, то відповідь — ніяк

Otak 25.12.2022 23:27

коли 2 з 4 людей в команді навіть не приховують, що їх мрія — це зайчизм

ХеХе)
Так у вас не з делегуванням проблеми

Що ж ви показуете не те що болить)

Sergii Marushchenko Працює в Ziemer Ophthalmic Systems AG 25.12.2022 14:34

Тут треба внести ясність, зокрема чи є у вас хоч якась «authority» (можете вплинути на ЗП «підлеглого»? можете самі роздавати задачі?)?

В аутсорсингу є строгий процес та ієрархічність. Коротка рука це перекинути на PM-а, довга — performance review.

Sergii Marushchenko Працює в Ziemer Ophthalmic Systems AG 25.12.2022 01:56

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

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

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

Щодо зависання — статус варто не боятися питати самому. І не просто не боятися, а не лінуватися і не прокрастинувати його обговорення. Найкраще на ремоуті виводити його в окремий колл після стендапу. Якщо ж стендапу немає, то по-перше його таки треба створити, а по-друге без нього то вже ваша задача, «пінгати» кожного. Єдина різниця між пінгом ПМ-а і технічного керівника — останній таки може допомогти!

anonymous 24.12.2022 22:12

Vyacheslav Mikhailenko Software Engineer 24.12.2022 21:59

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