✓ Зона 3 – это внутренная граница, где происходит обмен между командой и заинтересованными сторонами.
✓ Зона 4 – это местонахождение заинтересованных сторон. Участники команды время от времени должны заходить на эту территорию, чтобы совершать обмен знаниями, идеями и т. д.
✓ Зона 5 – это внешняя граница или места, куда иногда забредает кто-то из команды, чтобы почерпнуть идей.
Этот паттерн делает рабочее пространство, организованное для зон с 1 по 3, инструментом для комфортной социализации.
• Зона 1
Это комната с рабочими местами, расположенными так, чтобы команда могла свободно общаться. Видеопроектор позволяет делиться экраном со всей командой.
Есть места для уединения, чтобы подумать или помедитировать.
• Зона 2
Создана для обмена информацией. На стене висит доска, достаточно большая и доступная для каждого. Доска команды является важным инструментом: он облегчает обмен знаниями и эмоциями, фокусируясь на трех чувствах: слух, зрение, осязание.
Неважно, какие команда использует технологии – рекомендуется все равно использовать настоящую доску: визуальный менеджмент способствует более тесному сотрудничеству.
• Зона 3
Для встреч небольшим составом с заинтересованными сторонами. Маленькая комната и несколько кресел. Рекомендуется открытое помещение, обеспечивающее доступ заинтересованных сторон к достижениям команды. Такое пространство делает обмен между командой и заинтересованными сторонами конструктивным.
Рабочее пространство должно располагать к появлению новых идей через укрепление отношений.
3.6 Команда внутри экосистемы
Взаимодействие внутри команды имеет первостепенное значение.
Рассмотрим теперь отношения участников команды с другими людьми в экосистеме:
✓ в Зоне 3 с заинтересованными сторонами, находящимися в контакте с командой,
✓ в Зоне 4 с другими заинтересованными сторонами,
✓ в Зоне 5 с остальными людьми.
Рисунок 3.8 – Обмен участника команды с другими людьми
Люди, находящиеся вне команды, – не только ограничение, создающее зависимости, но и важный источник знаний.
Паттерн эксперта внутри границ. Определяем, кто заинтересованная сторона, какие у нее полномочия. Заинтересованная сторона будет помогать команде.
Эксперт – это роль, которую берет на себя заинтересованная сторона. Она находится внутри границ команды и обладает компетенциями, полезными для ее работы.
• Кто такой эксперт?
Это заинтересованная сторона, помогающая команде достичь результата.
Роль не выдается на постоянно. Она существует в течение определенного времени, пока заинтересованная сторона находится в контакте с командой.
По просьбе команды эксперт может подключиться к спринту.
Это может быть бизнес-эксперт, обладающий функциональными знаниями или решением, содержащим технические знания.
Дельфина много знает о собачьем корме. Она необходима, чтобы помочь команде Peetic по всем функциям, связанным с едой. Ален отвечает за инфраструктуру и безопасность. Он отлично разбирается в том, что касается развертывания.
• Ответственность
Эксперт, как заинтересованная сторона, присутствует на обзоре спринта. Участвует в других событиях спринта и активно взаимодействует с командой.
Желательно, чтобы эксперт участвовал в коллективной работе всякий раз, когда требуется его или ее участие.
Вовлечение эксперта в работу проблематично, если эксперт находится снаружи границ команды. Это может стать фактором риска для спринта.
• Ограничение зависимости
Как правило, экспертная заинтересованная сторона очень занята и не может участвовать в работе нескольких команд одновременно. Вот несколько способов уменьшить связанные с этим риски.
✓ Создание команды, которая бы зависела от малого числа экспертов.
✓ Приглашение эксперта, в котором команда нуждается на регулярной основе.
✓ Предвосхитить этот момент и не начинать работу, не убедившись, что требуемый эксперт доступен.
✓ Научиться у эксперта, чтобы в дальнейшем обходиться без него.
Рисунок 3.9 – Даже очень хорошей команде иногда нужен эксперт
Команда будет стремиться общаться с другими заинтересованными сторонами (которые являются специалистами в определенной области) без особой необходимости, просто с целью получения новых знаний.
Участники могут пользоваться знаниями, которые получат в ходе общения с другими командами.
Это обмен информацией с конечными пользователями, встречи с коллегами, участие в конференциях, обучение и так далее.
3.7 Антипаттерны
Ситуация. Каждый участник команды сидит в своем углу и делает свою часть работы – они думают, что работать исключительно по своей специальности эффективнее.
Последствия. Нет сотрудничества. Не развит коллективный разум. Только один человек разбирается в технической части вопроса. Когда он недоступен, вся команда застревает.
Как сделать лучше? Организовать парную работу, чтобы избежать гиперспециализаций.
Для повышения устойчивости экосистемы необходимо сделать так, чтобы каждая функция могла выполняться несколькими людьми и чтобы каждый человек мог выполнять несколько функций.
Ситуация: человек толком не понимает, к какой команде он принадлежит. Он работает над несколькими проектами и думает, что на один проект приходится одна команда, на один проект – только один бэклог.
Последствия: заинтересованные стороны могут входить в несколько экосистем. Но участник принадлежит только к одной Scrum-команде! Иначе он быстро «сгорит».
Как сделать лучше? Сократить количество мульти-проектов. В краткосрочной перспективе сосредоточиться на одной команде и приоритизировать задачи в бэклоге.
Ситуация. Во время спринта команде потребовалась экспертиза. Но участники не проверили, доступен ли эксперт.
Последствия. Команда не успевает завершить работу к окончанию спринта. Ожидается много работы из-за отсутствия необходимых компетенций для продвижения вперед.
Как сделать лучше? Предвидеть, что экспертиза понадобится. Определить людей, у которых есть опыт и знания, и зону обмена. Можно пригласить их выпить пива и поиграть, к примеру, в настольный футбол.
Ситуация. Заинтересованные стороны не стремятся вносить свой вклад в общую цель. Они не приходят на обзоры спринтов, а если приходят, ищут только недостатки в работе. Конструктивной обратной связи нет.
Последствия. Разработчики под гнетом контроля, нет атмосферы доверия.
Как сделать лучше? Сблизить людей при помощи паттерна рабочих зон. Познакомить все заинтересованные стороны со Scrum. Объяснить их роль. Приглашать их на каждый обзор спринта. Праздновать успехи вместе.
Чтобы идти дальше
Книги
‣ Tobias Mayer, The People’s Scrum, 2013. Вдохновляющая книга о людях в Scrum, которая включает эссе, опубликованные Тобиасом Майером на странице его блога.
4Роль Владельца продукта
Было время, когда я работал в компании по разработке программного обеспечения. Занимался маркетингом – ошибиться может каждый – для продукта, который сегодня уже не выпускается. Продукт включал в себя графический редактор, симулятор и генератор кода. Целью была разработка распределенных систем.
Я сам был разработчиком и менеджером проектов в области телекоммуникаций, поэтому хорошо знал потенциальных пользователей продукта. С моей должностью в компании я в некотором роде их представлял.
Но во главе компании стояли технологи. В конечном счете, именно технический директор решил, какие функции добавлять в продукт.
Функции были мощные. Например, исчерпывающее моделирование на основе конечных автоматов. Использовать продукт было непросто, и, на мой взгляд, предлагаемые функции не учитывали потребности пользователей.
Чтобы избежать такой ситуации, в Scrum существует роль Владельца продукта. Она гарантирует, что проделанная работа приносит пользу и нужна пользователям. Наличие Владельца продукта позволяет не допустить, как в моей истории, доминирования техники или начальства при выборе содержания продукта.
Если бы в то время существовала такая роль, я бы хотел стать Владельцем продукта. Прошло много времени, я начал практиковать Scrum, и эту роль мне все же довелось исполнить: в частности, на протяжении долгих лет я являюсь Владельцем продукта iceScrum.
Именно об этой роли и моем опыте будет эта глава.
4.1 Product что?
Но начнем с терминологии.
Впервые я прочитал о Scrum в книгах и статьях на английском языке. Я, разумеется, перевел Product Owner как собственник продукта. Но собственник не отражает распределение и обмен, присущие этой роли.
Рисунок 4.1 – Собственник продукта
В 2005 году я участвовал в тренинге по Scrum. Его вел уроженец Квебека Франсуа [21]. Материал курса был на французском языке. Product Owner, о котором речи тогда было мало, переводился как администратор продукта. Это название так и не прижилось во Франции. Я думаю, наши канадские братья также от него отказались.