Как управлять командами в рамках одного проекта?

Всем привет

Стало интересно, как управлять большим количеством команд, скажем, порядка 20 команд компании, вовлеченных в один проект. Например, есть проект, и 20 команд по 4-5 разработчиков, плюс архитектор над ними.

Если проект с небольшим количеством команд, лид или архитектор может раздавать директивы и контролировать качество решений, потому что кода проходит не очень много, и сделать ревью можно.

Если мы имеем много команд с разной экспертизой, то физически проверить и скорректировать изменения нельзя (не хватит времени в пределах, скажем, спринта). Поэтому выходит что ответственность по ревью (или полностью, или всё кроме архитектуры) нужно делегировать лидам команд.

Если делегировать ответственность на лидов команд, выходит что общий уровень качества обеспечивается только уровнем команд, а сам архитектор только задает направление и работает с высокоуровневыми вещами. Тогда получается что архитектор сам по себе один в поле не воин, и если команды не высокого уровня, в продукт будут пролазить технические проблемы (может быть даже архитектурные).

Итого вопрос, как построить процесс так, чтобы изменения сделанные множеством команд одного проекта соответствали требованиям архитектора и проходили корректную проверку (архитектурные ошибки, или грубые ошибки кодирования не попадали в общую кодовую базу)?

Если знаете литературу, посоветуйте, пожалуйста
  • Вопрос задан
  • 218 просмотров
Пригласить эксперта
Ответы на вопрос 3
Robur
@Robur
Знаю больше чем это необходимо
Поэтому выходит что ответственность по ревью (или полностью, или всё кроме архитектуры) нужно делегировать лидам команд.

делегируйте, лиды затем и нужны.

Если делегировать ответственность на лидов команд, выходит что общий уровень качества обеспечивается только уровнем команд,


вопрос кому делегировать ответственность не влияет на уровень, который могут выдать команды, а влияет на то кто за это будет отвечать.
Общий уровень качества всегда в первую очередь обеспечивается уровнем команд. Все остальное - управление, QA, ревью и прочее - только поддержка чтобы он всегда был на этом максимуме. Если уровень недостаточный, это решается не контролем и проверками, а обучением и наймом специалистов более высокого уровня.

архитектор сам по себе один в поле не воин, и если команды не высокого уровня, в продукт будут пролазить технические проблемы

Если бы архитектор был один в поле воин, вам не нужны были бы эти 80-100 человек.
Архитектор в первую очередь принимает решения по архитектуре, принимает на себя ответственность за эти решения и доносит это все до остальных. Ответственность за реализацию лежит уже не на нем а на командах.

Текст звучит так что у вас есть кто-то слишком за все ответственный, кто контролирует код который пишут 80-100 человек. Это заведомо гиблое дело. Либо у кого-то очень большое эго, если он сам на себя это взял, либо очень слабый характер, если на него навешали. На таких масштабах вам нужны иерархия и делегирование.

Это что касается уровня написанного кода.
А качество самого продукта(и это совершенно другая штука) должен проверять отдел QA. Либо те кто выполняет эти функции, но на таких масштабах у вас должен быть такой отдел из нескольких человек, явно или не явно.
Ответ написан
firedragon
@firedragon
Senior .NET developer
Роман Якимчук Роман А почему бы не выбросить на помойку Agile ?
По сути заказчику внушают мысль что он сможет спланировать Тяп-Ляп, сэкономить на ТЗ и бизнес аналитиках и по ходу добавлять фичи или удалять. На самом деле выходит, то что вы сказали, кто в лес а кто по дрова.
Ответ написан
@StepEv
Посмотрите как эти проблемы предлагают решать современные масштабируемые фреймворки - Nexus, LESS, SAFe. Для лучшего понимания любого из них стоит сначала разобраться с тем как работает Scrum в рамках одной команды, в чём особенности и выгода самоуправляемых команд, как их строить, как при этом обеспечивать качество. Путь долгий, серебрянной пули нет.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы