Обсудите мотивы других пользователей. Обсудите мотивы компании, в которой работают пользователи. Обсудите мотивы всех сторон, заинтересованных в бизнесе. Исследуя «Почему?», можно сделать множество интереснейших открытий.
Обсудите то, что происходит за рамками программного обеспечения. Подумайте, где и когда люди могут использовать ваш продукт, как часто они это делают. Представьте себе, кто еще может присутствовать при использовании продукта. Все эти факторы могут вам помочь нащупать наилучшее решение.
Обсудите, что произойдет, если все пойдет не так. Что будет, если произойдет какой-то сбой? Что случится, если система вдруг прекратит работу? Какими альтернативными способами пользователи могут достичь своих целей? Как они удовлетворяют свои нужды сейчас?
Обсудите вопросы и предположения. Если вы проговорите все это, то, скорее всего, столкнетесь со многими вещами, о которых не знаете. Сформулируйте свои вопросы и обсудите, насколько важно получить ответы перед тем, как приступить к работе над программным обеспечением. Нужно решить, кто проделает все необходимое для получения информации, и сохранить вопросы до следующего обсуждения. Как вы убедитесь, порой для полного рассмотрения некоторых историй требуется очень долго их обсуждать.
Запланируйте время на проверку своих предположений. Действительно ли вы понимаете пользователей? Вы точно знаете, чего они хотят? Реальны ли их проблемы? Смогут ли они, используя ваше решение, справиться с этими проблемами?
Рассмотрите также свои технические предположения. На какие базовые системы мы полагаемся? Будут ли они в самом деле работать так, как мы планируем? Есть ли какие-то технические риски, которые необходимо учесть?
Все эти вопросы и предположения могут потребовать дополнительного исследования или изучения. Составьте для этого особый план.
Обсудите вероятность нахождения лучшего решения. По-настоящему крутые результаты получаются тогда, когда в ходе обсуждения истории участники отклоняют первоначальные предположения о том, каким должно быть решение, возвращаются к рассматриваемой проблеме, а затем все вместе приходят к другому решению, более эффективному и экономичному в реализации.
Обсудите «Как?». Очень часто, присутствуя на обсуждении историй, я слышу чей-то раздраженный голос: «Мы должны обсуждать, что мы делаем, а не как!». Под этим обычно подразумевается, что нужно обсуждать действия и мотивы пользователей, а не код, который необходимо написать. А я чувствую точно такое же раздражение, когда мы говорим только о «Что?», не затрагивая «Почему?». В действительности при хорошем обсуждении мы стремимся к оптимизации всех трех составляющих. На самом деле нехорошо, когда кто-то предполагает, что определенное решение или какой-то способ технической реализации является требованием. Поэтому без явного обсуждения «Как?» (а если вы разработчик, вы неизбежно думаете об этом аспекте) очень трудно оценить стоимость решения. А слишком дорогое решение никак не может быть наилучшим.
Уважительно относитесь к опыту и компетентности других участников обсуждения. Не стоит указывать высококвалифицированному техническому специалисту, как ему делать свою работу. Не говорите кому-то хорошо знакомому с пользователями и их работой, что он ничего не понимает. Задавайте вопросы и искренне пытайтесь научиться чему-то друг у друга.
Обсудите, сколько времени понадобится. В конце концов все-таки приходится принять несколько решений, чтобы продвинуться вперед и что-то построить или не построить. Эту ситуацию можно сравнить с решением о покупке товара, не имеющего ярлычка с ценой.
В мире программного обеспечения понятие стоимости в первую очередь связано с временем, которое потребуется на написание кода. На ранних этапах вполне допустимо использовать понятия «очень долго» или «пару дней». Еще лучше сравнить то, что вы обсуждаете, с чем-то уже законченным: «Это похоже на те улучшения для комментариев, которые мы реализовали в прошлом месяце». По мере того как мы все ближе подбираемся к началу разработки, все дольше обсуждаем и принимаем все больше решений, оценки трудозатрат должны становиться все более точными. Но не забывайте: в любом случае мы говорим лишь об оценках, а не об обязательствах.
Сделайте «фото из отпуска»
Поскольку нужно очень многое обсудить и хорошо бы ничего не забыть, убедитесь: вы записали самое важное, что позволит позднее припомнить принятые решения, а также вопросы и предположения, в которых следует хорошенько разобраться. Не забудьте озвучивать ход своих мыслей, чтобы и все остальные понимали, что записывается.
Если вы пишете на бумаге, прихватите ее с собой и заглядывайте в нее позднее. Если записи сделаны на стене, можно просто обращаться к ним по мере надобности. Кроме того, если вы общаетесь как настоящая команда, то обнаружите, что вам не нужно беспрестанно все повторять. Люди и так будут помнить подробности обсуждения, особенно если вы сопровождали его документами и простыми рисунками… теми самыми «фото из отпуска».
Эта небольшая группа сейчас обсуждает историю. По мере обсуждения они визуализируют свои идеи и делают заметки о решениях.
Мой любимый подход именно такой. Я делаю записи на большом листе бумаги или доске прямо во время разговора. Я люблю сделать прямо на доске пометку о том, кто присутствовал на обсуждении, а затем фотографирую свои записи. Затем любым способом отправляю фото всем присутствующим. Я хорошо знаю, что в любую минуту могу припомнить детали или записать их более формально, если вдруг понадобится. Если у меня не получится точно припомнить, что было сказано, наверняка это вспомнит другой участник обсуждения: я всегда знал, что записывать имена участников – хорошая идея.
Придется о многом позаботиться
Да, обсуждение истории включает в себя множество составляющих, и это может немного пугать. В этот момент вы, возможно, с тоской вспоминаете старые добрые времена, когда все, что вам нужно было, – это правильно понять требования, и хотите вернуться туда, где вам не приходилось по-настоящему решать задачи. Вы просто должны были создать, что сказано, а о том, правильны ли инструкции, заботился кто-то другой. Но я уверен, что на самом деле и вам, и почти всем прочим людям нравится решать проблемы. Так что это ваш шанс.
Возможно, обсудив все, о чем мы здесь говорили, вы получите огромный объем информации, которую необходимо хранить и отслеживать, а на стикеры или карточки она никак не помещается. Все в порядке. Так и должно быть. Давайте поговорим о том, что необходимо писать на карточке, а чем можно пренебречь.
Глава 8. Не бросайте на карту всё
Да, короткие заголовки историй на карточках помогут вам запланировать и провести множество обсуждений между людьми, которые умеют писать программы, и людьми, которые разбираются в проблемах, для решения которых предназначаются программы. Но, к сожалению, выпуск полностью готового программного продукта требует участия гораздо большего количества людей.
В обычной команде вы, скорее всего, увидите менеджеров проекта, менеджеров продукта, бизнес-аналитиков, тестировщиков, специалистов по пользовательскому взаимодействию, технических писателей и многих других, о которых я наверняка забыл. Все они могут
