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