Скільки має бути команд? Відповідь на це питання класична — it depends.
Ситуація
Ось яка історія була у мене:
- проект стартував з 5 команд (по 2-3 людини):
- 3 бекенд команди під три окремих групи підсистем
- 2 фронтенд команди під user facing фронти та бекофіси внутрішні і для партнерів
- через 2 роки: об’єднали бекендшиків у 2 команди
- в такому режимі компанія працює от вже 3 роки (бекендщики 4-5 людей на дві команди. Фронти 3-5 людей на основних фронтах, 1 людина на бекофісі)
Які тепер є проблеми
- буйний ріст закінчився, всі очевидні фічі заімплеменчені, по інерції продовжуємо рухатись як Feature Factory
- незбалансований пул задач під різні команди в кварталі. Якісь команди перевантажені, а іншим доводиться вигадувати собі роботу
- підвищений бас фактор, особливо в команді з однієї людини
- бекофіс команда має додаткові проблеми, так як middle фронтенд розробник не може самотужки забезпечити надійне майбутнє проекту, його треба весь час контролювати. Шукати на цей напрям senior — дорого
- поганий knowledge sharing — тільки окремі розробники наважуються дивитись як працюють сусідні частини проекту
- невиправдане ускладнення планування — проджект менеджеру треба весь час синхронізувати команди, балансувати їх навантаження і шукати як закрити прогалини у навантаженні
- продакт менеджер один і так як по фічам ми вийшли на плато, то фокус йде в більш вузьких напрямках. Продакт не займається рівномірною генерацією функціоналу під кожну підсистему (команду) — він розвиває продукт. Відповідно, якщо продукт розділений на багато команд, то якась з команд може випасти з області фокусу
- якщо тех борг по збігу обставин сфокусувався в найзавантежнішій частині проекту — це взагалі джек пот. В результаті незавантажена команда займається оптимізаціями і позбавляється від тех боргу (бо а що ж робити?), а та команда, яка потребує час на технічні задачі, такий час отримати не може
Рішення
Дивлячись на проблеми рішення напрошується саме собою — проект досяг чергового етапу розвитку і багато команд перестали бути ефективними. Зменшення кількості команд має вирішити ледь не всі вище перераховані проблеми.
Впроваджується це як екперимент. За людьми залишається експертність в певних частинах проекту. Пул задач потрохи буде розмазуватись між людьми, які раніше були задіяні в інших напрямках.
Плани на майбутнє: коли всі звикнуть до нового режиму хочеться піти ше далі і спробувати створювати тимчасові міні кросфункціональні команди на виконання якогось великого епіку і подивитись як це вплине на результат.