Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты

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

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

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

И все-таки есть характеристика, с которой можно выйти из тупика — это глубина проработки интерфейса. Со временем мы нашли хороший баланс, разбив работы над проектом на три фазы:

1. Концепция

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

Для этого мы анализируем проект и предметную область, описывая результаты аналитики в виде серии документов: видения проекта, описания целевой аудитории (персонажей), сценариев взаимодействия и перечня функциональности (user stories). Они дают общее представление о проекте, достаточное для того чтобы и клиент, и аналитики, и разработчики могли общаться предметно. Еще лучше расширить пакет спецификации за счет предварительного проектирования. Важно получить уже на этапе концепции точную структуру системы и черновые наброски структурных схем ключевых страниц. Переход от текстовых описаний к наглядным образам здорово облегчает понимание. Да и для раннего начала разработки они как нельзя кстати.

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

2. Прототип

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

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

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

3. Детальная спецификация

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

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

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

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

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

Все части материала:

8 Comments Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты

  1. Pingback: Процесс и продукт проектирования.

  2. Pingback: Процесс и продукт проектирования.

  3. sevranty

    Мне бы очень хотелось увидеть всю данную методологию работы над проектами на примере живого проекта.

    Думаю это будет потрясающий материал.

    Reply
  4. Juras Vetrau

    Всеволод,

    Я обязательно распишу такой пример — самому не терпится уже давно 🙂 Единственное, что ограничивает — то что проекты еще в работе и до запуска сложно вдаваться в конкретику. Осенью у нас будут запущены три крупных проекта (один выйдет из беты, два стартуют как бета-версия), так что там будет очень много интересных историй 🙂

    Сейчас, кстати, пишу еще один интересный материал по поводу процесса, с подробной раскадровкой шагов участников — в понедельник-вторник опубликую. Так что продолжаем интересное чтиво 🙂

    Reply
  5. Pingback: Проектирование в agile-процессе. График работы команд разработки и аналÐ

  6. Pingback: Проектирование в agile-процессе. График работы команд разработки и аналÐ

  7. Pingback: Процесс и продукт проектирования.

  8. Pingback: Процесс и продукт проектирования.

Leave a Reply

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