Это не история про плохих менеджеров или выгорание. Это история о профессиональной эволюции: о том, как я, системный аналитик, осознала, что моя задача — не только передавать требования, но и активно участвовать в улучшении процессов, выявляя и устраняя узкие места.
Привет, Хабр! Меня зовут Хасият Юлдошева, я ведущий системный аналитик в Lenta tech («Группа Лента»).
Есть в нашей профессии красивый образ — «аналитик-мост». Мы соединяем миры бизнеса и разработки, обеспечиваем движение информации. Долгое время я искренне верила в эту модель и старалась быть идеальным мостом: пропускала через себя максимум задач, была всегда на связи, вникала во всё. Пока однажды не поняла, что из прочного моста я превратилась в единственное узкое «бутылочное горлышко» на всем проекте.
Эта статья — рефлексия о том, как я сместила фокус с роли «удобного исполнителя» на роль проактивного «адвоката качества».
Точка перелома: когда ты — единственный технический специалист
Изначально моя роль была четкой: системный анализ, написание технической документации. Но зона ответственности начала органически разрастаться — задача за задачей.
Ситуация усугубилась тем, что незадолго до этого проект неожиданно покинул тимлид по состоянию здоровья. Так образовался вакуум ответственности, и множество технических и организационных вопросов, которые раньше замыкались на нем, естественным образом перетекли ко мне.
Я не жаловалась. Работа была интересной, и я чувствовала свою значимость. Но был и побочный эффект: ко мне как к единственному техническому эксперту со стороны заказчика шли все — подрядчики, стейкхолдеры, бизнес-пользователи. Многие вопросы я решала налету, даже не успевая заносить их в систему управления задачами. К концу дня я с разочарованием обнаруживала, что не сдвинулась с места по своим основным задачам, потому что весь день тушила мелкие пожары.
Проблема: приближались приемо-сдаточные испытания (ПСИ)
Это был критический этап, требующий огромной организационной работы: собрать фокус-группу, объяснить им сценарии, собрать обратную связь, зафиксировать ошибки, отличить реальный баг от неправильного использования системы. И с точки зрения команды было логично поручить координацию этого процесса мне — ведь я лучше всех знала продукт изнутри.
В этот момент я ощутила подступающее выгорание. Мне казалось, что я просто плохо справляюсь, раз не успеваю всё. По просьбе руководителя проекта я составила список всех своих текущих задач — и формальных, и тех, что «прилетали» устно. Картина оказалась пугающей. Дело было не в том, что кто-то хотел меня перегрузить. Проблема была системной: в процессе приемки образовался вакуум ответственности, и я, как самый «удобный» кандидат, должна была его заполнить. Матрица RACI, висевшая в Confluence, была просто красивой картинкой.
Мои попытки объяснить, что это физически невозможно сделать качественно, не останавливая всю остальную аналитическую работу, приводили к стандартному ответу: «Мы понимаем, давай просто правильно расставим приоритеты». Но какие могут быть приоритеты, когда всё — важное?
Решение: Визуализировать проблему, а не жаловаться на загрузку. Понимая, что слова не работают, я решилась на другой шаг. На очередном созвоне с руководителем проекта, продактом и менеджером по внедрению я расшарила экран и сказала: «Коллеги, я хочу не обсуждать мою загрузку, а показать, как сейчас устроен наш процесс приемки и какие риски это создает».
На доске в Miro я в реальном времени нарисовала диаграмму приемки ПО. Я схематично изобразила все потоки задач — от тестирования до документации — и показала, какие роли, по моему мнению, должны отвечать за отдельные части этих потоков.
Это был не упрек. Это был сухой анализ процесса. Я не говорила: «я перегружена», я говорила: «процесс имеет узкое место, которое создает риски для сроков и качества». Диалог мгновенно стал конструктивным. Мы больше не обсуждали мою загрузку, мы обсуждали, как «расширить» это горлышко. В итоге задачи по организации ПСИ были переданы менеджеру по внедрению, для которого это была профильная работа. А я смогла наконец сосредоточиться на технических задачах, документации и контроле потоков данных.
Цепная реакция: битва за нагрузочное тестирование
Эта ситуация стала для меня катализатором. Я поняла, что моя задача — видеть такие «узкие места» заранее, а не тогда, когда уже «горит».
Тот же проект. Мы готовимся к запуску. Продукт сложный, предполагается высокая нагрузка. Как технический специалист, я понимала, что без нагрузочного тестирования (НТ) запускаться — игра в русскую рулетку. Мне необходимо было проверить соответствие нефункциональным требованиям, а сделать это вручную было невозможно. Но в первоначальном бюджете проекта НТ предусмотрено не было.
Проблема: как донести до руководства, не мыслящего в категориях RPS и latency, критическую важность этих тестов? Прямой запрос «нам нужно НТ» уже был отклонен с формулировкой «нет бюджета».
Решение: Говорить на языке бизнеса — на языке рисков. Я сменила тактику. Пошла к руководителю проекта и предложила обсудить два сценария:
Я не просила денег. Я предложила руководству взвесить риски. Я показала, что стоимость НТ — это не расходы, а страховка от гораздо больших потерь. «Это не трата, — сказала я, — а возможность купить уверенность в том, что в день запуска мы не потеряем больше». Диалог перешел из плоскости «тратить/не тратить» в плоскость «управлять рисками». Бюджет на тестирование был найден.
Чтобы получить объективную картину, мы привлекли для НТ другого внешнего подрядчика, а не того, кто занимался разработкой. Это дало нам независимую оценку. Весь процесс занял некоторое время, включая несколько итераций оптимизации. Результат превзошел все ожидания: после того как мы указали разработчикам на узкие места, время отклика системы сократилось в несколько раз. Мы вышли в прод с уверенностью, что система выдержит нагрузку.
Превентивный удар: ТЗ, которое экономит время
Осознав силу проактивного подхода, я посмотрела на свою базовую задачу — написание ТЗ — под новым углом.
Классическая ситуация: ты пишешь подробнейшее ТЗ, выкладываешь в Confluence, а потом в течение нескольких недель тебя постоянно выдергивают разработчики с уточняющими вопросами. Это отвлекает и замедляет всю команду.
Проблема: Раньше я думала, что разработчики просто невнимательно читают. У меня даже начал развиваться синдром самозванца: казалось, это я плохо формулирую мысли. Но после истории с «бутылочным горлышком» я задала себе другой вопрос: может, дело не в них, а в формате, в котором я подаю информацию? Стена текста, даже хорошо структурированного, сложна для восприятия, когда речь идет о динамических процессах.
Решение: Дополнять каждое сложное ТЗ простой Sequence-диаграммой. Я выбрала PlantUML, который позволяет описывать диаграммы текстом прямо в Confluence. Вместо абзацев, описывающих, «кто, кого, когда и с какими параметрами вызывает», я стала рисовать наглядную схему, которая «на пальцах» объясняет процесс.
Это был не дополнительный документ «для галочки», а центральный элемент ТЗ. Сначала я описывала бизнес-цель, а потом сразу давала диаграмму. Весь остальной текст стал лишь комментарием к этой схеме.
```plantuml
@startuml
title Пример:Процесс создания промо-акции
actor "Менеджер" as Manager
participant "UI (Фронтенд)" as Frontend
participant "Сервис акций (Бэкенд)" as PromoService
participant "Система SAP" as SAP
Manager -> Frontend: Заполняет форму новой акции
Frontend -> PromoService: POST /api/promo/create (данные акции)
PromoService -> SAP: Запрос на проверку остатков товара
SAP --> PromoService: Ответ (остатки, доступность)
alt Товар доступен
PromoService -> PromoService: Сохраняет акцию в БД
PromoService --> Frontend: 201 Created (ID новой акции)
Frontend --> Manager: Показывает сообщение об успехе
else Товар недоступен
PromoService --> Frontend: 400 Bad Request (ошибка)
Frontend --> Manager: Показывает ошибку
end
@enduml
```
Результат был ошеломляющим. Цикл разработки по таким задачам сократился почти в два раза, потому что исчезли бесконечные созвоны для уточнений. Количество вопросов от разработчиков по одной задаче упало в среднем с десяти до двух-трех. Они видели общую картину и приходили уже не с вопросом «а что тут делать?», а с конкретными предложениями по реализации.
От личной инициативы к культуре команды
Однако здесь кроется новая ловушка: став единственным «адвокатом качества», можно снова превратиться в «бутылочное горлышко», но уже на уровне методологии. Индивидуальная инициатива — это искра, но чтобы разжечь огонь, нужна вся команда.
В моем случае катализатором системных изменений стало развитие самой команды. Изначально отсутствие тимлида на проекте как раз и было одной из причин возникновения «бутылочного горлышка». Но к концу проекта у нас сформировалась полноценная продуктовая команда, и появился руководитель, который разделял ценности качества и амбициозно смотрел на развитие продукта.
Это стало отправной точкой для построения культуры, где качество — общая, а не чья-то личная ответственность. Вот как это сработало на практике:
Появление союзника. Моя инициатива нашла отклик у нового тимлида. У нас сформировался тандем, ориентированный на результат, а не на процесс. Это мотивировало и меня, и всю команду.
Устранение «вакуума ответственности». Проблема «бутылочного горлышка» была решена системно. В команду пришли новые специалисты — по сопровождению и бэкенд-разработчик с глубоким знанием продукта. Роли и обязанности были четко пересмотрены, что позволило мне вернуться к своим прямым задачам бизнес - и системного анализа.
Качество как общая цель. Когда руководитель грамотно распределяет обязанности и каждый специалист отвечает за свой участок, «героизм» перестает быть нужным. Ситуация, когда один человек тащит на себе всё, больше не повторится, потому что теперь за качество отвечает система, а не один человек.
Таким образом, индивидуальная инициатива — это не героизм, а катализатор. Один человек может подсветить проблему и показать, как ее можно решить. Но чтобы решение стало системой, нужна поддержка руководства, четкое распределение ролей и команда, где каждый чувствует себя «адвокатом качества» на своем месте.
Выводы, которые я сделала для себя
Моя роль на проекте не изменилась формально. Но изменилось мое отношение к ней. Я поняла, что быть просто «мостом» — это пассивная позиция. Настоящая ценность аналитика — в проактивности. В умении видеть не только требования, но и всю систему целиком: процессы, риски, коммуникации.
Быть «адвокатом качества» — это не про критику и поиск виноватых. Это про то, чтобы подсвечивать проблемы и предлагать решения. Иногда для этого нужна простая диаграмма, иногда — разговор на языке бизнеса, а иногда — просто изменить формат своей привычной работы.
А как вы видите границы роли аналитика? Приходилось ли вам выходить за рамки должностной инструкции, чтобы повлиять на качество проекта? Очень интересно будет обсудить в комментариях.
