Открыть список
Как стать автором
Обновить

Комментарии 16

Наблюдая за компанией 9 лет, я вижу, что кратное увеличение количества инженеров приводит к падению скорости разработки.
Это классика, описанная давным-давно в знаменитой книге-бестселлере «Мифический человеко-месяц».
А еще это называется many cooks spoil the broth. Система распределения коллективной безответственности, выраженная еще 50 лет назад в «Костюме» Райкина-Жванецкого.
Цитата: «Целевую архитектуру вырабатываем вместе с бизнесом, фиксируем описание, планируем реализацию», «Далее фигачим, регулярно актуализируем видение, не забывая рассказывать о ключевых изменениях всем командам.»

То есть, всё-равно agile — наше всё. Только ещё и матричный: архитектура vs фичи.
НЛО прилетело и опубликовало эту надпись здесь
Фичи = деньги в руках. Архитектура = что-то магическое, что деньги (со точки зрения не технического бизнеса) только тратит.
Можно долго лукавить и говорить, что продакты давят по срокам, но разработчики тоже не хотят растягивать реализацию фичи. В конце концов команда дает оценки, не продакты. Часто разработчики не видят всей картины целиком и прямо сейчас для них не очевидна необходимость рефакторинга. Это становится очевидно после того как с кодом становится сложно работать.

Т.е. задача обеспечивать качества архитектуры лежит на разработчиках и, если мы не сумели объяснить бизнесу(продактам) почему мы не можем делать фичу без предварительного рефакторинга — это только наша вина.

Например, у каждого продукта есть конкуренты, которые тоже не дремлют. Пока вы не релизите новые фичи, это делают они, и их продукт, соответственно, становится более привлекательным для пользователей, а вы в этот момент пользователей теряете.
Спасибо, Олег! Это боль многих стартапов и решение кажется довольно неплохим. Единственная проблема которую вижу — не каждая компания доросла / успеет дорасти до момента когда руководство осознает и поддержит инициативу создания подобных команд. Фича тимы приносят деньги, рез-т можно легко померить. Как измерить эффективность подобной команды в деньгах вопрос открытый :)
ЗЫ: Миро желаю успехов и процветания ;)
Да, это правда. Спасибо за коммент
Спасибо большое за статью!
Спасибо за статью!
Можете предположите какие практики будут полезны в случае, если команд не так много, чтобы закреплять за ними определенные части системы и выделять отдельные core-команды?

Выделение 20% на рефаторинг уже есть, а согласование технического развития проекта с планами бизнеса взял на заметку, спасибо :)
1) Да, core-команды и правда не всегда нужны. Но закреплять владение за кодом нужно в любом случае, т.к. это напрямую влияет на качество архитектуры. Когда вы явно договариваетесь что этот человек отвечает за качество этого компонента, то риски там появится серьезные костыли значительно снижаются. Плюс не надо играть в игру «найти кто фиксит баг».

2) Так же стоит в процесс разработки ввести практику описания и ревью крупных технических изменений. Детали можно понять отсюда:
stackoverflow.blog/2020/04/06/a-practical-guide-to-writing-technical-specs

3) Если мы говорим про продуктовую разработку, то продакт-менеджер или тот кто выполняет его роль, должен быть часть команды, а не внешним заказчиком по отношению к ней. Это радикально меняет культуру и отношения между разработчиками и бизнесом. Это отдельный большой топик, но если вы не можете назвать продакта частью команды — это повод задуматься.
Спасибо!
С технической точки зрения от закрепления команд за компонентами действительно только плюсы, а вот с организационной — как вы справляетесь с неравномерной нагрузкой по командам, работающих над разными компонентами(не всегда же есть фичи, которые затрагивают сразу все)?
Конкретно у нас сейчас такая ситуация, что у каждой команды задач больше чем она в силах прожевать. Так что о простое речи не идет. Но для команд, у которых самый сильный недостаток в людях, повышается приоритет в хайринг плане. Т.е. в них людей нанимаем в первую очередь.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
miro.com
Численность
501–1 000 человек
Дата регистрации
Представитель
Сергей Шабалин

Блог на Хабре