Коротка відповідь
Стафінг (staff augmentation) додає окремих підрядників у вашу наявну команду й процес. Вони з'являються на ваших стендапах, отримують завдання від вашого лідера, працюють у ваших інструментах, і ви керуєте ними так само, як будь-яким іншим інженером у штаті — з тією різницею, що вони в платіжній відомості підрядника, а не вашій. Виділена команда відрізняється не просто масштабом, а самою природою: це самодостатній підрозділ, зазвичай зі своїм лідом або проєктним менеджером (PM), який відповідає за напрям роботи чи продуктову область відповідно до узгоджених результатів, працюючи за процесом підрядника, а не вашим.
Більшість порівнянь подають це як питання чисельності штату чи ціни. Це не так. Реальна різниця — хто бере на себе ризик постачання результату і хто здійснює щоденне управління. У випадку стафінгу це завжди ви. У випадку виділеної команди це підрядник — так задумано. Усе інше — тривалість контракту, час на розгортання, структура вартості — випливає саме з цієї відмінності.
| Стафінг | Виділена команда | |
|---|---|---|
| Хто керує щоденно | Ви — планування спринтів, розподіл завдань, рев'ю коду | Лід/PM підрядника, який звітує вам про результати |
| Хто відповідає за постачання результату | Ви. Підрядник постачає години, а не результат | Підрядник. Він відповідає за те, щоб напрям роботи був доведений до релізу |
| Час на розгортання | Швидше залучити людину, повільніше вийти на повну продуктивність без щільного онбордингу | Повільніше зібрати команду як єдине ціле, але швидше вийти на стабільний темп роботи, щойно вона запрацює |
| Кому найкраще підходить | У вас уже є сильний PM/лід і робочий процес | Вам бракує внутрішніх ресурсів або процесу, щоб щільно вести новий напрям роботи |
| Типова тривалість контракту | Коротка чи середня — закриває конкретну, часто тимчасову потребу | Довша — прив'язана до продуктової області чи постійної дорожньої карти |
| Структура вартості | Нижча погодинна ставка, але управлінське навантаження — ваше | Вища повна ставка, але вона вже включає управління і QA |
Коли стафінг — правильний вибір
Стафінг добре працює, коли потреба, яку ви закриваєте, вузька, а у вас самих уже все влаштовано. На це вказують три сигнали:
- У вас є сильний PM або технічний лід усередині компанії. Хтось у вашій команді вже веде планування спринтів, робить рев'ю коду й ухвалює архітектурні рішення. Додавання підрядника просто дає цій людині більше рук, якими можна керувати.
- Вам потрібна конкретна навичка, а не команда. Можливо, вам потрібен ще один сеньйор бекенд-інженер на квартал, поки ви завершуєте міграцію, або людина, яка вже реально запускала Kubernetes у продакшені. Це прогалина в навичках, а не в управлінській спроможності.
- Ваш процес уже усталений. У вас працює CI/CD, є чітке визначення готовності (definition of done) і культура рев'ю. Вам просто потрібно більше людей, які виконуватимуть роботу в межах цього процесу, — а не новий процес, побудований навколо них.
У цьому режимі підрядник — це, по суті, тимчасовий співробітник. Нижча погодинна ставка виправдана тим, що ви не платите за чийсь управлінський прошарок — ви забезпечуєте свій власний.
Стафінг виглядає дешевшим у рахунку, і в перерахунку на годину зазвичай так і є. Але прихована вартість — це управлінське навантаження, яке бере на себе ваша власна команда: писати тікети настільки детально, щоб їх зрозуміла людина, не знайома з вашим кодом, перевіряти її PR рядок за рядком, добудовувати контекст, якого їй бракує, бо ніхто не відповідає за те, щоб цей контекст їй дати. Повна ставка виділеної команди вища, але вона вже покриває ліда, який виконує це управління, і процес QA, що ловить проблеми ще до того, як вони дійдуть до вас. Чесне порівняння має враховувати час вашої власної команди, а не лише зіставляти два рахунки. Чимало «дешевших» стафінг-контрактів у підсумку виходять дорожчими, щойно порахувати години, які ваші сеньйор-інженери витрачають на те, щоб няньчитися з підрядниками.
Коли виділена команда — правильний вибір
Розверніть ситуацію навпаки — і виділена команда матиме більше сенсу:
- Ви запускаєте щось нове. Новий продукт, нову платформу, напрям роботи, у якого з вашого боку ще немає власника з ресурсом, щоб щільно ним керувати.
- Вам потрібна відповідальність за результат, а не за кількість людей. Ви радше скажете «випустіть цей набір функцій до такої дати» і дозволите підряднику самому вирішувати питання зі штатом, ніж керуватимете окремими виконавцями самостійно.
- Вам потрібна команда, яка може працювати з меншим наглядом з вашого боку. У вас немає часу сидіти на щоденних стендапах заради напряму роботи, який не є вашим основним фокусом, але вам усе одно потрібна видимість прогресу — зазвичай через регулярні робочі демо з передбачуваною періодичністю, а не через постійні перевірки.
Це ближче до аутсорсингу цілого напряму роботи, ніж до найму додаткових рук. Ви купуєте процес і команду, які вже вміють працювати разом, а не збираєте команду самостійно з окремих людей. Наш власний процес постачання побудований саме на цьому: робочі демо приблизно кожні два тижні, тож ви отримуєте реальну видимість, не керуючи командою щодня.
Де кожна модель дає збій
Більшість невдалих результатів тут насправді не пов'язані з інженерами підрядника. Вони пов'язані з невідповідністю між обраною моделлю та реальною управлінською спроможністю клієнта.
- Стафінг дає збій, коли управлінського ресурсу насправді немає. Лід команди каже «просто додамо підрядника», але цей лід і так перевантажений. Підрядник наполовину простоює в очікуванні вказівок, береться за неоднозначні тікети, вгадує неправильно і витрачає години на переробку. Клієнт звинувачує в цьому якість підрядника. А реальна проблема в тому, що ні в кого не було часу ним керувати.
- Виділені команди дають збій, коли клієнту насправді потрібен щільний контроль. Деякі клієнти кажуть, що хочуть відповідальності за результат, але насправді хочуть переглядати кожен PR і затверджувати кожне архітектурне рішення. Це нормально — але це стафінг із зайвими кроками, а не виділена команда, і нав'язування моделі виділеної команди такому клієнту призводить до тертя: він відчуває, що втратив видимість, підрядник відчуває, що його рішення, за які його й найняли відповідати, постійно ставлять під сумнів, а напрям роботи застрягає в суперечках замість того, щоб просуватися до результату.
Жоден із цих провалів насправді не пов'язаний із рівнем навичок підрядника. Це невідповідність між тим, наскільки глибоко клієнт хоче (чи має час) бути залученим щодня, і тим, що передбачає обрана модель співпраці. Чесно оцініть свою реальну управлінську спроможність, перш ніж обирати модель лише виходячи з бюджету.
Як ухвалити рішення
Якщо не впевнені, яка модель підходить, поставте собі одне запитання: якщо цей напрям роботи вийде із запізненням або зламається в продакшені, чиєю роботою було це запобігти? Якщо відповідь «нашою, бо ми ним керували» — стафінг є правильною рамкою: ви вже виконуєте роботу з відповідальності, просто додайте потужностей. Якщо відповідь має бути «підрядника, бо ми передали йому відповідальність за результат» — вам потрібна виділена команда, і варто побудувати співпрацю — і контракт — так, щоб ця відповідальність справді лягала на нього.
Не впевнені, яка модель підходить саме вам?
Розкажіть, що ви хочете реалізувати і наскільки глибоко готові керувати цим самостійно. Ми чесно скажемо, яка модель має сенс — навіть якщо це не та, що залучає нас найбільше.
Поширені запитання
Чи можна почати зі стафінгу, а пізніше перейти на виділену команду?
Так, і це поширений шлях. Команди часто починають з одного-двох підрядників за моделлю стафінгу, щоб перевірити, як складається співпраця, а потім переходять на виділену команду, щойно напрям роботи виростає настільки, що виправдовує власного ліда й процес. Зворотний напрям — розбити виділену команду назад на окремих підрядників — трапляється рідше, але теж можливий.
Виділена команда працює за нашими інструментами/процесом чи за своїми?
Зазвичай за своїми — у цьому й суть: ви купуєте команду, яка вже вміє керувати собою, включно з власним ритмом спринтів, стандартами рев'ю коду й процесом QA. Водночас більшість виділених команд працюватимуть у вашій системі тікетів і комунікаційних інструментах, щоб у вас була видимість без потреби переходити на їхні внутрішні інструменти.
Наскільки швидко кожна модель виходить на робочий темп?
На папері стафінг стартує швидше — окремий підрядник часто може почати вже за тиждень-два — але без щільного онбордингу довше виходить на повну продуктивність, оскільки йому потрібно вбудуватися у ваш наявний контекст. Виділену команду довше зібрати як єдине ціле, але оскільки команда вже працювала разом раніше, вона зазвичай швидше виходить на стабільний, передбачуваний темп роботи, щойно реально запускається.
Яку модель насправді використовує Hardened Soft?
Ми переважно працюємо як виділена команда, а не як суто стафінг за кількістю голів. Ми беремося за окремі проєкти зі стафінгу, коли це справді доречно — зазвичай коли у клієнта вже є сильний внутрішній лід і потрібен лише додатковий сеньйор-інженер, — але за замовчуванням ми беремо на себе відповідальність за напрям роботи за результатами, коли наш власний лід керує постачанням і звітує вам про прогрес.