Статья посвящена трудным/трудовым обстоятельствам работы аналитиков на проектах, которые выполняются по некому варианту «Scrum + Аналитик», эти обстоятельства являются причиной стресса. Если вы думаете, что я дам вам какие-то решения, то увы, нет. Трудности эти в обозримом будущем никуда не денутся, можете считать, что вы ходите по кругу Сансары аналитика. Знайте, что вы не одни по нему ходите, может вам психологически станет легче.

Текущий спринт VS Будущий спринт

Все сейчас работают по спринтам. Сколько активных спринтов у аналитика? Конечно, два. В одном он оказывает аналитическую поддержку разработчикам, объясняет задачи текущего спринта, устраняет замечания, которые ему накидали при старте спринта. В тоже время аналитик должен сформировать описание задач для будущего спринта. Со стороны других членов команды это представляется, что так и должно быть. Разработчики любят рассуждать, что они творцы и работают в потоке, от которого отвлекать их нельзя. А для аналитика как будто это не применимо, получается, что аналитик изучает материалы, думает над решением, тут, бац, вопрос по задаче текущего спринта. Потом еще вопрос по другой задаче, и вопросы будут, и это нормально. Допустим, аналитик описал кучу задач заранее, убежал с анализом вперед команды разработки, минутку, что-то мне это напоминает? Так это же водопад, а что будет с задачами, когда к ним приступит команда разработки, правильно, всё равно будет куча вопросов, а еще аналитику придется всё переделывать. Еще представим, что задачи в начале спринта идеально описаны и полностью понятны разработчикам. Знает, что это значит? Ничего хорошего. Вероятно, проект развивается медленно, никто никуда не спешит, нет динамики, возможно, ваш проект/продукт никому не нужен. Таким образом, норма – это два активных спринта у аналитика.

Мы работаем по спринтам, но план тоже есть!

Для понимания этой противоречия вспомните как развивались ваши проекты и постройте логическую цепочку. Опять же все сейчас работаю по спринтам. Но исходное планирование и оценка трудозатрат выполняется не по спринтам. В лучшем случае у вас есть архитектор, он или вы сделали предварительное проектирование, декомпозировали систему на компоненты и модули, оценили трудозатраты на реализацию или даже вместе с менеджером проекта построил дорожную карту, а может даже план с диаграммой Ганта. При этом все же понимают, что работать-то вы будете по спринтам. А как это соотносится с классическим планированием? Оказывается в головах людей этот разрыв нормально уживается, точнее игнорируется. Но грабли эти могут хорошо выстрелить если веху из диаграммы Ганта приземлить в какой-то будущий N-ный спринт без правильной переоценки. Составляющая этой проблемы то, что работа по спринтам и применение практик Scrum, то есть планирование в начале спринта, дейлики, демо день, ретроспектива множеством людей воспринимается, что мы изначально работаем по Scrum. Но в Scrum категорически против всяких вех и долгоиграющих планов. А почему это в голове так легко стыкуются план и работа спринтам? Хочу отметить, что я не против планов с дальним горизонтом. Планирование – это хорошая умственная деятельность, которая дает понимание того, что вообще нужно делать. Но я против фиксации плана в первоначальном виде, без корректировок, потому что так это не работает. А будет ли он работать, если его разбить на спринты? Является ли работа по спринтам корректировкой плана? А если срок поставки жестко закреплен, то это можно назвать уточнением? Ну да, еще же остается два параметра, которые можем уточнить, содержание и качество. Все же понимают, в какую сторону произойдёт изменение?

А почему это у вас задачи анализа в спринте изменились?!

Эта проблема знакома всем, это случай, когда есть некоторый регламент работ, по которому вся работа команды должна вестись по спринтам в Jira. Аналитики, дизайнеры, разработчики, тестировщики, все загоняются в типовой спринт. И по началу это похоже на мем «Всё смешалось в доме Облонских». Почему нельзя с аналитическими задачами работать также как с задачами разработки, и какие ухищрения делаются чтобы не было или наоборот было так. И почему аналитическая задача в любой момент может открыться или закрыться. И о том, как из-за это портится отчетность по спринтам у всей команды. Не буду рассказывать об этом. Но, я вас прошу подумать вот о чем, опять же о качестве, в этом случае о качестве аналитической работы. Если ваше планирование спринтам, чисто формальное, и вы не ведете отдельно некоторую карту или перечень аналитических задач, то аналитическая работа дезорганизуется. Чтобы этого не происходило, аналитики прибегают к помощи внешних инструментов, и может образовать параллельный спринт вне правил Scrum, вероятно он будет в инструменте чем-то подобном Trello. В итоге получаем странную ситуацию, что если работать по правилам Scrum, то влечет дезорганизацию анализа, а параллельная работа вне Scrum – это подводная часть айсберга, которая не отражается в отчетах, и описывает кучу работы и рисков по проекту. Что с этим делать?

Привет, я дизайнер, я буду строить CJM

Дизайнер – относительно молодая IT-специальность. Деятельность дизайнеров очень сильно пересекается с аналитиками. Но они заслуженно завоевали свое место под солнцем. Чего только стоят их классные инструменты, вроде Figma, и их замечательные методики, которые они украли у маркетологов, шучу, позаимствовали. Я не буду описывать банальные вещи о том, что CJM нужно строить совместно и не ходить порознь к разным пользователям. И в зависимости от того, как аналитик и дизайнер наладят совместную работу, они станут друзьями или врагами. Я предлагаю посмотреть, что об всём, что рассказал выше думаю дизайнеры, они ведь тоже должны работать по спринтам. Или не должны?

Agile and design: how to avoid Frankensteining your product

Сочетать Agile и дизайн — всё равно что смотреть на картинку через замочную скважину. Дизайнеру приходится работать инкрементами, разбивая целое на части. Именно такой подход может привести к тому, что я называю «Франкенштейнированием» цифровых продуктов или сервисов.

Франкенштейнирование происходит, когда продукты или услуги, созданные с использованием Agile, становятся фрагментированными или разрозненными. Фрагментация нарушает целостность восприятия, что негативно сказывается на пользовательском опыте.

Дизайн и UX в гибких методологиях

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

Получается дилемма: либо качественно и долго (когда концепция продумывается целостно), либо сыроватый продукт, но быстро (когда на глобальное видение нет времени, зато работа подчинена законам Agile).

Вообще-то компромиссное решение давно придумано — параллельные потоки дизайна и разработки, где поток дизайна идет впереди на одну итерацию.

Как видите, если «дизайн» заменить на «анализ», то получим похожую ситуацию. Ну как вам такой Agile, где по содержанию у аналитиков свой спринт, у дизайнеров свой спринт, у разработчиков свой. Допустим они даже технически работаю в рамках одного спринта в Jira. Но по правилам для спринта же назначается цель, какая цель у такого спринта? Как собирается отчетность?

А ты нашел в Scrum место аналитика?!

А там его нет. Ну нет, так нет, можно ведь добавить? Но прежде нужно понять простую вещь: Scrum – это способ организации работ по созданию программных продуктов. А виды работ по созданию остались, как и прежде: анализ, проектирование, программирование, тестирование. И тут нужно понимать вторую простую вещь: задача анализа – это борьба с неопределённостью, с целю прийти к пониманию. Scrum не выделяет под это отдельную роль аналитика. Работы по анализу, проектированию и программированию выполняет разработчик. Такой организационный способ вполне работает для небольшой команды, где тесное взаимодействие, быстрый обмен информации, прямой контакт подразумевается понятием Scrum Team. Как только появляется второй продукт, вторая команда и нужно обеспечить взаимодействие команда, а значит понимание между командами, то у Scrum-а нет никаких способов организовать это. Для решения этой задачи начинаю использовать другие методологии, например, SAFe.

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

• А было ли у них время и задача написать документацию?

• Хотя ли вообще разработчики писать документацию?

• Кто из разработчиков хочет отвлекаться на вопросы соседней команды?

• Хочет ли кто-то из разработчиков анализировать Scrum доску и беклог соседней команды?

• Хочет ли он о чем-то договориться и идти на компромиссы?

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

• проводить комплексный анализ с разбивкой по спринтам;

• работать в двух активных спринта;

• не ломать отчетность Scrum доски команды.

Samsara / Scrumsara

Все конструкции как встроить аналитика в Scrum специфичны для проекта и компании, выглядят на первый взгляд даже неплохо, но на практике ограниченно работоспособны, также как водопадная модель в теории работает, а на практике всё зависит от людей. И, вообще говоря, если у вас команда профессионалов, то в принципе не важно по какой методологии они работаю. Но что я знаю точно, что работа по схеме «Scrum + Аналитик» на живых и достаточно активных проектах регулярно приводят подгоранию работ аналитиков и перегоранию самих аналитиков. Их начинают мотивировать работать в таких сложных условиях. В ход идут фразы наподобие «Не нужно искать виновных, нужно сделать работу!» или «Потом это исправим» и тому подобное. Но так как Scrum в своей основе не предполагает отдельной роли аналитика, то это неисправимо никакими ретроспективами. Кто бы чтобы не говорил, Scrum не может принципиально изменить сам себя. Может быть нужно принять судьбу аналитика в проектах, которые выполняются по некому варианту «Scrum + Аналитик»? Такова Скрамсара?