Как запускать проекты вовремя

Принцип проектной работы Дизайн-бюро Артема Горбунова

  • 15596
Возможно, этот подход покажется вам неожиданным.

С ним не соглашаются многие веб-студии и клиенты. Мне было
непросто на него перестроиться. Он требует дисциплины и ответственности. Но одно ясно: с ним проекты открываются
вовремя. В Бюро Горбунова убеждены, что этот принцип применим к любой сфере жизни. Давайте проверим.

Проектная работа бюро

Дизайн-бюро Артема Горбунова создает сайты, фирменные стили, придумывает интерфейсы и навигацию в общественных
местах. Бюро запускает проекты вовремя, потому что следует принципу «ФФФ» — fix time, fix budget, flex scope. Чтобы
понять этот принцип, для сравнения разберем типичную схему работы российской веб-студии.

Типичная проектная работа

Первая встреча. Клиент обращается в веб-студию за обновлением сайта. Менеджер составляет
техзадание, календарный план и смету. Заключают договор: веб-студия обязуется создать сайт по ТЗ в указанный срок,
а клиент обязуется эти работы поэтапно оплатить.

Маляр

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

Внутренние страницы. Отставание на 7 дней. Студия отправляет клиенту макеты внутренних страниц,
но клиент в отпуске. Согласование затягивается на две недели. Пока макеты зависли у клиента, дизайнеры получают
другие задачи, а проект на паузе. Спустя три недели менеджер вспоминает о проекте и добивается согласований.

Программирование. Отставание на 28 дней. Макеты закончены, передаем их программистам.
Просим сделать быстрее, чтобы нагнать отставание. Но быстрее не получится: дизайнеры не предусмотрели миллион
нюансов, и на переделку нужно не две недели, а шесть. Менеджер подключает к проекту еще одного дизайнера
и разработчика, чтобы проект шел быстрее. Меж тем, клиент настойчиво интересуется, почему «съехали» сроки.

Кризис. Отставание на 56 дней. Менеджер в панике. К проекту подключается директор студии:
лично едет к заказчику и договаривается об увеличении сроков на два месяца. Клиент соглашается, но не готов
оплачивать дополнительное время. Студия работает бесплатно. + 60 дней в план

Последние доработки. Следующие месяцы студия работает через силу: дизайнеры загружены другими
проектами, у программистов каждый день всплывают новые ошибки, менеджер деморализован и, скорее всего, выпивает.
За неделю до пуска понятно, что сайт сырой: миллион ошибок, всё на «костылях», и клиенту он в целом не нравится.
«На картинках было совсем другое», — говорит, — «Так открывать нельзя».

Клиент присылает досудебную претензию: работы в срок не выполнены, платите штраф. Директор приглашает клиента в ресторан и договаривается об отсрочке.

Проекту добавляют неделю, под личную ответственность директора студии. Он мобилизует все ресурсы и ставит на паузу
остальные проекты. Неделя проходит в аду, потом незаметно вторая и третья.

Запуск. В конце четвертой недели, с трехмесячным отставанием от срока в договоре, хромой
и косой сайт открывают для публики.

Публика никак не реагирует: сайт посредственный.

Веб-студия в минусе: половину проекта сделала бесплатно и в процессе заморозила несколько текущих проектов.
В портфолио этот проект не пойдет, потому что стыдно за результат.

Клиент в обиде: студия его подвела. Пообещала открыть хороший сайт за три месяца, а открыла калеку через полгода.

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

Но это самообман. В следующий раз все будет так же. И вот почему.

План — это иллюзия

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

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

План становится предметом переговоров. «Нет, делать сайт 4 месяца — это слишком долго. Сделайте
за три, и проект ваш». Клиент запросто продавит менеджера по срокам, потому что рисовать план несложно. «Потом
разберемся», — думает менеджер, — «Главное — продать проект».

Исполнители не любят план. «Вы там напланировали себе две недели, но быстрее, чем за месяц
мы это не запрограммируем. Меняйте свои планы, значит. Или переделывайте дизайн». Всплывет это в середине проекта.

К концу проекта всем плевать на план. Клиенту уже не так важно уложиться в сроки, как сделать
хороший продукт: «Мы с вами и так потратили два месяца. Давайте потратим еще два, но зато не будет стыдно».

Исполнителям план изначально не важен, потому что они работают на зарплате. Утром пришли — поработали — поздно ночью
ушли. Сроки — это вопрос менеджера.

Менеджер перестает смотреть в план где-то в середине проекта, потому что план уже давно не соответствует
действительности, а времени его обновлять нет.

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

Это не значит, что не нужно готовиться к проекту (сориентируемся, мол, на месте). Наоборот. Зная, что все пойдет
не по плану, нужно готовиться вдвое тщательнее: предусматривать трудности, проводить разведку и тестировать
подрядчиков. Хороший менеджер готов к тому, что его план улетит в мусорное ведро через две недели, но ресурсов и сил
хватит до запуска, причем с запасом.

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

Короткие итерации

Типичный сайт — задача месяца на три. За это время делается главная страница, внутренние, каталог, обратная связь.
Чтобы соблюсти технологию, сначала дизайнеры рисуют картинки, а потом программисты превращают картинки в живой сайт.
Далее — тесты и запуск:

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

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

Здесь меньше макетов, согласований, разработки и тестирования. Даже если что-то «съедет» по срокам, нам легче
это контролировать. В итоге мы быстрее запустим продукт, клиент начнет продавать, а мы поймем, работает ли вообще
идея с каталогом.

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

Мы все равно составляем план, но теперь это не многомесячный монстр, а короткие управляемые итерации. Мы меньше
рискуем и быстрее выводим продукт на рынок. В короткой итерации меньше гибкости и легче зафиксировать время
и деньги.

Фиксированное время и деньги

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

Время фиксируется по двум причинам: философской и чисто прагматической.

Философское объяснение в том, что время человеческой жизни — ограниченный и невосполнимый ресурс. Каждый проживет
ровно столько, сколько ему отмерено, и разбрасываться временем на плохое управление — слишком жирно. Всем хочется
сделать больше.

ВРЕМЯ — ОГРАНИЧЕННЫЙ И НЕВОСПОЛНИМЫЙ РЕСУРС. ВСЕМ ХОЧЕТСЯ СДЕЛАТЬ БОЛЬШЕ

Прагматическая причина в том, что незапущенный проект — это потерянные деньги клиента. Когда в проект начинают
добавлять время, появляется соблазн заодно добавить и функций. Проект заболевает «фичеризмом». Клиент требует
добавить в каталог интеллектуальный поиск, но это отодвигает старт еще на две недели. Эти две недели сайт мог бы
работать и продавать.

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

Любые решения по проекту принимаются исходя из того, что у нас нет дополнительных денег и времени. Что остается?

Гибкая функциональность

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

Запланировали, что у каждого раздела в каталоге будет индивидуальный дизайн. Понимаем, что
индивидуальный не успеем. Советуемся с клиентом: как мы навредим проекту, если все разделы будут одинаковые?
Оказывается, особенно не навредим. С согласия клиента «отрезаем» эту функциональность и запускаемся в срок. В бюро
это называется «пофлексить», от flex scope, «сделать охват проекта гибким».

Пишу рассылку о технологии
переговоров Джима Кемпа
. Понимаю, что текст сдавать через два часа, а я охватил только половину книги. Ничего
страшного. Говорю, что в следующем выпуске мы продолжим разбирать эту технологию, и через неделю дописываю все
остальное. Со стороны кажется, что я сделал серию рассылок, на самом деле — просто «пофлексил» половину.

В бюро открыли «Коворкафе» — это кафе, коворкинг, офис бюро, место
встречи с клиентами и зал для проведения курсов. Когда его открыли, это были голые стены, столы, стулья, интернет,
розетки и электрочайник. Было пустовато, но этого хватало, чтобы проводить курсы и работать. Это была первая
итерация.

За два года в «Коворкафе» появилась вывеска, декор, маркиза, цветы; хозяин-«бюриста»,
который заботится о гостях; кофемашина, меню с закусками и десертами; абонементы, библиотека, пуфики и музыка. Новые
функции добавлялись постепенно, и все это время «Коворкафе» приносило пользу.

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

Как «флексят»

В бюро формализованы способы «отрезания» функций:

Заменить часть системы, решив задачу. Вместо формы обратной связи указать эл. адрес для писем. Вместо кнопки «Оформить заказ» — телефон отдела продаж.

Зафиксировать. Сделать часть системы статичной. Не программировать блок «самые популярные товары», а поставить в него товары вручную.

Перенести на следующую итерацию. Если совсем не успеваем — анонсируем функцию и пишем «откроется скоро».

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

Всего в бюро применяется десять способов «флексить». Они подробно описаны в курсе «Управление
проектами, людьми и собой»
; кое-что можно подсмотреть в раздаточных материалах.

Кажется, что гибкая функциональность несовместима с проектной работой. Клиент заказал сайт из 10 страниц, а бюро
предлагает ему открыться с тремя. Для многих клиентов это выглядит как попытка сделать меньше за те же деньги, и они
не соглашаются так работать. Это нормально. Не каждая компания станет клиентом бюро. Часто такие компании все еще
верят, что уж в следующий-то раз они точно найдут себе нормальных подрядчиков.

Жизненный принцип

«ФФФ» изначально сформулирован для разработчиков программ, сервисов и приложений. В Бюро Горбунова этот принцип адаптировали для дизайна. Однако в бюро уверены, что он применим к чему угодно. «ФФФ» — это больше жизненный принцип, чем технология управления проектами.

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

«ФФФ» заставляет команду проекта больше думать о цели, а не упираться в конкретные дела и задачи.

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

К открытию гостиницы не готов ресторан. Придется придумать, как кормить гостей: доставлять
еду в номер, накрыть столы в шатре на природе, договориться с соседними ресторанами.

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

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

Система

Подход «ФФФ» трудно применять в отрыве от других принципов бюро:

Техника
переговоров
 Джима
Кемпа
 помогает дизайнерам договариваться с клиентом и принимать взвешенные решения. У бюро не бывает «адовых клиентов», потому что любая просьба, даже самая «адовая», рассматривается с точки зрения пользы для проекта и в мире клиента.

Система удаленной работы «Ресурс» помогает встречаться с клиентами по скайпу, даже когда клиент
или дизайнер в отъезде. В бюро создана технология презентации макетов, внедрены правила их показа и хранения,
продуман процесс обсуждения и согласования замечаний.

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

Принцип
«сделывания»
 (18+) подразумевает, что задача не сделана, пока она не согласована у непосредственного заказчика — арт-директора или клиента. Мало нарисовать макет — нужно его согласовать, доработать и «сдать», чтобы заказчик принял работу. Ответственность по сдаче работы лежит на исполнителе. Исполнитель сам планирует свое время, чтобы успеть и сделать, и сдать.

Принцип «горы знаний» служит фильтром людей. Чтобы работать в бюро, дизайнер проходит ступени
профессионального роста, осваивает верстку, работу с клиентом, управление временем и проектами, дизайн интерфейса,
текст, юридическую сторону дизайна. Бюрошники, которые стоят на более высокой ступени иерархии, управляют и обучают
младших. Каждая ступень — это пот, кровь и бессонные ночи. До управления проектами доходят только стальные.

Школа стажеров бюро

Миссия бюро — распространение дизайнерских знаний.

Чтобы эти знания накопить, бюро делает проекты. Чтобы распространить — проводит курсы и дает советы. В 2014 году
в бюро открылась «Школа стажеров» —
школа дизайна, которая ставит на поток подготовку дизайнеров в системе знаний бюро. В школе дизайнер обучается
не только типографике, верстке и интерфейсу, но и переговорам, тексту, юридической стороне дизайна и управлению
проектами. Принципу «ФФФ» в школе посвящена отдельная дисциплина.

Автор — Максим Ильяхов.

comments powered by HyperComments
игорь
2014-06-13 22:18:21
молодец Максим.........хорошие статьи
Антон
2014-06-16 18:11:02
У меня статья вызвала очень двойственные чувства. История с отставанием - она какая-то совсем детская. Сейчас делаю свой веб-проект, выбираю Веб-студию, с которой буду работать. Ни ОДНА студия не пропускает стадии согласования макетов. ВСЕ студии требуют от меня (клиента) определенное время ответа, иначе не гарантируют никакие сроки. Более того, на согласование закладывается минимум столько же времени, сколько на первоначальную версию, а то и больше. Да и клиент в этой истории вел себя совсем как новичок. Он заключил договор - и все, ожидает что через несколько месяцев будет готов сайт под ключ, без активного участия с его стороны? Я вижу проблему в первоначальной истории, что ни клиент, ни студия, не понимали как делаются сайты, и при планировании пропустили очень большой и важный кусок работы. Что же предлагается в статье? Мне показалось, что предложенный принцип "ФФФ" он как-то совсем не про детские ошибки в планировании. То есть решение не подходит к описанной проблеме. Сам принцип "ФФФ" мне показался, мягко говоря, странным. Вместо того, чтобы каждый раз творчески решать управленческую задачу по тому, как уложиться в треугольник "сроки-деньги-функциональность", предлагается жесткое и универсальное решение - резать функциональность. Я могу найти много примеров, где меня как клиента этот подход никак не устроит. Где-то я скорее буду готов заплатить больше денег, чтобы часть работы отдать фрилансеру, где-то я буду готов отложить старт проекта ради большей функциональности. Важно то, что это мое решение, только у меня полная картинка проекта. Это же ужас, если студия за меня решает, что мне важнее всего соблюсти сроки, и тем более если она не ставя меня в известность, выбрасывает часть функциональности. Отдельно хочется написать про итеративную разработку. Когда проект вместо одного этапа бьется на несколько (в дополнительные этапы выносится отрезанная функциональность), то это просто дороже. Иногда даже в разы (обновление живого сайта, переделывание уже работающего кода/дизайна, конвертация данных). И клиенту предлагается за все это платить, не давая ему выбор: дешевле но позже, или дороже, но часть сейчас? Вообщем, успехов описанной студии. Есть много проектов и клиентов, где их подход будет работать, только не надо его продвигать как универсальное решение проблем со сроками и бюджетами проектов.
Виктория
2014-06-17 12:15:05
А мне интересно чем вызвано решение изменить название данной статьи в рассылке? (или это просто "ляп" или "косяк" технаря. Там, в рассылке, статья называется "Как заканчивать проекты вовремя" :-) И название статьи из рассылки более точное :-) Я далека от перфекционизма. Да, вот подтверждение http://us2.campaign-archive1.com/?u=833bf5395122c8de57f99f863&id=9a87f63d69
Elvin
2014-06-30 13:29:32
В принципе здесь описаны некоторые фрагменты управление проектами по методу Agile/Scrum. Было бы правильно дать на них ссылку так как я не думаю что автор изобретал эти методы сам с нуля.
Людмила Сарычева
2014-07-06 23:19:47
Виктория, здорово, что вы такая внимательная (-: Мы всегда используем в рассылке два варианта названия, тестируем на популярность.
Данила
2014-07-14 10:12:27
Хотелось бы подробнее про флексинг. Как на практике он согласовывается? Клиенту делается КП с какой-то первоначальной примерной оценкой, общим наброском функциональностей (перечнем моделей или чем-то ещё чтобы было понятно что оценивается) и предварительным планом (не графиком, а просто сроки, допустим, будет готово через 3-4 месяца)? А дальше что? Идёт какой-то этап проектирования, на котором создаётся ТЗ? По его итогам составляется точная смета и график? И что? Как тут клиенту доносится идея того, что если не будете успевать, то будете резать функциональность? Чем аргументируется?
Анастасия
2014-09-07 20:03:13
Антон, показалось, что статья рассчитана на менеджеров веб-студий. Возможно, поэтому не все мысли прозрачны для клиентской стороны. "Это же ужас, если студия за меня решает, что мне важнее всего соблюсти сроки, и тем более если она не ставя меня в известность, выбрасывает часть функциональности." В принципе ФФФ студия помогает клиенту получить деньги с сайта, как можно быстрее. Если возможно получить прибыль с сайта без менее приоритетного функционала и ущерба для репутации (ведь качество лайт-версии на высоте), какие у вас есть причины не согласиться? Сокращение функционала проводиться только обоюдно с клиентом. Антон, поделитесь, пожалуйста опытом разработки сайта не по ФФФ. Насколько вы довольны работой по вашему сайту? Как отличается срок запуска от запланированного?
Анастасия
2014-09-07 20:31:50
Данил, главное: вместо идеи того, что если не будем успевать, то будем резать функциональность доносится идея, что можно зарабатывать сайтом уже с минимальным функционалом. Цель в мире клиента. Аминь. Я пока не сотрудничаю с Бюро Горбунова, поэтому не могу говорить за них. Но может и мой опыт вам пригодится. Клиент получает понедельный план работ. Работы предварительно расставлены по приоритету. С моей стороны флекса не бывало, я знаю объем, который выполню за неделю. В этом помогает опыт + профилактика внешних воздействий на проект. Например, ожидания чуть занижены, всех причастных к принятию решения собрала, устав (цели проекта, приоритеты задач, форма согласования, форма изменения состава участников ) клиент может повторить разбуженный и в три часа ночи. То что помехи - это норма и они возникнут все равно клиент усвоил и согласился 3 раза:), поэтому как план "Б" держим возможность сократить функционал ради запуска (читай прибили) в срок без вреда для качества (читай репутации). Что еще могу пояснить об управлении проектом по ффф?
1
2014-12-14 15:05:48
когда в бюро пирогова будут писать свои идет, а не вольно переводить западные статьи? имейте совесть переводя, указывать ссылки на источник, например http://gettingreal.37signals.com/ch02_Fix_Time_and_Budget_Flex_Scope.php
altrueast
2014-12-17 13:00:13
"Каждая ступень — это пот, кровь и бессонные ночи." - считаю это не правильным. Особенно бессонные ночи. Временем управлять необходимо так, чтобы делать работу исключительно в рабочее время.
Андрей
2015-02-01 02:00:13
Очень странный подход! Приходит клиент и говорит: "Мне нужен сайт такой-то и такой-то". Описывает функционал (достаточно сложный, над которым работать не один месяц, не говоря уже о дизайне). Клиент хочет знать, сколько ему будет стоить такой сайт и в какие сроки его сделают. Насколько я понял, вы бьёте весь проект на мелкие этапы. Вы по каждому этапу заключаете договор и описываете смету? Второй вопрос: я так понял, что сроки и цена не изменяются. Просто вы за оговоренные деньги, в оговоренные сроки делаете не тот сайт, который нужен клиенту, а что-то меньшее. А клиент ЗАРАНЕЕ предупреждён, что он может не получить нужный ему сайт? Как это в договоре оговорено? Ведь ТЗ является неотъемлемой частью договора. Т.е. это описание товара, за который клиент платит оговоренные деньги. И вы можете так просто взять и за эти деньги дать ему другой товар, хуже функционалом? Чем это не обман? Я понимаю, что вы оговариваете. Но оговариваете вы это уже в процессе работы, т.е. ставите клиента перед фактом. Дескать, мы не успеваем, поэтому не будем делать что-то. В общем, резюмирую - есть 3 фактора: цена, время и товар. Очень трудно сделать так, чтобы все 3 были соблюдены. Обычно жертвуют временем. Вы решили жертвовать товаром. Не думаю, что это лучший вариант!
Иннокентинй
2015-03-28 13:16:29
Кривой сайт потер комментарий, который я писал около шести минут. Выдал ошибку при публикации, а текст не сохранил. Обижен на вас.
Дмитрий
2015-03-28 13:19:16
Присоединяюсь к вопросам: 1) Как удается согласовать с клиентом, что за те же самые деньги он получает меньше функционала, чем было договорено при старте? 2) Как удается согласовать с клиентом дополнительную оплату функционала второго релиза, который уже был заложен в первую смету, но зафлексился в процессе.
IVAN
2015-04-25 10:41:33
Заказал сайт три года назад. До сих пор жду...
Как начинать автоматизацию предприятия - Автоматизация предприятий 1C:УПП, 1С:ERP
2015-12-12 00:06:49
[…] я бы порекомендовал вам ознакомиться со статьёй «Как запускать проекты вовремя». […]