презентация технологии создания программных продуктов. Проработка концепции проекта Рабочая тетрадь команды в интенсиве Университета 20. 35

• Название: Проработка концепции проекта Рабочая тетрадь команды в интенсиве Университета 20. 35
• Анкор: презентация технологии создания программных продуктов
• Дата: 17.05.2022
• Размер: 2.66 Mb.
• Имя файла: Work_book_GateWay_WhiteTumbler.pptx
• Тип: Решение; #533384

Проработка концепции проекта

Рабочая тетрадь команды в интенсиве Университета 20.35

Проект: WhiteTumbler

Команда: Gateway

Вуз: СевГУ

Сначала прочитайте тетрадь целиком, потом приступайте к работе с ней.

Оглавление

Введение

Как увидеть свои пробелы в понимании?

1. Завести HADI-таблицу

2. Проверить свой паспорт проекта

3. Уточнить формулировки: Проблема, Решение, MVP.

4. Проанализировать стейкхолдеров

5. Прописать главный пользовательский сценарий

6. Сделать ревизию HADI-таблицы

7. Спланировать своё исследование

Введение

Привет, меня зовут Петр Федин, и я написал для вас эту тетрадку вместе со своими коллегами по Университету 20.35

Когда-то я работал в Яндексе, и мы с коллегами открыли нового страшного зверя — Ежупу.

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

Что же это за зверь и откуда он взялся?

Часто у нас бывает внутренняя уверенность, что нам в команде всё совершенно понятно и мы лучше всех всё про свои проекты понимаем. Да ежу понятно! Ежупа.

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

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

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

Вот краткий обзор того, что мы предлагаем вам сделать:

1. Подготовьтесь к работе: заведите «реестр ежуп» — табличку со списком появляющихся по ходу работы над этой рабочей тетрадью вопросов по проекту. Потом вы последовательно будете искать ответы на эти вопросы.
2. Проверьте паспорт проекта, который у вас получился по результатам прошлой недели — насколько ясно в нем обозначены все ключевые пункты: проблема, решение, первый прототип, вовлеченные стороны. Попросите у вашего проектного наставника обратную связь про паспорт, посоветуйтесь с ним.

3. Выпишите на отдельные слайды скорректированные формулировки проблемы, решения и первого полезного прототипа (MVP) вашего решения. Можно также расширить и дополнить их подробностями.

4. Начните работу со слайдом «Стейкхолдеры»: выпишите всех, кто как-либо влияет на ваш проект и всех, на кого ваш проект повлияет. Начать можно с пользователей и заказчиков, но подумайте и о других проектных ролях.

5. Напишите главный пользовательский сценарий. Когда вы будете его прописывать, отслеживайте — не обнаружились ли новые вовлеченные в процесс лица, новые стейкхолдеры? Выписывайте их в табличку на слайде «Стейкхолдеры»

6. Посмотрите на свой «реестр ежуп» — список открытых вопросов по проекту. Определите, как вы сможете найти ответы на эти вопросы

7. Составьте приблизительный план проблемного интервью, которое будете проводить со своими пользователями.

Как увидеть свои пробелы в понимании

Развивайте в себе скептический настрой: каждый раз, когда вы видите какие-либо утверждения о своем проекте (свои или чужие), проверяйте их по SMART-критериям.

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

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

Критерии SMART:

Specific конкретность:

— «а кто/что/когда/где конкретно?»

Measurable измеримость:

— «а сколько?

— Как мы можем измерить, что…?»

Attainable / Achievable достижимость:

— «При каких условиях это возможно?»

Relevant обоснованность, уместность:

— «Для кого/чего это значимо?»

— Как это вписывается в общий контекст?

— Почему это важно?

Time-bound привязка ко времени:

— «Когда это было/будет? Как часто бывает? Когда последний раз?»

Основные этапы работы

• Заведите HADI-табличку

Вот Шаблон HADI-таблицы — возьмите его за основу, сделайте себе копию.

Сделайте публично доступную Google-таблицу и вставьте сюда ссылку на неё:

https://docs.google.com/spreadsheets/d/1mTV3JsPFOYel7RdsJk6gZAe_D7HQ5r4eBjZYfhP-_2k/edit?usp=sharing.

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

Надеюсь, что вам самим уже не терпится начать искать ответы на эти вопросы.

Кстати, что такое HADI?

Как бы мы ни были уверены в своих идеях, очень часто эти идеи опираются на неверные представления об окружающей действительности.

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

Главный инструмент работы с неопределенностью — выдвижение и проверка гипотез. Алгоритм такой:

• Мы чего-то не знаем? Так. Фиксируем — чего мы не знаем? Это наши вопросы/гипотезы (H - hypothesis).
• А какие есть возможные варианты? 1, 2, 3 и еще пара вариантов, о которых мы сейчас даже не догадываемся.
• Как мы можем проверить, какой из вариантов имеет место на самом деле? Планируем действия по проверке, выполняем их, по сути это — эксперименты (A - actions - действия).
• Получили результаты эксперимента? (D - data - данные) Беспристрастно их оцениваем и делаем выводы, вне зависимости от того, нравится ли нам тот вариант, на который они указывают.

Вот такой процесс, выполняемый каждый раз, когда нам что-то непонятно, называется HADI-цикл.

2. Проверьте свой паспорт проекта

У вас уже должна была пройти первая встреча с вашим проектным наставником.

Попросите его посмотреть взглядом со стороны на то, что вы написали в паспорте проекта — что в нем вам стоило бы уточнить, дополнить или исправить?

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

На следующих двух слайдах мы показали несколько типичных ошибок и даем советы, как с ними справляться. Проверьте себя и если увидите ошибку, но не будете знать, как её исправить — зафиксируйте в свою HADI-таблицу вопрос о ней.

Типовая ошибка	Пример	Лечение
Круговая логика: проблема в том, что у них до сих пор нет нашего решения!	Современный человек хочет получить новые вкусовые ощущения, но не может потому что ему мешает нехватка мясных изделий	Задать себе два проверочных вопроса: А правду ли мы написали? Или это мы из головы выдумали и надо это зафиксировать как гипотезу, а потом проверить? Что изменится в жизни у человека после появления нашего решения? Как оно было устроено до появления нашего решения?
Хотим сделать нашего пользователя лучше (хотя он и не просил)	Наш потребитель хочет эффективно распределять свое время, но не может, потому что ему не хватает на это временных ресурсов, организаторских способностей или денежных средств	Лучше вообще не брать тематику связанную с психологией, личностным ростом и развитием, если в команде нет профессиональных психологов или если они не являются вашими заказчиками. В таких задачах исследование может занимать 90% времени и не дать точных ответов
У нашего решения нет аналогов в мире	существующие проекты не позволяют раскрыть потенциал у людей в сфере Сельского Хозяйства,обладающих малой заинтересованностью. Подобные аналоги отсутствуют.	Не следует искать стопроцентный прямой аналог. Даже у первого самолета братьев Райт были аналоги — воздушные шары, дирижабли и воздушные змеи. Какие есть косвенные аналоги, как сейчас люди решают проблему?

Типовая ошибка	Пример	Лечение
Пользователь — все люди	Наш [человечество] хочет [хочет жить на чистой планете]	Надо фокусироваться. Выберите какую-то отдельную группу людей, с представителями которой вы сможете поговорить, и в деятельности которых выбранная проблема особенно актуальна.
Некорректное заполнение шаблона	Какую проблему решаем: Разработать технологию производства качественно новых и безопасных пищевых продуктов для сохранение и укрепление здоровья населения региона, профилактика заболеваний, связанных с неправильным питанием взрослых и детей	Надо следовать шаблону. Шаблон специально сделан так, чтобы помочь вам задуматься — а кому нужно решение? Кто будет теми людьми, которые получат от него пользу? С кем они взаимодействуют, кто еще вовлечен в ситуацию? Мы с вами попробуем дальше поработать с этим при проработке концепции, но от вас нужна готовность к тому, чтобы в явной форме начать проговаривать и фиксировать такие вещи, которые кажутся слишком простыми и очевидными. Они не простые и не очевидные и при проговаривании всегда вскрываются дополнительные важные обстоятельства.

На следующем слайде мы поставили пустой шаблон паспорта проекта — просто замените его на ваш (по возможности обновленный и улучшенный) паспорт проекта.

Также, если у вас уже возникли открытые вопросы про ваш проект — поздравляем с первым уловом ежуп! Зафиксируйте их в вашей HADI-табличке.

WhiteTumbler

Какую проблему решаем:



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

Кроме этого, все сценарии использовании BBB без Moodle вынуждают студента каждый раз заполнять ФИО, хотя эти данные содержаться в единой системе университета.

В случае сдачи экзамена в удаленном режиме, от преподавателя требуется сделать видеозапись сессии, что невозможно сделать в BBB при разбиении встречи на подгруппы.

Интеграция существующей системы с СДО Moodle не позволяет проводить занятия в рамках совмещенных потоков (между курсами, между институтами).

Какое решение предлагаем:



Разработать систему управления встречами в BBB. В системе реализовать следующую функциональность:

• предустановленный набор настроек и возможность выбора настроек по-умолчанию для каждой встречи.
• аутентификацию через единую систему университета с автоматическим определением прав доступа пользователя и других данных (ФИО, группа и т.д.).
• режим сдачи экзамена, в котором для каждого студента будет создаваться отдельная встреча с возможностью записи сессии. Все встречи будут логически объединены и не будут загромождать интерфейс.
• разграничение прав доступа к встрече на основе данных (группа, курс) из единой системы университета.

Пользователи и другие вовлеченные стороны:

Кто?	Чего хочет?
Заказчик	Модернизировать систему удаленных конференций “ВВВ” с добавлением наборов настроек для встреч, авторизации пользователей через единую систему университета и реализации админ-панели.
Пользователь	Студенты: хотят упрощенного процесса авторизации в системе удаленных конференций Преподаватели: хотят оптимизации процесса организации конференций в краевых случаях (Объединение нескольких потоков в конференции, выделение отдельных конференций под каждого студента)
Держатель ресурсов	Оптимизировать удаленный учебный процесс
Команда реализации проекта	реализовать поставленные задачи в соответствии с составленным ТЗ; получить опыт в работе с полноценным проектом.

Прототип (MVP):

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

Вуз: СевГУ

Рынки НТИ: Сквозные технологии НТИ:

Gateway

Команда:

Запишись в команду здесь (ФИО / роль / leader-id):

• Никита Клышко /Архитектор, разработчик/ ID622091
• Елена Кайда /Разработчик, дизайнер/ ID689108
• Владислав Стельмах / Разработчик, Тестировщик/ ID755790
• Полина Холодова/Разработчик, дизайнер/ ID1470289

Готовы ли вы принимать в команду участников из других вузов:

нет

3. Уточнённые формулировки

На этой неделе у вас есть время, чтобы более детально проработать своё понимание проекта.

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

3. Уточнённые формулировки. Постановка проблемы

Шаблон описания проблемы вам известен

Наш [пользователь]

хочет [цель/желание/потребность],

но не может, потому что

ему мешают [барьеры],

а существующие [решения такие-то]

обладают [недостатками такими-то]

и потому не позволяют эти барьеры преодолеть.

Если вы внесли правки в паспорт проекта — запишите сюда свежую версию своей постановки проблемы.

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

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

В таком случае попробуйте описать цепочку использования — кто пользователи конечного продукта вашей организации-заказчика, и какую пользу сможет ваш заказчик приносить им благодаря вашему решению?

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

Для проверки значимости проблемы есть 4 проверочных вопроса, мы разместили их на следующем слайде. Попробуйте на них ответить.

Но если у вас нет достоверных фактов, подтверждающих ваши ответы — то возможны два варианта развития событий:

• Вы проведете исследование и выясните эти факты (как проводить исследование мы еще расскажем)
• Вы проведете исследование, а подтверждений всё равно не найдётся, потому что в реальности всё устроено не совсем так, как вы думали изначально.

Впишите свои ответы в поля под вопросами на следующем слайде, а если они не будут влезать — создайте дополнительный слайд со своими ответами.

Если у вас появились сомнения и неясности — сформулируйте их в виде вопросов и занесите в HADI-таблицу.

Есть ли ущерб? Кто и как его несёт?

(Если не потеряно время/деньги/здоровье/эмоции — в чем тогда проблема? Или может быть недополучена какая-то польза? Какая?)

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

Как долго люди готовы терпеть и почему?

(Если люди готовы терпеть неопределенно долго, то возможно проблема не так уж и сильно им докучает, а может и вовсе её нет.)

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

Что будет, если ничего не делать?

(Если подождать и проблема рассосется сама — то может проще ничего не делать? И решение тогда не нужно?)

Наш проект направлен на разработку админки для краевых случаев (когда какое-то спец. мероприятие, или лекция на несколько потоков и т.п.).

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

Как мы поймем, что решили проблему?

(По каким объективным признакам мы это поймем? Что нам скажут пользователи или заказчик? Какие измеримые показатели нам это покажут?)

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

3. Уточнённые формулировки. Решение

Шаблон описания решения вам известен

Для [пользователей]

наше [решение]

будет [выполнять главную функцию],

и в отличие от [альтернатив]

будет иметь [такие-то преимущества]

Уточнение формулировки решения:

Для администратора проектируемой системы наша админ-панель будет предоставлять возможность администратору

• просматривать активные конференции, записи,
• редактировать настройки конференций и пользователей,
• регистрировать пользователей вручную,

и в отличии от текущей версии системы удаленных конференций СевГУ будет осуществляться

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

Этот шаблон подходит и для заказных разработок (когда вы работаете на заказчика) и для продуктовых (когда вы разрабатываете продукт для широких групп пользователей). Давайте попробуем добавить немного разъяснений к нему. Пользователи — укажите здесь как можно более конкретную группу людей. На шкале от 1 до 10 где 1 — это максимально абстрактная формулировка, а 10 — максимально конкретная, попробуйте дать ответ на уровне 7-8. Не «клиенты» (это 1, очень абстрактно), не «студенты нашего вуза» (это уже конкретней, но всё равно 3), а «студенты-первокурсники, изучающие иностранные языки» (вот это гораздо более конкретно, баллов на 7). Решение — указывайте, какой класс решения вы разрабатываете (например — мобильное приложение, прибор, интернет-сайт, технологический процесс производства). Хорошо бы, чтобы решение было технологичным, просто разработать методику — это недостаточно, надо тогда создать и набор инструментов, её поддерживающих.

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

Преимущества — здесь надо записывать не просто какие-то дополнительные функции решения, а полезный эффект, реальные изменения в жизни вашего пользователя.

Если на этой стадии у вас возникнут размышления и сомнения — а что же на самом деле будет реальным преимуществом для вашего пользователя, то это прекрасно — зафиксируйте свои вопросы в HADI-табличку, потом они лягут в основу вашего исследования.

3. Уточнённые формулировки. MVP

Минимально полезный прототип

(MVP – minimum viable product) — это продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями.

Основная задача создания MVP — получение быстрой обратной связи для формирования гипотез о дальнейшем развитии продукта.

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

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

Наводящие вопросы вам в помощь:

• Как может выглядеть прототип решения, который вы сможете сделать за ближайшие 10 недель? А за 5? А за 2?
• Какого результата мы можем достигнуть за это время?
• Какие артефакты (осязаемые результаты) получится у команд сделать?
• Что вы сможете понять, сделав эти артефакты?
• Как вы поймете, что ваши пользователи правда получают полезный эффект от вашего решения?

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

3. Скорректированные формулировки. MVP

Что может быть минимальным продуктовым прототипом (MVP) вашего решения?

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

4. Стейкхолдеры

Стейкхолдер — это вовлеченное действующее лицо, играющее значимую роль в проекте:

• Либо проблемная ситуация / решение на него влияет
• Либо он влияет на проблемную ситуацию / решение

Примеры проектных ролей стейкхолдеров решения: заказчик, пользователь, исполнитель, держатель ресурсов, регулятор.

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

Важно понимать различие: есть проектная роль и есть конкретный человек — исполнитель проектной роли.

Сам по себе человек — не проектная роль. «Стейкхолдер Иван Михайлович» — нельзя так записывать, потому что так непонятно, в чем суть бытия Иван-Михалычем для нашего проекта. Он ведь для проекта не Иван Михайлович, а заказчик.

Конкретный человек Иван Михайлович становится стейкхолдером проекта только когда исполняет свою проектную роль.

Почему важно делать анализ других стейкхолдеров, когда мы уже сфокусировались на помощи какому-то конкретному пользователю:

• Другие стейкхолдеры могут начать противодействовать нашему решению
• Наше решение должно минимально ущемлять других стейкхолдеров
• Идеально — если оно по-своему помогает всем сторонам одновременно

Давайте на следующем слайде начнем подробно описывать структуру проектных ролей вокруг вашего проекта и их стейкхолдеров-исполнителей.

4. Стейкхолдеры

Если вы понимаете, что вам неизвестны истинные цели, интересы или предпочтения кого-то из ваших стейкхолдеров, или неизвестны сами стейкхолдеры — скорее фиксируйте вопросы про них в HADI-таблицу.

Проектная роль	Кто исполняет? (если известен)	Чего хочет? (цели, интересы, предпочтения)
Заказчик	Куркчи Ариф Эрнестович	Модернизировать систему удаленных конференций “ВВВ” с добавлением наборов настроек для встреч, авторизации пользователей через единую систему университета и реализации админ-панели.
Пользователь	Преподаватели и студенты СевГУ	Студенты: хотят упрощенного процесса авторизации в системе удаленных конференций Преподаватели: хотят оптимизации процесса организации конференций в краевых случаях (Объединение нескольких потоков в конференции, выделение отдельных конференций под каждого студента)
Держатель ресурсов	СевГУ	Оптимизировать удаленный учебный процесс
Команда реализации проекта	Gateway	Реализация поставленной задачи в соответствии с составленным ТЗ. Получение опыта в работе с полноценным проектом.

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

5. Сценарий. Как устроен сценарный анализ

Сценарий — это пошаговое описание процесса, в котором у нашего пользователя возникает проблема.

Сценарный анализ полезен и для детального разбора проблемной ситуации, и для дальнейшей разработки решения, и для выявления собственных пробелов в понимании.

Есть два типа сценариев:

• Сценарии AS IS («как есть») – текущее состояние дел, когда проблема имеет место
• Сценарии TO BE («как будет») – прекрасное будущее, когда наше решение избавит пользователя от проблем

Сначала мы исследуем сценарий AS IS — а как же именно возникает проблема.

А потом мы проектируем сценарий TO BE и прописываем главный сценарий использования нашего решения.

Можно работать с разным уровнем проработки:

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

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

5. Сценарий. Шаблон сценария

Акторы (и главный из них, пользователь) – участники сценария

Предусловия (обстоятельства, в которых начинается сценарий):

...

Ожидаемый результат: ...

<актор достиг своей цели>

Шаги сценария:

1.<актор> <делает что-то> <с чем-то>.

2.<актор> <действие> <объект> + [доп. обстоятельства]

3. ...

4.<проблема: что-то мешает достичь цель>

5. ... Дальнейший ход сценария ...

Один из самых лаконичных подходов как можно писать сценарии показан справа. Основные его принципы таковы:

• Один шаг сценария – одно действие одного актора
• Сначала прописываем самый частый вариант прохождения сценария
• Точки ответвления сценария – отдельно отмечаем, а расписываем позже
• Аварийные ситуации – расписываем отдельно

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

5. Сценарий. Пример сценария AS IS

• Пассажир обходит автомобили и проходит к тротуару
• Пассажир идет по своим делам
• <Конец>

Варианты:

4а. <Проблема>: Пассажир не может выйти, потому что мимо открытых дверей трамвая едут автомобили.

4а1. Пассажир ждет, когда будет пауза в движении автомобилей.

4а2. Пассажир пытается выйти из трамвая.

4а3. Пассажир перебегает дорогу в сторону тротуара.

<Продолжение с шага 7>

4б. <Проблема>: Пассажир выходит из трамвая под колеса движущегося автомобиля

4б1. Водитель движущегося автомобиля сбивает пассажира

<Конец>

Акторы: пассажир трамвая, машинист, водители автомобилей.

Предусловия:

трамвай подъезжает к остановке.

Ожидаемый результат:

Пассажир выходит из трамвая и идет по своим делам.

Шаги сценария:

• Машинист трамвая тормозит трамвай у остановки посередине улицы
• Машинист открывает двери трамвая
• Пассажир спускается по лестнице на выход
• <Проблема> Пассажир не может выйти, потому что перед выходом стоит автомобиль
• Пассажир протискивается в щель между трамваем и автомобилем

4в. <Проблема>: Пассажир выходит из трамвая и наступает в лужу/слякоть/ на наледь

4в1. Пассажир поскальзывается

4в2. Пассажир пачкается

4в3. Пассажир доходит до тротуара

<Продолжение с шага 7>

4г. Пассажир выходит из трамвая без проблем

4г1. Пассажир доходит до тротуара

<Продолжение с шага 7>

5. Сценарий. Ситуация AS IS.

Шаги сценария:

1. Преподаватель создает комнату без указания настроек

2. Преподаватель создает встречу без указания дополнительных настроек

3. Студент переходит по ссылке

4. <Проблема> Студент перенаправляется на страницу подключения к конференции

5. <Проблема> Пользователь вводит ФИО и группу

6. Студент нажимает кнопку "Присоединиться"

7. Студент подключается к конференции

8. <Конец>

Варианты:

4а. <Проблема>: Нет разграничения прав доступа к встрече студентов.

4а1. Любой студент переходит на страницу подключения к конференции, так как нет дополнительных настроек конференции

<Продолжение с шага 5>

5а. <Проблема> Студент может ввести любые данные в поле ввода ФИО и группы

4г1. Студент подключается к конференции под чужим именем

<Продолжение с шага 6>

5. Сценарий. Ситуация TO BE.

Шаги сценария:

1. Преподаватель создает комнату с указанием дополнительных настроек (какие группы, потоки имеют доступ к встрече)

2. Преподаватель создает встречу с указанием дополнительных настроек (какие подгруппы, группы, потоки имеют доступ к встрече)

3. Студент переходит по ссылке

4. Студент перенаправляется на страницу подключения к конференции

5. Система проверяет доступ пользователя к конференции

5а. Студент имеет доступ к конференции

5а1. Система сама вводит данные пользователя в поля ввода данных

5а2. Студент нажимает кнопку "Присоединиться"

5а3. Студент подключается к конференции

5б. Студент не имеет прав доступа к этой конференции

5б1. Студента перенаправляет на страницу с ошибкой и пояснением к ней

6. <Конец>

6. Ревизия реестра открытых вопросов

Итак, мы выполнили все предварительные действия по проработке концепции проекта.

К этому моменту, в вашей HADI-таблице в первой колонке «Гипотезы / вопросы» должны были накопиться открытые вопросы по проекту в изрядном количестве.

Настало время внимательно посмотреть на них, возможно объединить тематически близкие, и составить план исследовательской работы. Есть как минимум три варианта, какие действия можно предпринять, чтобы найти ответы на возникшие вопросы:

• Посоветоваться внутри команды / с наставником
• Поискать информацию в Интернете и других источниках
• Добыть информацию в прямом контакте с теми, у кого она есть — через интервью.

Далее мы дадим короткий обзор о проблемных интервью.

7. Проблемное интервью

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

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

Проблемные интервью отличаются от опросов. Интервью — это беседа, диалог, а опрос — это проход по анкете с выбором вариантов ответа. Опрос — это количественный метод исследования.

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

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

Подборка эта находится на платформе Университета 20.35 и включает в себя прекрасные короткие видео Александра Еремеева про HADI-циклы, планирование и проведение интервью: https://steps.2035.university/collections/cc2cf618-d949-4263-9ea2-e323164ccb4b

Итоги

Итак, вы дошли до предпоследнего слайда этой рабочей тетради. Подведем итоги:

• У вас есть огромная HADI-таблица с кучей вопросов
• У вас есть гора артефактов, из которых складывается концепция проекта:
• Постановка проблемы и обоснование её актуальности
• Уточненная формулировка решения
• Уточненная формулировка первой продуктовой версии вашего решения (MVP)
• Перечень стейкхолдеров и их целей
• Сценарий AS IS — как пользователь приходит к проблемной ситуации
• Сценарий TO BE — каким будет путь пользователя, когда решение позволит снять проблему
• У вас есть приблизительное представление, что вам нужно узнать с помощью исследования методом проблемных интервью.

Ссылки

• Первая статья про ежупу — Константин Коломеец

https://teambook.ru/approaches/the-ezhupa

• Портрет Ежупы в естественной среде обитания — дизайнеры компании КРОК (ЗАО КРОК Инкорпорейтед)
• Подборка видео по теме рабочей тетради: