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

Меня зовут Маша. Да, как‑то даже во взрослом возрасте все меня так называют. Работаю в IT или около IT сфере еще со студенческих времен. Чего только не насмотрелась… но сегодня не об этом. Сейчас занимаю должность системного аналитика в Ростелеком Информационные Технологии.

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

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

История начинается…

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

Был замечательный солнечный рабочий день. Мне присылают новую задачу на доработку по проекту для написания технического задания. В описании есть требования заказчика к бизнес‑процессу, логике и оформлению доработки. Начинаю разбираться, проводить обычные встречи для уточнения требований. Так начинается первый этап — системный анализ.

На данном этапе я разрабатываю документ, в котором описываю постановку задачи, схему бизнес‑процесса, пользовательские сценарии и технические детали для разработчика. В зависимости от четкости требований процесс может занимать от пары недель, до нескольких месяцев. Затем отсылаю документ на экспертную проверку системному архитектору, который проверяет корректность интеграций и влияние на смежные доработки. И только после одобрения я отправляю техническое задание заказчику на согласование. Если есть замечания или корректировки, то самое время о них сказать.

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

Затем наступает долгожданный момент — заказчик подписывает согласованное техническое задание кровью. Через некоторое время после планирования спринта я очень довольная иду осчастливливать разработчика новой головоломкой. Так начинается второй этап — разработка.

Проходит пара месяцев, и тут заказчик присылает письмо…

Дорогой системный аналитик!

Мы бы очень хотели добавить пару условий в бизнес‑процесс, изменить названия статусов заявок и сделать кнопку «Скачать» с другой стороны. Примите, пожалуйста, в разработку.

С уважением,

Заказчик

Что делать? Куда бежать? Паника!

Отставить панику! Глубокий вдох, глубокий выдох и начинаем думать. В целом, получение правок на этапе разработки неприятное, но относительно частое явление. Оно обуславливается тем, что заказчик после согласования отвлекся от доработки, а потом смотрит на нее свежим взглядом и понимает: «Для полного счастья мне не хватает еще вот этой фичи».

Задача на этапе разработки, а у нас новые требования. Бежим к разработчику и отзываем задачу обратно на этап системного анализа? И снова адские круги согласования? Нет, нет, нет… 

Надо внимательно посмотреть на требования. Насколько они критичны для реализации? Ага, условия — это системная логика, ничего, поправим. Только это самое объемное требование, поскольку для его реализации придется дорабатывать не один элемент системы. Названия статусов — это бизнес‑логика, поэтому надо согласовать со всеми заинтересованными коллегами. Кнопка, а что кнопка? Разработчик точно до нее еще не добрался. Решение по правкам зачастую принимается системным аналитиком самостоятельно, если они не затрагивают другие системы или проекты.

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

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

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

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

Вот теперь заказчик присылает письмо…

Дорогой системный аналитик!

Мы подумали и решили, что хотим еще добавить условия в бизнес-процесс. Старые убрать, но не все. А еще нужны поля…

С уважением,

Заказчик

Точно паника, потому что уже назначена дата показа доработки, буквально через пару дней. К тому же договоренность вывести все на продуктив в ближайший релиз через две недели. Мы просто не успеем! И да, сесть и подумать уже не спасет ситуацию. Всё очевидно. 

Какое стоп‑слово?

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

Стоп‑слово оказалось простым и состояло всего из трех букв, но не тех, которые обычно пишут на заборах. Это слово — «Нет».

Разве можно говорить такое заказчику? Как можно отказать? А вот так. Просто и с обоснованием, что мы не волшебники, а только учимся, поэтому последние дополнительные требования можем реализовать либо в другой доработке, либо со сдвигом сроков по текущей. То есть не просто отказать, а предложить варианты выхода из ситуации.

Коллеги немного поспорили, но согласились на первый вариант. Уж очень хотелось увидеть что получилось. А мы начали готовиться к новой доработке и новым требованиям.

Вот такая вот вышла история

Клавиатуры целы, антидепрессанты не тронуты, заказчик доволен. Конечно, этапы работы над задачей укрупнены, но мораль сего рассказа такова:

1. Не поддавайся эмоциям — обычно в стрессовых ситуациях очень сильно хочется все отрицать, хотя это и не всегда логично.

2. Думай — пословица «семь раз отмерь, один раз отрежь» в полной мере раскрывает пункт про размышления.

3. Разговаривай и обосновывай свои решения — когда ты сам все понял и взвесил, необходимо донести эту информацию до заказчика. А чтобы он еще и понял, то пару аргументов в рукаве станут козырными в решении вопросов.

А какое стоп‑слово в вашей команде? Делитесь в комментариях.