В практике работы по модели Agile совершенно напрасно закрепилась традиция назначать кого-то одного ответственным за написание историй и проведение всех обсуждений. В Scrum, процессе Agile, этот человек называется владельцем продукта. Однако есть по меньшей мере две серьезные причины, по которым это не работает, а может, и целый ряд более мелких причин.

 Основная причина № 1. Чтобы пройти весь путь от неясной идеи до маленьких конкретных фрагментов программы, поступающих в разработку, требуется очень много обсуждений. Один человек просто не может их все обеспечить. И если вы построите процесс так, что он зависит от одного человека, этот человек может стать «бутылочным горлышком» и, несомненно, очень скоро им станет.

 Основная причина № 2. Один человек не обладает всеми нужными компетенциями и не сможет посмотреть со всех возможных точек зрения, чтобы прийти к наилучшему решению. Только сотрудничество людей с различными навыками позволяет создать по-настоящему полезный продукт.

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

Three Amigos

¡Three Amigos! – название заурядного вестерна-комедии 1986 года со Стивом Мартином, Чеви Чейзом и Мартином Шортом в главных ролях. Что общего у этого фильма и разработки по методологии Agile, управляемой историями? Там есть тройка ловких и расчетливых героев, что очень здорово для семинаров по историям. Я не знаю, кто первым назвал их тремя амиго, но, кажется, это прозвище ушло в народ (уверен, если бы фильм посмотрело больше людей, этого не произошло бы).

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

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

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

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

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

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

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

Антишаблон «клиент – исполнитель»

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

В этом антишаблоне один участник играет роль клиента, а другой – исполнителя. Задача клиента – знать, чего он хочет, и объяснить исполнителю все детали. Это мы называем требованиями. Работа исполнителя – слушать, вникать, а затем продумать технический подход к реализации того, что хочет клиент. После этого исполнитель оценивает трудозатраты, что в сфере разработки программ часто является синонимом обязательства (кстати, этим часто объясняется страх программистов перед необходимостью давать оценки без тщательного анализа).

Конец истории печален и вполне предсказуем.

Изредка, конечно, оценка снайперски точна, клиент получает именно то, что просил, а просил он именно то, что ему было нужно.

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

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

Но в антишаблоне «клиент – исполнитель» обсуждение проблем и решений заменено дискуссиями и соглашениями относительно требований. Проигрывают в такой ситуации все.

Одна из целей метода историй – избавиться от этого антишаблона.

Хороший пример отношений, разрушающих этот антишаблон, – отношения многих из нас со своим врачом. Попробуйте явиться в кабинет врача и предъявить ему свои «требования». Перечислите рецепты, которые вам нужно выписать, и процедуры, которые следует назначить. Если у вас хороший врач, он ответит: «Очень интересно, а сейчас расскажите мне, что вас беспокоит».

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

 

Владелец продукта как продюсер

Если ваша организация работает в традиционной манере разработки программного обеспечения, в ней могут не совсем ясно понимать, чем должен заниматься владелец продукта. Например, вы участвуете в разработке критически важных систем для банков. Банк знает, что реальные продукты – это банковские услуги, которые он продает своим клиентам. Если у вас есть сотрудник на должности менеджера продукта, то его работа – отвечать за определенный тип банковского счета или кредитного продукта. Компьютерные системы, которые поддерживают этот тип услуги, всего лишь шестеренки в большом механизме. Зачастую бывает, что одна и так же IT-инфраструктура поддерживает множество различных банковских продуктов. Понятно, что банк не рассматривает эту инфраструктуру как продукт, и, как правило, нет никого, кто может выступать в роли ее владельца.

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

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

Такова и работа бизнес-аналитика в IT. Используйте видение представителей бизнеса и помогите им воплотить его в успех. Вы не можете работать как приемщик заказов – вы должны выступать в роли доктора. Иногда это означает необходимость объяснять представителям бизнеса то, что они не хотят слышать. Но если вы искренне хотите помочь им добиться успеха, они заметят это и оценят вашу помощь.

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

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

 

Это сложно

Для идеи, весьма простой в своей основе, вся эта история с историями становится слишком запутанной на практике. Если кто-нибудь когда-нибудь говорил вам, что разработка программного обеспечения – да и предъявление любого продукта – прошла легко и просто, это было вранье.

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

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

Я надеюсь, вы тоже думаете, что это замечательно.