Скоро наш журнал обновит свой дизайн
Close
Будь в курсе
Подпишитесь на рассылку, чтобы не пропускать новые выпуски журнала
лекция
Управление и результаты
Из А в Б. ФФФ
Когда мы начинаем любой проект, мы обычно рассуждаем: есть какая‑то точка А, в которой мы сейчас находимся, и точка Б, в которой мы хотим оказаться. И мы представляем линию, которая нас туда приведёт. Это план проекта: надо сделать то‑то, и мы придём в точку Б.

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

Хочется всегда верить, что если сделаешь всё хорошо, если постараешься, хорошо спланируешь и, если тебе повезёт, то так всё и пойдёт — по плану. Нет. Никогда по плану ничего не будет, потому что, как только мы из точки А выйдем, на нас начнут действовать силы природы: сила трения и так далее. И выражаться это будет в чём угодно: программист заболел, у дизайнера закончилось вдохновение, клиент решил изменить задачу, вмешалось правительство и издало закон — картинку какую‑нибудь нельзя использовать — и так далее. И все эти силы будут нас отклонять от этого идеального плана. В реальности наше движение будет больше похоже на синусоиду, которая колеблется вокруг этой линии. И в результате мы придём вообще в какую‑то точку Б´, о которой в точке А мы даже и не думали.

Все думают, что будет вот так:
А реально будет вот так:
На этом рисунке прямая «Из А в Б» нарисована пунктиром, а на самом деле пришлось преодолевать и овраги, и монстров всяких, и акулу, и так далее. А пришли в результате вообще куда‑то в другое место.
«За маму»
Был давно в бюро проект детского питания. Человек привёз [произвёл по заказу — прим. редактора] детское питание для грудничков французское, хорошее и хотел продавать. Он обратился в бюро, чтобы ему сделали название, логотип, упаковку и сайт. И в бюро сделали.
На картинке этапы в процессе. Шрифтовой дизайнер рисовал, арт‑директор утверждал и так далее. Сделали упаковку:
И вот, считай, конец, но в России есть особенность с детским питанием — у нас оно очень жёстко контролируется, и всё нужно утверждать в институте питания РАМН. И он работает: в этом именно месте наше государство работает.

— Проверяет дизайн упаковки? Всё‑всё‑всё?

— Я не уверен, что прямо дизайн, но основные моменты… Главное, что в конце, когда всё было сделано, клиент послал всё это в институт питания, и ему приходит ответ:
Название «За маму» не подходит, потому что может создаться ощущение, что это замена грудного молока, а это запрещено. И до конца проекта два или три дня, а не подходит название. Не подходит название — значит, не подходит логотип, значит, надо всё переделывать.

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

В результате было придумано новое название, которое подошло под всю стилистику. Мы всё переделали, и проект теперь называется «Я расту».
Интерфейс управления зондовыми микроскопами «НД‑МДТ»
Это пример Артёма Горбунова с тех времён, когда он ещё в студии Лебедева работал. Они делали проект «НД‑МДТ», это программа для управления зондовым микроскопом. Там куча интерфейсов. Но нам интересен не интерфейс, нам интересно, что Артём в результате нарисовал, как шёл проект.
Видите, во‑первых, тут не очень хорошо видно, но эти подписи — это месяцы. Проект измеряется месяцами. Эти маленькие зелёные «колбаски» — это, собственно, работа, а все дыры между ними — это некие простои, точки — это письма, переписка с клиентом. Одно то, что Артём нарисовал этот график, говорит о том, что тут что‑то сильно пошло не так.

Опять же, я не знаю что там происходило, но смысл в том, что явно проект пошёл не по плану.
«Термофор»
Пример с сайта Тёмы Лебедева. Они делали сайт про печи и буржуйки. И я очень люблю последнюю часть. Это пишет клиент отзыв о работе студии: «Мой младший внук, родившийся после начала согласования ТЗ, научился сложносочинённо говорить к выходу сайта на стадию бета‑тестирования. И я верил, что сайт будет опубликован раньше, чем он научится курить».

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

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

Чиновник: Первоначальный срок — это июнь две тысячи одиннадцатого года.

Путин: Июнь две тысячи одиннадцатого?

Чиновник: Да.

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

Чиновник: Да.

Путин: Удорожание объекта есть?

Чиновник: Его даже… Первоначальные сроки, когда, помните, у нас принимали решение о предоставлении кредита…

Путин: Ну примерно?

Чиновник: Было миллиард двести.

Путин: А стало?

Чиновник: Стало восемь.

Путин: Из миллиарда двести превратилось в восемь миллиардов?

Чиновник: Да.

Путин: Молодцы, хорошо работаете. Ну, пойдём дальше.

Клёво, что на вопрос «Какое удорожание?», чиновник сначала сказал: «Ух!.. Его даже…». Видимо, хотел оценить.

Может быть, всё дело в том, что дизайнеры вечно расхлябанные, а чиновники воруют — но вот вам пример из разработческой среды.
«Занаду»
Есть такой проект, называется «Проект Занаду». И это проект мирового уровня, надсистемного. Ребята решили придумать новую основу веба. У нас сейчас веб построен на метафоре страниц, она взята из реальной жизни: есть страница, есть вторая страница и есть возможность ссылку сделать — нажать здесь, чтобы открыть ту страницу. И всё. Но парни подумали: «У нас же уже не страницы, у нас же теперь компьютер, и мы можем использовать все его возможности!» — и придумали такой проект, где документы хитро друг с другом связаны, в него заложено версирование, и выглядит всё это вот так:
Это даже работает. Тут какие‑то части документа могут иметь историю, и связаны с другими документами, но есть один момент: проект разрабатывался 54 года, с 1960 по 2014 год.

Это проект занесен в Книгу рекордов Гиннеса как самый долгий айтишный проект. Представьте, что такое 54 года: за это время произошло всё. Сейчас уже нет никакой возможности заменить веб — это основа всего — ХТТП и так далее. А в 1960 году даже формат времени TimeStamp не существовал.

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

Всё это приводит нас к мысли о том, что не бывает стопроцентных проектов вообще никогда.
Закон о потерях
Нельзя за 100% времени, 100% денег и со 100% качеством сделать всю функциональность. Что‑то из этого поменяется. Потому что будут неожиданности, влияния внешней среды. Они неизбежны, и в каждом проекте они всегда новые. Вы не можете предугадать: сегодня программист заболел, завтра вас вообще из офиса выселяют, потому что он, например, понравился мэру.
Чем жертвовать
Раз нельзя сделать всё на 100%, чем жертвовать?

Время
Чаще всего люди временем жертвуют: не успели что‑то сделать — добавили недельку, две, месяц. Почему время добавлять не очень хорошо?

Время — ограниченный и невосполнимый ресурс. Если вы потратили недельку, больше она к вам никогда не вернётся, что бы вы ни делали. И, хоть это пафосно звучит, всем нам отведено какое‑то время жизни, тоже ограниченное, и хочется за это время жизни успеть сделать побольше, а не просто пилить какой‑то продукт.


Фичеризм
Добавление времени ведёт к фичеризму.

Представьте, что у вас было две фичи: А и Б. А почти готова, а Б тоже готова, но не так же хорошо, как А. И вы решили, что надо допилить фичу А — и выпускаемся. И добавили, как всегда, с запасом, недельки две. И за эти две недельки вы успели полностью сделать фичу А, а фичу Б тоже решили поделать. Она почти уже готова и, кажется, совершенно глупо взять её и не доделать. И поэтому, кажется, что имеет смысл добавить ещё недельки две, чтобы фичу Б добавить. И это приводит к тому, что фичи нарастают, накапливаются и в результате получается «проект Занаду», который не выходит годами. И ничего не происходит.


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


Старение
А раз он не выходит, он устаревает.

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

Сейчас, по‑моему, у Тинькова, тач‑айди есть, но тогда оно, видимо, где‑то забуксовало в кипе всех остальных фич.

Время добавлять очень плохо. Оно невосполнимо, и [задержка] ведёт к неприятным последствиям в проекте.

Деньги
Можно добавить деньги: добавить программиста, добавить дизайнеров. Но с деньгами тоже есть несколько проблем.

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

Во‑вторых, добавление денег обычно обозначает добавление каких‑то ресурсов, которыми нужно управлять. И получается, вы добавили нового программиста, а ему нужно въехать в код, он будет сидеть и тупить. А когда он въедет, он ещё скажет, что тут всё надо переписывать.

Итак. Деньги тяжело зарабатываются, усложняют управление. Поэтому деньги добавлять тоже нежелательно. Особенно для клиента, у которого проект, к примеру, за личные средства делается.

Качество
Ещё можно жертвовать качеством. Качеством очень часто жертвуют. Это из серии «а, ну ладно, не доделали что‑то, это только на части пользователей проявляется, ничего страшного, открываемся как есть». И, действительно, продукт может выйти в срок и работать, но качество — это всегда удар по репутации. А репутация — коварная штука: её годами зарабатываешь, а потерять можно в один момент.

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

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

Или игра «Инфинити‑блейд». Про эту игру Джобс всё время рассказывал. Они выпустили новую версию и удалили аккаунты игроков. И игра с пятью звёздами тоже отхватила: весь прогресс слетел, мат и всё такое. После такого все будут вспоминать игру примерно так: «Ах, это те чуваки, которые удалили мой профиль!». Хотя до этого три года у них всё было хорошо.

Репутацией жертвовать, мягко говоря, нежелательно.

Ещё пример из Рокетбанка.

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

Получается, баг ударил по репутации Рокетбанка, но они потом исправили.

Функциональность
И просто методом исключения из нашего списка остаётся функциональность.

Временем жертвовать нельзя, деньгами нельзя, качеством не жертвуем. Остаётся функциональность. А с функциональностью интересная история:

Во‑первых, функциональность восполнима. Это значит, что если вы фичу какую‑то не прикрутили, вы всегда можете взять и её прикрутить потом. И она не прокиснет.

Проверка идей. Когда вы запускаете продукт в срок, вы всегда проверяете его в реальной жизни. Всё, что вы делали до запуска — это какие‑то гипотезы. Даже если вы гений, всё равно это [только] лучшие соображения. Сколько экспертов не приведи, все могут ошибаться. И только реальная проверка показывает: работает или нет. И пока вы тянете, пока у вас проект в разработке, вы не получаете информацию. Собственно, за это борется бережливый стартап — нужно быстрее запуститься и получить фидбек из реального мира.

Радость пользователей. Удивительно, но флекс — упрощение или удаление функциональности — обычно связан с радостью для пользователей. Работает следующим образом: человек и так уже купил у вас продукт, и через месяц вы ему — бац! — и обновление бесплатное. И все пишут, как хорошо. А если вы ему сразу две фичи, но полусырые, все напишут: какой ужас, ничего не работает.

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

А если вы добавляете новую функцию, вам даже париться не надо — у вас отличный повод ещё раз всем напомнить о своем продукте, приложении или сайте и рассказать, что у вас новая фича. И все пойдут смотреть.

Упрощение. Продукты с малым количеством функций проще отлаживать и запускать, и риск ошибиться гораздо меньше.
ФФФ
В описанном выше и есть смысл подхода ФФФ, название которого произошло от английской фразы fix time, fix budget, flex scope.

Время — фиксировано, бюджет — фиксированный, а функциональность — гибкая.

Мы верим в то, что дедлайн должен быть фиксированным и, что гораздо ценней проверить продукт в реальной жизни, чем добавлять в него новые функции.
Полезное действие
Мы договорились, что функциональность можно изменять, но как понять, что именно и как изменять? Есть список функций, может, даже из разных источников: клиент одно говорит, дизайнер второе, разработчики говорят «надо базу устанавливать»…

Как понять и как выбрать? Ответ: нужно знать, в чём польза. Пользу вообще надо всегда понимать — это не только про ФФФ, а относится к любому методу планирования. Даже если вы строите космический корабль, и у вас каскадная модель разработки, важно понимать пользу.

Убирать функции сложнее, чем добавлять время. Время очень легко добавить. Главное — договориться со всеми, чтоб вам клиент сказал ОК и разрешил добавить две недели. Вы сами внутренне должны согласиться, что вы их уже потратите дальше — и всё. А с функциями непонятно, что убирать: контакты на сайте флексить, или…

Любое принятие решений, и флекс в том числе, опирается на полезное действие. Флекс — это изменение функциональности или отказ от функциональности.

Например, есть автомобиль ВАЗ‑2107:
В чём его польза? Реальное полезное действие этого автомобиля — в перемещении, в передвижении. Как можно описать его полезное действие? Например, отвезти семью пенсионеров на дачу на выходные. И он с этим справится. А в чём польза лимузина?
Book design is the art of incorporating the content, style, format, design, and sequence of the various components of a book into a coherent whole. In the words of Jan Tschichold, "methods and rules upon which it is impossible to improve, have been developed over centuries. To produce perfect books, these rules have to be brought back to life and applied."
Front matter, or preliminaries, is the first section of a book, and is usually the smallest section in terms of the number of pages. Each page is counted, but no folio or page number is expressed, or printed, on either display pages or blank pages.