Дмитрий Устинов
1 мая 2014

Николай!

Как в ФФФ можно снизить стоимость проекта, если, к примеру, клиент ограничен в бюджете, есть понимание задачи и функционала, который обязательно должен присутствовать в первой версии, но сокращение календарного плана может привести к тому, что придётся урезать и так минимальный набор функций?

Допустимо ли передавать работу, предположим, по программированию, субподрядчикам, если это может снизить стоимость, при этом не вредя качеству? Как правильно контролировать процесс разработки у субподрядчиков (с точки зрения воплощения всех задумок дизайнеров и проектировщиков)?



Дмитрий!

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

Меня зацепила фраза о функциональности, которая обязательно должна присутствовать в первой версии. При таком условии ФФФ не сработает. Если есть функции, которые нельзя «пофлексить» (упростить, видоизменить, отказаться), в случае проблем придётся добавлять время или бюджет, чтобы их доделать.

В основе ФФФ-проекта всегда лежит полезное действие, а функции, которые реализуют это полезное действие, бесконечно разнообразны.

Я хочу пересказать историю разработки второй версии сайта компании «Регуляр», которой поделился со мной Илья Бирман.

Регуляр помогает своим клиентам анализировать состав и измерять влажность газов в их промышленных процессах. В новой версии клиент хотел поставить обработку заказов на поток.

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

Казалось логичным сдвинуть пуск на неделю. Эту неделю бюро было готово оплатить из собственного кармана.

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

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

Такой умный «флекс» ребята придумали благодаря чётко сформулированному полезному действию и пониманию задачи клиента.

Совет о полезном действии для понимания задачи
P. S.
Это был совет об управлении проектами, людьми и собой. Присылайте вопросы.
P. P. S.

Я проведу практический курс «Управление проектами, людьми и собой» 10, 11 и 12 июня в Москве

 

Запись открыта до ВС 4 июня


Поделиться

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

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




Недавно всплыло

7 Расскажите об управляемости: программа 2 Кто ты? 1 4