Как мы знаем, создать хороший продукт нелегко. Менеджеров, дизайнеров, проектировщиков, разработчиков, тестировщиков подстерегает множество проблем. Какие-то видны сразу, а на другие команде предстоит наткнуться лбом. И невозможно заранее предсказать, во что обойдется их устранение.
Многие молодые команды годами идут к оптимальному решению, оттачивая свое творение шаг за шагом, итерацию за итерацией. Они обходят проблемы, гибко адаптируются к изменению среды, компенсируют технические сложности. И этот метод работает — на выходе может получиться отличное решение. Но это долго, а значит дорого.
Можно пойти другим путем — аналитические методы позволяют быстро прийти к хорошему результату, избежав сложностей. Вот только найти людей, знакомых с этими методами и способных грамотно применить их на практике, крайне сложно. Сманить в свою команду еще сложнее.
Итак, получение оптимального решения — этого дорого и долго. Между тем, социальные сети и новостные сайты пестрят историями об ошибках при проектировании и их последствиях. Еще на слуху история сервиса «Кинопоиск», миллионы пользователей подписывают петиции на имя руководства Snapchat, по отзывам в сервисе обратной связи Microsoft можно учиться красноречию. Даже известные компании с огромными дизайнерскими командами ошибаются. И иногда продукт бывает проще закрыть, чем исправить все недочеты.
Смотря на такие новости, можно подумать: «Неужели такие крутые дизайнеры ошиблись? Почему люди так сильно недовольны? Они что, специально над пользователями издеваются? Брейнштормят, стикеры клеят?». И тут же в голову приходит мысль: «Нет, конечно нет! Никто не станет проводить мозговой штурм и придумывать, как досадить пользователям…».
А следующая мысль — «Это же идея!!!».
В самом деле, как небольшому стартапу поскорее выйти на рынок и, главное, остаться на нем? Как компании-аутсорсеру быстро реализовать приложение или сайт клиента при ограниченном бюджете?
Иногда кажется, что хороший продукт в таких условиях создать нельзя. А раз хороший продукт создать нельзя, давайте создадим … заведомо плохой!
Мы хорошо знаем наших пользователей. Давайте выделим их потребности и слабости, подберем наихудшие условия работы, сделаем все, чтобы пользоваться продуктом было очень сложно и крайне неприятно.
А потом — одумаемся, ведь мы в коммерческой разработке. У нас в руках список самых серьезных проблем, которые мы только можем создать для наших пользователей. Инвертируем его — получим список мер противодействия или свойств, которыми наш продукт точно не должен обладать. Из списка самых серьезных проблем мы получим ключ к созданию успешного решения. И сделаем это очень быстро.
Назначение
Метод «Problem Engineering» или «Целенаправленное создание проблем» предназначен для быстрого выявление критических проблем будущего продукта и поиска мер по их предотвращению.
Этот метод позволяет на самых первых шагах работы над продуктом выделить наиболее серьезные сложности и перейти к созданию прототипа. Конечно, это будет сырой набросок. Он требует серьезной доводки, но уже свободен от самых больших проблем, годится для тестирования и служит отличным поводом для конструктивного диалога с заказчиком.
Метод — рабочий алгоритм
Работа по методу Problem Engineering включает несколько простых шагов:
- Вводные данные — фиксация назначения будущего продукта, обзор условий применения, целевой аудитории, известных ограничений;
- Мозговой штурм — генерация идей или поиск проблем, которые сделают продукт неприменимым на практике или превратят работу с ним во что-то совершенно неприятное;
- Отбор наиболее выдающихся идей — упорядочивание идей по степени воздействия на будущий продукт, отбор 10–20 наиболее серьезных проблем;
- Инверсия — преобразование проблем в меры по их предотвращению. Из списка идей, каждая из которых может «закопать» продукт, получает список характеристик, которыми продукт точно не должен обладать, или конкретные технические решения по предотвращению этих сложностей;
- Прототипирование — получив список свойств, которых нужно избежать, можно переходить к созданию прототипа. Он будет сырой, но о нем уже можно беседовать с заказчиком.
Перечисленные шаги удобно совместить в «сессии» или «воркшопе» — совместной работе команды, возможно, с привлечением внешних экспертов, консультантов или кого-то со стороны заказчика.
Формат воркшопа
Можно предложить следующих формат воркшопа:
- Вводные данные, первоначальная подготовка — для подготовленной команды, знакомой с предметной областью, может вполне хватить 10 минут. Для команды, впервые приступающей к работе над подобным приложением/сервисом будет уместным заранее посвятить время обзору предметной области и аналогичных решений, с тем, чтобы приступать к последующим шагам уже кое-что зная;
- Мозговой штурм — 20 минут;
- Обработка и отбор зафиксированных в ходе мозгового штурма идей — 10 минут;
- Инверсия, поиск путей предотвращения проблем — 10–20 минут;
- Прототипирование — 20 минут.
Общая длительность воркшопа составляет 1.5–2 часа. От концепции продукта до прототипа.
Комментарии к шагам метода
Несколько слов о шагах метода. Во-первых, команда должна быть подготовлена к работе. Чтобы процесс шел динамично, и команда не «застревала» на однотипных идеях нужна определенная предварительная работа. Команду стоит заранее ознакомить с методикой «Problem Engineering».
Хорошо, если команда знакома с правилами проведения мозгового штурма. Тут сразу стоит отметить, что периодически проводить мозговой штурм на одну и ту же тему с одной командой не рекомендуется. Восприятие участников «забивается» ранее высказанными идеями, работа становится непродуктивной. Если сессию «Problem Engineering» хочется повторить менее чем через 1–2 месяца после предыдущей, стоит набрать новый состав участников.
В процессе мозгового штурма важно следить за регламентом и динамикой работы. В противном случае команда может «застрять» на одной идее или вообще не сможет включиться в работу. Тут будет полезен модератор мозгового штурма, который сам не будет принимать участия в генерации идей, но будет следить за процессом и «подталкивать» команду, когда она остановится.
В ходе мозгового штурма высказываемые идеи должны тщательно фиксироваться, но не должны обсуждаться и, тем более, критиковаться. Для этого есть следующие шаги сессии.
В качестве помощи для генерации идей можно использоваться некоторое основание классификации, подсказывающее участникам пути создания проблем для будущих пользователей. Например, классификацию на основе определения «usability» — проблемы в контексте применения, целях применения, в выборе целевой аудитории, возможности достижения результата, затратах ресурсов на использование продукта или субъективной удовлетворенности пользователей. Главное — сохранять неизменным назначение продукта, в противном случае полученные результаты могут быть очень далеки от практики (хотя, возможно, станут отправной точкой для создания совершенно нового продукта, что тоже неплохо).
Инверсия или поиск путей предотвращения проблем хорошо работает, если проблемы не только упорядочить по степени влияния на продукт, но и разделить на три категории:
- Проблему можно предотвратить — для таких проблем можно подбирать меры по полному исключению их влияния на будущее решение;
- Проблему нельзя предотвратить — подбираются меры по компенсации эффекта от соответствующей проблемы;
- О проблеме известно, но предотвратить или компенсировать ее нельзя — ищутся способы своевременного информирования пользователя о проблеме.
Отобрав «Top–10» или «Top–20» наиболее критичных проблем, будет несложно перейти к их делению на категории и выработке контрмер.
Что касается прототипирования — тут могут использоваться любые доступные участникам меры и методы. Это может быть бумажный прототип пользовательского интерфейса, схема бизнес-процесса, быстро сверстанная web-страница. Что угодно, позволяющее быстро продемонстрировать подход к построению продукта.
Первоисточники и аналоги
Разумеется, метод «Problem Engineering» появился не на пустом месте. Его можно считать результатом междисциплинарного синтеза рабочих методов, давно используемых в смежных с IT областях.
Отправной точкой для авторов стали множественные «посты» в социальных сетях, буквально заваливающие критикой популярные сайты и сервисы. Именно такие «посты» и комментарии к ним навели на мысль о «команде, ведущей мозговой штурм, чтобы досадить пользователям».
Метод доказательства «от противного» на протяжении столетий используется в математике. Этот метод отлично зарекомендовал себя, но по какой-то неизвестной причине в других областях применяется мало или не применяется вообще.
Метод мозгового штурма многократно описан в литературе по системному анализу, проектированию, построению командной работы, психологии и стимуляции творческой деятельности. Правда, обычно он используется для генерации «положительных» идей, а не «отрицательных».
Метод инверсии заимствован из машиностроительного проектирования. В частности, в книге П.И. Орлова «Основы конструирования» (Москва, издательство «Машиностроение», 1977) описывается инверсия узлов и агрегатов для улучшения их характеристик.
Алан Дикс (Alan Dix) в своих статьях (например, “Why bad ideas are a good idea”, Alan Dix et al, Proceedings of HCIEd.2006-1 inventivity, Ballina/Killaloe, Ireland. 23-24 March 2006) описывает метод «Плохих идей» (BadIdeas). Этот метод, направленный на стимуляцию творческого мышления и расширение кругозора команды, также использует «плохую» или «глупую» идею в качестве отправной точки. Однако, целью применения данного метода является, в большей степени, анализ продукта и поиск путей его развития, чем получение конкретного технического решения. Метод «Problem Engineering» является в этом плане гораздо более практическим.
Артемий Лебедев упоминает о приеме «от обратно» в своем «Ководстве» (§150, 2008). Однако, автор пишет о таком способе работы на уровне общей идеи, не рассматривая конкретных деталей алгоритма принятия решения.
Классификация сгенерированных проблем по возможности их предотвращения заимствована из выступления Эрика Райса (Eric Reiss) на конференции ПрофсоUX (Санкт-Петербург, 2017).
Коллеги, ознакомившиеся с первыми заметками о «Problem Engineering» также отметили сходство метода с такими методами, как «Шесть шляп» де Боно и SWOT-анализ. Действительно, сходства есть. Правда, «критической шляпе» в методе де Боно предписано критиковать решение, но не генерировать заведомо провальные идеи. А вот SWOT-анализ может быть полезен для более глубокого анализа сгенерированных идей. Например, для разделения их на «внутренние» (связанные с самим продуктом) и «внешние» (вызванные внешними факторами).
То есть, можно смело сказать, что каждый из шагов «Problem Engineering» по-отдельности известен уже давно. Авторам оставалось соединить их вместе, выстроить в определенном порядке и применить в сфере IT.
Опыт применения
Разумеется, любой метод проектирования необходимо опробовать на практике. Авторы провели ряд пробных воркшопов, в ходе которых проверили на практике метод и некоторые его вариации. В воркшопов, а также по результатам общения с их участниками (огромное спасибо всем за ваши отзывы!) были отмечены следующие моменты:
- Крайне важно удерживать фокус команды на решении заданной проблемы, на работе над заданным продуктом с заданным назначением. В противном случае генерируемые идеи получаются слишком обобщенными, применить их на практике будет сложно. Для поддержания фокусировки полезно привлечь модератора, который будет направлять работу команды. Также помогает ограничение времени работы и строгое следование регламенту;
- Большую роль играет наличие в команде компетенции в рассматриваемой области. В команду нужно включить технических экспертов, опытных пользователей аналогичных продуктов или, например, ярких представителей целевой аудитории. В противном случае команда будет руководствоваться только общими соображениями и не сможет прийти к новому решению или выделить ранее незамеченные проблемы;
- Необходимо избегать инверсии существующих решений. Если команда в ходе мозгового штурма оттолкнется от существующего решения, есть риск, что генерируемые проблемы будут зеркальным отражением существующего работоспособного варианта. В этом случае инверсия идей/проблем вернет команду в исходную точку и не принесет новых знаний. Модератор должен контролировать ситуацию и не давать команде инвертировать существующие продукты;
- Было замечено, что применение метода «Problem Engineering» может принести команде новый взгляд на существующий продукт, «освежить» мнение о том, над чем команда уже давно работает. Это полезно, так как за долгое время команда привыкает к своему «детищу» и перестает воспринимать его объективно;
- Результатом применения метода «Problem Engineering» вполне может стать новое направление развития продукта;
- Полезно, что в ходе воркшопа проблемы фиксируются в ранге проблем — участники называют вещи своими именами. Это упрощает последующую работу. Ведь если команда назвала какое-то свойство продукта проблемой, то в будущем вряд ли кто-то станет настаивать на его реализации;
- Совместная работа, мозговой штурм, прототипирование настраивают команду на «общую волну», помогают всем участникам получить общее представление о будущем продукте. Если в воркшопе участвует кто-то со стороны заказчика, это позволит быстро синхронизировать понимание, ускорить и упростить дальнейшее взаимодействие;
- Командам интересно и приятно получать обратную связь относительно полученных решений. Это может быть отзыв заказчика, мнение соседней команды (если в воркшопе параллельно участвуют несколько групп), рассказ ведущего воркшопа или эксперта;
- Подобная активность настраивает людей на позитивный лад и поднимает настроение, что само по себе очень ценно! Подобный эффект отметили и авторы метода «BadIdeas».
Возможным направлением применения метода может стать аналитика и быстрое прототипирование с участием фокус-группы. Несколько экспертов или преставителей целевой аудитории могут участвовать в мозговом штурме, генерируя проблемы и «узкие места» будущего продукта.
Так как участники фокус-группы могут не быть разработчиками и не обязаны обладать компетенцией в области проектирования или реализации продукта, шаги инверсии и прототипирования нужно использовать осторожно, тщательно анализируя предложения. В некоторых случаях эти шаги можно просто пропустить.
Однако, выполнив эти шаги, можно получит интересные идеи, основанные на опыте участников группы.
Когда не нужно применять метод «Problem Engineering»
У любого метода есть область применения, за пределами которой он не приносит пользы, а при неправильном применении может принести вред. Есть подобные ограничения и у метода «Problem Engineering».
Прежде всего, не стоит применять данный метод при отсутствии у команды экспертизы в предметной области. Команда не сможет генерировать идеи, которые бы можно было инвертировать в применимые на практике решения.
При отсутствии данных о назначении продукта (например, если команда только выбирает, какой продукт она хочет создать) метод позволит выполнить обзор предметной области, но вряд ли не позволит прийти к решению. Тут он будет близок к методу «BadIdeas», который в такой ситуации работает эффективнее.
Также проблемой может стать отсутствие у команды готовности следовать регламенту. Последовательность шагов и точная фокусировка на решаемой задаче — важные аспекты метода.
Когда стоит применять метод
Метод «Problem Engineering» будет полезен и эффективен, если:
- В команде присутствуют эксперты предметной области, такие эксперты или, например, представители целевой аудитории могут быть приглашены к участию в воркшопе;
- Команда приступает к созданию нового продукта и хочет в минимальные сроки получить решение, пусть сырое, но уже пригодное для тестирования;
- Есть желание получить единое для всей команды и, возможно, заказчиков понимание назначения и целей создания продукта;
- Команде необходимо «освежить взгляд» на давно разрабатываемый и, следовательно, отлично знакомый продукт;
- Присутствует участник, готовый взять на себя обязанности модератора, следить за процессом, помогать команде двигаться в нужную сторону в достаточно высоком темпе.
Как обеспечить эффективное применение,
«Problem Engineering Canvas»
Выше уже было сказано, что для успешного применения метода необходимо обеспечить присутствие в команде специалистов по предметной области и добиться максимальной фокусировки команды на решаемой задаче.
Для повышения концентрации можно использовать специальный шаблон или «канвас», включающий краткую инструкцию по применению метода и поля, заполняя которые, можно продвигаться к цели.
Ссылку на пример такого «канваса» можно найти ниже. На его первом листе находится описание алгоритма работы и поля для записи 1–4 метрик, по которым можно судить о том, достигли ли предложенные проблемы цели — стал ли продукт хуже.
На втором листе находятся поля, в которых можно фиксировать проблемы, группируя их по областям. Что помешает применить продукт для достижения заданной цели? Какие проблемы могут скрываться в окружающей среде? Какие сюрпризы готовят «неподходящие» пользователи? Как помешать пользователям достигнуть результата? Как повысить затраты сил и ресурсов? Как сделать работу с продуктом ну очень неприятной?
В центре второго листа находится поле для краткого описания назначения продукта. Важно! Его изменять нельзя! Продукт должен соответствовать изначальному назначению и решать поставленные перед ним задачи. Предлагаемые проблемы должны мешать пользователям, но продукт должен быть по-прежнему пригоден для применения по назначению.
На третьем листе находятся поля, в которые можно внести наиболее серьезные из предложенных проблем и соответствующие им меры противодействия.
Вы можете загрузить готовый «Problem Engineering Canvas», распечатать его и немедленно применить в работе. Выберите подходящий для вас вариант:
- «Версия 1 Lite» — вариант с упрощенным набором направлений для создания проблем пользователям. Подойдет для первых проб метода.
Вы можете загрузить файл (v. 1.1E, PDF, 74 кБ);
- «Версия 1» — вариант с полным набором направлений для создания проблем.
Вы можете загрузить файл (v. 1.1, PDF, 74 кБ).
Bonus track
Если вы используете метод «Problem Engineering», и кто-то скажет: «Вы издеваетесь над пользователями», в ответ можно честно сказать: «Да» ;)
Авторы
Метод разработали:
- Юрий Солоницын
() — концепция метода и алгоритм работы, экспериментальные воркшопы для проверки метода, сбор обратной связи, Problem Engineering Canvas;
- Сергей Кривой
() — практическая отработка метода, модификации алгоритмов, отработка процедуры проведения воркшопов и способов повышения концентрации команды.
Спасибо всем, кто внес свой вклад!
Спасибо вам за отзывы и советы: Эрик Райс, Анна Карпушина, Кирилл Улитин, Тамара Кулинкович, Анатолий Буров, Алексей Федоров, Любовь Фомичева, Саша Позднякова, Алан Дикс, Иван Серебренников и многие другие!
Попробовали метод на практике? Расскажите, нам интересно!
Авторы с благодарностью выслушают ваш рассказ. Отзывы и впечатления помогут дальше совершенствовать метод «Problem Engineering». Напишите нам!
Санкт-Петербург
21.04.2018, 10.04.2018, 05.11.2021
