Коли потрібен тех-лід, а коли достатньо розробника.

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

Це текст людини, яка 11 років пише на PHP та Laravel і знає обидві ролі зсередини, тому багато прикладів нижче типові для проєктів на Laravel, але логіка застосовна до будь-якого стеку.

Хто такий тех-лід і чим він відрізняється від розробника

Розробник вирішує задачу: зробити функцію, виправити баг, інтегрувати API. Тех-лід відповідає за те, щоб набір таких задач складався в працюючий, підтримуваний продукт.

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

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

Що саме робить тех-лід

Конкретні задачі, а не загальні слова:

• Архітектура. Вибір структури застосунку, меж модулів, способу зберігання даних, кешування, черг. Фіксація рішень у коротких документах (ADR): що вирішили, чому, які були альтернативи.
• Код-рев'ю. Перевірка змін перед злиттям: коректність, безпека, продуктивність, відповідність домовленостям. Рев'ю також навчає команду.
• Стандарти й автоматизація. Лінтери, статичний аналіз (наприклад, PHPStan або Larastan), правила гілок, CI з тестами. Це робиться раз і далі працює без нагадувань.
• Оцінка й планування. Розбиття функціоналу на задачі, виявлення ризиків і залежностей, чесна оцінка термінів із вказанням невизначеності.
• Технічний борг. Рішення, що виправляти зараз, а що лишити, з розрахунком вартості відкладення.
• Вибір і перевірка підрядників та технологій. Оцінка чужих пропозицій, чужого коду, виявлення завищених кошторисів і ненадійних рішень.
• Міст до бізнесу. Переклад із мови вимог на мову технічних компромісів і навпаки.

Ознаки, що вам потрібен тех-лід

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

1. Кожен реліз ламає щось сусіднє. Це сигнал, що немає тестів і меж між модулями, і ніхто не відповідає за цілісність.
2. Оцінки постійно зриваються. Задачі «на два дні» тривають тиждень. Причина часто не в лінощах, а в прихованій складності, яку ніхто не розібрав заздалегідь.
3. Нова людина входить у проєкт місяцями. Немає документації, стандартів, зрозумілої структури, а все знає одна людина.
4. Залежність від одного розробника. Якщо він піде або захворіє, проєкт зупиниться. Це бізнес-ризик, а не лише технічний.
5. Повільний сайт або падіння під навантаженням, а причини не знайдені. Хтось гасить пожежі, ніхто не розбирається з системними причинами.
6. Незрозуміло, скільки це має коштувати. Підрядник називає суму, а ви не можете оцінити її адекватність.
7. Рішення ухвалюються «як вийде». Різні частини системи написані в різних стилях, є три способи зробити те саме.
8. Стратегічні питання без відповіді. Переписувати чи латати, переходити на інший стек, робити мікросервіси чи лишити моноліт.

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

Коли достатньо розробника

Тех-лід не завжди потрібен, і не варто ним переплачувати. Розробника достатньо, якщо:

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

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

Типові сценарії, коли тех-лід рятує проєкт

Нижче узагальнені ситуації, з якими ми стикаємося. Це не конкретні клієнти, а патерни.

Сценарій 1. Старт нового проєкту

На етапі старту найдорожчі помилки: вибір стеку, структура даних, межі між модулями. Виправляти їх через рік коштує у рази більше. Тут достатньо тех-ліда на 5–10 годин у тиждень: він складає технічний план, ухвалює ключові рішення і налаштовує процеси, а реалізують розробники.

Сценарій 2. «Успадкований» код

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

Сценарій 3. Вибір і контроль підрядника

Ви наймаєте студію чи фрилансера, але не можете перевірити їхні оцінки й код. Тех-лід з вашого боку складає вимоги, оцінює пропозиції, рев'юїть результат на етапах. Це страхує від переплат і від проєкту, який «ніби готовий», але не підтримується. Питання, які варто поставити підряднику, ми зібрали окремо: 12 питань перед вибором підрядника.

Сценарій 4. Команда є, а результат непередбачуваний

Розробники хороші, але терміни зриваються, а якість нерівна. Часто тут не потрібно міняти людей, потрібні стандарти, рев'ю та тест-стратегія. Тех-лід вводить ці практики за кілька тижнів і далі лише підтримує.

Сценарій 5. Масштабування і повільна робота

Сайт повільнішає, база росте, виникають блокування й повільні запити. Типова причина в Laravel-проєктах: N+1 запити, відсутні індекси, важкі синхронні операції, які варто виносити в черги. Тех-лід швидко знаходить вузькі місця за профілюванням і ставить задачі в порядку впливу.

Формати співпраці з тех-лідом

Тех-лід не обов'язково штатна одиниця на повний день. Для малого й середнього бізнесу найчастіше працює фракційний формат.

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

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

Не впевнені, що вам потрібно? Почніть із консультації тех-ліда на 90 хвилин: розберемо проєкт, ризики й скажемо, чи потрібен вам тех-лід постійно, чи вистачить розробника. Тех-лід на аутсорсі, від 3 000 грн.

Скільки часу тех-ліду потрібно на проєкт

Запитання, яке ставлять найчастіше: скільки годин на тиждень потрібно? Єдиної відповіді немає, але орієнтири з практики такі (оціночні, залежать від проєкту):

• Старт проєкту, перші 2–4 тижні: 8–15 годин на тиждень. Це найінтенсивніший період: архітектура, налаштування CI, перші рев'ю, розбиття на задачі.
• Стабільна розробка командою з 2–3 людей: 4–8 годин на тиждень. Рев'ю, відповіді на технічні питання, планування наступних ітерацій.
• Підтримка вже запущеного продукту: 2–4 години на тиждень або за запитом: складні інциденти, оцінка нових фіч, контроль технічного боргу.

Якщо хтось пропонує «тех-ліда на 40 годин» для проєкту з однією людиною в команді, це швидше за все розробник із гучнішою назвою. Перевіряйте, що саме входить у роботу: рішення й рев'ю чи лише написання коду.

Як зрозуміти, що тех-лід працює добре

Якщо ви найняли тех-ліда, ось ознаки результату, які можна перевірити без глибоких технічних знань:

• з'явилися письмові рішення. Хоча б короткі записи: що вибрали й чому;
• реліз став рутиною. Деплой не вимагає героїзму й не ламає сусідніх функцій;
• оцінки стали точнішими. Відхилення зменшуються, а ризики озвучуються заздалегідь;
• код-рев'ю проходять усі зміни. І це не формальність: у коментарях видно змістовні зауваження;
• нова людина входить у проєкт за дні, а не за місяці. Є README, інструкція запуску, угоди щодо стилю;
• ви розумієте, що відбувається. Тех-лід пояснює технічні речі мовою бізнесу: що, навіщо, скільки.

Якщо ж після кількох місяців нічого з цього не змінилося, а тех-лід лише «багато пише коду», то вам, ймовірно, потрібен просто senior-розробник, і це нормально, тільки платити за іншу роль не варто.

Помилки при наймі тех-ліда

• Шукати «героя», який усе зробить сам. Тех-лід налаштовує систему, а не замінює її.
• Не давати повноважень. Якщо тех-лід може лише радити, а рішення ухвалюються поза ним, користь мінімальна.
• Плутати з архітектором-теоретиком. Хороший тех-лід регулярно пише код або хоча б читає його, інакше рішення відриваються від реальності.
• Наймати на повний день, коли вистачить частини. Для проєкту на 2–3 розробників зазвичай достатньо кількох годин на тиждень.
• Не перевірити досвід на реальних проєктах. Попросіть розповісти про конкретні рішення, їхні наслідки й помилки. Чесна розповідь про провали каже більше, ніж список технологій.

Підсумок

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

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

Хочете розібратися, яка роль потрібна вашому проєкту? Розкажіть про задачу, і ми підкажемо, достатньо розробника чи потрібен тех-лід, без зобов'язань. Написати нам.