← Назад в блог

Почему я веду список «что НЕ делать в следующем проекте»

После каждого проекта я открываю одну и ту же заметку. Называю её «что не делать в следующем проекте». Там не «что прошло хорошо» — это в ретроспективу. Только одно: что именно я не повторю.

За два года там 23 пункта. Некоторые из них стоили клиентам денег. Некоторые — мне.

«Lessons learned» документы пишут для команды. Этот файл только для меня. И он меняет то, как я разговариваю с новым клиентом, ещё до того, как проект начался.

Почему уроки проекта исчезают

Ретроспектива — хороший инструмент. Но она решает командную проблему: как мы работали как группа. Личные решения там не выживают.

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

Знания в голове не считаются. Только то, что написано.

Лучшие практики стареют. Фреймворки меняются, рынок другой, подходы переписываются. Список ошибок не стареет. Больно было тогда — помнишь точнее, чем любую методологию.

Как выглядит мой список — формат и категории

Простая структура. Никакого специального инструмента — у меня это plain text в Obsidian:

Дата: 2023-04-10
Проект: e-com на Bitrix, каталог 8k SKU
Категория: оценка
Пункт: не оценивать каталог до базового профайлинга
Последствие: недооценил в 2 раза, потерял три недели

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

Конкретные ошибки с конкретным ущербом, не умные мысли.

Пять пунктов, которые появились за последние два года

Вот реальные записи — немного перефразированные, чтобы не дублировать клиентские детали, но суть не изменена.

  1. Не брать проект без аудита архитектуры.

Зимой мне предложили $40K на rewrite Bitrix-магазина с 28 000 позиций. Клиент был уверен, что Bitrix тормозит. Я попросил два дня. Оказалось — кастомные запросы без индексов и неправильный OPcache. Rewrite был бы три месяца работы за деньги, которые не нужны. Я отказался от контракта. С тех пор первый шаг любого контракта — диагностика. Факты до оценки.

  1. Не соглашаться на интеграцию без API-документации.

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

  1. Не оценивать производительность без профайлинга.

Когда клиент говорит «страница грузится медленно», первый инстинкт — смотреть код. Это ловушка. LCP 3.8s может быть от сервера, от CDN, от стороннего скрипта аналитики. Без профайлинга — никакой оценки. После одного проекта, где я потратил неделю на оптимизацию запросов и улучшил LCP на 0.1s, я этот пункт записал навсегда.

  1. Не закрывать тикет — закрывать риск.

Если задача «добавить кнопку» и ты добавил кнопку — хорошо. Но если за этой кнопкой прячется логика, которая затрагивает корзину, авторизацию и 1С-синхронизацию, кнопка — это риск, не тикет. Я перестал измерять полезность через velocity. Спрашиваю: какой риск я закрываю этой задачей? Про это подробнее в статье «Я перестал закрывать тикеты».

  1. Не брать проект у клиента, который не называет метрику успеха.

«Хочу, чтобы было лучше» — не метрика. «Конверсия корзины должна вырасти с 2% до 3%» — метрика. Если к третьему созвону клиент не называет конкретное число — два варианта: помочь сформулировать, или не брать. Без метрики нет критерия сдачи, а без критерия сдачи проект не заканчивается.

Чем этот список отличается от ретроспективы

Ретроспектива командная. Она про процесс: стенд-апы, реакция на блокеры, что замедляло спринты. Нужная штука.

Но ретро публичная. В публичном документе не пишешь «я недооценил в два раза из-за самонадеянности». Там пишут «планирование нужно улучшить». Политически нейтрально. Лично бесполезно.

Список личный. Что именно я решил, что вышло не так, что не повторять. Он со мной на следующем проекте. Ретро — нет.

Как список меняет разговор с клиентом

Теперь на пресейле я открываю список и быстро сканирую: есть ли у этого клиента признаки ситуаций из моих записей? Нет API-документации — проверяю пункт 2. Говорят про «медленный сайт» без цифр — смотрю пункт 3.

Фильтр, не параноя.

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

Минимальный шаблон — как начать

Три колонки:

| Что сделал | Что получилось | Что не повторять | |---|---|---| | Взял интеграцию без доков | 3 недели лишней работы | Контракт только с документацией |

Инструмент не важен: Obsidian, Notion, Google Doc, текстовый файл. Важно одно правило: запись делается сразу после деплоя или сразу после неудачи, пока боль свежая.

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

Best practices guides стареют. Next.js 14 стал 15, методологии поменялись, рынок другой. Список собственных ошибок не стареет. Больно было тогда — значит, помните.

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