Декомпозиция отдела разработки
Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.
Как обычно устроен департамент разработки
рис. 1. Стандартная схема департамента разработки
Всё казалось бы хорошо и это вполне жизнеспособная модель, до того момента, пока не начинаются следующие проблемы:
Рост числа продуктов. Нужно нанимать либо новых людей, либо переводить команду на новый продукт, но при этом старый продукт никуда не девается. Влечет за собой рост числа разработчиков, рост затрат на разработку и поддержку.
Bus фактор — ушёл ключевой разработчик, какой-нибудь тимлид и продукт начинает рассыпаться под вопросами — почему реализовано так, а не иначе, почему работает именно так, а по другому не работает, что с чем связано и почему нельзя удалить этот «ненужный сервис». Зачастую это приводит к разработке продуктов с нуля и постепенному переносу части старой функциональности в «новый и красивый» продукт. Через время всё повторяется.
Устаревание кода — Вы выпустили продукт, он работает, а команда перешла на разработку второго, третьего продукта. И вдруг требуется внести правки в давно выпущенный продукт, а там Вы обнаруживаете устаревшие библиотеки, старую декомпозицию, забытые костыли т.д. Ещё хуже может быть когда продукт выпущенный 3 года назад вдруг ломается и никто не помнит что там и как. Я не говорю уже об угрозах безопасности и быстродействии.
Адовый Onboarding — разработчики приходят и уходят, а продукт остается. Теперь представьте себе ситуацию, когда надо ввести джуна, мидла или не дай бог сениора на большой проект, который разрабатывался 5 лет, имеет сотни апишек, десятки сущностей и миллионы разных нюансов. Это же касается и перехода разработчиков между продуктами.
Где документация? Проблема заключается в том, что когда вы погружены в продукт — многие вещи Вам кажутся естественными и даже если вы стараетесь вести документацию, зачастую она далеко не полная.
Одинаковые вещи в разных продуктах. Пилят по своему, со своими костылями, получается пустая трата человеко-часов, особенно когда на каком-нибудь демо 3 разные команды показывают как они запилили одни и те же вещи.
Есть ещё много связанных проблем, Я лишь обозначил самые явные.
Как же быть?
Я предлагаю следующий подход:
рис. 2. Функциональные команды
Функциональные команды вместо продуктовых
Чтобы не дублировать компетенции в разных продуктах, не дублировать одинаковые сервисы, получить некую унификацию технологий Я предлагаю сосредоточиться на функциональных командах разработки, вместо продуктовых. Например сейчас у нас в компании Я выделяю 6 функциональных команд:
команда по приему и хранению данных (самый highload проекта)
команда обработки данных (пилят апишки для взаимодействия с данными)
команда интеграций (с оборудованием, другими сервисами и контрагентами)
интерфейсная команда (наш фронтенд)
команда тестирования
команда DevOps (CI/CD и поддержка)
Какие плюсы?
Библиотечный подход. Так как команды сосредоточены на своей функциональной области, они могут выработать общие паттерны работы, лучшие практики и заложить их в функциональные библиотеки, которые будут переиспользоваться между продуктами. Библиотеки будут покрыты тестами и задокументированы, потому что им не надо распыляться на весь продукт, они сосредоточены на своей компетенции.
Ускорение разработки новых продуктов. За счет того, что каждый продукт это набор функциональных модулей, продукты можно собирать как кубики lego уже из имеющихся библиотек. Нужно будет лишь немного подпилить напильником под нужные требования.
Отпадает необходимость в раздувании штата разработчиков.
Упрощение поддержки. Так как вы пользуетесь одним и тем же набором инструментов из раза в раз, отследить баг в любом из продуктов гораздо проще и быстрее.
Bus фактор не такой болезненный, т.к. от конкретного разработчика теперь не так сильно всё зависит.
Опять таки это не все плюсы, Я выделил самые явные.
Как оно должно работать
За каждым продуктом также остаются аналитики и ПМ-ы.
Аналитики составляют бизнес требования выделяют сущности и расписывают их взаимодействия, составляя тем самым первый уровень документации.
Затем, с тимлидами команд, бизнес требования и сущности разносятся по функциональным областям.
Далее пишется более техническая документация как и что должно работать, с какими библиотеками и сервисами.
По документации выставляются задачи, которые уже берут разработчики.
ПМ-ы курируют задачи по своему продукту и контролируют сборку продукта воедино согласно документации.
Тестеры покрывают продукт E2E тестами.
При появлении новых требований, шаги со 2 по 7 повторяются.
Естественность процесса
Те, кто работал в компаниях над разными продуктами думаю замечали, что функциональные компетенции складываются естественным образом даже внутри продуктовых команд, ведь кто-то хорошо может написать сложные взаимодействия и апи-шки, а кто-то упарывается по highload. Проблема в том что эти компетенции заперты внутри продукта, они не развиваются и не делятся опытом с другими разработчиками, запертыми на других продуктах.
К тому же на разработчиках зачем то висит бремя знаний о всей работе и нюансах продукта, они становятся точкой истины. Хотя у продукта есть аналитки и ПМ-ы, которые должны разбираться в своём продукте лучше всех.
Есть ли минусы?
Конечно, минусы есть в любом подходе, иначе бы подход без минусов применялся везде.
Например тут уже не будет возможности не документировать продукт, потому что нет документации — нет продукта, а это временное снижение скорости, пока к подходу не привыкнут. Также возрастёт важность ПМ-ов, по контролю хода разработки.
Думаю при ознакомлении с материалом у Вас сразу возникли возможные проблемы в голове, так что не вижу смысла их описывать.
Однако плюсы представленного подхода сильно перевешивают его минусы (для меня), поэтому и был написан данный материал.
В итоге
В итоге советую хотя бы мысленно прикинуть, какие проблемы в вашей компании данный подход может решить и стоит ли это тех минусов, которые он породит.
Спасибо за внимание
