Стартуем проекты. Удачная рабочая сессия

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

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

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

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

Зная эти задачи, мы спускаемся на уровень интерфейса. Например, найти подходящие источники автор может с помощью каталога, поиска или рекомендаций. Это уже функциональность системы, которую необходимо реализовать. Добавим сюда служебные и сервисные страницы — например, ведение учетной записи пользователя (регистрация, авторизация и т.п.). И получим на выходе процентов на 90 точный перечень ключевых страниц интерфейса, которые необходимо отразить в спецификации. А также набор функциональности, которая должна быть в системе.

Черновой вариант wireframeЗдорово, если в рамках этой сессии получается набросать низкоуровневые wireframes — на уровне набора блоков (“черных ящиков”), содержащихся на странице. На бумаге или в электронном виде — не так важно. Это позволяет проговорить функциональность еще глубже, максимально приблизившись к конкретике. Также полезно определиться с составом интерактивного прототипа — задача это достаточно трудоемкая и лишнюю работу в ее рамках делать не стоит. На это во многом влияет цель, с которой он создается — юзабилити-тестирование или презентация инвесторам.

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

29 Comments Стартуем проекты. Удачная рабочая сессия

  1. Pingback: Стартуем проекты. Быстрая оценка интерфейсной трудоемкости | Juras Vetrau. БÐ

  2. Pingback: Стартуем проекты. Быстрая оценка интерфейсной трудоемкости | Juras Vetrau. БÐ

  3. Juras Vetrau

    Да, 2003й. Но они все начиная с 2002 более-менее пристойные.

    Нотификации попробовал починить — надеюсь, сработало 🙂 Спасиб за информацию!

    Reply
  4. Кодирующий кролик

    Я поэтому и спросил – сам пользуюсь 2002, оно не очень-то похоже визуально.

    Нотификации нашел. В спаме. Странно, в CBL вашего домена нет 🙂

    Reply
  5. Juras Vetrau

    А это стенсил специальный, вот и не похож 🙂 По функциональности что 2002, что 2007 — отличаются минимально.

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

    Reply
  6. Pingback: Работа со стартапами. Заказчик хочет быстро, инвестор — надежно и заÑ

  7. Pingback: Работа со стартапами. Заказчик хочет быстро, инвестор — надежно и заÑ

  8. Pingback: Проектирование пользовательских интерфейсов. Краткий обзор процес

  9. Pingback: Проектирование пользовательских интерфейсов. Краткий обзор процес

  10. Pingback: Немного анонсов | Juras Vetrau Blog. Управление проектами и проектирование интерфÐ

  11. Pingback: Немного анонсов | Juras Vetrau Blog. Управление проектами и проектирование интерфÐ

  12. Павел Коноплицкий

    Юра, в кратком обзоре процесса ты эта озаглавил всё это как предпроектный анализ. Хотел бы уточнить артефакты которые были на входе и получились на выходе.

    Я успел высмотреть следующие
    – Описание персонажей(задачи и цели) и их user stories
    – Низкоуровневый прототип (в идеале – детализированный)
    – Куски функциональной спецификации исходя из пользовательских задач и прототипа

    А что ты имел в виду тут?
    “Не забыли и про спецификацию — business rules, сущности и их атрибуты, особенности реализации и прочие технические моменты”
    Что тут в результате создается ?

    Если можно перечисли все полученные артефакты на всём этапе. Спасибо.

    Reply
  13. Juras Vetrau

    Паша,

    На входе был поток сознания клиента и пара набросков ключевых страниц. На выходе после рабочей сессии получилось вот что:

    — перечень и краткое описание персонажей;
    — набросок карты сайта;
    — наброски схем страниц на бумаге (это очень и очень низкоуровневый бумажный прототип 🙂 );
    — перечень user stories с примерной оценкой страниц для каждой;

    После того как обсуждение закончилось, я привел это все в порядок и получил:

    — описание персонажей;
    — карта сайта и схема навигации — в каких меню какие разделы будут отображаться;
    — низкоуровневые wireframes, как на скриншоте в статье;
    — расписанные в базовом виде user stories — как раз вышла нулевая часть статьи о них;
    — куски спецификации — описание хитрых алгоритмов работы со сторонней базой данных. Тут вообще в достаточно свободной форме все, описана бизнес-логика работы связки пользователь/наша система/сторонняя система, требования к безопасности и т.п.;

    Примерно так. Заняло все это вместе с написанием коммерческого предложения и договора неделю.

    Reply
  14. Павел Коноплицкий

    Юра, спасибо тебе большое за ответ. Учусь на твоих статьях и на твоём опыте. Ты как Прометей несёшь людям огонь юзабилити. Жду анонсированных материалов.

    В планируемой своей статье о персонажах буду ссылаться на тебя

    Reply
  15. Juras Vetrau

    Паша,

    До Прометея мне еще далеко, но здорово что получается помогать 🙂 Сейчас плотно занят написанием пачки статей для нового сайта моего отдела — так что текстов в феврале будет адски много 🙂 За будущие ссылки тоже спасиб 🙂

    Reply
  16. Pingback: Стартуем проекты. Еще одна рабочая сессия | Juras Vetrau Blog. Управление проектам

  17. Pingback: Стартуем проекты. Еще одна рабочая сессия | Juras Vetrau Blog. Управление проектам

  18. Velarix

    Юрий, оцени пожалуйста программу, подготовленную для рабочей сессии с заказчиком (волнуюсь немного, первая встреча):

    Исходные данные
    – Формализация предпосылок и оснований для разработки проекта.
    – Необходимо дать общее описание ситуации и условий, в которых возникла идея создания проекта.
    Бизнес-возможности
    – Обсуждение и формализация бизнес-возможностей проекта.
    – Необходимо зафиксировать бизнес-возможности проекта: источники получения прибыли и/или иной выгоды.
    Формулирование бизнес-целей и критериев успеха
    – Формализация целей проекта и критериев успеха.
    – Необходимо сформулировать конечную цель (цели) проекта и критерии её (их) достижения (как мы поймём, что мы достигли цели).
    Описание целевой аудитории
    – Определение и сегментация целевой аудитории.
    – Необходимо в общем описать целевую аудиторию и составить портреты типовых пользователей (персонажи).
    Пользовательские истории
    – Необходимо описать типовые истории использования системы пользователями (используя предопределённые персонажи).
    Образ решения
    – Необходимо сформулировать общее описание продукта, его функциональность, особенности.
    Масштабы и ограничения
    – Необходимо определить функциональность, реализуемую в первой версии продукта, функциональность последующих версий, а также рамки проекта – функциональность, которая вообще не будет реализована в проекте.
    Приоритеты проекта
    – Необходимо распределить по степени важности следующие параметры проекта:
    – объём функциональности;
    – качество;
    – сроки реализации
    – бюджет.

    Из поста сделал выводы, что по возможности следует набросать низкоуровневые wireframes, а также определить основные сущности и их атрибуты. Можно про сущности с атрибутами поподробнее, на примерах?

    Reply
  19. Pingback: Минимальные требования инвесторов к технической стороне проектов â

  20. Pingback: Минимальные требования инвесторов к технической стороне проектов â

  21. Pingback: Юрий Ветров. Управление проектами и проектирование интерфейсов » ПÐ

  22. Pingback: Юрий Ветров. Управление проектами и проектирование интерфейсов » КÑ

Leave a Reply

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