В начале июля 2026 я потратила шесть рабочих дней на Python-автоматизацию для клиента — микрокоманды из трёх человек. Задача была простой: собирать данные из трёх источников (CRM, Google Sheets, почта), сводить их в один отчёт и отправлять в Telegram по пятницам. Я сделала скрипт на 400 строк с расписанием, логированием, обработкой ошибок. На шестой день сдала, клиент ответил одним вопросом — и я переписала всё с нуля.

Что я строила шесть дней

Сначала — схема данных. Я выгрузила три источника, посмотрела на колонки, нашла общее поле (id клиента), написала нормализатор. Дальше — модуль сверки: где источники расходятся, что считать эталоном, как отмечать конфликты. Дальше — генератор отчёта: шаблон в HTML, таблицы по сегментам, верхние 5 KPI, ссылка на исходники. Потом — Telegram-бот на aiogram, который берёт отчёт и шлёт в рабочий чат.

По дороге я добавила фичи, которые меня никто не просил: ретраи при сетевых ошибках, валидацию email-адресов, кеширование запросов к Google Sheets, автоматический архив старых отчётов в S3. Каждая фича добавляла 30-50 строк кода, каждый день — коммит в git, тесты в pytest, описание в README. К концу недели у меня был production-ready инструмент на 400 строк, готовый к деплою.

Я была довольна. Клиент — нет.

Вопрос, который всё изменил

Клиент посмотрел на первый отчёт и спросил: «А зачем тут верхние 5 KPI? У нас три клиента, я и так их всех знаю по имени.»

Это был не вопрос про баг. Это был вопрос про смысл. За три секунды он показал мне, что вся моя работа последней недели решала проблему, которой у него нет.

Я начала копать. Оказалось:

  • Кеширование Google Sheets — лишнее, источник обновляется раз в неделю руками, актуальность не критична.
  • Валидация email — в источниках email-адреса заполнены в 2% строк, поле декоративное.
  • Архив в S3 — клиент читает отчёты только в момент получения, через неделю про них забывает.
  • Ретраи при сетевых ошибках — у клиента стабильный интернет, за полгода не было ни одного сбоя.
  • Модуль сверки конфликтов — данные в трёх источниках никогда не расходились, поля просто разные по формату.

Из 400 строк кода 280 строк решали задачи, которых не существовало.

Что я сделала не так: пять ошибок anti-гайда

1. Спрашивала «что», а не «зачем». Клиент сказал «мне нужен отчёт по пятницам». Я побежала делать отчёт. Правильный вопрос был «зачем вам пятничный отчёт — что вы с ним делаете дальше?» Ответ: «Смотрю, кто из трёх клиентов задерживает оплату, и пишу им в личку.» То есть клиенту нужна была не аналитика, а список из 0-3 имён. Всё.

2. Накидывала «на будущее». Каждая вторая фича родилась из мысли «а вдруг пригодится». Архив — вдруг пригодится. Валидация — вдруг. Ретраи — вдруг. Правило: фича попадает в релиз, только если её можно отнести к конкретному решению, которое клиент примет в конкретный день. «Вдруг» — не решение.

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

4. Считала строки, а не решения. Метрика «400 строк production-ready кода» звучит как достижение. Реальная метрика — «1 строка в отчёте, ради которой клиент его открывает». Если бы я сразу спросила, какой последний отчёт реально изменил решение клиента, я бы построила 30 строк вместо 400.

5. Не показывала промежуточные результаты. Я показывала код в git, тесты в pytest, README в репозитории. Ни разу за шесть дней не показала клиенту промежуточный «отчёт, собранный из сырых данных», без всей обработки. Если бы показала на третий день — клиент бы увидел, что верхние 5 KPI бесполезны, и я бы перестроила архитектуру сразу, а не в конце.

Что я изменила в подходе к Python-задачам

Сейчас перед тем, как открыть редактор, я задаю клиенту пять вопросов:

  1. Что ты делаешь с результатом через час после получения?
  2. Какое последнее решение ты принял на основе похожего отчёта?
  3. Если результат будет пустым — это плохо или нормально?
  4. Когда результат перестанет быть нужным?
  5. Какую часть задачи ты готов делать руками, если она упростит инструмент?

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

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

Главный урок: Python-автоматизация — это не про то, что умеет Python. Это про то, что нужно клиенту. Остальное — лишний код.