Как мы ведем проекты

Есть два метода разработки

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

Популярна из-за предсказуемости. Стоимость и список работ обозначается до начала проекта, а потом проект разбивается на этапы. Клиент с самого начала в курсе, какую делают работу на каком этапе.

Гибкая. Адаптируемый подход в разработке за счет меняющихся внешних условий. Еще называется Аджайлом [Agile].

Если надо пять страниц, то берем фиксированную цену и умножаем на пять, добавляем время на правки и контроль качества. Это и будет цена за дизайн.

Если надо пять страниц, то берем фиксированную цену и умножаем на пять, добавляем время на правки и контроль качества. Это и будет цена за дизайн.

Суть

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

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

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

Оценка проекта

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

Например. У нас есть фиксированная цена за одну страницу для оценки дизайна, поэтому стоимость дизайна проекта зависит от количества страниц, которые нужно сделать. Если надо пять страниц, то берем фиксированную цену и умножаем на пять, добавляем время на правки и контроль качества. Это и будет цена за дизайн.

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

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

В начале описываем функционал и разбираемся в цели проекта, уточняем технические нюансы задач и отдаем разработчикам, чтобы оценил сроки на реализацию. Потом распределяем по шагам: составляем таблицу задач с оценкой по времени и приоритетом, формируем график. Это называется Бэклог [список задач]. Если в начале договорились что один шаг 80 часов, то нужно насобирать задач на 65 часов в сумме. Почему не 80? Потому что надо закладывать риски, чтобы соблюдать сроки. Пока задачи этого шага в работе, менеджер планирует новые и готовит их к размещению в бэклоге.

Оплата может быть почасовой или фиксированной, по оценке проекта. По почасовой оплате клиент платит за часы, которые были затрачена на решение задачи.

О сроках работы и этапах

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

План работы и техническое задание расписано в смете. Если сроки переносятся, то обсуждаем на уровне переписки в таск-трекере [сервис для отслеживания и обсуждения задач]. Клиент всегда в курсе, какой этап работы идет и когда покажут результат.

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

О правках

Последовательная. Список работ и бюджет на каждую позицию описаны в договоре и отступить от него нельзя. Поэтому объём правок закладывается в стоимость работы. У нас это 30% от всего проекта.

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

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

Например. Сделали регистрацию через имя и пароль. Клиент попробовал пару раз зарегистрироваться и ему не понравилось, слишком долго и сложно. Он решил сделать авторизацию через социальные сети, например Фейсбук. Правку добавляет в список задач: сделать авторизацию через Фейсбук. И эта задача будет решаться на следующем шаге.

О рисках

Последовательная. По рискам на правки писали выше, это 30% от объёма работ. А на риски по срокам мы закладываем 50-100% времени. Это сроки на приемку, утверждение и внесение правок. Но даже такие сроки не всегда спасают. До старта работ не понятно, понравится ли первый дизайн клиенту или будут правки, сколько их будет. Клиент может неделю обсуждать цвет кнопок или уехать в отпуск.

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

О контроле качества работ

Последовательная. Арт-директор контролирует качество работы и задаёт уровень дизайна в компании. Этот уровень можно увидеть в портфолио.

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

Гибкая. Он такой же, как и при последовательной разработке.

Когда подписываем договор и начинаем работу

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

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

Гибкая. Если оплата по факту сделанных задач, то старт проекта/задач упирается в занятость специалистов.

В итоге

Последовательная. Клиент получает фиксированный бюджет и фиксированные сроки.

Гибкая. Клиент оплачивает процесс достижения своих целей, а не конечный продукт. Платит за конкретные задачи.

Кому подойдет

Последовательная. Разработка сайт-визитки, корпоративного сайта, интернет-магазина. У таких проектов функционал похож на 90%, они типовые. Опираясь на опыт, мы можем сказать сроки и стоимость.

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

Гибкая. Крупным проектам, стартапам, онлайн-сервисам.