Итерационная разработка. Показ сырого проекта в лучшем виде

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

Проблема

Где-то около месяца назад один из текущих веб-проектов как раз ушел в staging (рабочую версию для клиента). Параллельно идет плотная работа над функциональностью. И в общих сжатых сроках верстка разваливается гораздо быстрее, чем ее успевают причесывать. Кроме того, часть модулей еще даже не начиналась делаться, а без них общая картинка не складывается.

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

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

Решение

На общем брейншторминге определились приоритеты и ответственные за эти задачи. Тим лидер команды разработки курировал первый процесс. Шеф нашего минского офиса, где ведется разработка, взял на себя оперативное руководство вторым пунктом (он, кстати, отлично написал об этом процессе, да и за фразу о разобранном мопеде ему спасибо). А я должен был решить, что делать с последним вопросом.

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

Использование блоков-заменителе в рабочей версии сайта

Идея пришла из образа новых ценных бумаг. Перед выпуском в обращение в прессе часто печатают их внешний вид с жирной надписью “образец”. Аналогичный ход подойдет и для еще нереализованных функций. Делаем скриншот прототипа, переводим его в черно-белый вид и пишем большими красными буквами “В разработке”. И вставляем в те места страниц, где они должны находиться в финальной версии. Можно, конечно, просто вставить на эти места статический HTML-код. Но тогда никто будет точно знать, что работает, а что нет.

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