Мы представляем себе точку А, в которой находимся, точку Б, в которой хотим оказаться, и идеальную линию, которая соединяет эти две точки,— это план проекта:
Самая большая ошибка — предполагать, что проект пойдёт, как задумано.
Проект — это путешествие из точки А в точку Б, полное неожиданностей и приключений.
Начиная движение, проект сталкивается с сопротивлением окружающей среды. Дизайнер забывает учесть сложный случай. Клиенту не нравится дизайн. Программистов тормозит проблема в реализации. Кто‑то заболевает. У кого‑то ломается компьютер. Можно перечислять возможные сюрпризы, но в каждом проекте будут свои.
Проект движется и колеблется вокруг идеальной линии, и, возможно, придёт в совсем другую точку Б’:
Закон о потерях: нельзя реализовать задуманный проект за 100% времени, 100% денег, со 100%‑й функциональностью и без потери качества. При отклонении от курса придётся чем‑то пожертвовать. Чем именно — жизненный выбор.
Репутация зарабатывается годами, а теряется за один день. Поэтому жертвовать качеством — не вариант.
Фиксируем срок. Если команда не успевает доделать проект вовремя, обычное решение — сдвинуть срок запуска. Но время — невосполнимый ресурс, недаром deadline происходит от слова «смерть». За отпущенное нам время мы успеем только то, что успеем. Чтобы не уходить в мрачные аналогии, мы сравниваем запуск проекта с наступлением Нового года. Отодвинуть его нельзя, даже если ты не успел купить подарки. Мы не сдвигаем срок.
Фиксируем бюджет. Когда проблемы в проекте решают деньгами, это означает одно из двух: либо оплачивают дополнительное время, либо расширяют команду. Первое не подходит. А увеличение команды нередко снижает управляемость проекта и только усугубляет его проблемы.
Флексим. Когда жертвовать сроком, бюджетом и качеством нельзя, методом исключения приходим к одному: жертвуем функциями, «флексим». Отрезаем то, что не успеваем сделать.
Аббревиатура ФФФ означает fix time, fix budget, flex scope. Мы работаем с фиксированными сроками и бюджетом, а функциональность оставляем гибкой
Этот вариант — большая удача:
Часть клиентов соглашаются с этим подходом, часть — нет. Но даже если клиент согласен, это не значит, что проблем не возникнет. Мы честно предупреждаем о подводных камнях.
Флексить страшно
Несмотря на плюсы, звучит устрашающе: в запущенном с нами продукте оказывается меньше функций, чем изначально планировалось. Мы понимаем, что наш подход к ведению проектов может выглядеть как шарлатанство в глазах некоторых клиентов.
Любой человек, если заказывает ящик апельсинов, а потом точно в срок получает отличные апельсины, но только пол‑ящика, почувствует себя обманутым. Но доставка апельсинов — стандартизованная процедура с отлаженной логистикой. Риски предсказуемы и сразу заложены в цену.
С проектами иначе. У Колумба в экспедиции были бунты, болезни, поломки и штормы. И в результате он открыл вовсе не ту страну, на путешествие в которую собирал деньги.
Проект гораздо больше похож на экспедицию, чем на доставку апельсинов.
Флексить больно
Одно дело решить делать зарядку по утрам, другое дело — делать её. Когда приходит время отказаться от какой‑то задумки, больно всем. Дизайнерам больно, потому что они придумали классную фишку, но её не будет в продукте. Разработчикам обидно, потому что они потратили силы на отладку функции, а её пришлось убрать. Но больнее всех клиенту, который придумал проект и имел от него свои ожидания.
Не все готовы к этой боли.
Клиент — предприниматель
Мы работаем напрямую с предпринимателем — человеком, который затеял проект и принимает в нём все решения. Обычно это директор компании. Мы привлекаем его с самой первой встречи, ведь самое главное говорится в начале.
Чтобы сделать проект без директора или с минимальным его участием, нужно либо лишить его права голоса (что звучит неправдоподобно), либо попросить его делегировать задачу человеку, которому он полностью доверяет.
Опыт показывает, что если мы будем пытаться угодить нескольким «клиентам» одновременно, проект получится болезненным, а продукт — беззубым и компромиссным. Мы не сможем взяться за проект, в котором больше одного командира.
Результат — это пуск
Обычно дизайнеры отдают клиенту картинки.
Но большинство дизайнерских решений принимается на этапе разработки. Что произойдёт, если пользователь нажмёт на эту кнопочку при незаполненной форме? Что делать, если в реальной базе данных на странице оказывается в три раза больше текста, чем предусмотрено дизайном? Как выглядит 404‑я ошибка при ширине экрана 2000 пикселей? Поскольку дизайнер не позаботился об организации этого этапа, а клиент не подозревает о проблемах, все решения достаются бесконтрольным программистам:
Дизайнер кладёт скриншоты в портфолио, а на реальный продукт без боли не взглянешь.
Раньше бюро пыталось осуществлять авторский контроль над разработкой через клиента:
Дизайнеры спамят клиента замечаниями о том, что продукт не похож на картинку. Клиент передаёт программистам. Программисты кладут в баг‑трекер. Список проблем растёт быстрее, чем его успевают разгребать. Дизайнеры паникуют, запуск несколько раз откладывается, в конце концов клиент вынужден открыть сырой продукт.
Чтобы повысить эффективность коммуникации в проекте, нужно оставить клиенту принятие ключевых решений, а общение о поведении кнопки на форме обратной связи вести напрямую с программистами:
Решения в любом проекте принимаются постоянно. Ни подписание ТЗ, ни утверждение чертежа не способны зафиксировать конструкцию будущего самолёта. Если вы создаёте пользовательский интерфейс, большая часть решений во время его разработки будут дизайнерскими — кто бы их ни принимал. Лучше, чтобы решения принимали дизайнеры совместно с клиентом, а затем напрямую, через технического директора, транслировали их в разработку.
Дизайнерское управление разработкой гарантирует, что программисты будут работать не на ТЗ и баг‑трекер, а на проект. Перед началом проекта мы тестируем разработчиков. В проекте — руководим ими. Это может не подойти вашему техническому директору.
Регулярные пуски
Предположим, в продукте задумано четыре функции, а разработка оценена в четыре месяца. Тогда, теоретически, через четыре месяца откроются эти четыре функции:
Но это теоретически. В жизни длинные проекты не идут по плану. Сначала дедлайн кажется бесконечно далёким и все расслабляются. К концу все устают от труда без видимого результата и опускают руки. Работа требует длительных вложений без информации о том, правильно ли приложена сила.
Мы разбиваем большой проект на короткие итерации. Результат каждой — пуск полезной функциональности:
Так каждая отдельная функция начнёт приносить аудиторию и доход гораздо раньше, а если в процессе работы мы поймём, что первоначальный набор функций и план были неверными, сможем скорректировать работу.
Ритмичные пуски держат команду в тонусе: во‑первых, пуск всегда вот‑вот, и расслабляться некогда; во‑вторых, ничто так не вдохновляет команду, как объявление «Мы открылись».
Никаких сюрпризов
Как идёт проект по ФФФ? В самом начале мы пишем понедельный план от начала работы до пуска. Для каждой недели известна работа и результат.
За пуск проекта отвечает ведущий дизайнер: он понимает задачу, руководит работой дизайнеров, проводит презентации, согласовывает замечания с клиентом, передаёт задачи разработчикам и проверяет, чтобы всё было сделано вовремя. Если на очередной неделе что‑то пошло не так и есть угроза сроку, вероятно, придётся флексить.
Самый страшный грех ведущего дизайнера — принести клиенту в последний день половину проекта и спокойно сказать «мы успели только это». Сколько бы ни обсуждался флекс перед началом проекта, любой клиент будет возмущён, если его просто поставят перед фактом, что чего‑то не будет.
Когда возникает угроза сроку, приходится принимать решение об упрощении дизайна или ограничении функциональности. Ведущий дизайнер предлагает решение, клиент принимает его или предлагает своё. Достижение договорённости о «флексе» — наша взаимная ответственность с клиентом.
Научиться работать по ФФФ
С 19 июня по 9 июля пройдёт трёхнедельный дистанционный курс «Управление проектами, людьми и собой» Николая Товеровского, запись открыта до 18 июня.
Курс будет полезен менеджерам, руководителям, стартаперам, дизайнерам, редакторам, разработчикам — и всем людям.
Если захотите поучаствовать, будем рады вас видеть:
Записаться на курс