Внутренние инструменты - странный жанр. Ты не делаешь продукт для миллиона пользователей. Ты делаешь для двадцати человек, которые будут использовать это каждый день. Облажалась - скажут лично. Прямо на созвоне. Иногда с демонстрацией экрана, где всё сломано 💀

Я занимаюсь этим несколько лет: Python, внутренние сервисы, утилиты, автоматизация. За это время появился довольно конкретный взгляд на то, как надо работать. Не из учебника, а через синяки.

Мы никогда не работали наперёд

Ни разу. Всегда была живая проблема - что-то медленное, ручное, раздражающее. И всегда дедлайн.

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

Требования в словах и в действиях - это разные вещи. Почти всегда.

Однажды мне передали сервис

Задача звучала просто: добавь фичи, отдел ждёт.

Сервис работал исправно. Но когда начала копать под новый функционал - архитектура не предусматривала роста вообще. Я добавляла недостающий палец на руку, а у меня отваливались ноги.

Классика: делалось быстро, под давлением, “лишь бы работало”. Тогда это выполнило задание, но потом сервис стал важным, начал расти и каждое изменение превратилось в хождение по минному полю.

Справилась - добавила всё, что просили. Но потом пошла и честно рассказала с чем столкнулась: вот что работает, вот точки риска, вот что будет при росте. Без “тут всё плохо, кто это писал”, а конкретно и с примерами. Запросила полный рефакторинг. Одобрили.

Главный навык здесь - обосновать техдолг на языке рисков. Красивый код никого не волнует, а “это замедлит каждую следующую фичу вдвое” - волнует еще как.

Как я собираю требования

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

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

Последний вопрос - самый важный. Люди почти всегда описывают решение вместо проблемы. “Хочу кнопку, которая делает N” - на самом деле им нужно просто не переключаться между двумя системами руками. Это разные задачи.

После отдела - к лиду / сеньору с техстеком и архитектурным предложением. Не “вот мой план, согласуйте”, а “вот как я вижу, но где что не учла?”. Это сохраняет кучу времени потом - гораздо дешевле переделать на бумаге, чем в коде.

Когда говорю себе “готово”

Прохожу весь сценарий со стороны пользователя: типичный кейс, краевой, и тот, который сделают не так, как задумала (потому что сделают 100% 🙃)

Тестовая выдача паре коллег и кому-то из целевого отдела. Критичное - правлю сейчас, “было бы удобнее…” - в тудушку. Если тащить всё в релиз - не зарелизишь никогда.

Что я поняла

Внутренний инструмент - не упрощённая версия продукта, а другая ответственность. У продукта есть менеджеры, поддержка, роадмапа. Здесь ты и двадцать человек с конкретной болью. Если неудобно - продолжат делать руками. Молча. Ты, возможно, никогда не узнаешь.

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

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

А у вас было такое - получили сервис, который “работает”, но трогать страшно? Как вышли из этого?