Офтоп Andrey Semyonov
4 979

Игры разума: как ментальные ловушки на три года завели наш сайд-проект в долину смерти

История о том, как мы создавали карточки для планирования проектов What's Plan, с какими когнитивными искажениями столкнулись в процессе и как эти искажения повлияли на наши решения по управлению продуктом.

В закладки

Содержание

  1. Введение.

  2. Рождение идеи.

  3. Проверка идеи.

  4. Разработка MVP.

  5. Тестирование MVP.

  6. Пивот.

  7. Уроки.

  8. Заключение.

Введение

Процесс разработки нового продукта пронизан цепочкой принятия решений: какую потребительскую проблему он будет решать, какие функции для этого в нём должны быть, какую цену ему назначить и так далее. Каждый такой выбор может приблизить команду к успеху, а может завести в долину смерти или ещё глубже — на кладбище стартапов.

Само собой, никто не хочет увидеть там свой продукт, поэтому каждый шаг по его разработке тщательно обдумывается. Беда в том, что человеческий разум подвержен когнитивным искажениям, которые влияют на интерпретацию информации и формирование суждений. Искажённое понимание ситуации вокруг продукта приводит к неверным решениям по управлению им.

Такие решения принимали и мы, пока создавали What’s Plan — набор карточек для обучения процессу производства цифровых проектов. Они дорогого нам стоили, поэтому мы постарались в них разобраться и поделиться ими с сообществом. Надеемся, извлечённые нами уроки кому-то покажутся полезными и помогут избежать некоторых ментальных ловушек, способных привести к напрасным тратам времени и денег.

Статья построена следующим образом: сначала поэтапно описана история создания What’s Plan’а, затем рассмотрены когнитивные искажения, повлиявшие на принятие решений, а также способы борьбы с ними. Если нет времени читать статью полностью, то пропускайте описание процесса разработки продукта и сразу переходите к разделу «Уроки».

Рождение идеи

Карточки

Всё началось в далёком 2015 году. Тогда я проектировал сайты в продакшн-студии Denero, и вместе с её основателем Денисом Будковым мы неоднократно обсуждали возможность запуска сайд-проектов внутри компании. С одной стороны, нам хотелось воплотить в жизнь своё видение, а не клиентское, с другой — было желание попробовать создать успешный продукт.

Так как мы занимались заказной веб-разработкой, неудивительно, что большинство идей было связано с этой сферой — как и любой другой бизнес, студия сталкивалась с насущными проблемами, которые ждали своего решения. Одной из таких проблем на тот момент было недопонимание клиентами процесса разработки, что приводило к попыткам исключить из него составляющие, которые они считали неважными.

У нас была гипотеза, что если вовлечь заказчика в планирование проекта, то это позволит доступнее объяснить нюансы разработки и сохранить рабочий процесс. Другая гипотеза заключалась в том, что подобное мероприятие поможет выяснить у них требования к проекту и заложить фундамент для эффективного взаимодействия в дальнейшем. Так появилась идея What’s Plan’а — набора карточек для планирования производства цифровых проектов.

Концепция

Совместное планирование предполагает организацию cовещания с клиентом, на котором будут обсуждаться цели проекта и их достижение. Карточки на физическом носителе показались нам подходящим инструментом для этого: чтобы их использовать, нужна только горизонтальная поверхность, они наглядны и ими легко манипулировать.

По завершении совещания должно получиться что-то вроде структуры декомпозиции работ, представленной в виде карточек. Эти карточки должны были описывать этапы, процессы и ресурсы, которые необходимы для реализации конкретного проекта, а также результаты, которые поставляются заказчику по мере выполнения каждого из процессов.

What’s Plan: типы карточек на этапе идеи
  • Карточки проектов определяют, из каких этапов состоит реализация того или иного проекта.
  • Карточки этапов определяют, какие процессы должны быть совершены на том или ином этапе в рамках реализации конкретного проекта.
  • Карточки процессов кратко описывают процессы и содержат списки задач, необходимых для их выполнения.
  • Карточки результатов описывают, какие результаты поставляются после выполнения каждого процесса.
  • Карточки ресурсов описывают ключевые компетенции человеческих ресурсов, которые могут быть привлечены к реализации проекта.
  • Карточки требований и ограничений содержат списки вопросов для выявления требований к проекту.

Мы исходили из того, что у проектов по разработке сайтов и приложений разного типа есть характерный для них состав работ. Например, для многосторонней платформы следует формализовать взаимодействие между целевыми группами пользователей в артефактах вроде swimlane-диаграмм. Очевидно, что при разработке целевой страницы этого делать не нужно.

What’s Plan: структура декомпозиции работ на этапе идеи

Помимо того, что процесс разработки зависит от типа продукта, на него также влияют требования к бюджету, срокам и качеству проекта. Как следствие, состав работ может меняться, адаптируясь к тем или иным условиям.

What’s Plan: циклы адаптации проекта на этапе идеи

Таким образом, совместное формирование карточной структуры декомпозиции работ помогает, с одной стороны, объяснить клиенту нюансы разработки проекта и важность тех или иных процессов, а с другой — прояснить требования к нему. Карточки результатов устанавливают контрольные точки для коммуникации с заказчиком, чтобы обсудить произведённые артефакты и, если требуется, скорректировать вектор разработки продукта. В идеале совместное планирование закладывает фундамент для создания атмосферы взаимного доверия и понимания между студией и клиентом.

Так мы видели концепцию продукта, польза которого — для нас — была очевидна.

Проверка идеи

В то время нам казалось, что мы уже прониклись философией бережливого стартапа, чтобы сначала протестировать потребность в продукте и только потом вкладывать ресурсы в его разработку. Для этой цели мы решили запилить лендинг с описанием концепции What’s Plan’a.

Проверить идею хотелось как можно дешевле, поэтому инвестировать средства в привлечение посетителей не планировалось. Мы прикрутили к лендингу виральную механику и просто анонсировали запуск продукта в своих социальных сетях. На этом наша рекламная кампания и закончилась.

What’s Plan: блок с виральной механикой на целевой странице

Описание виральной механики: Мы наштормили типы сайтов и приложений с характерным для них составом работ и присвоили каждому из них цену в шейрах — чем больше пользователей поделиться ссылкой на лендинг, тем больше «фреймворков» будет выпущено. Каждому пользователю, который поддержал проект таким образом, мы пообещали выслать PDF-версию карточек.

Дальше оставалось только верить в непредсказуемую магию шейра и попивать смузи в ожидании отклика аудитории. Сначала отреагировали наши друзья и коллеги по петербургскому рынку разработки — пошли первые лайки, комментарии и репосты. Дальнейшее распространение простимулировала виральная механика, предусмотренная на целевой странице.

Увидев активное обсуждение What’s Plan’а в социальных сетях и набрав больше 200 шейров целевой страницы, мы уверились, что у людей есть потребность в нашем продукте.

Разработка MVP

Мы с энтузиазмом взялись за проработку идеи. Концепция продукта осталась прежней: набор карточек для определения структуры декомпозиции работ по реализации различных сайтов и приложений. Структура включает в себя тип проекта, этапы его реализации, процессы, выполняемые на каждом из этапов, и результаты, поставляемые заказчику после выполнения каждого из процессов.

На этапе проверки идеи пользователи проголосовали своими шейрами за выпуск набора карточек для двух типов проектов: целевой страницы и промосайта. Мы решили добавить в него также корпоративный сайт, так как создание соответствующих карточек не потребовало бы серьёзных усилий, а ценность MVP возросла бы.

Проектирование

Начали с того, что формализовали концепцию продукта в геймфрейме (Дигнан, 2011). Мы хотели, чтобы совещание по планированию проекта было непринуждённым и вовлекающим, поэтому задумывали информационную модель What’s Plan’а как настольную игру.

What’s Plan: геймфрейм — менеджер проекта

Затем составили структуры декомпозиции работ для целевой страницы, промо- и корпоративного сайтов. Мы старались ориентироваться на человеко-ориентированный подход, а также руководства по управлению проектами и разработке (PMBOK, SWEBOK), чтобы эти декомпозиции были более-менее универсальными, но с учётом специфики сайтов, включённых в первую итерацию набора.

What’s Plan: структура декомпозиции работ — промосайт

Составив декомпозиции, мы получили список карточек, для которых нужно было определить содержимое: три карточки проектов, 18 карточек этапов (по шесть штук для каждого проекта), 20 карточек процессов и 20 карточек результатов. Плюс семь карточек ресурсов, призванных демонстрировать заказчику, что за разработку проекта отвечает несколько специалистов разного профиля.

Ещё на этапе рождения идеи, мы прошерстили интернет в поисках конкурентов и нашли одного, который предлагал похожее на What’s Plan решение — MethodKit. Но помимо того, что карточки этих ребят практически не обладали структурностью, они также содержали мало контента и не объясняли процессы разработки. Мы посчитали это минусом, поэтому в прототипах своих карточек предусмотрели более детализированное содержимое, чтобы What’s Plan выполнял ещё и информационную функцию.

Заключительным аккордом стала проработка механики адаптации декомпозиции работ под потребности конкретного проекта. Ведь на процесс производства сайтов и приложений влияет множество факторов (цели проекта, ресурсы, риски и так далее). Эта механика заключалась в том, чтобы при планировании выяснить у заказчика требования к проекту и заменить или исключить из состава работ некоторые процессы, если это необходимо. Помимо этого объёмом работ можно управлять, изменяя степень детализации тех или иных поставляемых результатов.

Степень детализации результата процесса прототипирования

Учитывая, что What’s Plan был сайд-проектом, и параллельно мы занимались заказной разработкой, на проектирование MVP ушло несколько месяцев — на дворе уже шёл 2016 год.

Но это было только начало.

Дизайн

При проектировании у нас выкристаллизовались требования к карточкам, которые во многом определяли их макет. В дальнейшем это сыграло против нас, потому что они задавали жёсткие рамки для дизайна.

What’s Plan: прототипы карточек — третья итерация

Мы понимали, что сделать дизайн What’s Plan’а будет непростой задачей, и хотели найти думающего дизайнера, который бы проникся идеей продукта и оформил её. Первый же дизайнер, привлечённый к проекту, оказался именно таким. Видимо, поэтому он поставил некоторые наши требования к карточкам под сомнение и предложил альтернативное видение реализации продукта. Мы продавили своё решение, аргументируя его тем, что за него «проголосовали» пользователи на этапе проверки идеи. На этом и разошлись.

Проблема была в том, что история повторялась вновь и вновь: мы находили крутого дизайнера, он подвергал критике нашу концепцию и предлагал альтернативные, которые нас не устраивали. Один раз нам даже посоветовали распечатать наши прототипы и показать их потенциальным пользователям, чтобы оценить, насколько хорошо они решают потребительскую проблему. Но мы отвергли эту идею, в очередной раз сославшись на эксперимент с целевой страницей.

После того, как проект покинул третий дизайнер, мы совсем приуныли. Долгое время прогресса практически не было, что убивало наш интерес к What’s Plan’у, и дальнейшие попытки дизайна носили скорее спорадический характер. В какой-то момент нами стало двигать желание просто доделать MVP — ведь столько усилий уже было вложено.

Наконец, мы познакомились с Валерией, с которой нам удалось достичь взаимопонимания относительно дизайна карточек, и вскоре он был готов.

What’s Plan: финальный дизайн карточек

В общем, спустя ещё два года и около семи итераций дизайна нам удалось вплотную приблизиться к моменту материализации своей идеи.

Тестирование MVP

По прошествии стольких лет с начала работы над проектом в нас таки проросло зерно сомнения. Поэтому перед печатью масштабной партии What’s Plan’a было решено заказать пилотный тираж и протестировать его с реальными людьми — чтобы выявить существующие дефекты и оценить взаимодействие с продуктом. Ещё мы хотели узнать: удалось ли создать что-то действительно ценное, за что люди готовы платить.

Чтобы ответить на этот вопрос, было запланировано провести серию встреч с игроками рынка разработки, которые базируются в Петербурге. Мы посчитали, что участники тестирования должны обладать сильной экспертизой в планировании и производстве цифровых продуктов, что позволило бы извлечь больший объём полезной и разноплановой обратной связи даже при небольшом количестве сессий. В итоге состоялось пять встреч с представителями компаний ARTW, Aidem, «Собака Павлова», Nimax и «Моё здоровье».

Каждая встреча проходила по следующему сценарию:

  • Приветствие: знакомство с участниками тестирования и описание плана встречи.
  • Демонстрация продукта: рассказ об истории проекта, описание типов карточек и механики построения структуры декомпозиции работ.
  • Проверка гипотезы относительно проблемы: дискуссия о том, существуют ли у участников тестирования сложности с объяснением клиентам процесса разработки сайтов и приложений.
  • Проверка гипотезы относительно решения: дискуссия о том, насколько хорошо продукт решает проблему.
  • Проверка гипотезы относительно стоимости продукта: оценка готовности участников тестирования заплатить за продукт нашу цену.

Стоимость первой итерации What’s Plan’a мы установили в размере 4000 рублей, то есть чуть выше, чем у наборов от MethodKit. Нам казалось, что наши карточки ценнее за счёт более подробного содержимого и механики формирования структуры декомпозиции работ.

Уже с первой встречи стало понятно, что проблема недопонимания клиентом нюансов разработки и, как следствие, торга относительно процессов хоть и существует, но с ней справляются привычные для всех инструменты вроде презентаций, смет и диаграмм Ганта. Поэтому в дальнейшем фокус тестирования сместился на то, чтобы определить: способствует ли What’s Plan выявлению у заказчиков требований к проекту.

В результате мы выяснили, что во всех пяти компаниях постоянно или часто сталкиваются с данной проблемой, но только в одной из них нам ответили, что могли бы использовать What’s Plan для её решения. Такой низкий показатель был обусловлен тем, что у разработчиков отлажен свой рабочий процесс, а карточки формируются в жёсткую структуру, которую им сложно адаптировать под себя. Кроме того, нам неоднократно заявляли, что составление структуры декомпозиции работ при помощи What’s Plan’а носит, в основном, презентационный характер и не вовлекает заказчика в планирование.

Было непросто признать, но три года мы верили и вкладывали ресурсы в карточки, которые не выдержали первой же встречи с потенциальными потребителями. Нужно было устроить её ещё на этапе проверки идеи — дизайнер, который советовал это сделать, оказался прав.

Мы в очередной раз приуныли.

Пивот

В этот раз состояние апатии длилось недолго — три из пяти компаний, принявших участие в тестировании, с некоторыми оговорками отметили, что созданные карточки подходят для обучения процессу разработки.

Мы увидели для себя … применение этого фреймворка в качестве дидактического пособия для быстрого погружения новых менеджеров в специфику и процессы

ARTW

Этих данных маловато, чтобы делать далеко идущие выводы, но у нас на руках был практически готовый продукт, и с его помощью можно подтверждать гипотезы в условиях рынка. Поэтому мы исправили обнаруженные в процессе тестирования дефекты и переориентировали What’s Plan на помощь в обучении процессу разработки сайтов и приложений. Затем, как и обещали, разослали PDF-версию набора тем 242 пользователям, которые поддержали проект шейром, и инициировали один предзаказ. После всех перипетий мы порадовались даже такому результату.

В опытных образцах карточек процессов и ресурсов у нас были предусмотрены поля для указания затрат времени на процесс и стоимость часа специалиста, но после пользовательского тестирования мы отказались от них

Кроме того, тестирование MVP подтвердило наличие у разработчиков проблемы выявления требований к проекту. В процессе мы собрали пользовательские требования и стали лучше понимать, какой продукт всё-таки нужно создать, чтобы её решить. Дело «за малым» — разработать карточки, которые удовлетворяли бы эти требования.

What’s Plan: пользовательские требования к карточкам

Похоже, мы начали двигаться в правильном направлении.

Уроки

Сейчас, окидывая взглядом пройденный путь, становится очевидно, на каких развилках мы сначала свернули, а потом и углубились в долину смерти. Однако в момент принятия этих решений нам казалось, что разработка What’s Plan’а будет двигаться в верном направлении.

Мы попытались разобраться, почему так произошло, и пришли к выводу, что причина кроется в нашем разуме: из-за особенностей человеческого мышления у нас не получилось объективно воспринимать ситуацию вокруг продукта. Это в свою очередь повлияло на качество решений по его разработке.

К сожалению, когнитивное совершенство вряд ли достижимо в силу того, что часть мыслительных процессов, связанных с интерпретацией информации, формированием суждений и принятием решений, протекает на бессознательном уровне. Но можно сознательно использовать различные практики, которые помогают бороться с когнитивными искажениями.

Далее описаны ментальные ловушки, в которые мы угодили на пройденных этапах жизненного цикла продукта, а также способы их обойти.

Рождение идеи и искажение изобретателя

Когда концепция What’s Plan’а только родилась, она казалась нам стройной, а польза продукта — очевидной.

Предприниматели и изобретатели склонны переоценивать свои идеи. Данная когнитивная ошибка носит название искажение изобретателя. Это убеждённость создателей продукта в том, что он будет немедленно принят рынком в изначально задуманном виде.

Как бороться

Для борьбы с оптимизмом в отношении собственных идей Даниэль Канеман в своей книге «Думай медленно, решай быстро» предлагает использовать метод «прижизненного эпикриза». Его суть заключается в том, чтобы перед реализацией очередного грандиозного плана (например, запуска нового продукта) собрать команду на совещание и обсудить возможные неблагоприятные исходы:

  • Какими они могут быть?
  • Какие события к ним могут привести?
  • Сколько они могут стоить?

Подобное обсуждение поможет обнаружить неочевидные угрозы и более критично отнестись к оптимистичным сценариям развития событий.

Проверка идеи и предвзятость подтверждения

Чтобы протестировать идею What’s Plan’а, мы запустили целевую страницу с описанием концепции продукта и постарались инициировать её вирусное распространение. Локальный успех в этом направлении был интерпретирован нами как интерес именно к той реализации продукта, которую мы задумали изначально.

Люди склонны искать и интерпретировать информацию таким образом, чтобы она доказывала истинность их убеждений. Это называется предвзятостью подтверждения.

Как бороться

В своих работах философ Карл Поппер сформулировал принцип фальсификации, согласно которому утверждение можно считать истинным, если опровергнуто обратное.

Поэтому вместо того, чтобы фокусироваться на информации, которая подтверждает гипотезу о продукте, команде нужно стремиться получить данные, которые ставят её под сомнение. Если такие данные не найдены или найдены, но опровергнуты, то предположение можно рассматривать как верное (но это не точно).

Разработка MVP и мотивированное рассуждение

У нас была, казалось, стройная концепция What’s Plan’а, подтверждённая при помощи эксперимента с вирусной механикой. Некоторые из дизайнеров, привлечённых к участию в проекте, подвергали сомнению наше видение продукта и предлагали своё, но мы всегда продавливали первоначальное решение. В итоге дизайн растянулся на семь итераций в течение пары лет. За это время внимание аудитории к продукту поугасло, да и клиенты студий стали образованнее.

Люди склонны считать свои первоначальные идеи, которые уже успели укорениться в их головах, более ценными, чем новые, которые их не подкрепляют. Они всеми способами стараются обосновать старые убеждения, и такое когнитивное искажение известно как мотивированное рассуждение.

Как бороться

Мотивированное рассуждение вызвано эмоциональной реакцией на новую информацию, которая противоречит привычной картине мира. Сознание ещё не успело на неё среагировать, а бессознательное уже идентифицировало её как угрозу и запустило механизм «бей или беги». Далее в дело вступает сознание, но только затем, чтобы сыграть роль адвоката устоявшихся убеждений.

На мой взгляд, здесь два аспекта, над которыми можно работать: повышение толерантности к новым идеям и переоценка старых.

В первом случае важно преодолеть защитную реакцию бессознательного на альтернативную точку зрения и быстрее вовлечь сознание в её обсуждение. Для этого можно использовать простое упражнение из книги «Настольная книга по консенсусу»: команде нужно выступить адвокатом новой идеи и убедительно её аргументировать. Логические рассуждения, отодвигающие эмоции на второй план, позволят найти в ней зерно истины (если оно есть).

Появление обоснованной альтернативной точки зрения послужит команде сигналом, чтобы подвергнуть сомнению существующие идеи и перепроверить факты, на которых они основаны.

Тестирование MVP и ретроспективное искажение

Когда потенциальным потребителям был показан опытный образец What’s Plan’а, выяснилось, что продукт не решает те проблемы, которые, по нашему мнению, он должен был решать, и его нужно улучшать. После трёх лет разработки продукта такая перспектива подействовала на нас удручающе . Оглянувшись назад, мы сразу увидели ключевые ошибки, которые привели нас к такому результату.

Забавно, но в ретроспективе люди склонны воспринимать произошедшие события как очевидные и предсказуемые. Они легко могут объяснить причинно-следственные связи между ними, хотя и не обладают исчерпывающей информацией для этого. Это называется ретроспективным искажением или ошибкой хайндсайта.

Как бороться

Дайана Халперн, автор книги «Психология критического мышления», вместо ретроспективной оценки событий советует использовать проспективную: события фиксируются в момент наступления после чего предпринимаются попытки спрогнозировать их последствия. Это поможет команде, с одной стороны, лучше прослеживать причинно-следственные связи между произошедшими событиями, а с другой — рассмотреть варианты развития этих событий и подготовиться к неблагоприятным исходам.

Пивот и слепое пятно в отношении когнитивных искажений

Потенциальные потребители не увидели в пилотной версии What’s Plan’а той ценности, которую мы изначально хотели в неё заложить. Однако они увидели в нём потенциал для обучения процессу разработки сайтов и приложений, и мы решили переориентировать продукт на эту потребность. Уверены ли мы теперь, что после всех совершённых ошибок нам удастся избежать новых? Нет.

Ирония в том, что люди склонны не замечать свою познавательную немощь. Это называется слепым пятном в отношении когнитивных искажений.

Как бороться

Наверное, универсальным советом здесь будет придерживаться принципа научного скептицизма, согласно которому любое знание, не имеющее экспериментальных доказательств и воспроизводимость результатов, следует подвергнуть сомнению.

Командам нужно систематически проверять свои продуктовые гипотезы при помощи экспериментов и принимать решения на основе данных. Звучит банально, но в реальной жизни строгий подход к этому встречается редко.

Заключение

Нельзя утверждать, что когнитивные искажения несут исключительно вред. Напротив, они помогают людям справляться с переизбытком информации, интерпретировать и запоминать её, а также принимать быстрые решения, когда это необходимо. Именно благодаря искажению изобретателя предприниматели и учёные решаются на реализацию своих идей, что в свою очередь двигает экономический и технологический прогресс.

Однако если идти на поводу у когнитивных искажений, это грозит ненужными потерями времени и денег, а значительные потери этих ресурсов угнетают дух предпринимательства.

Чтобы этого избежать:

  • подвергайте сомнению идеи своих продуктов — только так можно обрести неиллюзорную уверенность в них;
  • будьте открыты к восприятию альтернативных фактов и точек зрения — это позволит сделать своевременный пивот и повысить шансы команды на успех;
  • устанавливайте достоверные причины своих неудач — чтобы избежать их повторения в будущем;
  • проверяйте гипотезы при помощи экспериментов — это обеспечит накопление подтверждённого знания.

Надеемся, эти советы помогут вам воплощать свои идеи таким образом, чтобы они находили отклик у вашей аудитории. Если у вас есть идеи относительно развития What’s Plan’а, будем рады услышать их здесь в комментариях или в нашей публичной дорожной карте.

Материалы по теме

#инструменты #кейс

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Andrey Semyonov", "author_type": "self", "tags": ["\u043a\u0435\u0439\u0441","\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b"], "comments": 34, "likes": 27, "favorites": 27, "is_advertisement": false, "subsite_label": "flood", "id": 39522, "is_wide": false, "is_ugc": true, "date": "Thu, 07 Jun 2018 11:07:31 +0300" }
{ "id": 39522, "author_id": 95411, "diff_limit": 1000, "urls": {"diff":"\/comments\/39522\/get","add":"\/comments\/39522\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/39522"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199791, "possessions": [] }

34 комментария 34 комм.

Популярные

По порядку

Написать комментарий...
4

Продукт слишком сложен для заказчика. Не нужен ему весь этот геморрой с планированием проекта, нюансами разработки и кучей карточек. Ему нужен результат и приемлемая стоимость.

Максимум, что хочет типичный заказчик – разбиения на приемлемые понятные ему этапы.

Возможно, такой продукт пойдёт в B2B-сфере, но при условии хорошо-выстроенной интеграции и обучения. Да и конкурентов там уже полно (Bitrix24, Мегаплан, Jira и прочие).

Имхо, вы очень далеки от реальных потребностей аудитории. Вы делаете скорее "программерскую" такую "игрушку", в которой всё разложено, структурировано, разбито на процессы и схемы, красиво упаковано в карточки, структуры и т.д.

То есть в конечном счёте удовлетворяете свой интерес к созданию сложного логичного философского продукта, но не интерес типичных заказчиков (конечных пользователей).

Ответить
0

Продукт слишком сложен для заказчика. Не нужен ему весь этот геморрой с планированием проекта, нюансами разработки и кучей карточек. Ему нужен результат и приемлемая стоимость.

Соглашусь, что заказчик хочет просто заплатить денег и получить качественное решение. И я был бы рад, если бы так это работало :) Проблема в том, что когда озвучивается стоимость такого решения, как правило, начинается торг. Всё равно приходится объяснять, зачем нужен тот или иной процесс, и как повлияет на качество проекта, если его исключить, чтобы сократить стоимость.

Возможно, такой продукт пойдёт в B2B-сфере, но при условии хорошо-выстроенной интеграции и обучения. Да и конкурентов там уже полно (Bitrix24, Мегаплан, Jira и прочие).

Возможно, сюда получится зайти с ко-брендинговыми проектами — будем прощупывать почву.

Ответить
0

Всё равно приходится объяснять, зачем нужен тот или иной процесс, и как повлияет на качество проекта, если его исключить, чтобы сократить стоимость.

Это ошибка с точки зрения продажи IT-услуг. Есть по большому счёту два вида заказчиков IT-услуг: внутренний и внешний.

Внутренний заказчик практически всегда хочет знать, почему так долго? Почему применено именно такое решение? Можно ли его как-то упростить? Можно ли оптимизировать какой-то этап? И так далее. Пример внутреннего заказчика – продуктолог в IT-компании, который пишет задания для команды разработки. И для него есть смысл всё это расписывать, чтобы увеличить эффективность взаимодействия, дать ему на регулярной основе понимание тех или иных инженерных процессов.

Внешний заказчик тоже хочет всё это знать. Но в этом случае с ним должен общаться продажник, а не инженеры. И отношения с внешним заказчиком должны регулироваться рынком, а не стоимостью ваших внутренних процессов. Грубо говоря, даёте ему ценник:
* сайт-визитка за 5 000
* интернет-магазин за 50 000
* корпоративный портал за 500 000

Всё!

Хочешь брать за такую цену? Бери.
У Коли за углом дешевле? Ок, иди к Коле (или, например, "Ок, держи скидку" – в зависимости от того, стоит ли у вас очередь из заказчиков).

Но как только мы начинаем погружать заказчика в какие-то внутренние процессы, да ещё и позволять выкидывать их как ненужные (!!!), это путь в пропасть... Не надо ему этого знать. И не надо позволять в это лезть. Это "кухня" компании. Что она "готовит" и как – это её дело. А для клиента есть прайс и продажники.

Ответить
3

Возможно, лет 5 назад всё так и было. Сегодня заказчики в крупных компаниях достаточно компетентные, некоторые из них — вчерашние сотрудники интернет-агентств, люди с техническим бекграундом.

Ваш пример больше похож на продажу типовых решений в потоковых студиях в низком ценовом сегменте. Там — да, продажника, который назовёт цену и отправит типовое предложение будет достаточно.

Но если речь идёт о нестандартном проекте в котором только проектирование может стоить 300-500 т.р., то без понимания клиентом какую пользу даёт тот или иной этап процесса — продажа, скорее всего, не состоится.

Поэтому погружение в процессы создания сложного и дорогого продукта — важная часть продажи любой сложной услуги.

В некоторых веб-студиях продажники отсутствуют как класс, продажи совершают руководители проектов, потому что они наиболее компетентны в вопросах разработки.

Ответить
1

Не путайте: одно дело разложить этапы и состав работ (это ОК). Другое дело: позволить участвовать во внутренних процессах, а тем более оптимизировать их.

Ответить
4

1) Идея проекта состоит в том, чтоб вовлечь клиентов в процесс планирования проекта на стадии препродажи, когда формируется фундамент будущего проекта.

2) На больших и сложных проектах участие заказчика в процессе — неизбежно. Особенно на стадии проектирования и создания контента, где заказчик выступает главным носителем знаний о бизнесе, рынке и аудитории. Остальное — творческое и техническое дело, где участие заказчика не обязательно.

Что касается оптимизации процессов. Тот или иной процесс может быть исключен заказчиком осознанно или неосознанно.

Любой проект — это работа с возможностями и ограничениями: финансовыми, временными, техническими.

Чаще всего на нашем рынке решения принимаются неосознанно («чем больше фич, модулей за меньшую цену мы получим — тем лучше» — типичный запрос сегодня).

Понимание влияния процессов на конечный результат позволяет отказываться от каких-то этапов осознанно, образовывает клиента, способствует появлению проектов, которыми приятно пользоваться и делает рынок лучше.

Карточки (или любая другая визуализация) позволяют «на пальцах» донести пользу этапов до заказчиков.

Ответить
1

Ок. Убедили. Есть ЦА у проекта.

Значит, его нужно грамотно подать этой ЦА и обязательно сопровождать во время каждого внедрения (обучать, наблюдать, собирать фидбэк).

Ответить

2

Мне кажется, можно было бы описать короче - мы, люди, часто просто любим пребывать в иллюзии, так как иллюзия рисует нам картинку, вызывающую шаблонное эмоциональное вовлечение. И "предприниматели" подвержены этому тоже.

В этом суть статьи) Правда, дело не только в эмоциях, но и в ограничениях разума при обработке информации. Хотели на конкретных примерах показать, к чему это может привести при разработке продукта.

Ответить

5

Напечатайте количество очков на карточках, придумайте правила и продавайте как отдельную настольную игру.

Ответить
0

Возьмём на заметку, спасибо!

Ответить
3

Проект классный, материал отличный. Пожелаю удачи ребятам, у вас всё получится!

Ответить
0

Спасибо :)

Ответить
0

Удачи! :-)

Ответить
3

Как же сложно то всё)

Ответить
1

Хорошо написано, много, по делу. Скажите, а можно было просто карточки из Trello распечатать?

Ответить
0

Да, только пришлось бы «поиграться» с масштабом, чтобы распечатанные карточки были компактными и при этом читаемыми.

Но вы мыслите в верном направлении — у пользователей есть потребность кастомизировать карточки, адаптируя их под свои процессы. Думаем, в сторону возможности оцифровывать их, но пока это отдалённая перспектива :)

Ответить
1

Перешла сразу к урокам. Интересно, спасибо!

Ответить
1

Я, конечно, всё понимаю, но проебать 3 года по собственной глупости и сбросить всё на какие-то когнитивные ловушки? Звучит как один из худших способов оправдать собственное нежелание развивать/ся.

Вы молодцы, что спустя годы вспомнили первого дизайнера, особенно учитывая тот факт, что он занимался как раз тем, что вам необходимо в первую очередь. Стоило начать рассказ с того, что вы и сами не знали, зачем вам дизайнер и этот проект.

Ну а по факту очень смешной материал, пару раз прям заорал. Желаю успехов в следующую пятилетку.

Ответить
0

Шампанского этому Джентльмену.

Ответить
0

С карточками, я надеюсь.

Ответить
0

И с куртизантками, разумеется.

Ответить
0

Я, конечно, всё понимаю, но проебать 3 года по собственной глупости и сбросить всё на какие-то когнитивные ловушки? Звучит как один из худших способов оправдать собственное нежелание развивать/ся.

По-вашему, нужно всё «сбросить» на глупость?) Это был бы действительно самый бесполезный способ что-то оправдать. И причём здесь нежелание развиваться? Мы вообще не стали бы ничего предпринимать и выходить из зоны комфорта, если бы не хотели расти.

Мы, напротив, пробуем делать что-то новое. Естественно, в процессе мы ошибаемся — это нормально, вся жизнь состоит из проб и ошибок. Главное принимать ответственность за свои промахи, тогда есть возможность учиться и менять свой продукт к лучшему. Что мы стараемся делать. И честно рассказываем о своих ошибках, чтобы другие их не повторяли. Это отсылка к ошибке выжившего: https://snob.ru/profile/30516/blog/121611.

Для вас пользовательское тестирование на этапе идеи — «прописная истина»? Хорошо, если так, но мне почему-то не верится. CustDev, появившись в нулевых, только сейчас становится общепринятым подходом при разработке новых продуктов. При этом, многие предприниматели до сих пор бояться встречаться с потребителями, пока не довели свой продукт «до совершенства».

Вы молодцы, что спустя годы вспомнили первого дизайнера, особенно учитывая тот факт, что он занимался как раз тем, что вам необходимо в первую очередь.

Вы, очевидно, имеете в виду дизайнера, который предложил показать прототипы пользователям? Это был 4-ый по счёту дизайнер, и он предложил так сделать потому, что хотел защитить своё видение продукта.

Если бы мы его приняли, то:
а) он просто нарисовал бы своё решение без всяких тестирований;
б) при таком раскладе шансы на успех его решения были бы точно такими же, как и у нашего.

Правда в том, что только 5-ый дизайнер смог предложить решение, которое бы соответствовало озвученным в брифе требованиям, а не своё «я так вижу».

Но признаю, что показать прототипы пользователям было хорошей идеей — теперь только так и работаем.

Ну а по факту очень смешной материал, пару раз прям заорал.

Да, самоирония наше всё)

Ответить
0

Ребят, ну правда, в вашем случае достаточно просто было проверить состоятельность самой идеи. Не нужно было создавать прототип. Вы хотя бы узнали, есть ли вообще такая проблема, которую вы решали, у коллег по цеху.

Не зашли ведь в итоге не прототипы, а в целом суть.

Ответить
0

Ребят, ну правда, в вашем случае достаточно просто было проверить состоятельность самой идеи. Не нужно было создавать прототип.

Мы так и сделали — см. раздел «Проверка идеи».

Не зашли ведь в итоге не прототипы, а в целом суть.

Если говорить про выявление требований, то суть зашла, не зашла реализация — см. раздел «Тестирование MVP».

Ответить
1

а идея хороша, и имеет право на жизнь. только не в плане карточек визуальных -а в плане шаблонизации типовых (под)задач.
Пример: Поезд выезжает с точка А до точки В.
Решение: Нажимаем создание 3Д объекта - создается куча подзадач
Скетч Модель текстуры анимации - на основе шаблонов создается пайплан, вырисовывается общее представление в виде Ганта. Формируются начальные трудозатраты в человекочасах и денежной себестоимости. Артлид тут же дает оценку по времени - получаем более правдоподобную оценку по времени и деньгам.
Вопрос только в шаблонах и конечном результате.
Андрей - идея хороша - давай познакомимся? пивка в Праге тяпнем?

Ответить
0

а идея хороша, и имеет право на жизнь. только не в плане карточек визуальных -а в плане шаблонизации типовых (под)задач.

Да, в процессе тестирования выявили такую потребность, но здесь требуется цифровое решение, а мы пока не готовы серьёзно за него взяться.

Андрей - идея хороша - давай познакомимся? пивка в Праге тяпнем?

Если я когда-нибудь туда доберусь, то обязательно)

Ответить
0

История "Как мы заебали дизайнеров". Неудивительно, что обосрались

Ответить
0

Неудивительно, что обосрались

На мой взгляд, это громко сказано :) Да и про дизайнеров — слишком упрощённое понимание ситуации.

Ответить
0

В общем, спустя ещё два года и около семи итераций дизайна нам удалось вплотную приблизиться к моменту материализации своей идеи.

сказано достаточно

Ответить
1

Действительно, если вы можете на основе одного единственного предложения сделать такой категоричный вывод о том, как всё было на самом деле, тут даже не поспоришь)

Ответить
0

Зачем тип карточки написан вертикально? Неудобно читать

Ответить
0

С вертикальной шапкой перебрать колоду и найти нужную карточку получается быстрее, чем с горизонтальной. Плюс когда на карточки смотрят с нескольких разных сторон, как на фото с пользовательского тестирования, не имеет особого значения, как написан заголовок — вертикально или горизонтально.

В общем, если вдаваться в подробности, то можно ещё один пост только про дизайн карточек написать :)

Ответить
0

Не понял зачем и кому этот продукт нужен. Это такое trello, только сложное?

Ответить
0

Не понял зачем и кому этот продукт нужен.

Описано практически в начале статьи: Рождение идеи > Карточки.

Ответить

0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Компания отказалась от email
в пользу общения при помощи мемов
Подписаться на push-уведомления
{ "page_type": "default" }