Страх белого листа: как преодолеть его и запустить первую версию программного продукта для бизнеса?

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

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

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

Реальность такой быть не может: первая написанная строка кода, первый собранный макет, первый показанный кому-то прототип – все это неизбежно будет несовершенным. В этот момент продукт перестает быть фантазией и становится фактом, у которого есть конкретные недостатки.

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

Человек или компания могут месяцами, а иногда и годами, писать техническое задание, которое никогда не становится финальным, потому что всегда находится что-то, что можно улучшить. Могут бесконечно выбирать подрядчика, сравнивая портфолио и условия, но так и не подписывая договор, потому что идеального исполнителя не существует, а страшно ошибиться.

Могут запустить разработку, но на этапе приемки первой версии заворачивать ее раз за разом до тех пор, пока он не станет безукоризненным – то есть никогда.

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

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

Анатомия страха белого листа

Заказчик, застрявший на нулевом цикле, обычно не говорит: «Я боюсь». Он говорит: «Мы пока не готовы, надо еще немного доработать концепцию», «Рынок сложный, давайте изучим конкурентов подробнее», «Сейчас не лучшее время для запуска, подождем пару месяцев».

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

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

Страх необратимости

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

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

Страх зазора между замыслом и воплощением

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

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

Парадокс в том, что пользователь, впервые увидевший продукт, не знает о фантазии автора, ему не с чем сравнивать. Он видит просто продукт и оценивает, решает ли тот его задачу, а не то, насколько продукт соответствует чьему-то внутреннему идеалу.

Страх чужой оценки

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

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

Страх неопределенности

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

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

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

Метод рабочего черновика

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

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

Слово «черновик» здесь выбрано не случайно. В школе нас учили, что черновик – это грязная, некрасивая, промежуточная версия, которую никто не оценивает как финальный результат. К черновику не применимы критерии качества, которые мы применяем к чистовику. Именно такое отношение нужно перенести на первую версию цифрового продукта.

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

Рабочий черновик – это более радикальная вещь, версия, про которую автор честно говорит: «Я знаю, что тут многое не так. Я специально выпускаю это сейчас, чтобы понять, что делать дальше». Такая честность перед самим собой снимает груз перфекционизма на старте.

Несколько принципов, по которым живет рабочий черновик:

• Внешний вид не имеет значения. Дизайн может быть собран из готовых библиотек, верстка может плавать на некоторых экранах, цвета могут спорить друг с другом. Все это поправимо потом, когда станет ясно, что ядро продукта попало в потребность.
• Работает только главная механика. Если это маркетплейс, черновик позволяет одному пользователю выложить товар, а другому – его купить. Все остальное – рейтинги, избранное, история заказов, уведомления – отсутствует.
• Ошибки допустимы и ожидаемы. Черновик не обязан быть стабильным как банковское приложение, что-то может отваливаться, что-то может грузиться медленно.
• Черновик не останется навсегда. Автор заранее знает, что через две недели или месяц после запуска он начнет переделку на основе полученных данных. Черновик – это инструмент сбора информации для настоящего продукта.

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

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

Пять шагов к запуску черновика

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

Шаг 1. Сформулировать одну проверяемую гипотезу

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

Поэтому первый шаг – выбрать одну гипотезу и признать, что все остальные вопросы подождут. Гипотеза должна быть проверяемой, то есть такой, на которую можно получить ответ «да» или «нет» по итогам взаимодействия пользователя с черновиком. И она должна касаться самого рискованного допущения в вашей идее.

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

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

Шаг 2. Выделить ядро продукта и отсечь остальное

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

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

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

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

Шаг 3. Назначить дату и получателя

Черновик, у которого нет даты показа и конкретного человека, которому его покажут, рискует остаться вечным проектом в разработке. Абстрактное «скоро запустимся» не работает, потому что не создает обязательств, а конкретная дата создает дедлайн.

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

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

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

Шаг 4. Собрать черновик любым доступным способом

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

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

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

Шаг 5. Показать, зафиксировать реакцию и принять решение

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

На что стоит обратить внимание в первую очередь:

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

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

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

Как бороться с перфекционизмом?

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

Перед вторым релизом он шепчет: «Ну вот, теперь-то у нас есть пользователи, теперь нельзя показывать сырое, люди ждут качества». Перед третьим: «Мы уже не стартап на коленке, нам есть что терять, давайте доделаем все как следует и выкатим разом». Это тот же страх несовершенства, просто он мутировал и приспособился к новым обстоятельствам.

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

Правило «Достаточно хорошо»

Это правило пришло из психотерапевтической практики и отлично прижилось в разработке. Суть в том, чтобы перед каждым релизом задавать себе не вопрос «Все ли идеально?», а вопрос «Мешает ли оставшееся несовершенство пользователю получить основную ценность?».

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

Если же несовершенство действительно мешает – например, пользователь не может завершить покупку из-за ошибки, – оно правится немедленно, и релиз выходит сразу после этой правки.

Сравнение с предыдущей версией, а не с мечтой

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

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

Публичное обязательство

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

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

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

Выделенное время на дошлифовку

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

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

Разработка ПО от 66 Бит

Вот вы и подошли к концу! Мы постарались разбить ваш страх чистого листа, уложившись всего в 10 минут. Настало время наполнить чистый лист красками, а в этом вам поможет команда 66 Бит.

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