А вот как бывает. Прилетает задача, которую может сделать только один специалист из вашей команды, у которого есть необходимые компетенции, настолько она узкоспециализированная. И этот специалист оценивает задачу как очень большую. Не меньше человеко-месяца, например. И задача эта крайне высокоприоритетная.

Можно поддаться ситуации и согласиться, чтобы этот узкий специалист месяц пилил эту узкоспециализированную задачу. А можно вот как поступить.

Попросить специалиста сделать низкоуровневую декомпозицию задачи. Практика показывает, что реально узкоспециализированной там являются 5 % задачи, а всё остальное могут сделать более широкопрофильные программисты из команды.

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

Когда-то было благословенное время I-shaped специалистов, которым было достаточно знать, как сделать свою часть работы и передать её дальше по конвейеру. Времена мануфактур и слабой автоматизации труда. В наше время всё больше функций автоматизируется и к специалистам предъявляются новые требования.

Сейчас время T-shaped специалистов, которые являются экспертами в какой-то одной области (вертикальная палочка Т) и немного разбираются в нескольких смежных областях (горизонтальная палочка Т). Необязательно двух, можно больше. Например, моя специализация — управление проектами, но я могу выступить в роли аналитика и собрать требования. Возможно, не так хорошо, как настоящий бизнес-аналитик, но всё-таки при его отсутствии требования будут собраны. Могу протестить, пусть и не так хорошо, как выделенный тестировщик. Могу нанимать членов команды, хоть и не так круто, как настоящий рекрутер. Вы поняли принцип.

Одна из ценностей T-shape подхода — взаимовыручка, когда члены команды помогают друг другу справляться с большим объемом текущих задач. Чем больше таких людей в команде, тем более гибко она реагирует на любые изменения.

Формирование команды из Т-образных специалистов позволяет достичь высоких значений bus-factor (максимальное количество членов команды, которых может одномоментно «сбить автобус» и работа при этом не остановится). В идеале значение этого параметра должно быть равно количеству членов команды минус один. То есть, в идеальной команде проект может, пусть и очень медленно, довести до конца любой произвольно взятый сотрудник. Конечно, такого идеала трудно достичь, но к этому можно стремиться.