Як кількість та рівень розробників впливає на time to market. Закон Брукса

Мене звати Андрій Попович, я CTO однієї з продуктових компаній venture builder SKELAR. Ми будуємо продукт, де користувачі можуть взаємодіяти навколо контенту.

У 2019 році ми зіштовхнулись з проблемою — нас не влаштовував час, за який фіча з моменту ідеї попадає до кінцевого юзера (time to market). Ми вже мали на той момент команду з 10 інженерів, але все одно хотіли рухатись швидше. І коли ти думаєш над питанням «як нам рухатись швидше», дуже часто перше, що приходить в голову, — «найняти більше інженерів». Але цей підхід далеко не завжди допомагає, а інколи взагалі може бути шкідливим для компаній. Про це й піде мова в матеріалі.

Щоб з цим розібратись, пропоную розглянути на прикладі абстрактної компанії, яка тільки починає своє існування. І робити ми це будемо за допомогою наступного графіка, де по вертикалі — time to market (чим він менший, тим краще, бо ми можемо робити більше фіч при однаковій пропускній здатності команди), а по горизонталі — кількість інженерів, які працюють в команді.

Чому зростання команди не завжди «плюс»

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

Залежність time to market від кількості інженерів

На самому початку ми наймаємо інженера, який починає розробку рішення. На даному етапі time to market буде сильно залежати від seniority цього розробника. Зрозуміло, що senior має робити задачі швидше, ніж junior-спеціаліст.

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

Якщо ми продовжимо додавати інженерів в команду, то з часом ми помітимо, що цей підхід не дозволяє масштабувати команду вічно зі зменшенням time to market. Фредерік Брукс у своїй книжці «Міфічний людино-місяць» говорить про те, що в системах зі складними залежностями в певний момент наступає ситуація, коли додавання нових інженерів в команду не пришвидшує її, а навпаки сповільнює.

Після найму N співробітників time to market починає рости з кожним новим членом команди

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

n — кількість людей в команді

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

Як визначити кількість інженерів (число N), після якої time to market починає рости

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

Проте є пряма залежність цього числа N від рівня розробників в команді (при сталій складності продукту і кодовій базі).

Динаміка time to market в залежності від кількості інженерів в команді та їхнього рівня

З цього графіка можна помітити, що в першому варіанті після наймання N1 джунів, які працюють в рамках однієї системи, ми проходимо перегин і time to market починає рости з кожним новим членом команди. Тобто, час на розробку фічі зростає.

В другому варіанті senior спеціалісти на початку існування проєкту закладають правильну архітектуру, компоненти та процеси. В якийсь момент ця архітектура дозволить нам найняти junior-спеціалістів, не витрачаючи багато часу на синхронізацію їхньої роботи. Тобто, ми можемо забезпечити менший time to market ніж в першому варіанті.

Ну, і третій варіант, коли в рамках однієї системи працюють виключно senior спеціалісти, то вони зможуть досить довго працювати в рамках однієї системи з досить низьким time to market.

То що, наймати джунів не можна?

Якщо дивитись виключно на ті графіки, які я навів, то дійсно можна прийти до такого висновку. Проте це не так.

Існує багато інших вимірів, які також потрібно враховувати, відповідаючи на це запитання. Наприклад, складність системи, яка також сильно впливає на time to market чи витрати на команду. Зрозуміло, що робота senior спеціалістів набагато дорожча, ніж junior-розробника.

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

Динаміка time to market та витрат на команду в залежності від кількості інженерів у команді та їхнього рівня

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

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

Що робити, коли наймати вже не можна

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

По факту, я бачу 2 варіанти, що можна зробити, коли ви знаходитесь на цьому вигині:

1. Рефакторити та спрощувати систему, щоб вона вимагала меншої синхронізації розробників, які працюють в рамках неї (виділяти модулі, мікросервіси, додавати абстракції, стандартизації тощо).
2. Розділяти команду на дві, щоб різні групи розробників могли автономно працювати над різними фічами. І це дуже складна тема, на яку написано багато книжок.

Як правило ці два пункти дуже повʼязані між собою і часто складно розділити систему на команди без попереднього рефакторингу.

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

При однаковій загальній кількості інженерів 2 команди будуть показувати швидший time to market ніж одна команда

Звісно, збільшення кількості команд викликає появу інших запитань. Наприклад, як координувати їхню роботу? Як саме розділити ці команди? За яким принципом?

Але це вже зовсім інша велика тема для окремого матеріалу. Для тих, хто хоче детальніше розібратись в цьому питанні є багато книг, наприклад: «Team Topologies: Organizing Business and Technology Teams for Fast Flow» By Matthew Skelton and Manuel Pais.

Тож, закривати проблеми високого time to market найняттям додаткових інженерів можна далеко не завжди. Інколи це навпаки може сповільнити проєкти, особливо якщо розглядати варіант найняття junior-спеціалістів. В якийсь момент проєкт все одно може зіштовхнутись з тим, що система вже занадто складна і її потрібно спрощувати, чи з тим, що людей в команді вже забагато і їх потрібно ділити на підкоманди.