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

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

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

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

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

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

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

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

Есть, кстати, и культурный слой. Во многих командах ценится скорость реакции. Быстро починил – ай, молодец! Срочно выкатил фикс – ну вообще герой! А вот человек, который потратил время на то, чтобы изначально сделать хорошо и без багов, запросто останется в тени. Его вклад для некоторых будет не так очевиден. Вот в итоге и формируется привычка: сначала сделаем, потом разберемся. И она подкрепляется со всех сторон - психологией, процессами и даже системой поощрений. 

Но, по сути, проблема (да и проблема ли?) не в самих переделках. В той же истории про двух разработчиков именно они и привели к успеху второго. Дело в том, что переделки часто происходят не как осознанный этап, а как побочный эффект спешки. В общем то, можно упростить задачу до крайности и работать под девизом "делай быстро, потом исправишь". Можно уйти в другую крайность и попытаться сразу учесть все. Оба варианта в чистом виде плохо работают. 

Более живой подход появляется, когда ты начинаешь видеть разницу и расставлять приоритеты. Где-то действительно важна скорость выхода и можно позволить себе сырой старт. Где-то цена ошибки слишком высокая, и лучше потратить время заранее. Где-то имеет смысл сделать прототип, но осознанно не тащить его в продакшн. И главное - фиксировать для себя, что именно ты сейчас делаешь? Это временное решение или постоянное? Ты правда потом вернешься к этому месту или это "потом" просто способ не думать сейчас? 

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