План — это иллюзия
Проект — это путешествие из точки «А» («Нет сайта») в воображаемую точку «Б» («Начались продажи с сайта»). На пути заказчик и исполнитель столкнутся с сопротивлением окружающей среды: дизайнер заболеет, юристы запретят новый слоган, программисты потребуют больше денег, обрушится база данных, изменится рынок. Что-то всегда происходит. Наивно думать, что проект пойдет по плану.
План всегда описывает идеальную ситуацию. Никто в здравом уме не напишет в плане «А вот здесь у нас заболеет дизайнер», «А тут вы захотите все переделать». Менеджер приносит клиенту сказочный план, в котором все соблюдают сроки, а макеты согласовываются с первого раза. И этот заведомо сказочный план попадает в договор и смету.
План становится предметом переговоров. «Нет, делать сайт 4 месяца — это слишком долго. Сделайте за три, и проект ваш». Клиент запросто продавит менеджера по срокам, потому что рисовать план несложно. «Потом разберемся», — думает менеджер, — «Главное — продать проект».
Исполнители не любят план. «Вы там напланировали себе две недели, но быстрее, чем за месяц мы это не запрограммируем. Меняйте свои планы, значит. Или переделывайте дизайн». Всплывет это в середине проекта.
К концу проекта всем плевать на план. Клиенту уже не так важно уложиться в сроки, как сделать хороший продукт: «Мы с вами и так потратили два месяца. Давайте потратим еще два, но зато не будет стыдно».
Исполнителям план изначально не важен, потому что они работают на зарплате. Утром пришли — поработали — поздно ночью ушли. Сроки — это вопрос менеджера.
Менеджер перестает смотреть в план где-то в середине проекта, потому что план уже давно не соответствует действительности, а времени его обновлять нет.
Переживает только директор: фирма получила деньги за три месяца работы, а работает уже пять, и конца не видно.
Это не значит, что не нужно готовиться к проекту (сориентируемся, мол, на месте). Наоборот. Зная, что все пойдет не по плану, нужно готовиться вдвое тщательнее: предусматривать трудности, проводить разведку и тестировать подрядчиков. Хороший менеджер готов к тому, что его план улетит в мусорное ведро через две недели, но ресурсов и сил хватит до запуска, причем с запасом.
Без плана нельзя: студии нужно резервировать команду, строить финмодель, считать смету, заполнять кассовый разрыв, брать новые проекты. Но и по плану нельзя: всегда все идет не так. Чтобы разрешить противоречие, в бюро особый подход к планированию.
Короткие итерации
Типичный сайт — задача месяца на три. За это время делается главная страница, внутренние, каталог, обратная связь. Чтобы соблюсти технологию, сначала дизайнеры рисуют картинки, а потом программисты превращают картинки в живой сайт. Далее — тесты и запуск:
В реальности оказывается, что и дизайн, и программирование занимают больше времени, чем планировалось. А клиент, к тому же, еще и не хочет принимать работу с первого раза. И сначала опаздывают дизайнеры, потом тормозит клиент, потом программисты, и, наконец, все разом:
А что если не делать сайт целиком, а открыть только каталог? Информацию о компании поставить в «подвал», главную страницу пока скрыть и запустить сайт с одним каталогом. Как тогда будет выглядеть план проекта? Не забудем, что дизайн нужно еще и согласовать:
Здесь меньше макетов, согласований, разработки и тестирования. Даже если что-то «съедет» по срокам, нам легче это контролировать. В итоге мы быстрее запустим продукт, клиент начнет продавать, а мы поймем, работает ли вообще идея с каталогом.
Если работает, мы запланируем вторую короткую итерацию для главной страницы. Пока мы будем ее делать, клиент будет зарабатывать на запущенном каталоге, а мы получим обратную связь от пользователей.
Мы все равно составляем план, но теперь это не многомесячный монстр, а короткие управляемые итерации. Мы меньше рискуем и быстрее выводим продукт на рынок. В короткой итерации меньше гибкости и легче зафиксировать время и деньги.
Фиксированное время и деньги
В бюро принят диктат дедлайна: дата запуска никогда не сдвигается. Это осознанный принцип, которому следуют бюрошники и с которым должен согласиться клиент. Никто в бюро не рассматривает вариант сдвинуть дату запуска, чтобы «допилить» проект. Этого варианта не существует. Все решения по проекту принимаются исходя из того, что дата запуска не сдвигается.
Время фиксируется по двум причинам: философской и чисто прагматической.
Философское объяснение в том, что время человеческой жизни — ограниченный и невосполнимый ресурс. Каждый проживет ровно столько, сколько ему отмерено, и разбрасываться временем на плохое управление — слишком жирно. Всем хочется сделать больше.
ВРЕМЯ — ОГРАНИЧЕННЫЙ И НЕВОСПОЛНИМЫЙ РЕСУРС. ВСЕМ ХОЧЕТСЯ СДЕЛАТЬ БОЛЬШЕ
Прагматическая причина в том, что незапущенный проект — это потерянные деньги клиента. Когда в проект начинают добавлять время, появляется соблазн заодно добавить и функций. Проект заболевает «фичеризмом». Клиент требует добавить в каталог интеллектуальный поиск, но это отодвигает старт еще на две недели. Эти две недели сайт мог бы работать и продавать.
Где время — там и деньги. Нельзя бросать в проект новых людей на «затыкание дыр»: вы тратите в первую очередь их время. Нельзя из-за аврала бросать в проект новые деньги — это незапланированные траты, которые могут поставить под угрозу коммерческую целесообразность всего проекта.
Любые решения по проекту принимаются исходя из того, что у нас нет дополнительных денег и времени. Что остается?
Гибкая функциональность
А вот с функциональностью все куда интереснее. Секрет бюро в том, что частью функций нового продукта можно жертвовать, чтобы открыть продукт высокого качества и вовремя.
Запланировали, что у каждого раздела в каталоге будет индивидуальный дизайн. Понимаем, что индивидуальный не успеем. Советуемся с клиентом: как мы навредим проекту, если все разделы будут одинаковые? Оказывается, особенно не навредим. С согласия клиента «отрезаем» эту функциональность и запускаемся в срок. В бюро это называется «пофлексить», от flex scope, «сделать охват проекта гибким».
Например, я пишу рассылку о технологии переговоров Джима Кемпа. Понимаю, что текст сдавать через два часа, а я охватил только половину книги. Ничего страшного. Говорю, что в следующем выпуске мы продолжим разбирать эту технологию, и через неделю дописываю все остальное. Со стороны кажется, что я сделал серию рассылок, на самом деле — просто «пофлексил» половину.
Или такой пример: открыли «Коворкафе» — это кафе, коворкинг, офис, бюро, место встречи с клиентами и зал для проведения курсов. Когда его открыли, это были голые стены, столы, стулья, интернет, розетки и электрочайник. Было пустовато, но этого хватало, чтобы проводить курсы и работать. Это была первая итерация.
За два года в «Коворкафе» появилась вывеска, декор, маркиза, цветы; хозяин-«бюриста», который заботится о гостях; кофемашина, меню с закусками и десертами; абонементы, библиотека, пуфики и музыка. Новые функции добавлялись постепенно, и все это время «Коворкафе» приносило пользу.
Отрезанную функциональность можно вынести в следующий этап проекта, а из ее запуска сделать инфоповод. Так как пользователь не знал, что мы изначально планировали эту функцию, для него это будет выглядеть как забота, а не запоздалые доделки проекта.
Как «флексят»
В бюро формализованы способы «отрезания» функций:
Заменить часть системы, решив задачу. Вместо формы обратной связи указать эл. адрес для писем. Вместо кнопки «Оформить заказ» — телефон отдела продаж.
Зафиксировать. Сделать часть системы статичной. Не программировать блок «самые популярные товары», а поставить в него товары вручную.
Перенести на следующую итерацию. Если совсем не успеваем — анонсируем функцию и пишем «откроется скоро».
Запрещено: закрывать глаза на недостатки. При любых обстоятельствах нельзя жертвовать качеством. Простое решение не значит плохое, а отсутствующая функция лучше, чем сломанная.
Кажется, что гибкая функциональность несовместима с проектной работой. Клиент заказал сайт из 10 страниц, а бюро предлагает ему открыться с тремя. Для многих клиентов это выглядит как попытка сделать меньше за те же деньги, и они не соглашаются так работать. Это нормально. Не каждая компания станет клиентом бюро. Часто такие компании все еще верят, что уж в следующий-то раз они точно найдут себе нормальных подрядчиков.
Жизненный принцип
«ФФФ» изначально сформулирован для разработчиков программ, сервисов и приложений. В Бюро Горбунова этот принцип адаптировали для дизайна. Однако в бюро уверены, что он применим к чему угодно. «ФФФ» — это больше жизненный принцип, чем технология управления проектами.
Работать по нему невозможно, если вы не умеете договариваться. Клиент должен согласиться «пофлексить» функцию ради запуска в срок. В идеале — самостоятельно предложить, что и как «пофлексить». В бюро запрещен «скрытый флекс» — когда исполнитель отрезает функцию в одностороннем порядке, не договариваясь с клиентом.
«ФФФ» заставляет команду проекта больше думать о цели, а не упираться в конкретные дела и задачи.
Нет времени открыть сайт из десяти страниц. Придется подумать, как добиться цели одной страницей.
К открытию гостиницы не готов ресторан. Придется придумать, как кормить гостей: доставлять еду в номер, накрыть столы в шатре на природе, договориться с соседними ресторанами.
Для квартального отчета не хватает подробной статистики продаж от отделов. Договариваемся, что сейчас они пришлют общие цифры, а конкретную статистику внесут в отчет позже и самостоятельно.
Семья планировала поехать в субботу в торговый центр, но у папы на работе завал. Вместо поездки заказывают товары из интернета.
Система
Подход «ФФФ» трудно применять в отрыве от других принципов:
Техника переговоров Джима Кемпа помогает дизайнерам договариваться с клиентом и принимать взвешенные решения. У бюро не бывает «адовых клиентов», потому что любая просьба, даже самая «адовая», рассматривается с точки зрения пользы для проекта и в мире клиента.
Система удаленной работы «Ресурс» помогает встречаться с клиентами по скайпу, даже когда клиент или дизайнер в отъезде. В бюро создана технология презентации макетов, внедрены правила их показа и хранения, продуман процесс обсуждения и согласования замечаний.
Метод прогрессивного джипега помогает дизайнерам уже в первый день работы иметь представление о результате. С каждым днем это представление уточняется. Если дизайнер заболел, у него все равно есть полное решение задачи, пусть и проработанное не до конца. С некоторыми оговорками его можно показать клиенту.
Принцип «сделывания» (18+) подразумевает, что задача не сделана, пока она не согласована у непосредственного заказчика — арт-директора или клиента. Мало нарисовать макет — нужно его согласовать, доработать и «сдать», чтобы заказчик принял работу. Ответственность по сдаче работы лежит на исполнителе. Исполнитель сам планирует свое время, чтобы успеть и сделать, и сдать.
Принцип «горы знаний» служит фильтром людей. Чтобы работать в бюро, дизайнер проходит ступени профессионального роста, осваивает верстку, работу с клиентом, управление временем и проектами, дизайн интерфейса, текст, юридическую сторону дизайна. Бюрошники, которые стоят на более высокой ступени иерархии, управляют и обучают младших. Каждая ступень — это пот, кровь и бессонные ночи. До управления проектами доходят только стальные.
Взято с сайта: thebigplans.ru
