Комментарии 18
Все эти техники предполагают, что мы знаем целевую аудиторию продукта. Но в реальной жизни это очень трудно технически, потому что:
1. Пользователи, которые готовы ответить на вопросы интервью не обязательно входят в большинство пользователей продукта.
2. Телеметрия позволяет определить «куда кликают», но не позволяет определить «зачем кликают». Интерфейс Windows 8 делался на основе телеметрии. И получил просто огромное количество критики.
В результате «показале десяти знакомым, провели опрос на сайте, собрали фидбек — сделали. Оказалось никому не нужно.» — суровая правда жизни.
1. Пользователи, которые готовы ответить на вопросы интервью не обязательно входят в большинство пользователей продукта.
2. Телеметрия позволяет определить «куда кликают», но не позволяет определить «зачем кликают». Интерфейс Windows 8 делался на основе телеметрии. И получил просто огромное количество критики.
В результате «показале десяти знакомым, провели опрос на сайте, собрали фидбек — сделали. Оказалось никому не нужно.» — суровая правда жизни.
Чаще даже так: «Я показал жене, ей не понравилось, переделайте...». И это независимо от уровня проекта. А в идеале — да, все верно, все перечисленные техники очень полезны.
Мне показалось, что автор в бОльшей степени имел в виду разработку ПО для корпоративных заказчиков. Там ситуация с целевой аудиторией более определенная.
Продукты, ориентированные на широкого пользователя, требуют чуть-чуть других подходов, и их успешность часто сводится к лотерее «попал, не попал». И если о том, что «не попал» компания-разработчик узнает на стадии бета-тестирования — можно считать, что ей повезло.
Продукты, ориентированные на широкого пользователя, требуют чуть-чуть других подходов, и их успешность часто сводится к лотерее «попал, не попал». И если о том, что «не попал» компания-разработчик узнает на стадии бета-тестирования — можно считать, что ей повезло.
Мне показалось, что автор в бОльшей степени имел в виду разработку ПО для корпоративных заказчиков. Там ситуация с целевой аудиторией более определенная.
Почему, если не секрет? Всегда можно пойти и поговорить с 2000+ офисными работниками заказчика, которые разговаривают на языке предметной области, компьютер понимают как телевизор с одноклассниками, не хотят ничего менять а хотят пива? :) Или, может, с представителем со стороны корпортативного заказчика, для которого компьютер — это тот же телевизор понятно с чем, но ему при этом надо еще бюджет отмыть и в свои офисные игры поиграть? :))
В таком случае, мы имеем представление о должностных обязанностях пользователей. Т.е. мы знаем, что они должны делать. А хотят они это делать или нет, нас не касается.
Я согласен с вашими аргументами относительно овощной природы большинства пользователей, и это говорит о бесполезности опросов и фокус-групп. Автор их не предлагал. Использование Персон подразумевает другой подход.
Мы не спрашиваем у юзеров, чего они хотят — они все хотят большую кнопку «Сделать хорошо!». Мы предполагаем их потребности исходя из их обязанностей. А удобство интерфейса из условий их работы. Эта информация у нас есть.
А бегать вокруг них и спрашивать: «Ну, скажите, пожалуйста, что вам не нравится? Ну, расскажите, чего вы хотите?» — это нарываться на билет в пеший эротический тур. :-)
Кстати, о потребностях и удобстве — помните, многие сильно ругали рибоны, когда они только появились? А сейчас это считается одной из самых удачных находок в области GUI за последнее время. Вот яркий пример того, что юзеры не знают, чего они хотят, пока не привыкнут к этому.
Я согласен с вашими аргументами относительно овощной природы большинства пользователей, и это говорит о бесполезности опросов и фокус-групп. Автор их не предлагал. Использование Персон подразумевает другой подход.
Мы не спрашиваем у юзеров, чего они хотят — они все хотят большую кнопку «Сделать хорошо!». Мы предполагаем их потребности исходя из их обязанностей. А удобство интерфейса из условий их работы. Эта информация у нас есть.
А бегать вокруг них и спрашивать: «Ну, скажите, пожалуйста, что вам не нравится? Ну, расскажите, чего вы хотите?» — это нарываться на билет в пеший эротический тур. :-)
Кстати, о потребностях и удобстве — помните, многие сильно ругали рибоны, когда они только появились? А сейчас это считается одной из самых удачных находок в области GUI за последнее время. Вот яркий пример того, что юзеры не знают, чего они хотят, пока не привыкнут к этому.
В продуктах широкой аудитории к вариативному набору описанных выше техник добавляется следование принципам Lean StartUp, один из которых — измерение.
Как мы узнаем, что проблема над которой мы работаем — существует? Как мы узнаем, что решение, которые мы предлагаем — подходит? Как мы узнаем, что набор реализованной функциональности — удовлетворяет решению? Что меняется в поведении пользователей? Для получения ответов на эти вопросы, очевидно, потребуется дополнительная функциональность (аналитики гугл будет не достаточно).
Метрики имеют особое значение для стартапов, особенно, нацеленных на массовый рынок. Лучший материал на эту тему в 5-ти минутном ролике Dave McClure — Startup Metrics for Pirates. Можно нагуглить более полезный и обширный материал по запросу «AARRR», но в этом видео Дейв просто душечка.
Как мы узнаем, что проблема над которой мы работаем — существует? Как мы узнаем, что решение, которые мы предлагаем — подходит? Как мы узнаем, что набор реализованной функциональности — удовлетворяет решению? Что меняется в поведении пользователей? Для получения ответов на эти вопросы, очевидно, потребуется дополнительная функциональность (аналитики гугл будет не достаточно).
Метрики имеют особое значение для стартапов, особенно, нацеленных на массовый рынок. Лучший материал на эту тему в 5-ти минутном ролике Dave McClure — Startup Metrics for Pirates. Можно нагуглить более полезный и обширный материал по запросу «AARRR», но в этом видео Дейв просто душечка.
если вы что-то разрабатываете и не знаете ЦА — вы что то делаете не так.
Вы пишите «продукт ради продукта», который нужен лишь вам или вашим воображаемым друзьям.
Ваш продукт не решает проблемы пользователя, потому что если бы решал проблему — узнать у тех, у кого это проблема есть: как бы они хотели ее решить или устроит их ваше решение — вообще не сложно.
Если это все же сложно — значит вы решаете надуманную проблему.
Вы пишите «продукт ради продукта», который нужен лишь вам или вашим воображаемым друзьям.
Ваш продукт не решает проблемы пользователя, потому что если бы решал проблему — узнать у тех, у кого это проблема есть: как бы они хотели ее решить или устроит их ваше решение — вообще не сложно.
Если это все же сложно — значит вы решаете надуманную проблему.
«Желание — 1000 возможностей, нежелание — 1000 причин».
“Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
А бизнес и не должен уметь формулировать хорошие требования и разбираться в процессе разработки. Спецификация заказчика содержит представление о решении проблемы, которая была пол года назад, но не будущих проблем. Задача разработчика — угадать процессы, которые будут в будущем у бизнеса.
Простой пример из жизни. Заказчик просит добавить пару форм ввода и отчет. На самом деле это вообще не решает задачу по контролю за происходящим, и нужна интеграция с клиент-банком. ТЗ бизнеса содержит решение текущей задачи, как бы это было логично с их точки зрения. Но это задание ошибочно, и нужно решать его с другой стороны.
“Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации.
Если разработчик не понял задание, но сделал, то это проблема разработчика. Знание предметной области бизнеса — первое требование к разработке.
А бизнес и не должен уметь формулировать хорошие требования
Именно это я хочу донести. Таких примеров с формами ввода и отчетами — масса. Использующийся в проекте формат описания требований часто провоцирует клиентов писать подобные спецификации. Чуть лучше дела обстоят в командах, в которых есть бизнес-аналитики. Однако, даже в этом случае есть риск формализации «решений глазами аналитика». Поэтому, освоение некоторых продуктовых техник и смена подходов работы с требованиями мне кажется важной в проектах заказной разработки.
«Истории Пользователя» хороши для высокоуровневого диалога о функциональности — они содержат контекст, действующее лицо и конечную ценность действия с системой. А для обсуждения вариантов реализации лучше подключать либо всю команду (в случае если это небольшие feature teams), либо разносторонне сбалансированную ее часть (интерактивных дизайнеров, экспертов предметной области и технологических возможностей).
«Гамбургер истории» — несмотря на несерьезное название позволяет избежать довольно серьезных разногласий в том, какой способ реализации минимален и достаточен с точки зрения бизнеса (инвестиций в его исполнение) и разработки (качества, рисков, стоимости поддержки). Такие открытые обсуждения помогают сторонам с часто полярными интересами понять мотивы друг друга, не разрабатывать откровенно слабых решений и не заниматься излишним их «золочением» (Over Processing в терминах Lean TPS)
Истории пользователя, по моему мнению, это то, чем меньше всего нужно забивать голову. Приведу простой пример. Иван Иванович — фермер, решил расширить свой бизнес, путем автоматизации полевых работ. Он закупил два модных трактора, которые умеют рассказывать в режиме реального времени, какие GPS-координаты у техники на данный момент времени. Это натолкнуло Ивана Ивановича на мысль, что нужно бы написать некое ПО, которое сообщало бы о нецелевом использовании оборудования трактористами Вениамином и Илларионом. Давайте спросим у наших доблестных трактористов, какую функциональность нужно заложить в программу, чтобы им было что-то удобнее делать. Они расскажут, что неплохо было бы, чтобы программа травила анекдоты пока они гоняют по полю, дабы им не заснуть. Давайте спросим Ивана Ивановича об аналогичном. Он скажет, что неплохо было бы раз в сутки заходить в программу и видеть, что тракторы гоняли за пределы отведенной траектории. Вот тут начинается полет мысли «архитектора»… В реальности из всего придуманного полезно будет сделать одну вещь из пожеланий — отправка SMS Ивану Ивановичу с координатами трактора, если он выехал от разрешенной области передвижения дальше чем на 10 метров, и еще создать алгоритм оптимизации траектории движения, дабы минимизировать затраты на ГСМ. Первое решение помогает понять, что есть решения получше, чем рисует в голове заказчик, а второе — что он использует микроскоп для забивания гвоздей.
Формат Истории пользователя такой:
Как <Пользователь>, я хочу <Действие с системой>, что бы <Бизнес-ценность>.
Для описанного выше примера история может быть сформулирована так:
Как Владелец Фермы, я хочу получать уведомления о выезде тракторов за пределы фермы, что бы избегать не целевого использования своих активов трактористами.
Можно еще подумать над формулировкой и улучшить ее. Цель Истории — сделать понятным: кто и для чего будет использовать функциональность. Как только мы видим намек на техническое решение посередине <Действие с системой>, начинаем задавать больше вопросов о <Бизнес-ценности>.
Записываем такие бизнес-требования чуть наперед. А детали и способ реализации обсуждаем «точно вовремя» — когда Иван Иванович сказал что готов заплатить за эту функциональность. Хорошо работает в итеративных подходах с приоритезацией требований и доступом к «телу заказчика» для уточнения деталей.
Как <Пользователь>, я хочу <Действие с системой>, что бы <Бизнес-ценность>.
Для описанного выше примера история может быть сформулирована так:
Как Владелец Фермы, я хочу получать уведомления о выезде тракторов за пределы фермы, что бы избегать не целевого использования своих активов трактористами.
Можно еще подумать над формулировкой и улучшить ее. Цель Истории — сделать понятным: кто и для чего будет использовать функциональность. Как только мы видим намек на техническое решение посередине <Действие с системой>, начинаем задавать больше вопросов о <Бизнес-ценности>.
Записываем такие бизнес-требования чуть наперед. А детали и способ реализации обсуждаем «точно вовремя» — когда Иван Иванович сказал что готов заплатить за эту функциональность. Хорошо работает в итеративных подходах с приоритезацией требований и доступом к «телу заказчика» для уточнения деталей.
А теперь представьте, что случится с разработчиком и фермером, когда они узнают, что трактор все это умеет «из коробки»? Ему задаются координаты полигона, выезд за пределы которого приводит к выключению двигателя и уведомлению о нештатной ситуации? :)
Давайте теперь составим Историю с другой стороны
Как тракторист шайтан-машины, я хочу иметь функцию выключения GPS приемника, чтобы иметь возможность заработать денег.
Самое смешное, что фермеру не нужно ПО по уведомлению о нецелевом использовании техники. Эту проблему можно решить административным путем, а не программой. Программа гипотетически может сократить расходы, на практике все будет прозаичнее — про нее забудут через пол года.
Давайте теперь составим Историю с другой стороны
Как тракторист шайтан-машины, я хочу иметь функцию выключения GPS приемника, чтобы иметь возможность заработать денег.
Самое смешное, что фермеру не нужно ПО по уведомлению о нецелевом использовании техники. Эту проблему можно решить административным путем, а не программой. Программа гипотетически может сократить расходы, на практике все будет прозаичнее — про нее забудут через пол года.
Давайте теперь составим Историю с другой стороны
Так мы систему для кого разрабатываем? Конфликтующие требования вижу я :)
Для поиска альтернативных (не требующих разработки) решений — отлично «Impact mapping» подходит. В ментальной карте будет ветка целей («Уменьшить кражи»), под ней — две Персоны, которые помогут добиться этой цели («Фермер» и «Сторож»), под ними — будут действия Персон («Уведомление» для Фермера и «Ружье с солью» для Сторожа). На мозговом штурме — фермер решит, стоит ли идти по первой ветке или Петра Петровича с ружбайкой будет достаточно.
Я бы задал вопрос, а нужна ли система вообще? Нужно ли уменьшать кражи? Понимаете какая фигня, бизнес зачастую готов нести определенные потери, только бы не увеличивать мнимый «порядок» в процессах, и, соответственно, расходы на поддержания этого псевдопорядка. Если вы скажете, что ваша программа сэкономит целых 10 000, то вам могут рассмеяться в лицо, потому что на фоне миллионных заработков это чуть меньше чем пшик.
> Если разработчик не понял задание, но сделал, то это проблема разработчика. Знание предметной области бизнеса — первое требование к разработке.
На нашем примере это не прокатит. В банке даже сами пользователи не знают всей предметной области, что уж говорить о программистах? Тут уже либо программируй, либо разбирайся в предметке, и предметкой занимаются бизнес-аналитики. А разработчики знакомятся с предметкой по ходу проекта, и то, кто с чем работал.
Разработчик тут максимум что может сделать — это поставить под вопрос какие-то части задания, которые кажутся нелогичными в купе с предыдущими заданиями.
На нашем примере это не прокатит. В банке даже сами пользователи не знают всей предметной области, что уж говорить о программистах? Тут уже либо программируй, либо разбирайся в предметке, и предметкой занимаются бизнес-аналитики. А разработчики знакомятся с предметкой по ходу проекта, и то, кто с чем работал.
Разработчик тут максимум что может сделать — это поставить под вопрос какие-то части задания, которые кажутся нелогичными в купе с предыдущими заданиями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
7 Продуктовых техник, на которые стоит обратить внимание разработчику