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

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

Когда-то я понял, что сам попал в эту ловушку.

У меня была идея для стартапа. Я размышлял о ней неделями: «Вот если бы у меня были инвестиции, вот если бы я мог нанять команду...» И в какой-то момент в разговоре с более опытным человеком он спросил меня прямо:

«Что мешает тебе создать MVP прямо сейчас и проверить гипотезу?»

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

Сегодня, когда ИИ дал каждому инструменты для быстрого создания рабочих прототипов без навыков программирования, я вижу ту же картину. Люди проводят недели, описывая «идеальный космолет». Они детализируют каждую фичу, продумывают архитектуру, согласовывают требования. А в этом описании- куча неизвестных, ответы на которые можно было бы получить за пару дней, создав простой MVP и показав его пользователям.

Но они не делают этого. Они ждут, когда ИТ-команда освободится. Они ждут бюджет. Они ждут «правильный момент».

А гипотеза в это время остаётся непроверенной.

Что изменилось, когда я перестроился

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

1. Спрашивать себя: «А что мешает проверить это прямо сейчас?»- если нет объективных ограничений, почему я жду? 2. Отличать «критическое» от «интересного». Большинство вопросов можно проверить прототипом, а не ждать реализации полноценного решения. 3. Использовать ИИ не для описаний, а для действия. Сделать прототип, собрать обратную связь, скорректировать гипотезу. Всё это быстрее и дешевле, чем ждать дорогую команду. 4. Привыкать к неидеальным решениям. MVP должен быть минимальным, а не «почти готовым продуктом». 5. Перестать путать активность с результатом. Долгое описание «идеального» решения- это активность. Быстрая проверка гипотезы- это результат.

Как это применимо в корпорации

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

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

Итог

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

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