У вас возникла отличная идея как можно реализовать тот или иной функционал? Это очень хорошо… НО! поверьте, не стоит сразу бросаться в разработку. Почему? А именно об этом мы и поговорим в сегодняшнем докладе.
Какие бывают гипотезы?
Почему стоит их проверять и опровергать?
Как влияет разработка через гипотезы на процесс работы с требованиями?
Какие способы и техники проверки гипотез существуют? Какие работают, а какие нет - рассмотрим реальные примеры использования из практики.
2. Что такое Гипотеза?
«Гипо́теза — предположение или догадка;
утверждение, предполагающее
доказательство. Гипотеза считается научной,
если она удовлетворяет научному методу, то
есть потенциально может быть проверена
критическим экспериментом...
...Гипотезу впоследствии или доказывают,
превращая её в установленный факт, или
же опровергают, переводя в
разряд ложных утверждений...»
(с) Wikipedia
3. Научный метод
«Нау́чный ме́тод — совокупность основных
способов получения
новых знаний и методов решения задач в
рамках любой науки.
Следующие 7 шагов составляют суть
научного метода:
• Наблюдение.
• Постановка проблемы.
• Формулировка гипотезы.
• Эксперимент.
• Анализ полученных результатов.
• Заключение.
• Воспроизводимость.
4. Минимизируем время
прохождения цикла
THINK: Generation research, Ideation, Mental models, Participatory design, Concept maps, Behavior models, Test
results, Competitive analysis;
MAKE: Personas, Sketches, Prototypes, Wireframes, Value Prop, Landing view, Hypotheses, Comps;
CHECK: Evaluative research, AB Testing, Site analytics, Usability testing, Funnel analysis;
THE LEAN
STARTUP CYCLE
Научный подход в разработке
5. Процесс работы с гипотезами
Предположение
Гипотеза
Эксперимент
Подтверждение
Определение... Звучит как ...
То что мы приняли без
подтверждения.
«Людям нужен наш
продукт.»
Убеждение которое
мы хотим проверить.
«Я верю, что [потребность действие
поведение] для [конкретный
пользователь роль] приведет к
[результат]».
Действие для
проверки.
«Наименьшее, что я могу сделать для
проверки этой гипотезы – это
[эксперимент].»
Индикатор
подтверждения/опров
ержения.
«Гипотеза подтверждена если
[количественный или качественный
измеримый результат].»
6. Гипотеза хороша, если она...
Проста и понятна.
Написана в форме утверждения.
Содержит:
Участника (Кто)
Изменение (Что предлагается
сделать)
Предполагаемый результат действия.
Тестируема.
Измеряема.
Приоритезирована:
по важности для бизнеса.
по затратам на проверку.
7. Design thinking
• Понимание пользователей:
• User personas, Impact mapping, Empathy maps, Interviews
• Фокус на проблеме:
• Исследование, Root cause analysis, Journey maps
• Формирование идей
• Brainstorm, метод Делфи
• Прототипирование
• Story boards, UI Prototype
• Тестирование
9. MVP как эксперимент
• MVP (Minimum Viable Product) - это
версия продукта, позволяющая
запустить цикл «создать-оценить-
научиться» с минимальными
усилиями, потратив как можно
меньше времени на разработку.
• MVP нужно создать таким
образом, чтобы можно было
оценить его успех.
• Может не соответствует
традиционным представлениям о
качестве.
10. Модель удовлетворенности
потребителя «Модель КАНО»
Пять типов эмоциональной
реакции Кано:
• Привлекательные характеристики
• Одномерные характеристики
• Обязательные характеристики
• Неважные характеристики
• Нежелательные характеристики
http://marketnotes.ru/marketing-research/kano-method/
http://www.fdfgroup.ru/?id=281
12. Что мешает использовать гипотезы
Сосед курит на лестничной площадке — гипотеза
или факт? Факт — если вы его там видели. Пока
не видели — гипотеза.
«Та зачем кого-то спрашивать?! – Я лучше знаю что
им надо...»
«Да ты успокойся! Я уже 100 раз так делал...»
«Тили-тили, трали-вали. Это мы не проходили. Это
нам не задавали...»
• Использование гипотезы как факта
• Экспертное мнение
• Отсутствие данных
• Низкая мотивация
• Привычка
14. Спасибо за внимание!
Andrii Mandrika
Contacts:
• andrii.mandrika@gmail.com
• andrey.mandrika@betlab.com
• linkedin.com/in/andrii-mandrika
• Skype: mandrikaandrew
• «Я верю, что знание того как работать с
гипотезами для бизнес аналитиков приведет к
тому, что на ваших проектах станет меньше
потерь связанных с неправильной
интерпретацией и реализацией требований».
• «Наименьшее, что я могу сделать для
проверки этой гипотезы – это
1) Прочитать данный доклад.
2) Попросить Вас попробовать неделю
поработать в формате гипотез вместо
требований.
3) Написать мне о вашем опыте
использования.»
• «Гипотеза подтверждена если хотя бы 3
человека напишут мне, что использование
такого подхода позитивно повлияло на
ситуацию в ваших проектах.
Hinweis der Redaktion
Всем добрый день. Безгранично рад вас всех сегодня видеть. Меня зовут Мандрика Андрей. Я занимаю позицию руководителя проектов в одной из украинских продуктовых компаний под названием Бетлаб. В айти я не много, не мало, а уже 7 лет. Начинал с технического писателя, тестировщика, разработчика на дот нете, бизнес аналитика, продакт овнера и собственно руководителя проектов. Так что за это время пришлось познать айти сферу абсолютно с разных сторон. Ну а тема моего сегоднешнего доклада звучит как «доверяй, но проверяй. Или зачем нужно проверять гипотезы при работе с требованиями». Давайте так, сначала хочу спросить вас дабы немного раструсить и понять у кого какая экспертиза в этом вопросе. Поднимите, пожалуйста, руки те, кому приходилось работать с требованиями в формате гипотез? Ага, интересно. Ну тогда я думаю, что вам будет как минимум познавательно узнать, каким образом можно применять гипотезы при разработке программного обеспечения, та и в принципе в любых проектах в вашей жизни. Поехали.
Итак Гипотеза. Наша доблестная Википедия нам предоставляет следующую трактовку данного термина. То есть в чем отличие наших каноничных требований от гипотез. А именно то, что требование мы уже записываем в форме неопровержимого факта, который не подлежит проверке на подлинность. Даже тот же формат пользовательской истории про которую мы сегодня много слышим записывается в форме утверждения. А наверняка если не у каждого, то у большинства бывало такое, что проработав и реализовав определенное требование от бизнеса или заказчика, оно в итоге оставалось ненужным или неправильно интерпретировано. Тоже самое нам подтверждает и статистика от проджект менеджмент института, которая говорит нам о том, что 3я самая распространенная причина фейла проектов – это неправильная интерпретация требований. А ведь все можно было изменить проверив определенную гипотезу перед началом записи требования в форме утверждения. Тут в данном высказывании также есть фраза относительно того, что гипотеза считается научной, если она удовлетворяет научному методу. Тут вы можете спросить, а при чем тут разработка ПО и наука? Да при том, что данный научный метод отлично подходит для организации работы в разработке программного обеспечения. А давайте же разберемся каким образом.
совокупность основных способов получения новых знаний и методов решения задач в рамках любой науки. По факту, же мы с вами этим и занимаемся – постоянно получаем новые знания относительно предметной области того бизнеса где мы работаем, узнаем лучше процессы наших пользователей, получаем знания относительно рабоспособности вашей системы и все это именно для того, чтобы решить ряд проблем или задач, которые помогут сделать жизнь наших пользователей лучше. Только все это в контексте науки по разработке программного обеспечения.
Теперь давайте разберем более подробнее те шаги, которые мы проходим использовав научный метод.
Наблюдение – абсолютно все мы с вами производим процесс наблюдения перед тем как увидеть определенную проблему пользователей или бизнеса. В данном контексте – наблюдением может быть как общение с вашими пользователями, так и изучение проэктной документации.
Затем мы видим некую проблему, которую мы хотим решить тем или иным программным путем. Например, ваш пользователь вам сказал, что в какой-то электронной таблице ему нехватает например фильтра по дате создания записи. Это проблема? Ну конечно же проблема. И что мы делаем дальше, когда это понимаем? Стразу делаем заключение относительно того, что у пользователя есть проблема которую надо решить и порой мы даже не задумываемся, а действительно ли это та проблема, и даже если мы правильно интерпретировали проблему. А правильно ли мы выбрали решение? А данный подход позволяет нам после определения некой проблемы выдвинуть гипотезу, которую мы должны буде проверить перед окончательным решением. В нашем примере гипотеза может быть следующая, что имея данный фильтр некий пользователь будет тратить на поиск записи в списке в 3 раза меньше времени, чем он тратил до этого. Имея такую гипотезу, мы можем осуществить некий эксперимент и или подтвердить эту гипотезу или опровергнуть. Относительно экспериментов – мы поговорим немного дальше. И лишь после этого мы можем сделать какие-то заключения относительно того, действительно ли реализация данного требования решила данную проблему.
Еще очень важно составляющей научного метода – является критерий воспроизводимости. Это один из параметров, который позволяет критичность проблемы. В нашем же примере к нам мог обратиться один пользователь, а могло 10. И скорость могла у одного стать быстрее, а у другого нет. Тут просто надо знать, что стоит учитывать данный критерий.
Но в каких же методологиях по разработке программного обеспечения может быть использован научный подход?
Одной из самых распространенных методологий по разработке программного обеспечения, которая постулирует нучный подход является Лин стартап. Ее описание вы можете найти в одноименной книге от Эрика Райса. Данная методология используется, как можно понять из названия в стартапах. А поскольку в результататом разработки стартапов как правило являются инновационные продукты, которых еще никто не создавал, то и разрабатываются они в условиях крайней неопределенности. В таких условиях практически невозможно заранее выстроить детальный план проекта. Поэтому проекты такого плана развиваются посредством цикла создать-оценить-научиться. Вот вам тот-же научный подход. Еще одной особенностью данной методолгии является то, что все управленческие решения принимаются только на основе конкретных данных, или так называемых метрик. То есть изначально на этапе идеи или гипотезы мы сразу определяем те численные показатели, по которым мы могли бы понять, дсотигли мы цели или нет. А на основании этих данных принимается решение относительно продолжения разработки в этой же стратегии или совершение так называемого виража.
Вторая же картинка – это нечто модифицированная данная методология с уклоном на ЮИКС техники. Без которых абсолютно невозможна современная разработка пользовательских продуктов. + этой практики, то что ее создатели предлагают использовать все входящее в нее техники еще до начала любой разработки, что таки позволяет нам оценить наши гипотезы и не потерять уйму финансовых средств в результате никому ненужной разработки.
Все эти представленные техники все лишь позволяют систематизировать уже известную информацию, которую мы анализируем для определения дополнительных выводов. Но первоначальные данные для этих преобразований можно получить только из первоисточника – с полей.
Это всем известный МВП. Вроде все просто, делаем минимально рабочую версию – отдаем и внедряем ее пользователям и на основании полученного фидбека планируем следующую версию. И так до тех пор пока мы не добьемся наших финальных целей проекта. Но не так все просто. Я видел массу примеров или неправильной декомпозиции продукта на самостоятельные версии или включение в мвп слишком большого количества функционала. Да что тут говорить, в одном из первых моих проектов – мы разрабатывали мвп слишком долго и были в полной уверенности, что даже таким продуктом мы создадим фурор. А случилось, прям вот очень показательно, как в книге Эрика Риса. После столь желанного якобы релиза в прод – пользователи даже не обратили на него внимания. А как? Ну мы же все сделали?! После этого момента у меня остался яркий отпечаток и теперь у меня язык не поворачивается сказать, что мы в проде – если продукт никому не нужен. Но этот момент тоже не прошел зря – это опыт, который помог осознать какие действительно продукты необходимо разрабатывать, и что даже после разработки надо активно работать для внедрения вашего решения.
Очень показательным является вот эта иллюстрация от Генриха Книберга, что такое МВП. Она присутствует практически во всех книгах по гибкой разработке ПО. Но насколько же точно она изображает произошедшее. Особенно показательна верхняя часть. В моей памяти была и есть одна знакомая команда, которая постулировала ценности аджайла, упорными силами делали мвп, версия за версией. НО! Каждая новая версия – была всего лишь новым модулем огромной платформы. А вся платформа могла полноценно работать только имея все необходимые модули. В этом случае надо было конечно использовать нижнюю стратегию разбить не в глубину а в ширину. В каждой версии сделать хотя бы самый минимальный функционал, но который бы позволил пройтись по всему бизнес флоу и в конце концов внедрить данное решение.
Но есть и еще один кейс, когда вы вроде разбили все версии продукта на правильный функционал, разработали его, выдали, а он ничем ни лучше их старого решения. Вот вроде бы все есть, но у нового продукта нету фишки, нету конкурентного преимущества. А внедрить такой продукт можно только насильно приказом сверху. Поэтому я каждый раз когда необходимо сформировать композицию функционала для нового продукта пользуюсь отличным методом.
Это так называемая модель КАНО, или модель удовлетворенности потребителя. Метод, используемый для оценки эмоциональной реакции потребителей на отдельные характеристики продукции. Полученные с его помощью результаты позволяют управлять удовлетворенностью и лояльностью потребителей.
На самом деле все очень просто. С помощью данного метода можно любой функционал отнести к одному из 5 типов эмоциональной реакции человека.
Привлекательные характеристики – розовый рог. Привлекательные характеристики (если они присутствуют в продукте) вызывают чувства удовлетворения и восторга. Однако если этих характеристик нет, то пользователи не испытывают неудовлетворения. Привлекательные характеристики являются неожиданными, они удовлетворяют ранее неудовлетворенные потребности. Вот именно они и формируют инновацию и конкурентное преимущество. Это про них говорят, ВАУ.
Одномерные характеристики – желтая линия. Эти характеристики вызывают удовлетворение (если они есть) или неудовлетворение (если их нет). Например, и чем лучше реализована характеристика, тем больший эффект она принесет. К этой категории можно отнести простота использования, стоимость, ценность развлечения и безопасность.
Обязательные характеристики – синяя линия. Эти характеристики, по мнению потребителей, относятся к группе тех качеств, которые обязательно должны присутствовать в продукте. Усиление обязательных характеристик постепенно приводит к замедлению роста эмоциональной реакции.
Неважные характеристики - Наличие неважных характеристик вызывает неоднозначную реакцию пользователей, но, в целом, им все равно, присутствуют такие характеристики в продукте или нет. Отдача от вложений в такие характеристики – низкая.
Нежелательные характеристики - Наличие в продукте нежелательных характеристик сводит на нет положительное влияние привлекательных и одномерных характеристик.
А отнести весь функционал к той или иной характеристике можно с помощью вот такой простой таблички. Где по каждому функционалу задается 2 вопроса, один отрицательный, один положительный. Пересечение 2 ответов и позволит вам определить тип характеристики.
В моей практике, та и в практике тех людей которые используют данный инструмент для отбора первоначального функционала для мвп, наилучшим успехом было включение функционала в версию в следующей пропорции 50% обязательные, 30% одномерные и 20% привлекательные. Но рекламировать и ставить акцент вы должны именно на привлекательных характеристиках. Ибо соотношение 20 на 80 еще никто не отменял.
Всем добрый день. Меня зовут Мандрика Андрей и тема моего сегодняшнего доклада звучит как «Проект в условиях неопределенности? Используем концепцию Лин стартап на практике». Перед тем как начать давайте я расскажу пару слов о себе и о своем опыте. Итак, на данный момент я занимаю позицию продакт овнера в украинской продуктовой компании под названием бетлаб. В айти я уже около 6 лет и познал данную сферу с абсолютно разных сторон. За это время был техническим писателем, тестировщиком, около двух лет разрабатывал приложения на дот нете, попробовал себя в роли скрам мастера, но вот уже 2 года тесно связан с продуктовой разработкой на позиции продакт овнера. За этот не столь долгосрочный период я был участником нескольких различных проектов, как успешных так и не очень, менялись процессы, условия и окружение и, естественно, мое мировозрение относительно подходов разработки и вывода в продакшн новых продуктов. Но чего не отбавлять так это экспериментов на данном пути. И сегодня я хочу с вами поделиться своим опытом экспериментов относительно использования системы лин стартап не в стартапе, а внутри уже существующего продуктового бизнеса.
