3.2.2.1. Т-образные специалисты

Т-образные (англ. T-shaped, в форме буквы «Т») специалисты названы так по способу формирования компетенций и представляют собой комбинацию специалистов широкого профиля (dash-shape, или тиреобразные) и узких специалистов глубокого профиля (I-shape, или 1-образные). Т-образные специалисты глубоко разбираются в одной экспертизе, но при этом на базовом уровне разбираются в смежных (рис. 3.11).

Рис. 3.11. Способы формирования компетенций. Т-, I- и «-»-образные специалисты

Наличие таких специалистов в команде позволяет убрать бутылочные горлышки и снизить так называемый фактор автобуса[42].

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

Некоторые компании, в которых мне доводилось работать, поощряли развитие разработчиков в сторону Т-образности. Известная практика – создание звездной карты.

Рис. 3.12. Звездная карта

Звездная карта (рис. 3.12) – это простой инструмент, представляющий собой матрицу, в которой в пересечении «сотрудник – экспертиза» устанавливается звездочка, если сотрудник «звезда» в этой экспертизе, и точка, если может подменить «звездного» сотрудника, который по какой-то причине выпал. Звездная карта позволяет видеть провалы в экспертизах и риски возникновения бутылочного горлышка в случае незаменимости «звезды». Для минимизации риска «автобуса» можно поощрять сотрудников к развитию горизонтальных компетенций, например, оплачивая обучение. Если сотрудник хочет изучить что-то не по профилю, в ячейке ставится значок «книга».

Долгое время рынок труда в IT не поощрял многопрофильность. Это накладывало ограничение на желание разработчиков развиваться в смежных сферах. Например, фронтенд-разработчик не хотел развиваться в бэкенде, так как это не увеличивало его стоимость на рынке.

Сейчас, с развитием Agile, растет потребность в фулстек-разработчиках (от англ, full stack, полный стек[43]), и вакансий с каждым годом становится все больше.

3.2.2.2. Минимальная команда

Расширение команды увеличивает время на синхронизацию и ответственность каждого участника.

Согласно закону Меткалфа[44], количество связей в сети растет пропорционально квадрату количества узлов. Начиная с определенного количества участников, перестанет хватать рабочей недели, чтобы все они поговорили друг с другом хотя бы несколько минут. Следовательно, команда естественным образом начнет распадаться на несколько подкоманд. Коллективные встречи начнут терять свою эффективность, так как обсуждаемые задачи не затрагивают большую часть сотрудников.

Чем больше команда, тем меньше ощущение личного вклада в результат, а следовательно, и ответственность становится все менее очевидной.

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

Чтобы обеспечить максимальную связность и ответственность, подходит практика разбивать разработчиков на минимальные кросс-функциональные команды. Для этого можно использовать описанный выше инструмент звездной карты, разделив участников так, чтобы при минимальном количестве участников команда сохраняла кросс-функциональность (наличие полного набора экспертиз) и устойчивость к фактору автобуса.

3.2.2.3. Долгое время вместе

Изменение состава команды нарушает внутренние равновесие и перезапускает процесс ее формирования.

Рис. 3.13. Стадии формирования групп по Брюсу Такману

Брюс Такман в 1961 году предложил модель групповой динамики, согласно которой команда проходит четыре стадии формирования (рис. 3.13):

➠ формирование (forming),

➠ шторм (storming),

➠ нормирование (norming),

➠ производительность (performing).

Согласно этой модели, на первых порах участники команды присматриваются друг к другу. На всякий случай они показательно продуктивны и априори положительно настроены к другим участникам. Затем наступает фаза шторма, когда начинают возникать споры вокруг пустот между зонами ответственности. В третьей фазе участники команды слаживаются, притираются друг к другу и начинают наращивать продуктивность.

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

3.2.2.4. Владелец продукта

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

Владелец продукта отвечает за максимизацию ценности результата разработки Scrum-команды. Также он отвечает за управление бэклогом команды, а именно:

➠ разработку и детальное донесение цели продукта;

➠ разработку и ясное донесение элементов продуктового бэк-лога;

➠ приоритизацию элементов продуктового бэклога;

➠ обеспечение доступности, прозрачности и понятности продуктового бэклога.

Владелец продукта может делегировать обязанности, но при этом несет ответственность. Это не комитет: он может представлять несколько стейкхолдеров, но при этом автономно принимать решения. Владелец продукта имеет видение продукта (компонента или инициативы) и готов прозрачно его доносить. Как говорилось ранее, он отвечает за ценность продукта. Под ценностью в широком смысле понимается не только ценность для пользователя, но и ценность для бизнеса. Владелец продукта наделен властью управлять датами релизов и инспектировать инкремент на обзоре спринта. Владелец продукта должен быть жизненно заинтересован в успехе продукта и вдохновлять своим видением других.

Плохо, когда владелец продукта:

➠ Не наделен властью: тогда ему придется совещаться с центром, что парализует работу.

➠ Перегружен работой: будет терять контекст.

➠ Совмещает: не будет нести ответственность в трудной ситуации.

➠ Работает удаленно: будет недоступен в срочной ситуации и часто неправильно понят.

➠ Прокси: будет задерживать и искажать сигнал от реального РО.

➠ Скрытный: команде будет трудно понять, как сделать, если непонятно, зачем.

➠ Комитет: решения будут затягиваться.

➠ Не заинтересован: команда будет демотивирована бесполезным трудом.

➠ Боится: страх парализует и заставляет имитировать работу.

3.2.2.5. Scrum-мастер

Больше всего вопросов у людей, не знакомых со Scrum, вызывает роль Scrum-мастера, хотя это важнейшая роль для построения эффективной масштабируемой разработки. Scrum-мастер в первую очередь отвечает за внедрение фреймворка, не ограничиваясь уровнем подотчетной команды и стараясь распространить свое влияние на другие команды и компанию в целом. Scrum-мастер регулярно актуализирует теоретические и практические знания команды. Согласно руководству, Scrum-мастер – это лидер-слуга для Scrum-команды, который:

➠ развивает команду в сторону самоорганизации и кросс-функциональности;

➠ помогает увеличивать производительность – поставлять как можно больше максимально ценных элементов продуктового инкремента каждый спринт;

➠ убирает препятствия в прогрессе команды;

➠ фасилитирует события Scrum для регулярного увеличения их эффективности.

Scrum-мастер помогает владельцу продукта ⁄ Scrum-команде:

➠ внедрить эффективные процессы определения цели продукта и управления бэклогом продукта;

➠ эффективно действовать в комплексном мире (см. п. З.1.З.);

➠ поддерживать ясное понимание элементов продуктового бэклога;

➠ организовать взаимодействие со стейкхолдерами, фасилитировать встречи.

На уровне организации Scrum-мастер:

➠ возглавляет и активно участвует во внедрении Scrum;

➠ участвует в планировании мероприятий по внедрению;

➠ помогает стейкхолдерам осознать и внедрить эмпирический процесс для комплексного мира;

➠ убирает препятствия между стейкхолдерами и Scrum-командой.

Важно добавить, что Scrum-мастер создает эффективную здоровую среду взаимного профессионального уважения и самостоятельности. Он выступает в роли третейского судьи для команды разработки и владельца продукта. Это позволяет добиться состояния справедливости, когда владелец продукта не «продавливает» команду, а команда не «продавливает» ПО.

Scrum-мастер – агент продуктовой трансформации, он бежит впереди организации, осознавая текущий уровень зрелости и направление движения.

Плохо, если Scrum-мастер:

➠ Проджект-менеджер: это противоречие на уровне операционных окружений по модели «Киневин», рассмотренной в п. 3.1.3.

➠ Прокси: чью бы волю ни выполнял – РО, СТО, SH[45], – в команде образуется несправедливый перекос;

➠ Частичный: SM, который работает на две и более команды, по-настоящему не болеет ни за одну из них;

➠ Нянька: потакая капризам команды, убивает в них самостоятельность;

➠ Трусливый: боится настоять на правильном процессе, из-за чего Scrum превратиться в Scream.