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

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

Проблема

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

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

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

Решение

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

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

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

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

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

  1. Juras Vetrau

    Кирилл,

    Спасиб! Хотелось найти компромисс, а они часто приходят из неожиданных краев 🙂

    Reply
  2. Стас

    Помоему плохая идея. Сильно бросается в глаза “В разработке”, это плохо. Думаю лудше было сверстать в просто html, а если был клик по линку в этом блоке, то поверх вспывал полупрозрачный png с текстом “В разработке”.

    Reply
  3. Juras Vetrau

    Надпись “В разработке” можно и убрать, это уже детали решения. Суть-то в том, чтобы каким-то образом не ломая общую структуру показать текущий статус проекта. Эту версию будут видеть 5-10 человек, которым важно:

    1) Увидеть, как работают уже сделанные функции.
    2) Понять общий статус разработки.

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

    Reply
  4. Hienadz Drahun

    Юра – замечательная идея! Очень наглядно и легко позволяет заказчику отслеживать статус проекта.

    В моей практике было мало опыта работы с заказчиком уже после замораживания прототипа – мяч переходил на поле разработчиков, но вполне вижу, как бы работал твой подход.

    Слова “Итерационная разработка” немного смущают. Если честно, ожидал в статье чего-то другого.

    Reply
  5. Juras Vetrau

    Гена,

    Спасиб, надеюсь, и тебе пригодится 🙂 Не знаю, как сейчас в ЕПАМе процессы идут, но мне кажется, разработчикам можно предложить такую штуку — им самим будет удобнее отслеживать статус. Большинство людей с которыми я работал достаточно адекватными были и будут только за 🙂

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

    Reply
  6. Александр Сергеев

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

    Твой и мой методы дополняют друг друга 🙂

    Reply
  7. Juras Vetrau

    Саша,

    Да, согласен, для конкретных функций твой способ лучше. Мы обычно просто делаем такие контролы disabled. И тут есть минус — непонятно, почему он недоступен. То ли потому что в этой ситуации недоступен, то ли потому что просто не сделан. Так что будем соединять 🙂

    Reply
  8. Juras Vetrau

    На WUD планирую попасть, а вот ClientSide — вряд ли. Так что на первой пересечемся, если заедешь 🙂

    Reply
  9. Juras Vetrau

    Ну это громко сказано про директора юзабилити-компании 🙂 Хотя туда и движемся, лучше пока попроще говорить 🙂

    Reply
  10. Hienadz Drahun

    Юра,
    Просто слово “Итерационная”, у меня ассоциировалось с итерационным проектированием. Именно этим сейчас забит мозг, пробую об этом писать и собираюсь рассказать на Russia User Experience.
    На WUD – может быть тоже загляну. Если успею зарегестрироваться…

    Reply
  11. Juras Vetrau

    Гена,

    Про итерационное проектирование, кстати, как раз тоже собирался написать материал — как раз почти отработали новую методику, хотелось “проговорить” ее в блоге еще раз. А на UserExp будет мой коллега, попрошу пересказать твой доклад 🙂

    Reply
  12. copylove

    Надо вместо “В разработке” писать “Censored”. Чувствуете, к чему этом может привести?

    Reply
  13. Orlov_Evgeniy

    Уверен, что слова “В разработке” можно убрать со смелостью и оставить просто черно-белый фон (разумеется упомянуть об этом клиенту). Тогда все получится просто и понятно, да и в глаза бросаться не будет.
    Жгите дальше.

    Reply
  14. Pingback: Интерактивные прототипы. Действующая модель пользовательского инт

  15. Pingback: Интерактивные прототипы. Действующая модель пользовательского инт

  16. Juras Vetrau

    Евгений,

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

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *