Knig Fu для аналитика: чтение, которое поможет сделать работу группы по-настоящему увлекательной
Конфуций, который по одной из теорий был основателем кунг фу, говорил, что в человеке всё должно быть прекрасно: и мудрость ума, и сила духа, и здоровье тела (да-да, почти как у Чехова, только на две с половиной тысячи лет раньше). Вы наверняка уже проанализировали и составили план активностей на грядущие длинные выходные, а мы поможем закрыть пунк…
На эту же тему: Петровский «Скрайбинг. Объяснять просто». Применимость скрайбинга в аналитике спорное, но сама идея представления сложных материалов в виде «картинок», а не стандартных схем, с некоторыми заказчиками срабатывает неплохо. Отсюда появился вопрос: при визуализации все средства хороши или аналитик должен придерживаться общепринятых нотаций моделей?
Ксения, интересный вопрос и неоднозначный ответ.
В защиту общепринятых нотаций:
• больше гарантия однозначного понимания участниками, знающих нотацию. Важно, когда меняется состав, зафиксировать в договорных документах.
• не нужно придумывать элементы, в которые вложен опыт и которые поддерживаются инструментами
• некоторые инструменты позволяют сгенерировать код. Например, в движках workflow на основе bpmn. Не нужно "рисовать" дважды.
В защиту "адаптированных" решений:
• у Заказчиков может не быть специалистов, которые поймут нотацию и зачастую, к примеру, простая схема их картинок в этом случае будет эффективнее.
• не нужно детально изучать нотацию и все элементы. А зачастую это толмуты описания нотации, ещё больше материалов по методика применения. Уверены ли вы, что все заинтересованные лица правильно поймут разницу, к примеру, пунктирной стрелкой и обычной.
Думаем, для каждой ситуации лучше взвесить все за и против.
Также интересен опыт Григория Печенкина, который несколько раз выступал на Analyst Days по темам визуализации. Например, на 11-й с докладом "Лучше тысячи слов. Рисование диаграмм совместно с заказчиком" отметил бы график сравнения эффективности взаимодействия при различных форматах. Самое эффективное очное, в т.ч. с флипчартом. Предлагает не стремиться строго соблюдать нотации BPMN/UML(в т.ч. UseCase diagram) для обсуждения процессов с Заказчиками. При этом все, что на флипчарте рисует в ПО, а потом еще для разработчиков отдельно.