Главные мысли и примечательные цитаты из книги разработчика Apple, который участвовал в создании Safari для Mac OS, клавиатуры для первого iPhone и др.

Книга доступна на русском языке. Я покупал на Озоне.

Глава 1. Демонстрация

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

Глава 2. Магический кристалл

Демоверсия продукта — это не продукт. Она должна позволять оценить идею продукта и спланировать этапы его разработки. Для этого демоверсия должна быть тщательно cрежиссирована: в ней не должно быть вещей, которые не важны для оценки идеи продукта, и наоборот должны быть те, которые хоть и не являются основной целью продукта, но создают видимость, помогают поверить в то, что основная цель (главное, что нужно целевой аудитории) выполняется. Если при создании демоверсии ты где-то увяз и не можешь продвинуться дальше, скорее всего это не поможет создать демку. Это нужно скорее бросить и пойти другим путём.

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

Глава 3. Чёрный прямоугольник

Гений или законченный продукт — это 1% вдохновения и 99% тяжелого труда. Не надо думать, что классные продукты получились, только благодаря классным идеям. Идея — это то, что видно на поверхности. Но за её реализацией скрываются многие часы нудного, упорного труда.

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

Глава 4. Одно простое правило

Стив Джобс начинал готовиться к презентациям за 3—4 недели. Он репетировал снова и снова. Причём так, будто он уже находится на сцене перед сотнями зрителей. Он выверял каждое выражение и доводил презентацию до совершенства, зная каждое слово.

На пути к сложной цели важно выбрать одно простое, понятное всем вдоль и поперёк правило, которое поможет к этой цели прийти. И все, каждый должны это правило понимать досконально.

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

Такое правило, одна чёткая цель, помогает не делать то, что не надо, и избегать связанных с этим ошибок: «красивый» дизайн; бесконечные аб-тесты на цвет кнопки; раздутые команды; обсуждения без итогов, что делать дальше; стоящие сбоку отделы исследований и тд. Фокус на том, что поможет достичь цели, и отгораживание от того, что не поможет.

Или другой пример. Футбольный клуб «Пэкерс», который в 1959 году был полным аутсайдером. Пришёл тренер Винкс Ломбарди и стал на протяжении лет отрабатывать одну единственную комбинацию. Все соперники знали об этой комбинации. Но «Пэкерс» фокусировались только на ней, поэтому смогли отработать её настолько хорошо, что никто не мог противостоять.

Глава 5. Самая трудная задача

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

Кен рассказывает, как хотел уйти из Apple, потому что руководителем Safari сделали другого сотрудника:

«Потом Скотт узнал, что я недоволен решением о смене руководства в группе Safari. Он вызвал меня к себе. Мы просидели пару часов, и он дал мне понять, что не хочет, чтобы я уходил. Форсталл настоял на том, чтобы я оставил свои обиды по поводу смены руководства в прошлом, а чтобы помочь мне сделать это, он попросил рассказать ему обо всём, что меня задевает. После того как мы немного поговорили, он верно пришёл к выводу, что проекты мне нравятся гораздо больше, чем политические игры. Поняв это, Скотт сказал, что, возможно, у него есть интересная идея проекта для меня и через несколько недель мы встретимся, чтобы поговорить о ней.

Это мне подходило. Я действительно не хотел уходить из Apple. Мне нравилась направленность компании на то, чтобы разрабатывать крутые продукты, и я хотел делать их и дальше. Демонстрация полного доверия Скотта значила больше, чем то, что именно он сказал, и это повлияло на моё решение остаться. Я ощутил, что пока я работаю с ним и могу обратиться к нему в случае необходимости, со мной всё будет в порядке.»

Глава 6. Дерби с клавиатурой

Каждая функция iPhone начиналась с демо. Разработчики буквально должны были демонстрировать свои идеи. Они не могли рассказывать об идеях. Нужно было их показать. Причём демоверсия должна быть максимально точной и конкретной. Без демо не о чем спорить, нечего обсуждать — это абстрактные разговоры ни о чём. Демо — это возможность дать конкретную обратную связь на конкретные вещи, из которой становятся понятны следующие шаги. И конкретика этой обратной связи куда важнее того, от кого эту обратную связь получаешь (даже если это твои коллеги, а не реальные пользователи).

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

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

Глава 7. QWERTY

Дизайн — это то, как он (продукт / дизайн) работает. А вовсе не то, как он выглядит или воспринимается.

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

Глава 8. Конвергенция

Кен Косиенда отвечал за разработку клавиатуры для сенсорного экрана iPhone. Когда он понял, что его простенького алгоритма автоисправления не хватает для достойного качества, он пошёл к экспертам по текстам Apple. Те рассказали ему про цепи Маркова, условные случайные поля, Байесовские выводы и динамическое программирование. Но Кен ничего из этого не понимал. У него нет инженерной подготовки. В колледже он не ходил ни на один математический курс. Поэтому для решения задачи автоисправления он решил, что ему надо придумать что-то попроще. И это пишет про себя человек, чьей клавиатурой мы все пользуемся последние 10+ лет❤️

Про фокус (нацеленность на результат)

Дуглас Боуман, в 2006 году один из главных специалистов компании по визуальному проектированию Google, объяснил свой уход из компании:

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

Да, это правда, что команда Google не в состоянии выбрать из двух оттенков голубого, поэтому они тестируют 41 оттенок, чтобы понять, какой из них смотрится лучше.»

Кен Косиенда это комментирует:

«В то время как A/B-тестирование может быть хорошим способом найти один, самый привлекательный оттенок голубого, динамическое распределение между лучшим и худшим не так велико. Куда более важно то, что возможность пройти через все варианты означает, что у команды разработки останется меньше времени на то, чтобы продумать дизайн, который понравится людям в два, три или десять раз больше. A/B-тестирование может быть полезно при выборе цвета, благодаря которому люди будут чаще нажимать на ссылку, но это не поможет создать продукт, который ощущается как привлекательное единое целое. Google исключил вкус из своего процесса разработки.

В Apple нам и в страшном сне не могло такое привидеться. Мы никогда не устраивали A/B-тестов для какого-либо программного обеспечения iPhone. Когда дело доходило до выбора цвета, мы брали один. Мы использовали наш хороший вкус и наши знания о том, как сделать ПО доступным для людей с проблемами зрения, связанными с восприятием цвета, и двигались вперёд.

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

...

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

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

...

«У нас не было несоответствия между управлением и участием в проекте, когда высокопоставленный руководитель может пытаться имитировать доминирующую позицию Стива Джобса, лично не вкладывая ничего в работу. Стоящие особняком менеджеры высокого уровня, принимающие все ключевые решения, — это настолько распространённая беда, что они даже удостоились своего личного интернет-мема — „Чайка-менеджер“. Так говорят о руководителе высшего звена, который редко бывает на месте, но иногда внезапно прилетает неизвестно откуда, приземляется на ваш пляж, громко кричит, повсюду бьёт крыльями, потом взлетает в воздух, кружит над головой, сбрасывает на каждого большую какашку, а потом улетает восвояси оставив остальную команду разгребать беспорядок, строить предположения о том, что всё это значило и что делать во время следующего неизбежного визита.

У нас не было больших, стоящих на переднем крае современных технологий исследовательских отделов, существующих обособленно. Они работали в тесной связке с разработчиками и программистами, вместе создавая и преподнося покупателям реальные продукты. Хорошо известно, как Стив Джобс расформировал в Apple подобную организацию — группу передовых технологий — вскоре после того, как вернул себе управление компанией в 1997 году.

Подобные вредные шаблоны могут не позволить творческому отбору правильно функционировать, поскольку блокируют стабильное накопление положительных изменений во время разработки. Это не всё, чем можно разрушить процесс. Вы можете проводить показы демоверсий и прерывать их, так и не решив, что делать дальше, — ошибка, которая прерывает цепь критики, обеспечивающей логическую связь одной демоверсии с другой. Вы можете собирать раздутые команды проекта для выполнения заданий, с которым управятся один или два человека — недостаток, ведущий к путанице в коммуникации и ослаблении возможности каждого внести свой вклад. У вас могут быть конфликты в субординации, и вы никогда не сможете принять окончательное решение, которое признавали бы все. Вы можете создавать дизайн, руководствуясь тем, как изделие выглядит, что сейчас в моде или каким-то абстрактным идеалом, а не думать о том, как оно работает. Вы можете использовать A/B-тестирование, чтобы принимать простые решения, как это, очевидно, делали в Google.

Мы старались избегать всех этих ловушек. Если пытаться объяснить, почему это происходило, я бы сказал, что сбиться с пути нам не давало чёткое ощущение цели. Мы всегда были нацелены на создание грандиозной продукции — если для этого и не было никаких других причин, то всегда оставалось требование Стива. Возможно, поэтому мы и ориентировались на то, что могло помочь нам, и отгораживались от того, что не помогало.»