Comments 26
Александр, поясни, пожалуйста, что такое Pet Feature.
Спасибо за вопрос. Зря я не пояснил этот термин сразу. Исправляюсь в комментарии :)
Первый раз я увидел описание Pet Feature в книге Impact Mapping: Making a big impact with software products and projects.
Pet — домашнее животное или любимец. Здесь работает прямой перевод.
Представим ситутацию, когда заказчик хочет на сайте падающий снег. Ну хочет и всё. Влюбился он в падающий снег, увидел его у конкурентов и думает о нем постоянно. Приходит к разработчикам, ставит падающий снег в беклог. Ему резонно намекают, что надо был платежные системы прикрутить сначала, но заказчик хочет падающий снег. Это и есть Pet Feature.
В этой ситуации мы показываем, что ни на одну ветку Impact Mapping падающий снег не цепляется. Что падающий снег не приблизит продукт к цели. Если после всех объяснений заказчик всё еще хочет падающий снег и он осознает, что это будут деньги на ветер, то только после этого мы делаем ему красивые падающие снежинки.
Аналогично Pet Feature идут со стороны команды. Давайте перейдем на новую версию MongoDB! Или давайте прикрутим Azure, чтобы всё само и быстро и весело. Команда вынашивает свои Pet Feature. Рецепт отсева не меняется — идет в Impact Mapping и смотрим как и на какую цель влияет.
Если еще остались вопросы, буду рад ответить.
Первый раз я увидел описание Pet Feature в книге Impact Mapping: Making a big impact with software products and projects.
Pet — домашнее животное или любимец. Здесь работает прямой перевод.
Представим ситутацию, когда заказчик хочет на сайте падающий снег. Ну хочет и всё. Влюбился он в падающий снег, увидел его у конкурентов и думает о нем постоянно. Приходит к разработчикам, ставит падающий снег в беклог. Ему резонно намекают, что надо был платежные системы прикрутить сначала, но заказчик хочет падающий снег. Это и есть Pet Feature.
В этой ситуации мы показываем, что ни на одну ветку Impact Mapping падающий снег не цепляется. Что падающий снег не приблизит продукт к цели. Если после всех объяснений заказчик всё еще хочет падающий снег и он осознает, что это будут деньги на ветер, то только после этого мы делаем ему красивые падающие снежинки.
Аналогично Pet Feature идут со стороны команды. Давайте перейдем на новую версию MongoDB! Или давайте прикрутим Azure, чтобы всё само и быстро и весело. Команда вынашивает свои Pet Feature. Рецепт отсева не меняется — идет в Impact Mapping и смотрим как и на какую цель влияет.
Если еще остались вопросы, буду рад ответить.
> Зря вы взяли помидоры Шеди Леди для рагу из кролика.
> Почему вы благодарны кассиру и хотите его обнять?
Если бы мне продавец на кассе такое сказал, я бы послал его куда подальше. И дело не в том, что продавец возможно будет разбираться в продуктах «лучше» меня, просто я не считаю, что он там со своей кассы за 10 секунд поймет все мои вкусовые предпочтения.
Поэтому пример абсолютно не корректен. Конечно, в случае IT всё было бы по-другому, а в частности, специалист сначала долго вникал бы в проблему, копал бы её, узнал реальные потребности и через пару недель выдал: вам нужен не это решение. а вот это!
> Почему вы благодарны кассиру и хотите его обнять?
Если бы мне продавец на кассе такое сказал, я бы послал его куда подальше. И дело не в том, что продавец возможно будет разбираться в продуктах «лучше» меня, просто я не считаю, что он там со своей кассы за 10 секунд поймет все мои вкусовые предпочтения.
Поэтому пример абсолютно не корректен. Конечно, в случае IT всё было бы по-другому, а в частности, специалист сначала долго вникал бы в проблему, копал бы её, узнал реальные потребности и через пару недель выдал: вам нужен не это решение. а вот это!
Пример корректен. Просто вы привыкли реагировать агрессивно. Не более того.
Всё остальное это «объяснялики» самому себе, почему я агрессивен. И да, к реальности они не имеют никакого отношения. Честно честно! :)
Всё остальное это «объяснялики» самому себе, почему я агрессивен. И да, к реальности они не имеют никакого отношения. Честно честно! :)
Пример действительно не очень. Допустим, кассир прав. При этом половина моих товаров пробита, в очереди на кассу, в этом узком коридорчике, за мной стоит ещё два человека, среди которых женщина с коляской и ребёнком в ней. Конечно же я не пойду ни за какими другими помидорами, а почувствую себя сбитым с толку. Для чего кассир сказал мне об этом? Что мне теперь с этим делать? Это скорее завязка сюжета для короткометражного триллера по Кафке.
Просто многие клиенты не хотят особо заботиться и вникать, они любят взять и «накидать в корзину фич», а потом на кассе оплатить. Понимание того, что софт это решение конкретной проблемы с необходимостью осознания, как проблемы так и пути решения, приходит не всегда и не всем.
Обычно, желание «не вникать» заканчивается печально. Сначала клиент вбухивает деньги в реализацию своих хотелок, а потом оказывается что софт не решает проблемы и не генерирует прибыль, как итог — «плохие программисты». Компания, которое сделала такой софт либо задумывается и меняет подход к клиентам, либо продолжает продавать код.
Клиент, может, и прав, но он всегда профан. Если бы он был профи, то не пришел бы, а решил проблему сам.
Обычно, желание «не вникать» заканчивается печально. Сначала клиент вбухивает деньги в реализацию своих хотелок, а потом оказывается что софт не решает проблемы и не генерирует прибыль, как итог — «плохие программисты». Компания, которое сделала такой софт либо задумывается и меняет подход к клиентам, либо продолжает продавать код.
Клиент, может, и прав, но он всегда профан. Если бы он был профи, то не пришел бы, а решил проблему сам.
Очень и очень хорошая статья, буду перечитывать еще несколько раз, пока не пойму до конца
Александр, поясни, пожалуйста, что такое Pet Feature.
Присоединяюсь. По ощущениям напоминает что-то вроде «моя собачка/кошка/мышка хочет вот так, сделайте вот так», но хотелось бы знать наверняка, что вы имеете в виду
Александр, поясни, пожалуйста, что такое Pet Feature.
Присоединяюсь. По ощущениям напоминает что-то вроде «моя собачка/кошка/мышка хочет вот так, сделайте вот так», но хотелось бы знать наверняка, что вы имеете в виду
В целом полезная статья.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
Хаха, в истории про баланс ваше собственное решение — кнопочное.
Вы посчитали, что правильное решение — останавливать трату денег при отрицательном балансе, посчитав, что требование отчёта — нецелесообразное.
На самом деле, проблема вовсе не в том, что баланс начинает уходить в минус. Она возникает значительно раньше: когда со счёта начинают списываться деньги непонятно за что. Клиент совершенно законно хочет узнать, что вообще происходит со счётом, с помощью отчёта. А вы предлагаете лечить симптомы вместо лечения проблемы.
Вы посчитали, что правильное решение — останавливать трату денег при отрицательном балансе, посчитав, что требование отчёта — нецелесообразное.
На самом деле, проблема вовсе не в том, что баланс начинает уходить в минус. Она возникает значительно раньше: когда со счёта начинают списываться деньги непонятно за что. Клиент совершенно законно хочет узнать, что вообще происходит со счётом, с помощью отчёта. А вы предлагаете лечить симптомы вместо лечения проблемы.
Останавливать траты — Это лишь один из выходов ситуации.
А если продолжать копать-копать-копать то можно докопаться до чего угодно. К примеру этот же самый отчет — представим, что деньги утекают, но нужен не просто отчет, а нужна система которая определит КТО тратит и Куда тратит. Но это тоже можно считать кнопочный решением, ведь если копать глубже, то руководителю на самом деле нужно принять решение — и система может сделать это за него — к примеру оштрафовать сотрудника. Копаем дальше и оказывается, что это тоже кнопочное решение, ведь всё что надо организации-Это зарабатывать максимальную прибыль, и нужна программа, которая сама анализировала бы тренды, строила прогнозы, делала заказы, начинала и останавливала продажи, вела бухгалтерию итд итп. Я повторюсь, что копать можно бесконечно долго и глубоко, и я с этим не согласен с автором (надеюсь, свою точку зрения я высказал максимально аргументированно)
А если продолжать копать-копать-копать то можно докопаться до чего угодно. К примеру этот же самый отчет — представим, что деньги утекают, но нужен не просто отчет, а нужна система которая определит КТО тратит и Куда тратит. Но это тоже можно считать кнопочный решением, ведь если копать глубже, то руководителю на самом деле нужно принять решение — и система может сделать это за него — к примеру оштрафовать сотрудника. Копаем дальше и оказывается, что это тоже кнопочное решение, ведь всё что надо организации-Это зарабатывать максимальную прибыль, и нужна программа, которая сама анализировала бы тренды, строила прогнозы, делала заказы, начинала и останавливала продажи, вела бухгалтерию итд итп. Я повторюсь, что копать можно бесконечно долго и глубоко, и я с этим не согласен с автором (надеюсь, свою точку зрения я высказал максимально аргументированно)
Опишу проблему с точки зрения немного другой предметной области.
Тоже часто выступал в роли «Решалы» или «Спасателя», но замечаю что в некоторых случаях это было очень полезным и чем ближе к дедлайну тем полезнее. При этом я даже учитывал концептуальную целостность продукта и альтернативы, но все равно часто приходится делать то что быстро и с минимальными изменениями бизнес процесса (да, каюсь — когда команда не находила общего решения приходилось плевать на их мнение и делать то что считаешь правильным).
Как я писал выше, это полезно когда это оправдано. Но беда в том, что такие решения часто порождают технологические долги, которые необходимо гасить. Сложность в том — пояснить бизнесу почему необходимо изменить то или иное решение если оно худо бедно работает.
Тоже часто выступал в роли «Решалы» или «Спасателя», но замечаю что в некоторых случаях это было очень полезным и чем ближе к дедлайну тем полезнее. При этом я даже учитывал концептуальную целостность продукта и альтернативы, но все равно часто приходится делать то что быстро и с минимальными изменениями бизнес процесса (да, каюсь — когда команда не находила общего решения приходилось плевать на их мнение и делать то что считаешь правильным).
Как я писал выше, это полезно когда это оправдано. Но беда в том, что такие решения часто порождают технологические долги, которые необходимо гасить. Сложность в том — пояснить бизнесу почему необходимо изменить то или иное решение если оно худо бедно работает.
Статья хорошая, но немного однобокая. Часто в бизнесе, как и в армии, посредственное решение сейчас ценнее, чем хорошее — потом.
Александр, спасибо за отличную статью. Добавлю, что о проблеме кнопочных решений хорошо написал Даниэль Канеман в Thinking, Fast and Slow. Когда перед мозгом стоит большая задача, требующая анализа и проверки вариантов решений, он автоматически (для большинства людей) подменяет задачу на более простую, но примерно похожую по формулировке, решение которой или аналогичной было найдено им ранее. Так, например, в кейсе «Сужение видения» PO скорее всего просто не решал задачи вывода информации пользователю, поэтому привел решение похожей задачи — обмена сообщениями.
Есть подозрение, что «кнопочное мышление» — это отголоски подхода «сверху вниз» (от дизайна к данным), проповедуемому в Getting Real от 37signals, и гибких методологий разработки.
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Собственник или гендир, как человек действительно заинтересованный в глубоком анализе проблем и фундаментальном их решении, чаще всего на уровень конкретного проекта не погружается, а менеджеру гораздо проще поменять цвет кнопки и увеличить щрифток, показать положительные результаты на А/Б тестах начальству и получить премию.
Проблема, на мой взгляд, не в кнопочном мышлении, а в, зачастую, низкой заинтересованности принимающих решение лиц и нежелении погружаться в проблему/задачу.
Перевел статью в свой англоязычный блог https://medium.com/@alexander.byndyu/button-thinking-versus-consistent-it-product-3f5c6341cda2
Спасибо, статья интересная!
Ссылка на Cynefin framework неправильная, ведёт на «Cynefin», вероятно, нужна вот эта: https://en.wikipedia.org/wiki/Cynefin_framework.
Не умаляя достоинств осмысления фич и UX в целом, хочу обратить внимание на то, что у осмысления и прогнозирования есть ествественное ограничение: не всё можно предвидеть, + многое легко случайно не заметить. Некоторые инструменты сначала возникают непонятно зачем — и только потом другие люди находят им применение (Twitter, многомерные пространства).
Так что если бухгалтер Оля говорит, что ей хочется кнопку, то, возможно, стоит не доблестно отметать, а порасспрашивать её, зачем, какие практики будут окружать эту кнопку, и т. п. Возможно, вы вытянете из неё неожиданную киллер-фичу.
Т. е. ваши практики получаются не user-centric, а несколько мои-рационализации-о-пользователях-centric.
Повторюсь: я не предлагаю отказываться от осмысления и слепо идти на поводу, но развернуть ваши фильтрующие механизмы из режима «не пропускать» в режим «любопытно, может мы чег не знаем».
Ссылка на Cynefin framework неправильная, ведёт на «Cynefin», вероятно, нужна вот эта: https://en.wikipedia.org/wiki/Cynefin_framework.
Не умаляя достоинств осмысления фич и UX в целом, хочу обратить внимание на то, что у осмысления и прогнозирования есть ествественное ограничение: не всё можно предвидеть, + многое легко случайно не заметить. Некоторые инструменты сначала возникают непонятно зачем — и только потом другие люди находят им применение (Twitter, многомерные пространства).
Так что если бухгалтер Оля говорит, что ей хочется кнопку, то, возможно, стоит не доблестно отметать, а порасспрашивать её, зачем, какие практики будут окружать эту кнопку, и т. п. Возможно, вы вытянете из неё неожиданную киллер-фичу.
Т. е. ваши практики получаются не user-centric, а несколько мои-рационализации-о-пользователях-centric.
Повторюсь: я не предлагаю отказываться от осмысления и слепо идти на поводу, но развернуть ваши фильтрующие механизмы из режима «не пропускать» в режим «любопытно, может мы чег не знаем».
Некоторые инструменты сначала возникают непонятно зачем
Если это так, то надо заранее выяснить, что мы не знаем Зачем, поэтому давайте просто прикольную штуку сделаем. В этом случае бизнес-целей нет и делается продукт для удовольствия. Тогда и оценка результата будет другой.
Ценность анализа в том, чтобы выявить и цели или их отсутсвие.
порасспрашивать её, зачем, какие практики будут окружать эту кнопку
Так и делаем. Я не отметаю никаких идей пользователей, видимо не смог донести это в тексте статьи.
Кнопочный функционал очень дешевый:
— проще показать;
— проще объяснить;
— проще реализовать.
Большинство заказчиков не готовы инвестировать с проектирование. Более того, современные подходы за быстрые решения.
Очень часто сотрудники заказчика хотят проявить свою экспертизу и генерируют идеи для разработки, так как для них это бесплатно (они не платят за это), то и качество таких идей минимально.
Очень хороший вариант борьбы с кнопочными идеями, это попросить за них заплатить )
— проще показать;
— проще объяснить;
— проще реализовать.
Большинство заказчиков не готовы инвестировать с проектирование. Более того, современные подходы за быстрые решения.
Очень часто сотрудники заказчика хотят проявить свою экспертизу и генерируют идеи для разработки, так как для них это бесплатно (они не платят за это), то и качество таких идей минимально.
Очень хороший вариант борьбы с кнопочными идеями, это попросить за них заплатить )
Sign up to leave a comment.
Кнопочное мышление против целостного IT-продукта