Scrum. Революционный метод управления проектами - Джефф Сазерленд

Ничто не выполнялось вовремя. Клиенты оставались недовольными. Рабочие группы были деморализованы. В общем, полная катастрофа. Руководители вернулись к старому варианту: теперь группы разработчиков снова самостоятельно проводили оценку проектов. Вот чудеса! Оценки вновь стали сходиться с реальностью.

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

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

Сколько раз на работе вам давали задание, смысла которого вы не понимали? Вас просят определить, как меняются за месяц продажи в регионе A в магазинах площадью более пятидесяти квадратных метров. Вы выполните эту работу, не вдаваясь в то, для чего это нужно. Из-за этого вы можете проставить не те данные, неправильно истолковать вопрос или почувствовать досаду, что вас загрузили нудной работой. Если вы управляющий, дающий такое задание, то, скорее всего, вы будете недоумевать, почему ваши сотрудники не возьмут в толк, что вы просто хотите закрыть маленькие магазины и открыть большие.

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

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

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

Наконец, нужно подумать о мотивах. Почему выбранный нами персонаж хочет эту вещь? Как она будет ему служить, чем будет радовать его как потребителя? Определенно, этот момент оказывается ключевым. Личная заинтересованность придает колорит всему.

Мой любимый пример связан с интернет-мемом, который был популярен несколько лет назад. Это картинка с изображением капитана Жана-Люка Пикара[37] в знаменитом звездолете «Энтерпрайз» с подписью: «Как капитан космического корабля я хотел бы, чтобы в бортовом журнале автоматически использовалась сегодняшняя звездная дата…» Это высказывание приобретает некий смысл, только если задуматься. Вас никогда не удивляло, что в далеком будущем капитану космического корабля приходится в ручном режиме вводить дату, когда он заполняет бортовой журнал? «Дневник капитана. Звездная дата 4671.7. Планета Марс так хорошо смотрится с орбиты…» Даже нам не приходится делать так, когда мы оставляем запись у себя в блоге. Так почему же это делает он? Но ключевой вопрос, который остается без ответа на этой картинке, – зачем? Зачем ему нужна такая функция? Для какой цели? Чтобы отслеживать порядок записей? Или что-то более серьезное? Должны ли эти записи исключать возможность внесения изменений в целях проверок и расследований криминалистами Звездного флота? Две совсем разные цели. Одна – бытовая, другая – имеет весьма вескую причину. Команде нужно разобраться, что капитан на самом деле хочет делать, при этом они могут найти совершенно иной подход к выполнению задачи, так что капитан будет получать гораздо более важную информацию, о которой он, возможно, даже и не задумывался, но которая была бы ему очень полезна.

Потребности разных персонажей, как правило, совсем разные. Представьте себе такой случай, когда ситуация меняется на противоположную. Предположим, вы произносите: «Мне нужна машина, чтобы ездить на работу». А теперь начните предложение так: «Как жителю пригорода, постоянно ездящему в центр на работу…» Или ровно наоборот: «Как фермеру Южной Дакоты с ее плохими дорогами…» В результате вы получите два совершенно разных представления об идеальном автомобиле.

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

Когда сочиняете свои сюжеты, в которых содержатся пожелания пользователя, – будем называть их пользовательскими историями, а для краткости просто историями, – следите за тем, чтобы они были лаконичными и удобными для дальнейшей работы. Представьте, что вы составляете «пожелание пользователя Amazon.com». Пробный вариант выглядит так: «Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время».

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