Клиент всегда прав, не так ли?
Вернитесь к началу главы и перечитайте цитату. О чем говорит Генри Форд? О том, что людям надо предлагать то, что им действительно нужно, а вовсе не то, что они просят. У клиента есть потребность, и если вы создаете ПО, чтобы ее удовлетворить, то должны понять, способен ли он донести ее до вас. Как вы работаете с клиентом, который в начале проекта еще не знает, что ему нужна машина, а не очень быстрые лошади?
Это мотивация, выходящая за рамки 12 принципов: необходимо собрать команду, способную создать такое программное обеспечение, в котором пользователь действительно нуждается. Принципы зависят от идеи, которую мы закладываем при разработке проекта с целью получения некой ценности. Но понятие «ценность» сложное, потому что каждый понимает ценность программного обеспечения по-своему: люди ставят перед ПО совершенно разные задачи.
У вас в руках хороший пример воплощения этой идеи. Если вы читаете эту книгу на портативном устройстве для чтения электронной литературы, то значит, вы используете программное обеспечение, написанное для отображения книг на этом устройстве. Потратьте немного времени, чтобы подумать обо всех стейкхолдерах (заинтересованных лицах) проекта создания программного обеспечения для электронной книги.
• Как читатель вы хотите, чтобы программное обеспечение сделало книгу легкой для чтения. Вы заботитесь о том, чтобы можно было легко переворачивать страницы, выделять разделы, делать заметки, искать нужный текст и находить страницу, на которой остановились.
• Как авторы мы очень заботимся о том, чтобы слова, которые мы пишем, отображались корректно, пункты маркированного списка с отступом располагались так, чтобы вам было удобно его читать, а также чтобы вам было легко перемещать взгляд между основным текстом и сносками, а общее впечатление позволило получить удовольствие и знания от прочитанного.
• Нашего издателя O’Reilly волнует легкий способ дистрибуции этой книги и простота сбора позитивных читательских отзывов, а также продажи других книг.
• Продавец или розничный торговец, продавший вам эту книгу, хочет иметь возможность легко просматривать и покупать другую литературу, пригодную для торговли, быстро и легко скачивать ее для своих читателей.
Вы, наверное, сможете назвать еще больше стейкхолдеров и целей, важных для них. Каждая из целей представляет собою ценность для заинтересованной стороны.
Самые первые электронные книги не предлагали всех этих ценностей. Потребовалось много времени, прежде чем появилось программное обеспечение, способное удовлетворить эти требования читателей. И можно сказать с уверенностью, что ПО будет все лучше и лучше, потому что команды, работающие над его созданием, открывают для себя новые способы, позволяющие придавать ему новую ценность.
Легко понять ценность электронной книги задним числом. Гораздо труднее осознать ее на старте проекта. Давайте проведем мысленный эксперимент, чтобы исследовать это. Рассмотрим такой вопрос: как гипотетический читатель может узнать, что разработка программного обеспечения проводилась с использованием водопадного подхода?
«Делай так, как я говорю, а не так, как говорил»
Представьте, что вы в команде разработки самой первой портативной электронной книги. Техническая команда создала прототип устройства, которое имеет USB-порт для загрузки электронных книг и маленькую клавиатуру, позволяющую взаимодействовать с ним. Перед вашей командой стоит задача решить, какое программное обеспечение вы будете поставлять для этой электронной книги.
К сожалению, ваша компания имеет долгую историю создания ПО с использованием неэффективной, требующей подробной спецификации водопадной методологии. Поэтому первым делом ваш менеджер проекта организует большую встречу с участием всех, кого сможет найти. Ваша команда проводит несколько недель в переговорной комнате, встречаясь с топ-менеджерами компании, представителями издательства, которое хочет издавать электронные книги, ведущим менеджером по продажам из онлайн-магазина, желающего их продавать, и другими стейкхолдерами, которых нашел менеджер проекта и смог привести на встречу.
После нескольких дней интенсивных дискуссий ваши бизнес-аналитики смогли собрать воедино большую спецификацию с требованиями различных заинтересованных сторон, участвовавших в опросе. Была проделана тяжелая работа, но теперь у вас есть спецификации и все этому рады. Определен обширный пользовательский функционал, позволяющий предположить, что это будет самое передовое портативное устройство из всех доступных читателю. Появились функции сбора маркетинговой статистики для издателей, способные охватить все интернет-магазины и облегчающие процесс покупки книг. Есть инновационные функции для авторов с возможностью просматривать и редактировать свои работы, упрощая процесс публикации. Иными словами, предполагается поистине революционное программное обеспечение. После проведения всех подсчетов команда приходит к 15-месячному графику работ. Это кажется большим сроком, но все полны энтузиазма и уверены, что смогут довести дело до конца.
Перенесемся на полтора года вперед. Команда разработчиков электронной книги трудилась невероятно упорно, в том числе по ночам и в выходные дни, в результате чего распалось несколько семей. Такое колоссальное напряжение позволило выполнить проект точно по плану, практически день в день. (Это кажется невероятным! Но ради нашего воображаемого эксперимента попробуйте поверить, что так и произошло.) Каждое требование в спецификации реализовано, протестировано и исполнено. Команда очень гордится собой, и все заинтересованные стороны согласны, что получили именно то, что просили.
Итак, продукт выходит на рынок… и его ждет провал. Никто не покупает книгу, стейкхолдеры недовольны. Что же произошло?
Оказывается, ПО, актуальное всего полтора года назад, сегодня никому не нужно. За это время в отрасли произошли изменения, появились новые стандарты и отраслевой формат для электронных книг, которые не вошли в созданную ранее спецификацию. И теперь никто из интернет-продавцов не хочет размещать на своих ресурсах нестандартный формат. Команда создала отличный шаблон для интернет-магазина, но его интерфейс сильно проигрывает шаблонам, которые используют розничные продавцы в настоящее время. Поэтому он никого не привлекает.
Труд и усилия вашей команды по созданию специальной функции предварительного просмотра для авторов потрачены впустую, потому что эта функция уступает опции, разработанной конкурентами и позволяющей поддерживать документы MS Word и отправлять их по почте.
Какая неприятность! Спецификация, разработанная вашей командой в самом начале, имела большое значение для клиентов и была важна для всех как внутри компании, так и за ее пределами. Но теперь ПО, задуманное полтора года назад, потеряло свою ценность. Необходимость внесения некоторых изменений можно было обнаружить на ранних этапах проекта, но многое требовалось поменять с самого начала. Необходимая при водопадном подходе «подробная спецификация перед началом работы» лишает команду гибкости и не позволяет реагировать на изменения.
Так как же все-таки суметь удовлетворить потребности стейкхолдеров и запустить проект создания работающего программного обеспечения?