Большинство компаний уже используют ту или иную устоявшуюся топологию, но когда-то им приходилось с чего-то начинать.
У стартапов необходимость в топологии обычно появляется, когда число инженеров превышает 15 человек или около того.
Именно в этот момент в компании возникает понимание, что широкие полномочия и самостоятельность, которыми пользовались сотрудники в период становления, начинают страдать под бременем координации их деятельности. Принимать решения и выполнять простые задачи становится все труднее и труднее. Поэтому принимается решение сформировать три кросс-функциональные продуктовые команды, чтобы «разделять и властвовать». Способ, каким это делается, и определяет топологию.
В случае крупных компаний развитие топологии не пошло в сторону модели продуктовых команд. Отправной точкой обычно считается переход на методику Agile, организацию процесса вокруг небольших стабильных команд. Способ разделения команд, который избирает компания, определяет топологию.
Некоторые топологии устанавливаются в ответ на существенное изменение видения продукта и/или архитектуры продукта. Вне зависимости от причины, если компания вносит радикальные изменения в стратегический контекст продукта, может возникнуть необходимость пересмотреть уже существующую топологию.
Какой бы ни была причина пересмотра вашей топологии, нужно провести оптимизацию для расширения полномочий команд, сосредоточившись на таких аспектах, как ответственность, автономия и согласованное взаимодействие.
Какие бы широкие возможности ни предоставляла ваша первоначальная топология, она не может оставаться неизменной сама по себе. Реалии на местах постоянно меняются, и порой таким образом, что возникает необходимость в изменении топологии. Вот несколько примеров ситуаций, когда могут потребоваться изменения:
• Продуктовой команде нужно удвоить количество инженеров, чтобы завоевать следующий сегмент рынка.
• Новая стратегия включает сворачивание продукта, выпуск которого поддерживается в настоящее время несколькими продуктовыми командами.
• Новая стратегия предоставляет доступ к некоторым ключевым возможностям одной продуктовой команды другим командам посредством внутренней платформы.
• Новая цель бизнеса — разработать предложение для расширения рынка.
• Масштабный рефакторинг архитектуры ПО.
Даже если ничего из перечисленного не заставляет вас пересмотреть существующую топологию, хорошие руководители всегда находятся в контакте со своими командами и персоналом и должны уметь оценивать топологию через призму наличия у них полномочий и самостоятельности.
Вот несколько тревожных сигналов, которые могут свидетельствовать о том, что на топологию следует обратить внимание:
• Вы постоянно перебрасываете разработчиков из одной команды в другую.
• Вы часто вынуждены вмешиваться, чтобы урегулировать конфликты, связанные с зависимостью команд друг от друга.
• Ваши разработчики жалуются на очень большое количество зависимостей от других продуктовых команд даже при производстве простых продуктов.
• Команды обладают слишком ограниченным объемом ответственности.
• Разработчики должны иметь дело со слишком большим количеством сложности во многих областях.
Таким образом, бывают ситуации, которые вынуждают нас пересматривать топологию команд вне зависимости от того, инициируем мы это сами или реагируем на какие-то факторы.
По мере возможности нужно стараться сохранить существующие команды целыми и невредимыми. Ваша организация серьезно вложилась в эти взаимоотношения, в доброе сотрудничество.
Это означает, что везде, где возможно, лучше предоставить уже существующей команде новый набор обязанностей и ответственности, а не распускать продуктовую команду и перераспределять сотрудников в другие команды.
Но бывают случаи, когда изменение топологии важнее. Всего лишь старайтесь не злоупотреблять частыми переменами. Если вы постоянно меняете топологию команд — более одного раза в год, — это признак, что у вас что-то не ладится.
Топология определяет, с кем люди работают на повседневной основе, над чем они трудятся и как взаимодействуют между собой. Ее изменение может привести к крайне деструктивным последствиям.
Осторожным нужно быть даже в том случае, если вы временно перебрасываете сотрудника в другую команду для решения какой-либо задачи первоочередной важности. Эти перемещения негативно сказываются на людях: им приходится приспосабливаться к новой команде и новой работе. Это некомфортно и для основной команды, оставшейся без своего сотрудника, так как часто им приходится искать способ восполнить утрату.