Синергия аналитика и разработчика

Меня зовут Екатерина Статкевич, я руководитель отдела разработки в крупной ИТ-компании. Мы занимаемся разработкой финтех-сервисов, их сопровождением и поддержкой.

Опыт работы у меня более 18 лет – я прошла путь от разработчика до руководителя.

Обладаю опытом работы с людьми и формирования команд – на текущий момент у меня в команде по направлению 1С 12 разработчиков и 5 аналитиков.

Поговорим на актуальную тему синергии аналитика и разработчика. Я расскажу о том, что:

• Без аналитика обойтись можно, но без аналитики – нельзя. Эта тема – актуальная: не новая, но мы до сих пор это обсуждаем. Самое интересное, что до сих пор встречаются заказчики, у которых есть вопрос: «Нужен ли аналитик на проекте, или достаточно просто найти #Тыжпрограммиста – набрать кодеров, и они выпустят больше задач?»

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

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

Аналитики бывают разные, но я в своем докладе буду делать акцент именно на бизнес-анализе и на системном анализе.

• Бизнес-аналитик – это человек, ответственный за сбор требований. Он собирает функциональные требования с заказчика, согласует эти требования и напрямую работает с бизнесом. Самый главный вопрос, который ему нужно выяснить: «Для чего пользователям нужна наша новая система или улучшения в этой системе».

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

Без Аналитика можно. Без Аналитики – нельзя

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

• Например, бизнес-требования может собрать и проработать с заказчиком менеджер проектов, тимлид или разработчик.

• То же самое с системным анализом:

  • Системные требования может собрать и описать тимлид.

  • Поставить задачу разработчику тоже может тимлид.

  • А еще разработчик может все это сделать сам.

На слайде – картинка из крутого доклада Славы Панкратова про человека-снежинку. Он заканчивается словами: «И тут тебя не стало. Ты стал человеком-снежинкой». Когда один человек на проекте выполняет несколько ролей, это приводит к тому, что страдают сроки и качество. Каждый на проекте должен заниматься своим делом.

Жизненный цикл бизнес-задачи/проекта

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

На слайде – жизненный цикл нашей бизнес-задачи от инициации до приемки заказчиком:

• Зеленым цветом я здесь выделила блоки этапов, где присутствует бизнес-анализ.

• Синим цветом – блоки, где присутствует системный анализ.

• Блоки, которые в блок-схеме не выделены цветом – это чисто бизнесовые блоки, когда бизнес общается только между собой.

• Также цветом не выделены чисто статусные блоки, такие как «Ожидание разработки» или «Формирование релиза». Например, на этапе «Ожидание разработки» задача ожидает, когда у нас появятся ресурсы.

Если кратко по блокам:

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

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

Если системный аналитик видит, что где-то есть техдолг, и понимает, что в системе нужно что-то поправить, но тут не обойтись одним часом разработки – нужны определенные ресурсы, которые нужно спланировать, то системный аналитик создает задачу, и она тоже идет по этому этапу.

Далее у нас есть этап экспресс-оценки – мы смотрим те задачи, которые к нам поступили.

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

В экспресс-оценке участвуют руководители команд. Но не каждый руководитель может сказать точную верхнеуровневую оценку – сколько стоит задача в разработке. Поэтому на этапе экспресс-оценки мы тоже привлекаем системного аналитика, потому что он может предсказать, сколько это будет стоить нам в разработке.

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

Было же у вас такое, когда вам заказчик даёт задачу, а там: «Сделай, чтобы было хорошо», и всё? В этот момент мы не можем дать оценку – ок, мы можем делать хорошо, а где, на какой системе?

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

У нас задачи делятся на два типа:

• есть большие проекты – те, которые исполняются больше 14 рабочих дней и касаются более двух систем;

• и есть мелкие BAU-задачи, как мы их называем – те, которые касаются одной системы или взаимодействия двух систем и требуют меньше 14 рабочих дней на исполнение.

Маленькие BAU-задачи сразу после экспресс-оценки попадают на этап приоритизации, где у нас работает только бизнес. Здесь все бизнес-заказчики встречаются, видят свои задачки, смотрят, сколько это стоит сделать, и ставят нам их в бэклог в очередь разработки.

А если задачи большие, мы их отправляем на этап B4B – он на схеме между инициацией и экспресс-оценкой. B4B – это бизнес для бизнеса, где встречаются только бизнес-заказчики. Здесь обсуждаются важные проекты, которые нужно реализовать для запуска нового продукта. На этих этапах, естественно, нет ни системного, ни бизнес-аналитика.

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

Этап согласования требований – здесь уже тоже бизнес-аналитики, они передают задачу на этап согласования требований. Здесь тоже бизнес работает только между собой. Если задача со смежными подразделениями – например, она затрагивает производство и склад, и нужно, чтобы одно не поломало другое. Либо если нужно получить согласование от этих подразделений – в этом случае мы отправляем на этап согласования требований.

Дальше у нас проходит этап архитектуры. На этапе архитектуры присутствуют системные аналитики – архитектор, системный аналитик и тимлиды прописывают архитектуру нашей задачи.

Далее мы переводим задачу на этап системного анализа. Здесь уже идет описание интеграционных контрактов – постановка задачи для разработчика. Мы нашу бизнес-идею детализируем до задач и пользовательских сценариев, и описываем эти задачки для того, чтобы выдать их в разработку.

Дальше цикл не уместился и перешел на ту сторону – идет этап ожидания разработки. Когда нет ресурсов, и задача ждет.

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

Дальше, у нас идет этап тестирования. Этап тестирования – это отдельный тестовый контур. «Тестирование», «UAT», «Формирование релиза» и «Готово к релизу» – это задачи наших тестировщиков. Но на этапе тестирования мы привлекаем бизнес-аналитика, чтобы проанализировать по критериям приемки, правильно ли мы сделали. И привлекаем системного аналитика, который взаимодействует с отделом тестирования и показывает, как он ставил задачу разработчику. Далее, он принимает задачу от разработчика и проводит преддемо нашему отделу тестирования.

И на этапе приемки заказчиком тоже здесь присутствует системный аналитик, потому что он хранитель нашей системы.

Введение этого регламента помогло нашему бизнесу закрывать задачи более эффективно. На слайде – немного цифр за 2022 год.

• Маленьких BAU-задач мы за 2022 год реализовали порядка 436;

• Крупных задач-проектов – мы их называем CR – у нас за 2022 был реализован 31 проект.

А с помощью такого регламента взаимодействия мы уже с января по апрель сделали:

• более 260 маленьких задач;

• и 30 проектов.

На слайде – статистика на конец апреля 2023 года, когда я делала презентацию. На прошлой неделе (прим. ред. доклад от 26 мая 2023 года) мы выпустили релиз и закрыли еще плюс два больших проекта. Следование такому регламенту дало нам существенный прирост производительности в выпуске задач.

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

• если задачи малые, разделение ролей на бизнес-анализ и системный анализ нецелесообразно;

• а на больших проектах, в больших масштабных работах это уже будет определенно оправдано.

Как организовать совместную работу

Часто между аналитиком и разработчиком встречается сопротивление к совместной работе.

• Разработчик не хочет работать в команде с аналитиком, объясняя это тем, что: «Я же быстрее все сам сделаю. Там все понятно. Я сам. Не лезь, я лучше знаю».

• А аналитик, с другой стороны, не хочет погружаться в техническую задачу: «Ты же знаешь, как должно быть. Сделай, чтобы работало, и этого достаточно».

Тут проблема, чаще всего, не в людях – проблема в организации командного взаимодействия и в организации процесса.

Не всегда люди понимают, где заканчивается процесс анализа, и где начинается процесс разработки.

На слайде – детализация кусочка жизненного цикла бизнес-задачи, который отвечает за взаимодействие разработчика и аналитика.

Здесь у нас нет бизнес-анализа, работает только системный анализ – это касается случая, когда эти роли разделены.

• Схема жизненного цикла начинается с момента, когда мы детализировали бизнес-идею до более мелких задач, которые будут попадать в бэклог разработчику, и передали задачу в разработку. В момент, когда задача поступает в разработку, она сначала ставится на обсуждение – этап «На обсуждении».

• Потом задача попадает к разработчику в бэклог – он ее помещает на доску по проекту, на этап «Нужно сделать».

• И далее переходит на этап «В работе» – разработчик берет ее в работу. Причем он берет ее в работу вместе с системным аналитиком, потому что системный аналитик ставил задачу. Даже если они взаимодействуют друг с другом просто через описание задачи, они работают вместе в течение всего того времени, пока разработчик разрабатывает задачу.

• Далее задача проходит этап «Код-ревью».

• Попадает на этап «Ожидание сборки», когда мы выкладываем наш мини-релиз на тестирование.

• И дальше есть этап «Внутреннее тестирование». На этом этапе системный аналитик, который ставил задачу разработчику, проверяет, как разработчик ее выполнил – в идеальной картине мира системный аналитик проверяет свою же постановку задачи.

• Дальше задача переходит на этап «Разработка завершена».

• И попадает на этап «Тестирование ОТ» – на этом этапе тестирования системный аналитик взаимодействует с отделом тестирования. Мы сделали задачу, показываем нашему отделу QA преддемо, рассказываем о функциональности, которая изменилась, и объясняем, какие у нее критерии приемки. Пока задача тестируется – день-два-три-шесть, в зависимости от объемов – у отдела тестирования возникают вопросы. Мы ограждаем от этих вопросов разработчика, чтобы он у нас только кодил – с ним взаимодействует только системный аналитик.

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

Отсутствие готовности к совместной работе: разработчик не хочет работать в команде с аналитиком, а аналитик не хочет погружаться в техническую сторону реализации задачи

Не всегда бывает все гладко – в командах случаются проблемы. Расскажу свои советы о том, как эти проблемы обойти.

Но перед этим хочу обратить ваше внимание на постулат Agile, который гласит, что бизнесу нужно обязательно взаимодействовать с ИТ. Я сейчас побуду немного бунтарем и скажу: с ИТ – да, бизнесу действительно нужно взаимодействовать, но с разработчиками – нет, не нужно. Мы полностью оградили разработчиков от бизнеса.

Бывало же у вас такое, что нужно изменить бизнес-требования к задаче? Например, у задачи несколько заказчиков – Бухгалтерия, Отдел кадров и другие подразделения. Поставили у совещания тайминг 20-30 минут – за 20-30 минут все обсудили, договорились и ушли. Верите? Обычно обсуждения по изменению либо постановке требований – это поиск правды. Эти обсуждения затягиваются. И мы у себя в компании ограждаем разработчиков от этих обсуждений. У нас роль взаимодействия с бизнесом берет на себя системный либо бизнес-аналитик. Мы знаем систему не хуже разработчиков и выясняем все требования сами. А разработчики у нас только кодят.

Теперь про проблемы во взаимодействии аналитиков и разработчиков.

Одна из проблем – это взаимное недоверие. Разработчик не верит, что аналитик поставил задачу корректно: «Что он написал вообще, задача же не об этом?..». А аналитик не верит, что разработчик разберется в логике системы: «Что он там сейчас накодит…»

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

• Все ли тебя устраивает в том, как я описал интеграционные контракты?

• Все ли понятно в требованиях?

Важно получать эту обратную связь и корректировать свою дальнейшую работу.

Еще один порок у команды – это уход от конфликтов, когда проще не спорить: «Он считает, что так надо, пусть будет так. У меня есть свое мнение, но я лучше промолчу».

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

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

Как с этим бороться?

• Во-первых, нужно проводить совместные планерки, дейли. Аналитикам с разработчиками нужно каждый день обсуждать задачи в диалоге: «Что ты сделал вчера? Что ты будешь делать сегодня? Чем я тебе могу помочь? Давай посмотрим вместе – что получается, а что не получается».

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

• И для профилактики возможных конфликтов и проблем нужно представлять интересы разработчика перед бизнесом. Допустим, запрашивают одну функциональность, а разработчику с технической стороны виднее – он понимает, что это будет работать неоптимально, лучше сделать по-другому. Здесь нужно вступать в диалог с бизнесом и предлагать альтернативные идеи для реализации их потребностей. Бизнес же не всегда знает, как это предусмотрено в системе. Ты приходишь к ним и рассказываешь, а они тебе говорят: «А что, так можно было? Да, давайте сделаем так». Здесь тоже важен диалог, и системный аналитик должен представлять интересы разработчика перед бизнесом – предлагать альтернативные идеи реализации.

Еще есть такой порок, как необязательность – это когда мы не можем поддержать принятые решения. Мы решаем этот вопрос через подведение итогов после каждой встречи.

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

• Если мы встретились, чтобы провести мозговой штурм для проектирования архитектуры – нужно зафиксировать, о чем мы договорились. И в конце обязательно спросить – правильно ли мы все понимаем друг друга? Нужно подвести итоги и проговорить все принятые решения, чтобы убедиться, что мы их понимаем в одном контексте. Лучше договориться о решениях заранее, перед тем, как мы начнем их реализовывать на практике.

• Нужно проанализировать худший сценарий развития событий. Порассуждать на тему – вдруг что-то пойдет не так. Например, сейчас у нас в регистре десять записей, и все будет работать быстро. А как это будет работать, если их завтра в регистре будет тысяча записей и с каждым днем прирост будет увеличиваться? Будет ли это работать оптимально или нет?

• И дополнительная профилактическая мера – это совместное создание чек-листов для релиза, которое тоже воспитывает обязательность. Каждый раз, когда выходишь на релиз, у тебя должен быть чек-лист:

  • Что нужно сделать в системе со стороны разработчика – со стороны проверки кода и каких-то настроек;

  • Что нужно сделать в системе со стороны аналитика – настроить печатные формы, если это Документооборот, перенести карты бизнес-процессов, если это CRM и так далее. То, что мы делаем уже на релизе.

Нетребовательность к другим – еще один интересный порок, когда мы не требуем качественного результата от других членов команды.

В этом тоже помогает ряд профилактических мер:

• Разработка стандартов постановки задачи – например, для описания контрактов на интеграцию.

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

• Правильная организация приемки задачи. Системный аналитик должен принимать задачу с позиции «Как это работает?», «Как это может повлиять на существующую функциональность?» Нужно вникать в техническую сторону задачи и тем самым расти в глазах разработчика.

Еще один порок – безразличие к общему результату. Когда «сделал, и ладно».

Здесь работают следующие профилактические меры:

• Контроль реализованной функциональности после выпуска релиза. Определите для задачи, сколько времени нужно мониторить результат, чтобы убедиться, что все точно работает. Например, для доработки какого-то регламентированного отчета можно определить период мониторинга – квартал. Отчетность сдали – значит, все работает, уже можно фокус внимания снизить.

• Взаимодействие аналитика с отделом тестирования. Если будет фокус на общий результат, системный аналитик будет более заинтересован в том, чтобы задача выпустилась правильно. Чем более качественно ее сделал разработчик, тем меньше дефектов – тем меньше системный аналитик взаимодействует с отделом тестирования.

Реальный кейс, как включение Аналитика на проект позволило нам вывести систему из кризиса и закрыть технический долг

Немного фактов.

В 2022 году у нас был очень крутой стартап, когда мы совместно с партнерами устанавливали ПО на смартфоны. И эти смартфоны с нашим программным обеспечением мы выдавали в лизинг с последующим его выкупом.

В качестве бэкенда для работы ПО использовались конфигурации Бухгалтерия предприятия, БИТ.Финанс и БИТ.Центр управления лизингом.

В июне 2022 года мы выпустили MVP. Пока мы выпускали MVP, у нас на проекте присутствовал системный аналитик, но потом мы системного аналитика отдали на другой проект, а на проекте остались тимлид и разработчик.

Что стало происходить:

• в июне системный аналитик перешел на другой проект;

• в июле мы начали захлебываться в дефектах – на графике синим цветом показаны открытые задачи, а зеленым – дефекты;

• в августе, пока память свежа, мы эти дефекты закрывали, но у нас продолжали лететь новые дефекты.

С чем мы столкнулись:

• Полное возмущение клиентов.

• Нам не доверяет бизнес.

• У нас ежедневные совещания по стабилизации, на которые бизнес приходит и говорит: «Что там у вас сегодня?» Потому что бизнес тоже устал – это Бухгалтерия предприятия, там отчетность, с этим тоже связаны свои опасения. На эти ежедневные совещание мы ходим с опущенной головой.

• Ситуация была критическая: наше установленное ПО в случае просрочки по оплате выдавало на экран предупреждение «оплатите, пожалуйста». И на третий день телефон становился кирпичом. Даже если заплатить, телефон уже кирпич – по нему даже позвонить не получится. И вернуть его из состояния кирпича не получится, потому что у нас дефекты.

Мы ловим дикое возмущение наших клиентов: нам угрожают судами, у нас трясутся коленки-руки, мы судорожно тушим пожары. Задач много, это только MVP, нужно еще и развиваться, у нас встал вопрос: кого привлекать – разработчика или аналитика? И мы сделали ставку на аналитика.

• Аналитик погрузился на проект в августе.

• И уже в сентябре прекратились ежедневные совещания по стабилизации – они стали еженедельными.

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

На текущий момент система живет с минимальным вмешательством с нашей стороны.

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

Если у аналитика с разработчиком срабатывает эта синергия, у бизнеса растет доверие к нам, потому что мы выпускаем ровно то, что от нас хотели. Это в краткосрочной перспективе.

А в долгосрочной перспективе это еще дает возможность побороть саботаж при внедрении изменений.

И последнее: я хочу высказать благодарность моему первому аналитику Анастасии Евгеньевне.

18 лет назад я была таким же амбициозным #Тыжпрограммистом, который очень много знал о кодировании и ничего не знал об аналитике, и не считал это важным.

Спасибо тебе большое, Анастасия Евгеньевна, за то, что ты меня научила. С тех пор я уверена в том, что без аналитика на проекте нельзя.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции "Анализ & Управление в ИТ-проектах".