Перейдем к делу.
Сначала прочтите это
В этой книге нет введения.
Да, вы все прочитали правильно. И сейчас, наверное, задаетесь вопросом: «Почему же в книге Джеффа нет введения? Может быть, он забыл его написать? Не пора ли ему на покой? Или введение съела его собака?»
Нет, я не забыл написать введение. И мне не пора на покой (по крайней мере я туда не собираюсь). И моя собака не съедала введения, хотя насчет морской свинки своей дочери я не был бы так уверен. Это просто потому, что за долгое время я убедился: авторы тратят кучу времени, пытаясь убедить меня прочесть их книгу, и большая часть этого времени приходится на введение. Самое интересное во всех книгах начинается примерно с третьей главы. Кроме того, я уверен, что не я один всегда пропускаю введение.
Так что эта книга начинается прямо здесь.
И вам ни в коем случае нельзя пропускать эту часть, так как на самом деле она самая важная. Я буду доволен, если вы вынесете из книги всего две мысли. Вот эти две мысли.
• Цель работы с историями не написание идеальных историй.
• Цель разработки продуктов не создание продуктов.
Сейчас я все объясню.
Игра в испорченный телефон
Вы наверняка помните, как в детстве играли в дурацкую игру «Испорченный телефон». Вы говорили кому-то шепотом слово или фразу, тот озвучивал это следующему, и так повторялось с каждым играющим, а затем последний участник провозглашал совершенно искаженное сообщение, и все дружно смеялись. Сегодня мы часто играем в эту игру всей семьей за обедом. Кстати, родителям на заметку: это отличный способ занять детей, скучающих, когда взрослые беседуют.
В мире взрослых мы также продолжаем играть в эту игру, разве что больше не шепчем. Мы пишем длиннющие документы и проводим торжественные презентации, чтобы дать поручение кому-то другому, а затем получить от него совершенно не то, чего ожидали. А этот человек использует эти документы, чтобы написать еще больше документов и передать их еще большему количеству людей. Только вот, в отличие от детской игры, в конце концов нам становится не до смеха.
Когда люди читают письменные инструкции, они истолковывают их совершенно по-разному. Если вам сложно в это поверить (в конце концов, все это тоже написано!), читайте дальше – вот несколько примеров того, как инструкции действуют абсолютно неверно.
Перед вами обложка книги Джен Ятис «Торты, которым не повезло», опубликованной в издательстве Эндрю Мак-Милла (спасибо Джен и Джону Ятис за предоставление иллюстрации). Книга получилась по мотивам ее очень забавного сайта cakewrecks.com (только не ходите туда, если у вас нет по меньшей мере часа свободного времени). На сайте собрана коллекция по-идиотски украшенных тортов, логика их создателей не поддается объяснению, хотя Джен и предпринимает попытки сделать это. Так, одна из самых часто встречающихся и в книге, и на сайте тем – неверно понятые требования. Джен, конечно, не называет их требованиями, ведь это слишком формальный термин, вместо этого она употребляет слово «записи», так как исполнитель слушает и записывает, понимая буквально то, что слышит. Глядя на эти фото, я могу вообразить сотрудника кондитерской, который слушает заказчика и записывает его пожелания, а потом передает их кому-то, кто будет украшать торт.
Заказчик: «Здравствуйте, я хотел бы заказать торт».
Работник: «Конечно, что бы вы хотели на нем написать?»
З.: «Вы могли бы написать “Всего хорошего, Алиса” фиолетовым цветом?»
Р.: «Конечно».
З.: «А вокруг надписи пусть будут звезды».
Р.: «Без проблем. Я записал ваши пожелания и прямо сейчас передам их кондитеру-декоратору. Торт будет готов к завтрашнему утру».
Вот что получилось в результате.
Вот еще один пример. В разработке программного обеспечения такие вещи мы называем нефункциональными требованиями.
Все это очень весело, и можно посмеяться над 20 долларами, пропавшими зря. Но часто понесенные потери бывают куда более серьезными.
Может быть, вы слышали о неудачной попытке отправить в 1999 году на Марс орбитальный климатический зонд, в результате аварии которого NASA понесло убытки в размере 125 млн долларов[2]? Если не слышали, вот суть случившегося. Если когда-нибудь какой-либо проект по самые уши тонул в бумажной документации, это был, несомненно, проект NASA. Но несмотря на огромное количество требований и других документов, зонд вышел из строя по той простой причине, что NASA пользовалось метрической системой измерений, а инженеры партнерской компании Lockheed Martin, которые разрабатывали навигационные команды для двигателей аппарата, – британской. В результате никто не знает, где сейчас находится зонд, и некоторые надеются, что он нашел свое место на солнечной орбите где-то за Марсом.
Какая ирония – мы вкладываем огромные усилия в написание документов, чтобы общаться более ясно и избегать недоразумений, а в итоге получаем прямо противоположный результат.
Общие документы не дают единого понимания.
Притормозите на минутку и запишите это. Запишите на стикере и положите себе в карман. Представьте, что эти слова вытатуированы где-то на вашем теле и вы можете их видеть, когда утром приступаете к работе. Когда вы прочитаете их снова, вспомните истории, которые я вам сейчас рассказываю.
Единое (общее) понимание – это когда мы оба хорошо понимаем, что и почему представляет себе каждый. Очевидно, что между кондитерами и людьми, дававшими им инструкции, такого понимания не было. И в NASA какой-то важный начальник не обеспечил одинакового понимания того, как работает система управления, всеми участниками процесса. Уверен, если вы трудитесь в сфере разработки ПО, то быстро вспомните аналогичную ситуацию: два человека были уверены, что пришли к соглашению относительно функции, которую хотели добавить в проект, но оказалось, что они представляли себе совершенно разные вещи.
Единое понимание – это невероятно просто
Мой бывший коллега Люк Баррет первым показал мне этот комикс, чтобы описать проблему. Я спросил, где он его видел, но он так и не вспомнил (кто-то, возможно, не получает авторских отчислений). Годами я наблюдал, как Люк демонстрирует эти четыре слайда в презентации PowerPoint, и всегда воспринимал их как нечто забавное, но довольно банальное. Видимо, я туговато соображаю: лишь много лет спустя осознал, что этот комикс иллюстрирует, наверное, самую важную особенность работы с историями при разработке ПО.
Суть в том, что если у меня есть какая-то идея, я ее записываю на бумаге, а вы затем это читаете, то вполне можете представить что-то совершенно иное, чем я. При этом можно спросить каждого: «Вы согласны с содержанием этого документа?», и все дружно ответят: «Да! Да, мы согласны!» Но если
