📏 Сто раз отмерь, сто раз отрежь

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

Долгие итерации негативно влияют и на твою мотивацию, и на уровень коммуникаций в команде. Почему?

1. Долго делаешь? Тебе тяжелее воспринимать негативный фидбек. Представь себе ситуацию, что ты делал что-то пол года но уже первый тест показал, что всё это не то и нужно идти в другом направлении. Сколько продлится твоя мини-депрессия?
2. Долго делаешь? Людям вокруг сложнее тебе сказать, что это можно сделать лучше, потому что см. п. 1. Вместо ориентации на продукт команда будет ориентироваться на эмпатию. «Ой, сейчас ему скажу, что можно было сделать по-другому и лучше, а он обидится – он же это 3 месяца делал. Лучше промолчу!». А что выберешь ты, сделать лучше продукт или не задеть чьи-то чувства? Так просто не ставь людей перед таким выбором.
3. Долго делаешь? Тебе сложнее держать фокус. Мотивация делать новый проект всегда выше, чем заканчивать что-то, начатое полгода назад. «Вот сейчас мы ещё чуть-чуть допилим и точно выкатимся!» – в 80% случаев ложь. Доделаете – придумаете, как сделать ещё лучше. И снова никто это не увидит. Кто любит делать что-то в стол?
4. Долго делаешь? Ты не делаешь другие вещи, а значит они простаивают. Или наоборот, ты делаешь их параллельно, теряя фокус с большой задачи

Как этого избежать?

• Используй правило OHIO – only hold it once. Сделай минимально рабочее решение, выкати его в прод и забудь о нём до следующей итерации. Либо у тебя будет новая цель для улучшения сделанного, либо сделаешь другую задачу/фичу/проект
• Декомпозируй. Раздели большой продукт/фичу на небольшие, но рабочие куски – так будет возможность в любой из промежуточных шагов уже выкатить всё на реальных пользователей. А долгосрочное видение поможет заложить правильную архитектуру для дальнейшего улучшения

Отвечаешь за код? Чаще показывай и тестируй его

• Сразу открой pull request, коллеги будут делать ревью параллельно твоей работе и тебе сложно будет уйти не туда
• Чаще мёрж свои пулл-реквесты. Так не будет конфликтов и будет больше уверенности, что ничего нигде не сломалось
• Запланируй откат. Выкатить баг на прод – не проблема, проблема – не иметь возможности быстро его откатить или пофиксить.

Отвечаешь за продукт? Чаще релизь

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

------

Посты в Яндекс.Дзене выходят позже. Хотите получать без задержки? Подписывайтесь на телеграм-канал Saturday Night Hack