Менеджер по продукту Скотт Селхорст опубликовано в своем блоге появилась заметка, в которой он призвал разработчиков оперировать концепцией Minimal Valuable Issue (минимального решения проблемы) вместо привычного Minimal Viable Product (минимально жизнеспособного продукта).
Редакция vc.ru публикует перевод заметки Селхорста.
Определить и создать хороший минимально жизнеспособный продукт гораздо сложнее, чем может показаться на первый взгляд. Задача не ограничивается поиском и изготовлением той самой «Вещи», которая нужна людям.
Он включает в себя не только поиск минимального решения проблемы, но и все, что его сопровождает. Важно действовать в обоих направлениях: «изнутри наружу» и «снаружи внутрь».
Верхушка айсберга
Рич Миронов в его статье Иллюзия своими руками рассказывает о том, как важно сосредоточиться на своих основных компетенциях, а не изобретать велосипед. Представьте, что ваша команда работает над мобильным приложением.И вдруг, когда дело доходит до создания CRM для отслеживания ваших пользователей, вы начинаете создавать CRM с нуля.
Или вы сами разрабатываете систему заявок, чтобы управлять процессом разработки функций и исправления ошибок.
Рич в своей статье рассказывает о микроверсии классической модели государственно-частного партнерства (BBO – строй, покупай, партнер).
Эта версия идеально подходит, когда ваша команда определяет свои потребности в DevOps или другой инфраструктуре.
Если мы перейдем на более широкий организационный уровень, мы получим классическую версию MBA, и теперь нам нужно решить, создаем ли мы новый продукт, дополняющий наше портфолио? Или мы сотрудничаем с кем-то, чтобы использовать его продукт? А может быть, дело в том, чтобы приобрести нового партнера (или нам просто нужен продукт)? Все эти вопросы отражают подход «изнутри наружу».
Но что, если при обдумывании будущего продукта вы примените подход «снаружи внутрь»? В конце концов, ваши пользователи также принимают решения о создании, покупке и партнерстве вашего продукта.
Богатый своим статья затрагивает важный момент: работа, которую вам предстоит проделать (что бы вы под этим ни подразумевали), содержит в себе гораздо больше, чем можно понять при поверхностном анализе.
То же самое справедливо и для определения минимально жизнеспособного продукта.
Вашим пользователям нужны решения большего количества проблем, чем та, на которой вы сосредоточились.
Минимальное решение проблемы
Я собираюсь провести эксперимент со своей командой: в течение следующих нескольких недель мы будем обсуждать только минимальные решения проблем (вместо минимально жизнеспособных продуктов).Надеюсь, это поможет изменить мышление моих коллег.
Впервые я использовал этот термин вчера, во время переговоров с руководством.
Хотел уточнить, что наш продукт нацелен именно на минимальное решение проблемы, но не получил ни одного комментария по этому поводу, кроме нескольких одобрительных кивков.
Я помню цитату Саидвахан что минимально жизнеспособный продукт — это буквально «наименьшее, что вы можете сделать».
Я полностью с этим согласен и мне очень нравится эта цитата.
Возможно, некоторые из вас даже знают, кто ее первоначальный автор.
Почему я подчеркиваю разницу между продуктом и проблемой? Для этого есть две причины.
Один из них философский, другой чисто практический.
Философский взгляд
Одна из вещей, которую команды разработчиков получают от меня, — это мой «свежий взгляд» (точнее, взгляд со стороны) на то, что они делают или планируют делать.Я помогаю команде двигаться с позиции» изнутри наружу "на позицию" снаружи другими словами – исходя из потребностей рынка.
В контексте продукта это обычно означает отслеживание проблем, которые пытается решить определенная группа пользователей.
Именно введение термина «проблема» помогает мне при общении с командой постепенно смещать фокус их обсуждений.
И чем больше я работаю, тем больше в этом убеждаюсь.
Я работаю с командами на самых ранних этапах разработки, и когда разработчики обсуждают будущий продукт, они часто рассказывают о том, что они делают или планируют делать.
Но для меня эти разговоры не имеют никакой ценности, поскольку их не касается то, насколько этот продукт будет отвечать потребностям рынка.
Гораздо полезнее поговорить о проблеме, которую мы пытаемся решить.
Обсуждать, для чего люди будут использовать будущий продукт, гораздо ценнее, чем говорить о том, как он будет работать и сколько нам это будет стоить.
Практическая польза
Огромную проблему коммуникации блестяще иллюстрирует зарисовка Джеффа Паттона из его книги.Сопоставление пользовательских историй .
На собственном опыте я усвоил, что когда люди обсуждают «продукт», разговор протекает очень легко: все с удовольствием используют это слово, но никто не уточняет, что именно оно означает. Когда люди говорят о проблеме, они подразумевают под «продуктом» средство ее решения.
В такой дискуссии проблема присутствует постоянно: ее постоянно упоминают, определяют или хотя бы упоминают, не испытывая при этом никакого дискомфорта.
Я не знаю, почему это происходит, но это факт. Возможно, среди моих читателей найдется когнитивный психолог, который захочет объяснить эту разницу.
Что можно считать решением проблемы?
При работе над собственным продуктом (джиу-джитсу) я опирался на подход Гойко Аджика, описанный в его книге.Этот подход помог мне быстро определить, что будет означать для моего пользователя решение его (или ее) проблемы.
На самом деле метод Гойко не единственный, который позволяет это сделать, он мне просто понравился.
Ориентируясь на результат, вы понимаете, что иногда решения исходной проблемы может быть недостаточно.
Возможно, ваш минимально жизнеспособный продукт решит только половину проблем пользователя.
Получается, что вы создали только половину продукта.
Конечно, бывают случаи, когда такое частичное решение вполне приемлемо (в разбивке пользовательских историй, в инкрементном подходе и так далее).
Но это скорее исключение, чем правило.
Скажите честно, как часто вы покупаете половину решения проблемы, с которой столкнулись? Вы просите механика починить один из перегоревших стоп-сигналов и оставить другой для следующего визита, через месяц? Таким образом, определение минимального решения проблемы — это определение минимально жизнеспособного продукта.
Минимальное решение проблемы — это когда вы можете полностью решить проблему, даже если она находится в очень узком контексте, для небольшой группы пользователей или в каком-то ограниченном сегменте вашего рынка.
Вы можете найти решение, которое не будет лучшим или никогда не будет по-настоящему конкурентоспособным.
Но вы точно решили эту проблему для конкретного пользователя, в конкретной ситуации.
Помните: вы увеличиваете свой доход, обслуживая одного пользователя за раз.
Да, звучит банально, но работает отлично.
Допустим, один и тот же клиент выбирает одного из нескольких поставщиков.
Как вы думаете, кого он выберет:
- средний продавец, который такой же средний для других пользователей
- или идеальный продавец лично для него, даже если он не идеален для других пользователей?
Проблемное пространство пользователя
На диаграмме выше показано, как на самом деле выглядит экосистема, связанная с конкретным продуктом (я заштриховал метки, потому что это пример из реальной жизни).
В левом верхнем углу указана проблема, которую необходимо решить – кандидат на минимальное решение задачи.
Красные линии обозначают потребности: для решения своей проблемы пользователю нужна помощь другого пользователя.
Соответственно этому «другому» приходится участвовать в решении проблемы первого пользователя.
Между ними даже может быть какая-то оперативная связь (например, «контролировать решение задачи первой группой пользователей, чтобы мы могли подкорректировать свое решение»).
Вы видите это на каждой встрече, когда обсуждаете сервисные работы или многокомпонентные продукты.
Рисуя такую экосистему, мы можем обнаружить множество аспектов, связанных с адекватное решение проблема пользователя.
На рисунке ниже разными цветами обозначены пользователи, которые так или иначе участвуют в решении проблемы фокусировки для пользователя фокуса.
Эта сеть взаимозависимых проблем является скрытой (подводной) частью нашего айсберга.
Схема лука , созданный для той же проблемы, дает понять (даже в этой отредактированной версии), что существует три системы (или три системных интерфейса), через которые разные пользователи прямо или косвенно используют наш продукт для решения своих задач.
Преодолеть пробелы в процессах
Представление о пространстве проблем, описанное выше, помогает нам убедиться, что мы действительно ищем минимальное решение проблемы (что для меня звучит лучше, чем «создать жизнеспособный продукт»).Такой подход позволяет преодолеть разрыв между абстрактным мышлением продуктовой команды, конкретным мышлением инженеров-разработчиков и идеями менеджеров проектов, которые тоже хотят понять, что в конечном итоге здесь происходит.
-
Как Мгновенно Вернуть Утерянные Документы?
19 Oct, 24 -
Яндекс.фотографии Для Picasa
19 Oct, 24 -
Поговорим Об Интервью?
19 Oct, 24 -
С Днем Рождения, Твиттер!
19 Oct, 24 -
25 Приложений Для Iphone
19 Oct, 24
