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

В их представлении IT-специалист — это такая фея, которая по умолчанию разбирается в юриспруденции, финансах, всех федеральных законах, а в перерывах пишет код.

Поначалу я думала, что самое сложное в работе системного аналитика — это разбираться в коде или проектировать системы. Но быстро поняла: главное — научиться быть переводчиком между двумя мирами, каждый из которых говорит на своем языке.

Я уже несколько лет пытаюсь искать свои способы наладить этот «глухой телефон», и получается далеко не всё.

Первая встреча с реальностью произошла на задаче по отсрочке платежа. Открываю бизнес-требования и вижу то самое: «Учтите в учёте соответствующим образом».

Для бизнеса это было логично: есть IT-департамент со специалистами, которые должны знать технические детали. Их задача — поставить цель, а как её реализовать — уже наша работа.

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

Когда стала задавать вопросы заказчику, он тоже не смог на них ответить, потому что это тоже не его область экспертизы. «Идите туда... ну, к кому-нибудь, кто-то там вам сможет рассказать», — слышала я. А в ответ на формальный запрос могла также формально прилететь ссылка на страницу в Confluence двухлетней давности, где всё уже неактуально. Такова жизнь любой крупной организации: обратная сторона узкой специализации команд и отделов, где каждый занимается своим делом и часто плохо представляет, что и как делают коллеги.

Я тоже не представляла. И разбираться было страшно, но проект сам себя не сделает, так что пришлось.

А чего сложного-то?

На бумаге — задача простая: дать клиенту отсрочку платежа по кредиту.

Заявка от клиента может прийти из трёх точек: мобильного приложения, с сайта банка или из офиса. Этим занимается одна команда. Данные вносятся в учётную систему и передаются в Хаб, который затем общается ещё с одной системой.

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

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

Через полтора месяца должен был начаться общий старт, и… начались сложности.

Когда всё летит в /dev/null

Команда смежников, с которыми мы обо всём договорились, проводила реорганизацию. Мы ждали нового сотрудника, чтобы объяснить ему всё с нуля.

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

И над всем этим - бизнес-заказчик с вечным рефреном о сорванных сроках. Для заказчика и для наших клиентов внутренняя IT-кухня неважна — важен результат. Поэтому и объяснять про уволенных людей или архитектуру бесполезно.

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

Обменялись именно компетенциями, чтобы выйти одновременно в срок. Вышли в релиз день в день. Просто поговорив.

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

Как я начала чинить процесс

Постепенно я начала вносить изменения:

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

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

• Научилась использовать регламенты в свою пользу. Раньше они меня раздражали, а теперь стали защитой: «Мы не можем взять задачу завтра, по регламенту у нас двухнедельное планирование». И оно действительно необходимо, так получается даже быстрее.

Самое важное — я прошла обучение на медиатора. Это кардинально изменило мою коммуникацию с бизнесом.

Неожиданные инструменты

Один из самых ценных для меня навыков — научиться не эмоционировать на давление заказчика. Меня постоянно пытались провалить в «детскую» позицию. И с «детской» позиции я ничего не могла ответить. Меня научили возвращать ответственность: «А что вы можете сделать? Как можете помочь мне?»

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

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

Я поняла важность доверия. Когда спрашиваю у разработчика, сколько времени ему нужно на задачу, он называет срок, и я жду этого срока, не тереблю его. Из 14 человек только один не соблюдает обещаний, я это знаю и работаю с ним отдельно.

Микроконтроль ушёл, получается планировать не только на две недели вперёд, но и думать о квартале.

После перехода на удалёнку пришлось заново выстраивать коммуникацию. Люди, которые полтора года хотели просто получать задачи и работать в тишине, вдруг захотели общаться. Теперь мы созваниваемся, делимся тем, что происходит. Это совсем другая связь в отличие от офиса, но она работает. Хотя это какая-то совершенно новая коммуникация — ты её постоянно создаёшь в моменте, ежедневно.

Как изменился подход к требованиям

Теперь, когда приходят бизнес-требования, я не просто их читаю, а проговариваю с заказчиком. Тут особенно ярко видна вся разница подходов. Например, бизнес сознательно закладывает, что какая-то часть клиентских сценариев система обработает, а какую-то— «допустимая погрешность», которая упадёт на ручной разбор. С точки зрения IT — это технический долг. С точки зрения бизнеса — взвешенное решение, позволяющее быстрее выпустить продукт, покрыв большинство клиентов. Обсуждая требования, мы вместе с заказчиком стараемся снизить этот техдолг хотя бы до 10%, уточняем пользовательский путь, прорабатываем ошибки.

Дорога без конца

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

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

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