Паралич перфекциониста: почему в стремлении сделать идеальное ПО для бизнеса с первого раза вы хороните запуск продукта?

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

«Давайте сразу заложим выгрузку отчётов в пяти форматах – мало ли что клиенту понадобится».

«А если пользователь захочет менять цветовую тему интерфейса? Добавим три на выбор, это же несложно».

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

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

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

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

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

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

Анатомия перфекционизма в ИТ-проектах

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

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

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

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

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

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

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

Третий сценарий – требование предусмотреть в первой версии ситуации, которые наступят только через годы. «А что, если через два года у нас будет сто тысяч пользователей и им понадобится массовая рассылка уведомлений?» – спрашивает заказчик на этапе, когда у него ещё нет ни одного живого клиента.

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

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

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

Коварство паралича перфекционизма в том, что в моменте он ощущается как зрелость и ответственность. Происходит это из-за:

• страха негативной обратной связи;
• иллюзии экономии;
• эмоциональной привязки к системе.

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

Метод минимально-жизнеспособного продукта

Первый метод борьбы с параличом заключается в создании и внедрении МЖП – минимально-жизнеспособного продукта. Идея проста: нужно сформулировать минимальный набор функций, без которого продукт физически не может выполнить свой основной сценарий.

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

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

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

«Если этого не будет, пользователь всё ещё сможет решить свою главную задачу?»

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

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

• Карточка товара с фотографиями
• Корзина
• Приём оплаты картой
• Личный кабинет пользователя
• История заказов в личном кабинете
• Система отзывов и рейтингов
• Рекомендации похожих товаров
• Программа лояльности с накопительными бонусами
• Интеграция с тремя службами доставки
• Мобильное приложение

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

Без оплаты картой? А вот здесь начинается проблема – если мы не дадим возможность заплатить, главная задача не будет решена. Оплата остаётся.

После такого отсева минимально-жизнеспособная версия нашего интернет-магазина выглядит так:

• Карточка товара с фотографиями
• Корзина
• Приём оплаты картой
• Одна интеграция со службой доставки (не три, а одна, которая покрывает большую часть случаев)

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

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

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

Метод подкрепления данными

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

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

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

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

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

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

Важно только говорить правильно: не спрашивать «хотели бы вы, чтобы в личном кабинете была выгрузка в PDF?», потому что на такой вопрос почти всегда отвечают «да», просто из вежливости или потому что звучит неплохо.

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

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

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

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

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

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

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

Метод обратного отсчета до запуска

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

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

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

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

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

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

Чтобы метод сработал, а не превратился в формальность, нужно соблюсти несколько условий.

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

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

Метод пользовательского интервью

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

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

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

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

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

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

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

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

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

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

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

Когда вы говорите «представьте себе личный кабинет с историей заказов», человек представляет что-то своё, и вы не знаете что. Когда вы показываете ему конкретный набросок, он сразу реагирует: «О, а зачем здесь эта кнопка?», «А почему история заказов спрятана в меню, я бы хотел видеть её сразу при входе», «А у меня в прошлом сервисе было удобнее сделано, могу показать скриншот».

Самые частые ошибки пользовательского интервью мы собрали в чек-лист:

• Рассказывать о продукте до того, как спросили о проблеме. Если вы первые десять минут описываете, какой у вас замечательный сервис, собеседник понимает, чего от него ждут, и дальше будет подыгрывать.
• Задавать наводящие вопросы. «Правда ведь неудобно, когда приходится вводить адрес доставки заново при каждом заказе?» – это не вопрос, а приглашение согласиться.
• Спорить с собеседником. Если человек говорит, что какая-то функция ему не нужна, не надо объяснять, почему он неправ и на самом деле она ему пригодится, вы пришли собирать данные, а не продавать.
• Проводить одно интервью и считать картину ясной. Один человек – это частное мнение, которое может быть случайным. Три человека – уже намёк на закономерность. Десять – вполне надёжная основа для выводов.

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

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

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

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