Більшість керівників керують задачами. Команда при цьому лишається поза увагою — а це зовсім інша робота.
За роки управління IT-командами я зрозумів, що технічна експертиза — це лише половина, а може й ще менше. Друга половина, яка дається важче, — це люди й процеси.
Ось 5 правил, які працюють з моєї практики.
Давати контекст, а не просто ТЗ
Розробник, який розуміє, навіщо він це робить, кодить інакше. Замість «зроби фічу» даю ширшу картину: «ця фіча закриє ось цей біль». Тоді вмикаються мізки, а не тільки пальці на клавіатурі.
Є й другий ефект, який легко не помітити. Розробник, який знає мету, може посперечатися з самим ТЗ. «Тут не потрібен новий сервіс, достатньо конфіга» — таке скаже лише той, хто розуміє проблему, а не тільки задачу. Одна така розмова економить дні роботи.
Контекст також рятує від найпоширенішої комунікаційної пастки — «я думав, ти знаєш». Люди припускають, що інша сторона бачить повну картину, домовленості ніхто не фіксує, і в результаті кожен будує своє бачення результату. Десять хвилин контексту на старті — найдешевша страховка від цього.
Фільтрувати хаос
Постійна зміна пріоритетів і “горящі” таски вбивають мотивацію. Моя задача як керівника — бути щитом, який відбиває зовнішній шум і дає команді спокійно тримати фокус.
На практиці це означає, що нові запити йдуть через мене, а не напряму в чат розробника. «Швидке питання» від клієнта, яке впало інженеру в особисті, коштує пів дня фокусу. Ті самі питання, зібрані разом, коштують одну розмову на плануванні.
Команда все одно бачить тиск — але як пріоритезовану чергу, а не як пожежний шланг. На справжню аварію навалюємось усі й одразу. Все інше чекає своєї черги, і виявляється, що чекати може майже все.
Менше мікроменеджменту
Якщо найняв сильних розробників — даю їм простір для рішень. Контролювати кожен крок коштує надто дорого: і в часі, і в мотивації.
Тут є проста математика. Порахуйте, скільки коштує ваша година, і подивіться, скільки цих годин іде на переперевірку рішень, які сеньйор вже ухвалив добре. Делегування — це не слабкість керівника. Це ознака зрілого управління.
Що я тримаю за собою: домовлені результати, дедлайни і відкриті двері для питань. Що відпускаю: як саме робиться робота. Сильні люди дуже швидко відчувають цю різницю.
Реальний приклад: дав фронтенд-розробнику задачу зробити адмінку в проєкті для клієнта. Він не тільки зробив її — він запропонував додати пошук по користувачах, чого клієнт не просив. Згодом ми самі запропонували це клієнту. Це і є різниця між просто виконавцем і людиною, яка дивиться на проєкт як на продукт. Саме простір для рішень робить другу можливою.
Легалізувати технічний борг
Він накопичується непомітно, а потім може дати проблеми у розробці. Час на рефакторинг — це регулярна інвестиція у стабільність системи.
«Легалізувати» — тут ключове слово. Борг накопичує будь-яка кодова база; різниця між командами в тому, чи можна про нього говорити вголос. Якщо рефакторинг трапляється лише тоді, коли хтось протягнув його контрабандою у фічевий бранч, ви насправді не знаєте, в якому стані ваша система. Тому борг лежить на дошці як звичайна робота — видимий, оцінений, пріоритезований.
Виграш приходить пізніше — коли «маленька зміна» справді маленька, бо фундамент під нею не прогнив.
Відкрито помилятися
Коли не боюся визнати свій провтик, команда теж перестає ховати свої помилки. Люди починають говорити про проблеми вчасно — до того, як усе впаде на проді.
Довіра в команді будується так само, як і в бізнесі: з малих послідовних дій, а не з великих жестів. Сказати вголос «я не знаю», принести погану новину вчасно — саме на це люди спираються насправді.
Протилежна культура коштує дорого. Команда, яка боїться виглядати некомпетентною, киває «зрозумів» на кожній зустрічі й нічого не питає. Одне вчасне уточнювальне питання коштує хвилину; переробка після неправильного припущення — спринт.
Що з цього випливає
Зауважте: жодне з цих п’яти правил не технічне. Керувати інженерною командою — це про середовище, де сильні люди можуть спокійно робити свою роботу. Код — це результат команди. Середовище — мій.