Текст книги "Пользовательские истории. Искусство гибкой разработки ПО"

Как делать не надо

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

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

Хенрик предлагает вот такую альтернативную стратегию.

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

По мысли Хенрика, таким образом, дело доходит до выпуска велосипеда, с помощью которого я получаю возможность передвигаться, более соответствующую моим потребностям. А получив мотоцикл, я действительно могу видеть, что ваши идеи работают, – я еду и получаю от этого удовольствие. Таким образом, это и есть минимально жизнеспособный для меня продукт. Если мне очень понравился мотоцикл, возможно, следующим шагом будет его улучшение до более крупной и быстрой модели, скажем, Harley-Davidson, а до спортивного автомобиля дело не дойдет (у меня как раз наступил кризис среднего возраста, поэтому мысль о Harley-Davidson мне очень нравится). Но принять это решение можно только после того, как я опробую мотоцикл и мы оба получим определенный опыт.

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

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

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

Эмпирическое обучение

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

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

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

Мне нравится термин «исследование продукта» – он отлично описывает то, что мы делаем на этом этапе. Наша цель пока не в том, чтобы что-то создать, – скорее убедиться, что мы создаем правильную вещь. Как оказалось, разработать что-то и дать заказчикам этим какое-то время попользоваться – лучший способ убедиться, что проект развивается в верном направлении. Я позаимствовал определение исследования у Марти Когана[10]10
  Марти впервые описал, что подразумевает под исследованием продукта, в своей статье 2007 года. Позднее он дал более детальное описание в книге «Вдохновение: Как создавать продукты, которые обожают пользователи» (Inspired: How to Create Products Customers Love by Marty Cagan, SVPGPress). – Примеч. авт.


[Закрыть], а мое определение включает практики Lean Startup и Lean User Experience, практики «мышления дизайнера» и множество других идей. Мое понимание того, что нужно делать на этапе исследования, постоянно развивается, но цель остается неизменной: как можно быстрее убедиться, что работа над продуктом идет в правильном направлении.

Ставьте минимальные эксперименты

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

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

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

Резюме

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

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

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

Глава 4. План своевременного завершения

Это Аарон и Майк. Они работают в компании под названием Workiva, где выпускают ряд продуктов на основе платформы Wdesk. Эта организация помогает другим большим компаниям решать серьезные задачи и является одной из крупнейших компаний типа «программное обеспечение как услуга», о которых вы, скорее всего, никогда не слышали.

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

Аарон и Майк только что завершили очередной раунд исследования продукта, и теперь они уверены, что нашли решение, которое стоит разработать и запустить для использования клиентами.

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

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

Очень важно отметить, что эта карта не охватывает весь продукт – она касается лишь функциональности, которую они добавляют в существующее приложение. Вот почему она намного меньше карты Гэри из главы 1 или карты команд Globo.com. Я подчеркиваю это потому, что некоторые ошибочно полагают: они должны составить карту историй всего продукта, чтобы внести крохотное изменение, и по этой причине отказываются от использования карт вообще.

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

Поделитесь с командой

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

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

Секрет верной оценки затрат времени

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

Лучше всего затраты времени оценивают те разработчики, которые верно понимают, что именно они оценивают.

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

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

Планируйте разработку шаг за шагом

У команды Workiva не было возможности уменьшить количество необходимых элементов в разработке. Они не могли проделать то, что сделала команда Globo.com, как описано в главе 2, то есть оставить часть запланированного на потом. В Workiva было решено, что нужно разрабатывать сразу все. На этапе прототипирования у них уже была возможность исключить многое и подтвердить, что решение до сих пор остается полезным для заказчиков. Тем не менее на карте можно выделить три среза.

«Зачем они вообще тратили на это время?» – можете удивиться вы. Действительно, предъявить треть от того, что нужно заказчикам, – это примерно как продавать одну треть спортивного автомобиля: никто не сможет на нем ездить. Но Майк владелец продукта. Он не может отойти в сторону после того, как найдено хорошее решение. Его роль немного меняется, и сейчас он больше похож на режиссера в кино: должен присутствовать при съемках каждой сцены. И ему нужно решить, какие сцены должны быть отсняты первыми, а какие – последними. Он знает, что к концу съемок фильма все сцены сложатся вместе и составят одно последовательное повествование.

Поэтому Майк и работал со своей командой над составлением плана разработки. Вот что они сделали – разделили карту тремя поперечными срезами.

Первый срез включает в себя основные функциональные элементы. Как только все фрагменты, входящие в этот срез, будут реализованы, работа с функциональностью может быть проделана в приложении шаг за шагом. Функциональность будет работать не во всех ситуациях, где запланировано, поэтому предъявлять ее пользователям на этом этапе нельзя: последует лавина жалоб и возмущений. Но зато Майк и его команда смогут понаблюдать за работой функциональности с начала до конца. Они смогут ввести реальные данные и оценить производительность приложения, а также применить некоторые средства автоматизированного тестирования, чтобы оценить способность к масштабированию нагрузки. Можно узнать многое о технических рисках, которые способны вызвать значительные проблемы позднее. Таким образом, двигаясь вперед, команда будет более уверена в своевременном окончании разработки. Или по крайней мере будут выявлены непредвиденные трудности, которые могут замедлить работу. Первый срез я называю функциональным ходячим скелетом – этот термин я позаимствовал у Алистера Коберна. Я слышал также, что в этом значении употребляются слова «стальной каркас» или «трассирующая пуля».

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

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

Не каждый срез достоин релиза

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

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

Еще один секрет верной оценки временных затрат

Еще один страшный секрет оценки (который на самом деле вовсе не должен быть секретом) заключается в том, что оценки… оцениваются заранее. Я уверен: порывшись как следует в сборниках оксюморонов, выложенных в Интернете, вы непременно найдете там термин «точная оценка». Если нам точно известно, сколько времени займет какая-то работа, разве мы вообще называли бы это оценкой?

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

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

Разделяя большие куски работы на меньшие, мы получаем больше возможностей для измерений. Какие-то тонкости, конечно, есть всегда, но в целом предсказания всегда будут тем точнее, чем больше есть примеров выполнения аналогичной работы, где известны временные затраты.

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

Регулируйте свой бюджет

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

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

В зависимости от того, насколько плохо будут обстоять дела, понадобится увеличение запасов пива.

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

Выявление рисков при составлении карт историй

Крис Шинкл, SEP

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

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

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

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

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

Результаты оказались поразительными.

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

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

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

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

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

Что сделал бы да Винчи? Я часто задаю себе этот вопрос. Ладно, хорошо, не задаю. Но, возможно, мне следовало бы так поступать.

По сути Майк и Аарон выбрали ту же стратегию, которой пользуются художники, когда хотят завершить свои произведения вовремя. Точно такой же подход я применяю при создании программного обеспечения на протяжении многих лет. А когда я познакомился со своими будущими друзьями в Globo.com, оказалось, что и у них такой же подход, потому что, как я уже говорил, даже если они запоздают с разработкой нового интерактивного продукта к Олимпиаде, Олимпийский комитет не станет переносить открытие Игр. Я также думаю, что и вы привыкли следовать той же стратегии, даже не задумываясь над этим.

Начну объяснение с того, чего не делал Леонардо да Винчи, но, к сожалению, часто пытаются проделать обычные люди, занимающиеся созданием программного обеспечения.

Представьте себе, что вы Леонардо да Винчи и собираетесь написать картину, следуя той же стратегии, к которой традиционно прибегают большинство команд в мире разработки[11]11
  Я взял идею этой простой визуализации из опубликованной в 2004 году статьи Джона Эрмитеджа «Подходят ли методы Agile для дизайна?». Джон описывает применение данного подхода при проектировании пользовательского опыта. Я думаю, эту метафору можно распространить и на разработку программного обеспечения. – Примеч. авт.


[Закрыть]. Вы можете начать работу с четким представлением о картине, по крайней мере вам так кажется. Вы разбиваете картину на несколько частей. Допустим, на эту работу отведено пять дней и каждый день вы рисуете по одной части. А к концу пятого дня – бах! – вы закончили! Что может быть проще?

Проблема лишь в том, что в реальности это не работает, по крайней мере для художников. Что-то создать таким образом можно, если предположить, что изначальное видение точно и правильно. Необходимо также, чтобы автор был высокопрофессионален и способен точно выделить части работы без визуального представления их в контексте. Если вы поступаете подобным образом при разработке программного обеспечения, это называется стратегией постоянного прироста (инкрементальной). По сути, таким образом каменщик строит стену, и этот способ хорошо работает, если размеры всех кусочков одинаковы и хорошо определены – как у кирпичей.

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

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

Мне, к сожалению, не приходилось наблюдать за Леонардо, но, я полагаю, он делал что-то очень похожее.

Даже Леонардо да Винчи, вероятно, признал бы, что его первоначальное видение картины не было идеальным, а он кое-что понимал в рисовании. В первый день, как мне представляется, он рисовал эскиз композиции или, может быть, делал легкий набросок. Я уверен, что на этом этапе он вносил в композицию небольшие изменения: «Хм, кажется, здесь самое важное – ее улыбка. Надо убрать руку от губ. А эти горы на заднем плане… Кажется, они слишком высокие, недостает пространства».

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

«Работу над великим произведением искусства невозможно завершить – ее можно только прервать» (Леонардо да Винчи).

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