В последнее время проекты в нашей компании ведутся по смешанному типу управления. На одних участках работ это гибкие методики, на других — классические водопадные. От первых берется, в частности, итерационная разработка и доступность текущей версии клиенту. Когда система уже успела обзавестись несколькими модулями, заказчик получает доступ к ее регулярно обновляющейся рабочей версии. Другое дело, что сырой вид продукта может его испугать. С различными для всех участников проекта последствиями.
Проблема
Где-то около месяца назад один из текущих веб-проектов как раз ушел в staging (рабочую версию для клиента). Параллельно идет плотная работа над функциональностью. И в общих сжатых сроках верстка разваливается гораздо быстрее, чем ее успевают причесывать. Кроме того, часть модулей еще даже не начиналась делаться, а без них общая картинка не складывается.
Сложно получить хороший отзыв о разобранном мопеде. Даже если вся команда знает, что раму отлили знатную, мотор отменный и другие детали не хуже, просто еще привезти с фабрики не успели. Срочно вырабатываем план действий. Задачи стоят три:
- выбрать из сырой функциональности наиболее приоритетную, которую нужно доделать к показу;
- причесать верстку, чтобы система аккуратно смотрелась в трех ключевых для клиента браузерах;
- решить что делать с еще не разработанной функциональностью.
Решение
На общем брейншторминге определились приоритеты и ответственные за эти задачи. Тим лидер команды разработки курировал первый процесс. Шеф нашего минского офиса, где ведется разработка, взял на себя оперативное руководство вторым пунктом (он, кстати, отлично написал об этом процессе, да и за фразу о разобранном мопеде ему спасибо). А я должен был решить, что делать с последним вопросом.
К началу этапа программирования у нас обычно готов не только спроектированный пользовательский интерфейс, но и его интерактивный прототип. Клиент уже успел посмотреть и покритиковать его. А еще — начать ожидать именно такой картинки. Так что если просто взять да вырезать несделанные куски, можно получить серию вопросов “а куда пропало это?”. Опять же, с различными последствиями и нервными переживаниями.
Идея пришла из образа новых ценных бумаг. Перед выпуском в обращение в прессе часто печатают их внешний вид с жирной надписью “образец”. Аналогичный ход подойдет и для еще нереализованных функций. Делаем скриншот прототипа, переводим его в черно-белый вид и пишем большими красными буквами “В разработке”. И вставляем в те места страниц, где они должны находиться в финальной версии. Можно, конечно, просто вставить на эти места статический HTML-код. Но тогда никто будет точно знать, что работает, а что нет.
Итоговая презентация прошла удачно. Все выглядело так, как и при показе HTML-прототипа, только уже работало, а не просто имитировало взаимодействие. Куратору проекта со стороны заказчика мы показывали и более ранние рабочие версии. Но с момента этой презентации отзывы стали гораздо теплее.
25 comments
Евгений,
Да, можно и так — зависит от вашего заказчика 🙂 Основная суть идеи ведь в том, чтобы еще не работающую функциональность не убирать из релиза, а каким-то образом ее показывать. А уж каким способом — дело вкуса 🙂
Уверен, что слова “В разработке” можно убрать со смелостью и оставить просто черно-белый фон (разумеется упомянуть об этом клиенту). Тогда все получится просто и понятно, да и в глаза бросаться не будет.
Жгите дальше.
Леша,
Это значит что-то вроде “класть мы хотели на вашу функциональность”? 🙂
Надо вместо “В разработке” писать “Censored”. Чувствуете, к чему этом может привести?
Гена,
Про итерационное проектирование, кстати, как раз тоже собирался написать материал — как раз почти отработали новую методику, хотелось “проговорить” ее в блоге еще раз. А на UserExp будет мой коллега, попрошу пересказать твой доклад 🙂
Юра,
Просто слово “Итерационная”, у меня ассоциировалось с итерационным проектированием. Именно этим сейчас забит мозг, пробую об этом писать и собираюсь рассказать на Russia User Experience.
На WUD – может быть тоже загляну. Если успею зарегестрироваться…
Договорились 🙂 Про HumanoIT не сомневаюсь, бодро выглядишь 🙂
Забыл смайл поставить 🙂 Вообщем в личке поговорим на эту тему. А вообще у HumanoIT Group сейчас все преотлично 🙂
Почему громко?
Ну это громко сказано про директора юзабилити-компании 🙂 Хотя туда и движемся, лучше пока попроще говорить 🙂
Как это директор юзабилити-компании и не заедет на WUD? 🙂
На WUD планирую попасть, а вот ClientSide — вряд ли. Так что на первой пересечемся, если заедешь 🙂
Юра,
ты на clientside2007 будешь? А на WUD?
Саша,
Да, согласен, для конкретных функций твой способ лучше. Мы обычно просто делаем такие контролы disabled. И тут есть минус — непонятно, почему он недоступен. То ли потому что в этой ситуации недоступен, то ли потому что просто не сделан. Так что будем соединять 🙂
Да, обманывать ожидания клиента нехорошо, лучше сделать упреждающий сигнал. С другой стороны, есть допустим у тебя ссылка – “Отправить сообщение”, а сообщения еще не имплементированы. Здесь секси-окно в самый раз.
Твой и мой методы дополняют друг друга 🙂
Саша,
Тоже имеет полное право на жизнь, хотя мне по душе большая очевидность статуса 🙂
А мы, если фича не готова, показываем секси-floating-window с текстом
“Фича в процессе”
Гена,
Спасиб, надеюсь, и тебе пригодится 🙂 Не знаю, как сейчас в ЕПАМе процессы идут, но мне кажется, разработчикам можно предложить такую штуку — им самим будет удобнее отслеживать статус. Большинство людей с которыми я работал достаточно адекватными были и будут только за 🙂
А про итерационную разработку — я обычно небольшими сериями статьи пишу, так что это скорее название этого цикла, а после точки уже конкретной статьи. Если это делать тегами, их скопится чересчур много. А чего ожидал, кстати? 🙂
Юра – замечательная идея! Очень наглядно и легко позволяет заказчику отслеживать статус проекта.
В моей практике было мало опыта работы с заказчиком уже после замораживания прототипа – мяч переходил на поле разработчиков, но вполне вижу, как бы работал твой подход.
Слова “Итерационная разработка” немного смущают. Если честно, ожидал в статье чего-то другого.
Надпись “В разработке” можно и убрать, это уже детали решения. Суть-то в том, чтобы каким-то образом не ломая общую структуру показать текущий статус проекта. Эту версию будут видеть 5-10 человек, которым важно:
1) Увидеть, как работают уже сделанные функции.
2) Понять общий статус разработки.
А решение с HTML как раз наоборот не очень — оно не дает ответа на две эти задачи. Во-первых, непонятен статус — все вроде бы выглядит работающим. Во-вторых, после третьего клика по неработающей функции нас попросят перечислить то, что все-таки работают. При этом и клиент расстроится, что все не то и не так. И нам проблемы лишние.
Помоему плохая идея. Сильно бросается в глаза “В разработке”, это плохо. Думаю лудше было сверстать в просто html, а если был клик по линку в этом блоке, то поверх вспывал полупрозрачный png с текстом “В разработке”.
Кирилл,
Спасиб! Хотелось найти компромисс, а они часто приходят из неожиданных краев 🙂
Умно! 🙂