Flow. Вопросы к бизнес-анализу и системным требованиям?
#конференции #мысливслух

Вчера была возможность освободить день, удобно устроиться перед экраном и поучаствовать в конференции Flow, на этот раз JUG RU предложили только онлайн. Приманкой были не записываемые пара воркшопов и дискуссии после докладов.

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

▫️Нажала плашку с названием «Бизнес-анализ: Ремесло или искусство». Александр Белин выступал в формате живой беседы без презентации. Разговор пошел о том, что бизнес-анализ не должен быть ни ремеслом, ни творчеством. Анализ как часть процесса проектирования продукта должен быть воспроизводимым, в отличие от свободного творчества. Аналитик тратит время на создание объемных артефактов и делает это в отрыве от команды. Вся информация бизнес-анализа, кроме конечной постановки, остается не востребованной другой частью команды. Чтобы этого не происходило, нужно анализ превратить в инженерию разработки систем.

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

В ожидании записи вчерашнего интервью можно посмотреть доклад Александра Белина на Flow 2023

▫️Еще была плашка с провокационным названием «Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту». Не уверена, что провокация удалась. Иннокентий Бодров поделился наблюдением, что ТЗ обычно содержит 0,1% информации про проблему, еще 20% - пользовательские требования, а остальное — системные требования. Причины: 1) решаемая проблема мало изучена, команда предпочитает находиться в области решений 2) на согласование выносится много деталей решения, чтобы основную ответственность за проектирование перенести на согласующих. В случае экспертной, зрелой команды аналитику лучше оставить проектирование системы архитекторам и разработчикам, сосредоточиться на исследовании проблем бизнеса и не тратить время на мега-детальные описания решений. В презентации был показан пример классического верхнеуровневого Use Case в табличном формате. Подход не предлагает отказаться от системных требований, а предлагает сместить фокус работы аналитика на задачи более важные в его роли, если того позволяет зрелость команды.

Подключилась послушать дискуссию после доклада. Когда взглянула на иконку с человечком под основным экраном, она показала 32 участника. В разговоре выяснили, что детальные описания совсем не плохо, просто дорого. В нынешней команде спикера не ведется описания объектов, есть только глоссарий, атрибуты можно найти в коде. Не обошлось без карьерных вопросов. Погрустили о том, что никто не знает, чем занимается аналитик, настолько сильно тренд ушел в сторону проектирования. Закончится ли это? Кажется, закончится с развитием ИИ, который вытеснит рутинную работу и тех, кто умеет делать только ее.

Тут я заслушалась и пропустила закрытие ☺️

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

Нужно ли аналитику работать в Figma?
#мысливслух #прототипы

Недавно слушала лекцию о производстве кино. В нем еще до ИТ появилось то, что называется раскадровка (storyboard), а мы называем мокапом или каркасом (wireframe). То есть отрисовка каждого кадра в кино, а в нашем случае отрисовка страниц. Оказалось, что сложности эта самая раскадровка создает те же, что и прототипы в разработке. Если она слишком тщательно и красиво отрисована, то отвлекает от смысла кадра и динамики кино. Если слишком точно следовать раскадровке, которая на самом деле не отражает динамики переходов между кадрами, то ничего хорошего не получится.

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

В одном из моих первых проектов, по совпадению разных организационных и географических факторов, сбор требований поручили дизайнеру. В качестве описания требований мы получили набор детально отрисованных в MS Visio прототипов со словом storyboard в названии каждого файла. Именно по ним велась разработка. В получившемся продукте полностью отсутствовала передача данных между логическими компонентами системы. То есть можно было ввести данные об объекте «Книга» и указать автора на форме ввода, но потом нельзя увидеть эти данные в списке книг автора или в алфавитном указателе на странице «Библиотека». Визуальная модель никак не передавала связи между объектами данных, вот их и не создали. После нескольких суток подряд переписывания и тестирования этого приложения, я твердо запомнила, что прототип не может претендовать на необходимое и достаточное описание требований.

Красивый прототип не заменит работу профессионального дизайнера. Многие команды не привлекают профессиональных дизайнеров и аналитики стараются восполнить пробел, но лучше много раз подумать браться ли за такую задачу? Сделать дизайн и сделать иллюстрацию к разговору с заказчиком - далеко не одно и то же. Дизайн подразумевает проработку всех элементов интерфейса во всех состояниях или адаптацию существующих дизайн-систем под особенности вашего приложения. Как бы качественно вы ни представили десяток экранов, это не заменит необходимости проработать 3-4 состояния (Default, Hover, Active, Disable) для каждого поля, кнопки и иконки, понять оставшиеся состояния экранов, особенности каждого перехода между страницами и сделать много другой работы. Может получиться, что аналитик покажет клиенту красивую картинку и договорится о реализации, а разработчик окажется перед необходимостью адаптировать картинку во что-то пригодное к реализации: переделывать *.png в *.svg, менять размеры, придумывать внешний вид для разных состояний. Аналитик рискует потратить кучу времени и не услышать благодарностей.

В работе аналитиков случается переоценка возможностей прототипирования. Часто приходится слышать что-то вроде «вот картинку нарисуем и все-все будет понятно». А еще бывает, что аналитику просто интересно рисовать картинки, так как они вызывают положительные эмоции и у него, и у заказчиков. При этом заказчикам нужен продукт, а не только эмоции. Нужно понимать какие вопросы ожидается решить с помощью прототипа и не тратить сил больше, чем требуется. Если аналитик умеет работать в графических редакторах вроде Figma или Sketch, это большой плюс - он быстрее сможет подготовить материалы к обсуждению. Если не умеет, то может обходиться каркасным проектированием (wireframe)

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

О чем еще подумать при выборе прототипа можно найти в посте Что такое прототипы и какими они бывают?

Аналитик с опытом может быть новичком!

Сегодня думаю про адаптацию в новой команде. Участвую в подготовке курса для онбординга аналитиков, отсюда и #мысливслух.

Прием в новой компании и команде может оставлять впечатления очень надолго. У меня в прихожей прячется от дождя зонтик-трость с логотипом одной прекрасной компании. Мне там хорошо работалось и этот бесполезный остаток welcome-pack меня радует как старое семейное фото. К чему это я? ))

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

"Адаптация" не равно "развитие". Помнится, пару лет назад коллега в новой команде встретила меня словами "Так я же тебя знаю, твои вебинары смотрела!" (Аня, привет! 👋) Это было приятно, что никому не нужно ничего доказывать насчет развития. Не всегда так везет. Переход в новую команду бывает похож на изучение нового языка, когда человека считают глупым, потому что он неправильно называет аббревиатуры названий отделов. И вот уже бадди дружелюбно и очень навязчиво объясняет, что "дейли – это каждый день, а диаграмма - она из квадратиков". Наверное, в таких случаях тоже может эмоционально выручать какой-нибудь зонтик с логотипом какой-то прекрасной компании )))

Какие у вас мысли об онбординге? Как вас встречали в вашей нынешней команде?

#мысливслух

Нужно ли команде тратить время на ревью требований? (peer-to-peer review)

Когда работаю над большой задачей, отправляю первую версию описания требований команде и другим аналитикам с просьбой посмотреть и дать комментарии. Обычно мало надежды на развернутую обратную связь. На нее мало у кого находится время и интерес. Пока "мячик на стороне аналитика" не очень понятно зачем тратить время на какие-то задачи, которые еще не пришли в разработку. Тем не менее есть преимущества от такой траты времени

📌Остановить перфекционизм. Замечали, что чем дольше работаешь с текстом, тем больше начинаешь видеть недочетов, дополнять деталями и переставлять слова? Те кто перечитывает свои же документы через год или два, выдает "Нуу сейчас я бы сделал не так". Тем не менее разработка по этим описаниям как-то состоялась. Всегда есть, что улучшить, правда? Вопрос только, когда остановиться. Когда работа над описанием требований начинает превращаться в хождение по кругу и улучшательство, бывает полезно остановиться и кому-то из команды показать свой текст. По вопросам коллег можно заметить, где перфекционизм создал "многобукв", где пропущена важная деталь, а где неправильно расставлены акценты. Команде рано или поздно придется работать с этой информацией и чем меньше вопросов останется, тем быстрее и проще будет в разработке и тестировании
📌Исключить когнитивные искажения. Мы все вносим какие-то предположения в свою работу. У меня есть привычка делать очень детальные описание и за деталями становится сложно отследить концепцию изменений. Так бывает, когда я строю свои предположения о неизвестном в команде и добавляю детали. Предположение не всегда верно и может получиться перегруз всем известной информацией.
В одной компании я попалась на предположении, что любое изменение клиентских данных хранится в истории и можно легко найти предыдущие значения ФИО и даты рождения. Была уверена, что с чувствительными данными поступают именно так и построила вокруг этого целую фичу. Оказалось, что мой мир слишком идеален. Хорошо, что было кому посмотреть на мое решение и скорректировать ☺️
📌Экспертное мнение. Если вы ходите по кругу в выборе нюансов решения, то полезно сходить за дополнительным экспертным мнением. Если несколько команд работают над связанными фичами, то ревью полезно еще и как способ обмена информацией. Для команды это возможность сберечь время на реализации не самого оптимального решения.

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

Можно предложить документацию на предварительное ревью и бизнесу тоже, не только команде. Потом проще проходить формальное согласование. Об этом пара слов в статье тут

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

#инструменты #кейс #что_почитать