Принцип управления проектами

19 августа 2015 · Даниил Соколовский

Управление Веб-разработка

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

Типичный проект

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

Затем менеджер превращает план в подробное техническое задание, на основе технического задания дизайнер рисует макеты дизайна, а из макетов программист собирает рабочий сайт. Этапы дизайна и программирования объединим в одно слово «разработка».

Получается такой план:

Ожидания: план запуска типичного проекта

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

Идеальный план

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

С поправкой на действительность план уже выглядит так:

Реальность: проект запускается на два месяца позже

В итоге команда студии вынуждена работать в авральном режиме, потому что планировала запустить сайт еще месяц назад. Клиент недоволен, потому что теряет деньги — считает, что студия его подвела. Сайт запускается через два месяца с ошибками и косяками. Участники проекта деморализованы, деньги потрачены, репутация испорчена.

План — это идеальный сценарий, который никогда не случится

Закон о потерях

Факт: невозможно запустить проект в оговоренные срок, бюджет и функциональность со 100% качеством. Чтобы сделать качественный продукт, нужно чем-то пожертвовать. Рассмотрим возможные варианты.

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

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

Фичеризм. Запуск даже не виден на горизонте

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

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

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

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

Время —  самый ценный и невосполнимый ресурс во вселенной

ФФФ

Впервые я узнал об этом методе из книги Getting Real. На английском он звучит «fix time, fix bugdet, flex scope», что можно перевести как «фиксированное время, фиксированный бюджет, гибкий функционал». Для удобства мы называем это короткой аббревиатурой ФФФ.

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

Если во время работы станет ясно, что какие-то функции не успеваем сделать к запуску, оставляем их за рамками проекта и при необходимости добавляем в будущем — это процесс мы называем «пофлексить», то есть принять решение о гибкости.

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

Польза

Принимая решение о флексе, мы думаем о полезном действии. Полезное действие — смысл функции, ради чего она существует.

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

Пример флекса: форма заменяется на почту и телефон

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

Понятие пользы тесно связано с миссией, описанной в книге Джима Кэмпа, о которой я напишу отдельный пост.

Метод нацелен на результат: запуск качественного работоспособного продукта

Запуск по этапам

Долгосрочное планирование — не более чем догадки. Это одна из причин, почему при типичном управлении проектом план остаётся идеальным только на бумаге. В жизни длинные проекты не идут по плану: сначала дата запуска кажется далекой и всё идет гладко, а потом внезапно наступает аврал.

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

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

Вместо длительной разработки с непредсказуемым результатом:

Пример разработки сайта со всеми функциями сразу

Получаем прогнозируемый результат и понятную пользу:

Пример поэтапного запуска: каждая отдельная функция начинает раньше приносить пользу

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

Голос скептика: «Но разве можно открыть сайт без половины задуманных функций? У сайтов конкурентов вон сколько всего!».

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

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

Взаимная ответственность

Метод, по которому мы работаем, требует смелости и постоянного принятия решений. Решение о флексе, то есть упрощении дизайна или отказе от какой-то функции, принимается на основе взвешенного, обоюдного согласия. Проект — это взаимная ответственность студии и клиента.

Не для всех

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

Читайте также

Как создавать и запускать успешные проекты

Как создавать и запускать успешные проекты

Избранные цитаты из книги «Getting Real».

22 июля 2015
Типографика и верстка книг. Часть 2

Типографика и верстка книг. Часть 2

В первой части этой статьи собраны рекомендации и способы вычисления расположения полосы набора и каноны строения титульного листа. Рекомендую прочитать, если еще не успели.
В продолжении моего конспекта «Облика книги» Яна Чихольда мы углубимся в правила набора и форматирования текста и в верстку иллюстраций. Будет познавательно и интересно :-)

26 февраля 2016
Обновление сайта daniellesden.com

Обновление сайта daniellesden.com

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

23 июня 2016