Что я делал три года в крупном e-commerce, и почему самое трудное там было не про код

Рамка

Сразу оговорюсь, чтобы не было путаницы: это не клиентский проект и не услуга, которую можно у меня заказать. Это работа по найму в крупном российском e-commerce. Название компании я не назову ни здесь, ни в разговоре - оно под юридическим запретом.

Пришёл туда разработчиком в декабре 2022, дальше был тимлидом бэкенда, последнюю часть времени - техлидом кластера. Ушёл 14 ноября 2025, всего около трёх лет. Под конец под мной была вся техническая команда направления - бэкенд и тестировщики; в прямом подчинении три бэкенд-разработчика, работали спринтами по две недели.

Отвечал я за домен подарочных карт - розничных и корпоративных, на рынках Ближнего Востока и Казахстана. Чтобы был понятен масштаб: за это время продажи корпоративных карт выросли вдвое, потому что процесс автоматизировали целиком, а розничных - примерно на 20%, потому что расшили узкое место в оформлении заказа. Это результат команды, я ей руководил.

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

Инициатива первая: сообщения между сервисами

Что было до

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

Дальше начиналось человеческое. Нужно было прийти к другой команде, объяснить, попасть в её очередь задач и дождаться. Согласование отправки одного тестового сообщения занимало дни, а иногда растягивалось на неделю.

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

Как это выглядело в деньгах: в Казахстане у нас отваливалась оплата, каждый третий платёж, иногда второй. Чтобы поймать причину, приходилось вручную идти в банк и переключать режим оплаты туда-обратно.

Что я делал девять месяцев

С августа 2024 по апрель 2025. Самое долгое в этой истории происходило не в коде.

Начал не с инструмента, а со списка: пошёл к тестировщикам и собрал, что именно им мешает. Потом оформил решение как ADR - внутренний документ, в котором предложение описано вместе с обоснованием, зачем оно компании и чем мы за него платим. Без такой бумаги в большой организации разговор не начинается.

Два месяца я доказывал, что это вообще нужно. Бесконечные согласования. Сопротивление шло с двух сторон: комитет разработки и служба безопасности. И спорили мы не про инструмент. Спорили про права: кому, в какой команде и на каких тестовых средах (это копии системы, где всё пробуют до боевого запуска) можно разрешить отправлять сообщения. В большой компании инициатива умирает вот здесь, на вопросе «кому что можно», а не на технологии.

Бюджет я выбивать не пошёл. Взял бесплатную версию Conduktor - это удобный интерфейс к Kafka, той самой системе почтовых ящиков, - и довёл её до состояния, в котором ею пользуются. Потом ждал, пока её развернёт команда инфраструктуры; эта часть от меня уже не зависела совсем.

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

Дальше провёл две лекции для знакомства с технологией, несколько воркшопов и курировал написание документации. Потом автоматизировал выдачу прав и перевёл её в службу поддержки, так что посредник в моём лице стал не нужен.

Что получилось

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

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

До этого к тем же ящикам ходили через инструмент попроще, Kafdrop. Conduktor его вытеснил и стал в компании основным входом ко всем этим сообщениям - для всех, кому туда вообще надо. Сколько это людей, я точно не скажу: несколько сотен, порядка трёхсот-пятисот. Историю с казахстанскими платежами закрыли им же.

Сколько это сэкономило в часах, я посчитать не берусь. Часть эффекта - это возможности, которых до внедрения просто не было, и сравнивать их не с чем.

Инициатива вторая: нейросеть пишет юнит-тесты

Юнит-тесты - это маленькие проверки, которые разработчик пишет к собственному коду, чтобы тот не сломался незаметно. В 2025 году их сделали обязательными, внесли в критерии готовности задачи, и команда писала их из-под палки. Нагрузка стала заметной.

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

Один юнит-тест: было один-два часа, стало около двадцати минут. Держалось три спринта подряд. Разработчики оценили качество сгенерированных тестов на 4 из 5, где 1 - сырой черновик, а 5 - почти не требует правок.

Ценность тут не в том, что нейросеть умеет писать тесты. Это умеет любая. Ценность в том, что ею стали пользоваться каждый день, потому что появился интерфейс, промпт под конкретный код и полчаса объяснений.

Инициатива третья: как команда разбирала задачи до начала работы

Что было до

Прежде чем строить новую функцию, команда садится её разобрать: что именно делаем, кто что берёт, где подводные камни. Собирались на такой разбор всей командой, 15 человек, в среднем на час. Встреч на одну функцию выходило от 3 до 20, смотря по объёму.

Участвовали и те, кому это было не нужно, то есть тратили время всей команды. Контекст между встречами забывался - первые 15 минут каждой уходили на то, чтобы вспомнить, о чём вообще речь. Много вопросов оставалось без ответа, а на отвеченные потом никто не мог найти, где ответ. Спецификацию дописывали задним числом, и она работала как архив, а не как единая актуальная точка правды.

Что я сделал

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

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

Новый процесс презентовал 7 июля 2025, провёл воркшоп. Чтобы не спорить на словах, прогнал старый и новый порядок параллельно на двух функциях и сравнил, что вышло. Дальше команда по нему работала - это не осталось красивой презентацией.

Что получилось

Время на встречи сократилось вдвое. Пересогласований стало одно-два вместо пяти-десяти. Оценки сроков стали точнее, тестировщики перестали терять контекст.

А главный результат в цифру не ложится. Стало прозрачно, как работает команда и кто на каком основании что решает. И у тестировщиков появилось окно, чтобы задать вопрос. Раньше такого окна не было.

Что сказала команда

Отзывы разошлись, и это, по-моему, интереснее любой цифры выше.

Тестировщики: «звучит супер». У них главная боль была ровно в том, что контекст теряется и ребята терялись в итоговых решениях. Аналитики согласовали. Фронтендеры сказали «звучит хорошо, есть пара моментов» и отдельно пожаловались, что сессий разбора стало больше по количеству. На старте так и было. Потом логика упростилась, все привыкли, кому на какую встречу идти, и жалоба ушла сама: каждая сессия короче, а в сумме времени уходит меньше.

А бэкендеры отозвались сдержанно: «звучит прикольно, но ничего особо не поменялось».

И они правы, спорить тут не с чем. В их ежедневной работе действительно почти ничего не поменялось - они и до реформы разбирали задачи примерно так же.

Поменялось у других. Сильно выросла прозрачность: стало видно, как вообще устроена работа команды, кто чем занят и на каком основании принято решение. А больше всех выиграли тестировщики. До реформы у них не было ни одной точки, где можно задать вопрос. Вообще ни одной: им приносили готовое решение, и они в нём терялись. Появилась своя встреча - и вопросов пошло заметно больше. Ровно тех, которые раньше всплывали поздно и стоили дорого.

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

Как мы это мерили

Цифры выше разной природы, и я хочу, чтобы вы это видели.

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

Минуты вместо дней в первой истории устроены иначе. Там ничего не оценивали: раньше нужно было дождаться другой команды, теперь ждать некого. Это видно из устройства процесса.

Цифры по разбору задач ближе к первому типу, чем ко второму: время встреч я считал по календарю, а вот «оценки стали точнее» - это ощущение команды, и я его так и подаю.

Разница между «люди говорят, что стало быстрее» и «ждать больше нечего» существенная. Первое можно оспорить, второе нет. Я предпочитаю говорить, какая цифра к какому типу относится, чем округлять всё до одинаково уверенного вида.

Что из этого следует

Все три истории про одно. Технология в них не главное: инструмент для сообщений существовал давно, нейросеть стояла в компании и до меня, а в третьей истории технологии нет вообще - там одни люди и календарь. Не работало то, что вокруг: права, согласования, отсутствие интерфейса, никто не показал, как этим пользоваться, и никто не спросил, кому на встрече вообще есть что сказать.

Поэтому я и считаю внедрение законченным не тогда, когда что-то запустилось, а тогда, когда люди пользуются этим на следующей неделе без меня. Дорога от «работает у меня на экране» до «работает у всех» обычно длиннее самой разработки. В первой истории она заняла девять месяцев из девяти.

С бизнесом снаружи ровно та же механика, только вместо комитета по разработке - ваши люди и ваши привычки.