Слушать активно, а говорить короче
#мысливслух #что_почитать

Недавно в одном из чатов обсуждали почему даже внутри команды важны навыки общения. Кому-то из участников тимлид на 1-to-1 сделал замечание насчет общения в команде. Возник вопрос: «Почему просто не принять во внимание, что в команде есть такой, кто говорит грубо и этого его фишка, а не желание задеть?»

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

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

На фоне этих грустных мыслей встретилось две статьи в блогах для аналитиков
• Mastering the Art of Communication и
• 10 Simple Hacks to Improve Communication Skills

В статьях несколько советов и самыми удачными мне показались такие
📍Активно слушать. Это не про то, чтобы услышать слова, а еще и постараться понять, что в них вложено. Сколько раз вы ловили себя на мысли, что больше думаете, что скажете дальше, чем вникаете в суть услышанного?
📍В высказываниях не отделять себя от команды. Когда чаще звучит «мы» или «наша команда», чем «я», то создается атмосфера общей работы и уважения к вкладу каждого. Люди часто неосознанно (и осознанно!) исключают других из результата и этот небольшой шаг может привести к недоверию и конфликтам
📍Чем короче, тем лучше. Нужно оценить аудиторию и сформулировать высказывание в понятных ей терминах. Не нужно пытаться донести мысль избыточными пояснениями. Хороший навык общения означает еще и понимать, когда промолчать

А у вас сколько сил и времени уходит на общение в команде?

Зимние аналитические задачи
#мысливслух #истории

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

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

Поделитесь, кто-то сегодня устраивает викторины и конкурсы? 🎉

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)

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

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