Пользовательские истории. Искусство гибкой разработки ПО - Джефф Паттон Страница 48

Владелец продукта не может в одиночку написать все истории и присутствовать на всех обсуждениях. Это не работает.

Не поймите меня неправильно. С моей точки зрения, при правильной разработке продукта лидерство владельца продукта очень важно. Он следит за тем, чтобы в ходе работы вся команда сосредоточилась на движении в верном направлении.

Альтернативой может быть проектирование комиссией – еще одна ужасная устоявшаяся практика, где каждый получает равные права при принятии решений о том, что мы делаем. Работая как комиссия, имея время и ресурсы на то, чтобы сделать какую-либо одну вещь, мы вынуждены идти на компромисс. Мы с моей бывшей женой часто прибегали к этому способу, выбирая ресторан. Она любила морепродукты, я – мексиканскую кухню, и в итоге мы отправлялись туда, где не нравилось нам обоим. Когда же комиссия не имеет ограничений ни в ресурсах, ни во времени, мы делаем все, что только можем. Вы, наверное, сталкивались с программными продуктами такого типа: в продукте бессчетное количество функций и вы вечно мучаетесь, пытаясь отыскать среди них нужное или вспомнить, как его надо использовать.

Эффективно действующие владельцы продукта окружают себя людьми, которые нужны им для принятия удачных решений. Они объединяют компетенции, мнение и опыт многих людей. Но в условиях ограниченных ресурсов, когда успех продукта находится под угрозой, решения приходится принимать им, и, конечно, всегда найдутся недовольные. Моя подруга Лиза Райшелт хорошо сказала: «…В дизайне нет ничего от демократии» ^[24].

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

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

Работой по исследованию продукта должна дирижировать маленькая кросс-функциональная команда под руководством владельца продукта.

Идеальный размер такой команды – от двух до четырех человек, численность компании за обеденным столом, поэтому ее члены легко могут выработать одинаковое понимание проблемы.

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

Сплоченная команда исследования продукта представляет собой мощную, слаженно работающую группу экспертов, способную быстро обнаруживать проблемы и находить решения. Я часто слышу, что эту ключевую команду называют триадой. Когда я последний раз был в сиднейском офисе Atlassian, Шериф, с которым вы познакомились в главе 8, указал мне на три рабочих места, расположенных рядышком. «Здесь сидит триада», – объяснил он. Вокруг мест триады стояли рабочие столы с компьютерами, за которыми располагалась остальная команда. Мне также приходилось слышать, как триадой называли команду, где было два человека, четыре человека или даже больше, ибо три концепта, о которых мы говорим, – полезное, удобное, реалистичное – не соотносятся с тремя людьми.

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

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

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

А сейчас будет настоящий секрет. Для создания продукта любой значимости нужна команда. Чтобы сохранить ясное видение продукта, убедиться, что запланированное решение реализуемо, и задавать общее движение в заданном направлении, наличие сильного лидера критически важно. Самые лучшие лидеры обеспечивают такие условия, чтобы каждый мог внести свою лепту в принятие решений. В дружественной среде, управляемой историями, вы увидите, что множество обсуждений историй идет не прекращаясь. И большинство из них не требует присутствия лидера.