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)

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

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

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

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

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

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

Быстрее, лучше, дешевле. Девять методов реинжиниринга бизнес-процессов
М. Хаммер, Л. Хершман. Год издания: 2010

Когда вы читаете все, что еще год назад сохранили списком в Notion или еще где-то? Я вспоминаю о своем списке, когда оказываюсь где-то в ожидании или в пути, в остальное время всегда находится что-то ужасно срочное или интересное ☺️

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

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

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

Что может быть полезно?
На примерах посмотреть как отличаются в процессах шаги добавляющие ценность и прочие операционные, административные шаги. Как выглядит процесс, где только 3 шага добавляют ценность, а 15 – передача информации из рук в руки.
Мне понравился пример с процессом обрезки деревьев. Чтобы снизить количество аварий на линиях электропередач нужно было построить процесс обрезки деревьев и следить за его эффективностью. Хорошо передан контекст исследования проблемы и поиска решений.

Полезно обобщение семи принципов проектирования:
• какие операции будут выполняться;
• будут ли они выполняться и при каких условиях;
• кто будет их выполнять;
• когда это будет происходить;
• где они будут выполняться;
• насколько точно они будут выполняться;
• какая информация будет при этом использоваться.

Глава о показателях эффективности. Мне понравился прием, с перечислением "грехов", которые могут привести к ошибкам в выборе системы показателей. Оставлю их здесь, а вы сами читайте в книге или предполагайте, как они влияют на выбор метрик процессов:
• тщеславие;
• самолюбование;
• лень;
• нежелание масштабно мыслить;
• бессмысленность;
• легкомыслие.

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

#книжки

Цундоку и статьи про стейкхолдеров

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

Разобрала материалы про заинтересованные стороны, делюсь

🌱Эффективное управление отношениями со стейкхолдерами Рассказ от самых основ терминологии, описание основных инструментов RACI, карта заинтересованных сторон, матрица влияние-интерес. Все неплохо, но если вы уже в теме, то можно заскучать.

🌱Бизнес-аналитик — мастер переговоров или как не сойти с ума, работая с требованиями Это рассказ BI-аналитика о том, с чем приходится сталкиваться при проектировании дашбордов. Уверена, что многие из нас не думали о дашбордах с точки зрения переговоров с заказчиками

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

🎥Что и как спросить у бизнеса, чтобы проработать ИТ-решение Давний стрим с весьма честными рассуждениями об отношениях между ИТ и бизнесом, а еще с шаблонами того, чем следует поинтересоваться для успеха будущего ИТ-продукта. Слушать сложно, но и назвать бесполезным тоже сложно

🌱Цена термина "заказчик" не удержалась и добавила в подборку свое небольшое рассуждение о неполном понимание термина "заинтересованная сторона" и как оно влияет на сроки разработки продукта

🌱Кто такие «заинтересованные стороны» и в каком случае для бизнеса от них больше пользы, чем проблем? (на основе кейса) Это о заинтересованных с точки зрения маркетинга. Интересно перечислены ожидания разных сторон

#что_почитать

Повод больше общаться или ужас?

Как вы реагируете, когда видите реализацию сильно мимо вашей постановки или ТЗ? Я со временем прошла разные стадии: 1. ужас, я что-то неправильно сделала; 2. ужас, какие все ленивые, я-то все четко написала; 3. ужас, как люди разучились читать... Сейчас прихожу к точке зрения без слова "ужас"

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

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

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

Кроме вопросов мотивации, у читателей документа срабатывают те же механизмы когнитивных искажений, что свойственны всем нам. Отсекается то, что кажется неважным для задачи, теряется непонятное, насмотренность подсказывает какую-то интерпретацию "между строк"... Вот тут на Хабре еще одно мнение о том как получается результат не по ТЗ. Если коротко, то просто люди устают читать для них неважное и забивают на детали 🤷‍♀️

Чтобы неважное стало важным, каждому участнику нужно понимание результата и своего участия в нем. Не всегда из роли аналитика можно повлиять на всю команду таким образом. Зато можно перестать ужасаться и думать, что документ, таблица, задача или картинка сами по себе могут гарантировать общее однозначное понимание. Можно попробовать после подготовки требований больше общаться с командой, много отвечать на вопросы и устраивать обзорные встречи, чтобы донести информацию. Но и это не точно 😎

#мысливслух