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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

После того, как проект покинул третий дизайнер, мы совсем приуныли. Долгое время прогресса практически не было, что убивало наш интерес к 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’а носит, в основном, презентационный характер и не вовлекает заказчика в планирование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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