Уже 8 лет я — бэкенд-разработчик. Последние три года работаю в продуктовой компании, где до недавнего времени все ценили мой подход к работе: архитектура, чистый код и продуманная система всегда стояли на первом месте. Если что-то делали, то делали хорошо, чтобы потом не переделывать.
Меня часто спрашивали о технических решениях, новички приходили за советом, а менеджеры уточняли реалистичность сроков. В общем, комфортная и понятная среда.
Да, иногда я становился тем самым душнилой, который на каждом собрании говорил о правильной архитектуре, паттернах проектирования и важности чистого кода. И команда это принимала. Потому что все работало стабильно.
Но эта история не о моих звёздных временах. Она о том, как наша компания переключилась с философии «хорошо с первого раза», до «кодим как можем, фиксим на проде», и как я ̶с̶ ̶э̶т̶о̶г̶о̶ ̶о̶ф̶и̶г̶е̶в̶а̶л̶ к этому привыкал.
Дисклеймер: статья написана специально для блога Minervasoft на основе работы с источниками и личного опыта автора.
Новый CTO и его философия «делаем как получится»
В компании сменилось руководство. Новый технический директор пришёл из какого-то стартапа в Сколково, который недавно привлёк инвестиции. На первой презентации он рассказывал про agile, про то, как важно быстро выпускать продукт на рынок и итерироваться. Ничего такого, с чем я бы в принципе спорил.
Но вот дальше стало интереснее. Оказалось, что «быстрые итерации» на его языке означают «делаем как получится, а потом будем фиксить». А моя любовь к продуманной архитектуре стала называться «избыточным перфекционизмом» и… бюрократией…
Впервые ситуация стала меняться на совещании о разработке нового платёжного модуля. Я предложил наш обычный подход: сначала документация, детальное проектирование API и архитектуры. Новый CTO назвал эти этапы пустой тратой времени и потребовал немедленно начать писать код.
Я напомнил про технический долг, но в ответ услышал что-то вроде «разберёмся потом». Всё происходящее казалось сном или какой-то параллельной реальностью. Моё сознание активно сопротивлялось происходящему — классический этап отрицания, как в учебнике по психологии.
Новые приоритеты
Следующие несколько месяцев я наблюдал, как меняются приоритеты. Запланированный рефакторинг отложили. Код-ревью стали поверхностными — «лишь бы работало». А мои комментарии про такой формат работы начали вызывать нескрываемое раздражение у начальства.
Кульминацией стало обсуждение выбора фреймворка для нового микросервиса. Я настаивал на Django — проверенном, с большой экосистемой, позволяющем быстро и безопасно создавать сложные системы. Считал, что с Django у нас будет меньше багов и быстрее разработка в долгосрочной перспективе.
Новый CTO продвигал Flask. По его мнению, это простой и понятный фреймворк, ничего лишнего. С ним можно быстрее освоиться и быстрее сделать MVP.
В итоге выбрали Flask, хотя это означало, что многие вещи нам придётся реализовывать с нуля — авторизацию, ORM-настройки, админку. Когда я подсчитал, что в итоге мы потратим больше часов, меня уже никто не слушал. Важной стала скорость получения первых результатов, а не общая эффективность.
Я сидел и думал — когда именно я превратился из уважаемого специалиста в динозавра, тормозящего «гибкие бизнес-процессы»?
Новые KPI
Изначально я был не единственным, кому было сложно принять новое положение вещей. Мои коллеги тоже испытывали трудности: фронтендеры жаловались на кучу багов из-за спешки, QA — на поток тестирования без времени на автоматизацию, а аналитики не успевали документировать изменения.
Вскоре обновили KPI. Раньше мои показатели включали надёжность систем, количество инцидентов и время простоя — всё то, что мотивировало писать качественный и стабильный код. Теперь главными метриками стали:
Количество закрытых задач в спринте.
Скорость релизов.
Процент выполненных бизнес-требований в срок.
Чистый код? Документация? Архитектурные улучшения? Не, не слышали.
На одном из регулярных one-to-one с CTO я попытался объяснить, почему это проблема. Привёл пример нашего платёжного сервиса, который мы полгода назад переписали с более продуманной архитектурой и с тех пор не имели ни одного серьёзного инцидента.
Он ответил, что сейчас компания находится в совсем другой ситуации. Мы сжигаем деньги инвесторов, и если не покажем рост через полгода, никого не будет волновать, насколько элегантна наша архитектура. Я чувствовал себя точь в точь как в сериале “Консультант” с Кристофом Вальцем.
Я понимал логику. Но одновременно видел, как технический долг накапливается со страшной скоростью.
Начал замечать, что меня всё реже приглашают на обсуждения. Что новый разработчик, который пишет быстро, пусть и с багами, получает больше внимания и одобрения. Что мои технические знания, которыми я гордился, в новой реальности не так уж и важны.
А потом меня просто не позвали на встречу, где обсуждали архитектуру модуля, над которым я работал полгода. Полгода работы, ни одного серьёзного бага — и вот так.
Впервые за много лет я почувствовал, что могу потерять работу. Тогда я всерьёз задумался: либо стараюсь адаптироваться, либо за борт. За борт не хотелось.
Мнение с другой стороны
Мне пришлось поговорить напрямую с руководством, чтобы понять их мышление. Компания серьезно меняла свою бизнес-модель, и скорость вывода продуктов на рынок стала жизненно важной. Мы общались 2 часа. Многое стало понятнее.
Разработка всегда должна идти в ногу с бизнесом — это очевидно. Но главные ценности изменились: вместо стабильности и надежности стали важны скорость и гибкость. А я всё ещё работал по-старому.
Я не один испытывал дискомфорт. Команда фактически разделилась на два лагеря:
«Старая гвардия» — разработчики, привыкшие к качественному коду и продуманной архитектуре. Они скептически смотрели на новые подходы.
«Новая волна» — недавно пришедшие и те, кто быстро адаптировался к новому стилю. Они легко принимали идею «делаем быстро, потом доработаем».
Одни вечером оставались, чтобы рефакторить особенно проблемные участки кода (уже не в рамках задач, а просто потому что «так жить нельзя»). Другие штамповали фичи, не особо заботясь о завтрашнем дне.
Один опытный коллега поделился со мной, что после перехода на новый формат работы количество инцидентов выросло на 20%. Но никто как будто не замечает. Когда он попытался обсудить это с CTO, тот сказал, что пока мы укладываемся в SLA, это приемлемая цена за скорость.
Мой взгляд на работу постепенно менялся. Когда одна коллега спокойно писала модуль, зная, что через месяц его выкинут, я не испытывал возмущения. Она считала это нормальным, поскольку нам нужно было быстро проверить гипотезу. Окей, если так. Раньше я назвал бы это мартышкиным трудом.
Пять приёмов, которые помогли мне адаптироваться
Сначала было тяжело. Я привык делать хорошо, а не быстро. Я считал, что качество важнее сроков. Но, судя по всему, такой подход крайне устарел в наших реалиях.
Я пробовал работать по-другому. Вместо того чтобы сразу предлагать продуманное идеальное решение, я начал с минимально работающей версии, а потом постепенно её улучшал. Это было непривычно и, честно говоря, больно для моего перфекционистского сердца. Но так действительно получается быстрее.
А ещё я стал вести список технического долга — чтобы не забыть вернуться к проблемным местам, когда появится время.
Вот несколько приёмов, которые мне помогли:
Техдолг как проект. Я создал Jira-доску с техническим долгом, оценил каждый пункт и привязал его к конкретным бизнес-рискам. Например: «Отсутствие тестов в платёжной системе —> риск финансовых потерь и репутационного ущерба при сбоях». Всё стало визуализировано, а не просто жило в моей многострадальной голове.
Тактика малых побед. Вместо того чтобы предлагать недельный рефакторинг, я стал выделять маленькие улучшения, которые можно внедрить за 2-3 часа.
Разговор на языке бизнеса. Я пересмотрел свою коммуникацию. Разговоры на «языке бизнеса» всегда вызывали у меня какое-то непреодолимое жжение в определенной области. Но сейчас я понимаю, насколько важно уметь общаться и договариваться с руководством на их языке. Вместо «нам нужна вот такая архитектура» я стал говорить «это ускорит внедрение фич в будущем и снизит количество багов на X%».
Компромиссы с измеримой выгодой. Я научился идти на компромиссы, но с чётким пониманием, что мы получаем взамен. «Хорошо, мы можем сейчас сделать быстрое решение, это сэкономит нам 3 дня. Но давайте запланируем 1 день через две недели на рефакторинг, иначе мы потеряем эту экономию на сопровождении».
Работа с новыми инструментами. Я стал активнее использовать корпоративные инструменты и нашу базу знаний Minervasoft.
Осторожно, реклама! Это корпоративный блог. Мы сделали его, чтобы о Minervasoft узнало больше людей.
Мы показываем продукт в каждой статье — это цель блога. Без этого контента бы не было.
Мы понимаем, что рекламные вставки раздражают, особенно когда они «нативные». Поэтому предупреждаем: дальше герой расскажет, зачем ему понадобилась база знаний и как Minervasoft помогла решить его проблему. Спасибо, что читаете.
Когда новый СТО настоял на внедрении Minerva Knowledge, я был из тех, кто отнёсся к этому с прохладцей – еще одна система, в которой надо копаться. Но со временем мои коллеги начали меньше обращаться ко мне с вопросами и как-то больше самостоятельно вникать в процессы. Моя личка буквально пустовала.
Я решил дать шанс базе, и она действительно оказалось удобна. Раньше я думал, что корпоративные базы — как бабушкин сундук: вроде все есть, но найти невозможно. А тут поиск работает отлично, на уровне Яндекса. Когда я печатаю с ошибками или забываю переключить раскладку (ghbdtn), система всё равно находит нужные документы.
Особенно зашла функция с Wiki-структурой. Я организовал все наши архитектурные решения по модулям, и теперь, когда какой-нибудь джун спрашивает почему мы используем тот или иной паттерн, я просто кидаю ссылку вместо получасовой лекции.
Недавно попробовал пошаговые сценарии. Я создал инструкцию диагностики проблем в нашем платёжном API. Если кому-то из команды понадобится, зайдут и посмотрят. Удобно, что всё в одной системе — не нужно скакать между Миро, Джирой и другими сервисами.
Постепенно лёд начал таять. Новый CTO одобрил моё предложение по рефакторингу одного из модулей — правда, только после того, как я объяснил, как это ускорит внедрение нового функционала, который очень ждал бизнес.
Попробовать продукты Minervasoft
Первые признаки успеха
Переломный момент наступил, когда мы столкнулись с серьёзной проблемой в продакшене. Быстро созданный платёжный сервис начал дублировать транзакции в определённых сценариях — классическая проблема с race condition.
Команда билась над проблемой два дня без результата. В конце концов, CTO попросил меня взглянуть.
Я провёл вечер, анализируя код и системную архитектуру. Бардак. На утро представил не только решение, но и детальную схему того, как правильно организовать процесс обработки платежей с учётом всех краевых случаев.
CTO был впечатлён и спросил, сколько времени нужно на внедрение. Я ответил, что два дня на исправление текущей проблемы и ещё неделя, чтобы перестроить архитектуру и избежать подобных проблем в будущем.
К моему удивлению, он согласился на полное решение. А через неделю, когда мы успешно всё внедрили, он сам спросил, какие ещё системы требуют доработки.
Три важных урока, которые я извлёк из этого опыта
Технический перфекционизм — это сильное преимущество, но нужно смотреть на реальные задачи компании. Новый подход к работе уже не кажется таким ужасным, и я наконец-то снова кайфую от своей работы. Да и зарплата выросла благодаря развитию компании.
Адаптация — это не предательство своих принципов. Я просто добавил новые инструменты в свой арсенал. Конечно, я до сих пор ценю хорошую архитектуру и чистый код. Но теперь понимаю, что иногда быстрое и работающее решение лучше, чем идеальное, но опоздавшее к рынку.
И самое главное — я понял, что моя ценность как разработчика заключается не только в технических знаниях, но и в умении применять их в правильном контексте. Не в вакууме идеального мира разработки, а в реальности, где бизнес-потребности постоянно меняются.
Звучит как довольно простая мысль. Но поверьте, когда годами работаешь в одной парадигме, понять и принять новую — чертовски сложно.
Несколько месяцев спустя
Я всё ещё работаю в той же компании. У меня меньше контроля, но, возможно, больше влияния — через обучение команды и поддержку правильного баланса между скоростью и качеством.
Иногда я скучаю по тем временам, когда мог неспешно продумывать архитектуру до мелочей. Но надо признать, что новый подход научил меня многому. И, может быть, сделал разработчиком лучше — хотя и не таким, каким я представлял себя раньше.
Недавно, когда мы запускали новый сервис, CTO сам предложил выделить доп время на проектирование одного модуля — мол, он слишком критичен для быстрых решений. Видимо, где-то мы нашли правильный баланс, хоть и спустя время.
У Minervasoft есть свой блог в Telegram — там будут выходить другие статьи про спорные вопросы в найме, менеджменте и планировании. Подпишитесь, чтобы не пропустить.