Як побудувати ефективну організаційну структуру в команді розробки. Історія від СТО

Усім привіт, це Андрій Попович, я займаю посаду CTO в TENTENS Tech by SKELAR. У цій статті пропоную поговорити от про що. «Як пришвидшити нашу команду розробки?» — це питання я, як СТО, собі ставив дуже часто. Адже кожному бізнесу дуже важливо рухатись так швидко, наскільки це можливо. Чим швидше бізнес зможе адаптуватись під обставини, тим стійкішим він є.

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

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

Як організаційна структура впливає на швидкість компанії

У 2019 році, коли нас було близько 100 осіб, ми вперше вирішили ретельно підійти до зміни нашої організаційної структури. Тоді ми помітили проблему у нашому цілепокладанні — команди часто не досягали поставлених цілей.

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

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

Звісно, я дещо спрощую ситуацію, яка тоді була. Але це дає змогу показати справжню проблематику.

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

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

На що варто звертати увагу при створенні та зміні організаційної структури

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

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

1. Враховуйте комунікації та взаємодію

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

Адже, якщо в рамках виконання задачі frontend-інженер зрозуміє, що backend-інженеру потрібно зробити зміни в АРІ контрактах, то в рамках однієї команди розв’язати це питання буде дуже просто. Якщо ж ці інженери будуть у двох різних командах, то frontend може досить довго чекати, поки backend внесе зміни.

Колись ми цей факт не врахували й створили функціональні команди (backend, frontend, QA, DevOps, desing). Але, як я показав на прикладі вище, в рамках виконання задачі інженери часто спілкуються з іншими функціями, а не в рамках своєї.

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

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

2. Архітектура

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

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

Наприклад, якщо у вас сильно зв’язаний моноліт, то створення декількох команд, які будуть вносити в нього зміни, вас не пришвидшить, а скоріше навпаки — сповільнить. Уявіть, якщо в рамках однієї системи одна з команд завжди буде брати на себе технічний борг (бо їм потрібно рухатись максимально швидко), а інша буде робити якісні рішення.

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

І тут не йде мова про holly war між монолітом та мікросервісами. Моноліт також можна зробити модульним з автономністю між модулями. В цьому плані я прихильник Monolith First approach, коли спочатку розроблюється модульний моноліт, а потім, за необхідності, він розпилюється на мікросервіси.

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

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

3. Кількість людей в команді

Є багато рекомендацій на цю тему, по типу «two pizza team». Особисто я рекомендую робити команди в розмірі від чотирьох до дванадцяти осіб. Мені доводилось бачити команди, розмір яких виходив за ці рекомендації й можу сказати, що в обох випадках вони працювали менш ефективно, ніж команди з цільовим розміром.

Ось що Вілл Ларсон (CTO Calm, ex-Uber, ex-Stripe) у своїй книзі An Ellegant Puzzle каже про маленькі команди: «Teams with fewer than four individuals are a sufficiently leaky abstraction that they function indistinguishably from individuals».

При чому автор зазначає, що він шкодував кожного разу, коли робив команди з 2-3 осіб. Я можу з ним тільки погодитись, бо сам неодноразово робив такі неповноцінні команди і завжди про це шкодував. Такі команди мають завеликий bus-factor, малу кількість альтернативних думок, меншу гнучкість.

Звісно, існують винятки. Наприклад, коли проєкт тільки починає своє існування, в команді може бути лише 1-2 інженери, і це нормально. Проте коли проєкт масштабується і є бажання створити нові команди, то я б не рекомендував робити команду з менше ніж чотирма особами.

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

Команда, яка складається з 12 осіб має 66 звʼязків, з 13 осіб — вже 78. Звісно, в якийсь момент підтримувати таку кількість звʼязків стає не дуже раціонально.

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

Як створювати нові команди

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

1. Виходьте з бізнес-потреб та цілей

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

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

• За інтерфейсами: команда продукту для користувачів і інша команда продукту для креаторів. Такий варіант дозволяє нам паралельно та незалежно розвивати два різних продукти, але тоді нам буде складно досягати цілей, які завʼязані на двох продуктах одночасно (наприклад, метрика — середній рейтинг курсу).
• За функціоналами команда, яка відповідає за «курс», команда, яка відповідальна за платформу і т.д.. Таким чином команда, яка відповідає за «курс» буде реалізовувати його одразу в обох інтерфейсах. Це дасть нам змогу ставити цілі за метриками в рамках конкретного функціонала, але в такій структурі нам складніше забезпечити консистентність інтерфейсів.

Можна поділити команди, як першим, так і другим варіантом. Вони обидва працюватимуть, питання тільки в ефективності, оскільки кожен з цих варіантів несе свої обмеження та енейблери. Щоб зрозуміти, який варіант вам підходить більше, потрібно відповісти на запитання: які цілі є перед вашим бізнесом? Яка візія вашого продукту? Які у вашого бізнесу плани?

Зручний інструмент, який дозволить вам краще окреслити команди і їх зони відповідальності — це Domain Driven Design, конкретно підхід Bounded Context та Context Map.

2. Спочатку збільште поточну команду, а потім розділіть її

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

Відповідно до моделі Такмана, кожна команда проходить наступні стадії:

• forming (формування команди),
• storming («притирання» учасників один до одного),
• normalizing (нормалізація роботи),
• performing (вихід на необхідний рівень перформансу).

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

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

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

Тому, як на мене, найкращий спосіб створення нової команди виглядає наступним чином:

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

Замість висновку

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

• Виходьте з бізнес-потреб. Нова структура має сприяти досяганню бізнес-цілей.
• Враховуйте комунікації та взаємодію в рамках поточної команди, як орієнтир на те, як мають бути проведені межі між командами.
• Враховуйте архітектуру. Вона може виявитись серйозним блокером для приведення команди до бажаного виду (або ж навпаки енейблером).
• Найкращий спосіб створити нову команду — розділити існуючу.
• Тримайте баланс між кількістю людей в команді. Від малих команд ви не отримаєте плюсів «командності», а отримаєте тільки мінуси. В той самий час нескінченно довго наймати також не вийде, оскільки ви будете багато втрачати на комунікації. До речі, в минулій статті я детальніше розповідав, як кількість розробників впливає на time to market команди.

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

• Team Topologies: Organizing Business and Technology Teams for Fast Flow. Matthew Skelton, Manuel Pais.
• An Elegant Puzzle — Systems of Engineering Management. Will Larson.
• Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing. Technology Organizations. Nicole Forsgren, Jez Humble, Gene Kim.