Блог

Рита Лютикова, Старший бизнес-аналитик

Analyst Days 2017: Визуализация, Социальная сеть, Риски и Требования

В этой статье мы хотим поделиться своими впечатлениями от конференции Analyst Days 2017.
Для IT Band это была отличная совместная поездка в Москву, тимбилдинг, новые впечатления. Успели посетить мюзикл, Третьяковку, Останкинскую башню. Впечатлений много, но здесь не об этом.

Один из наших разработчиков перед отъездом на конференцию спросил: «А дайте посмотреть, что там за темы вообще?» В вопросе мы услышали легкий сарказм с подтекстом «А что там вообще можно рассказать?».

Так вот, в этой статье мы хотим рассказать, что же полезного мы узнали. Вашему вниманию – 4 топ-доклада от каждого участника – Риты Лютиковой, Ксении Поповой, Вали Петрашкевич и Славы Булько.

viber image

Топ-доклад Риты: о визуализации
Я бы хотела отметить доклад Колокова Алексея «Как дашборды помогают бизнесу и аналитикам понимать друг друга». Интригующий заголовок? Правда, не очень. На конференции было гораздо больше цепляющих заголовков (и разочаровывающих докладов). Тема звучит узко, не совсем понятно, какие дашборды имеются ввиду. А на деле оказалось, что эта тема гораздо шире и может найти прикладное применение в работе любого айтишника.
Начал докладчик с вопроса к аудитории «Сколько цифр 5 в тексте?» и показал картинку №1.

Рис1

А затем снова задал этот же вопрос и показал картинку №2.

Рис2

И все поняли, о чем пойдет речь. Пользователь не читает информацию, а просматривает. Занятой клиент или заказчик не стал бы считать 5ки на первой картинке. Основная мысль доклада в том, что любые отчеты должны быть визуализированы таким образом, чтобы первое, что увидит читатель – это ответ на его вопрос.
Как это сделать? На помощь этому приходят некоторые конкретные методы. Например, если мы делаем отчет и поделим экран/страничку/лист бумаги на 4 сегмента, то самое большое внимание пользователь уделит верхнему левому квадрату – чуть меньше верхнему правому и нижнему левому, и меньше всего – правому нижнему. Смотрите левую картинку ниже. Если мы говорим о дашбордах в веб-системах, то здесь будет работать правило с правой картинки ниже: вверху Ключевые показатели (цифры)-> ниже Визуализация (диаграмма) -> Детали (список, таблица, комментарии)

Рис 3

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

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

Вторым моим любимым докладчиком стал Игорь Макаров с темой «Социальная сеть для бизнес-анализа внутри компании».

facebook

Речь шла об использовании Workplace, инструмента Facebook для общения внутри компаний. В рамках небольшой фирмы использование этого тула не актуально, но мне понравилась тема и подача материала. Докладчик рассказывал о том, как их компания обсуждает требования при помощи постов, лайков и шарингов. Удобным показалось то, что все фото, диаграммы, иллюстрации, размещенные при обсуждении в рамках пространства конкретного проекта, потом находятся в одном месте. Маркетологи, сейлзы, служба поддержки – все имеют доступ в это пространство и могут быстро найти необходимую информацию. Для разработчиков-интровертов докладчик рекомендовал использование чатов вместо живых совещаний. Обосновал он это тем, что в чате некоторым людям проще высказывать свои мысли. Также неизменным преимуществом является полное документирование митинга и практически готовые митинг ноутс. У нас в компании такой проблемы нет – все ребята открытые, мысли свои высказывать не боятся, поэтому мы бы, например, не хотели заменять живое общение чатами и тратить больше времени на переписку. Если кому интересно больше о Workplace, читайте тут https://www.facebook.com/workplace

Топ-доклад Славы: о рисках

Могу отметить два моих фаворита:
1) Мастер-класс по управлению рисками от Валентины Круподеровой
2) Тренинг по психологии управления “PM vs BA vs World. Как ведут себя люди, которым вы ставите задачи” от минчанина Сергея Крупенина
Кстати, эти доклады заняли 3-е и 1-ое место по итогу голосования. В статье я сконцентрируюсь на первом докладе.
Докладчиком был предложен следующий алгоритм для определения возможных рисков при разработке продукта и их последующего контроля.

Первый шаг – Составляем список рисков
Собираем команду и проводим краткий мозговой штурм на предмет выявления всевозможных рисков в проекте.

Второй шаг – делим риски на категории

Строим следующий график (см. внизу).
1) “Реальные риски” – цена страховки, которых соответствует норме, а сами риски поддаются контролю. Для нас данный тип представляет наибольший интерес.
2) “Ошибки анализа” – которые также поддаются контролю, но их весьма дорого страховать.
3) “Мифические риски” – которые нужно сразу выявлять, чтобы с ними “не бороться”.
4) И, наконец, “чужие риски” или “риски заказчика”. Важно определить данные риски, чтобы разграничить зоны ответственности. Это все должно найти отражение в письменном документе, утвержденным обеими сторонами.

рис 4

Третий шаг – рассматриваем только реальные риски
“Прогоняем” риски по определенной схеме (см. внизу). Так как выделенные нами риски понятны, то они само собой являются осознаваемыми. Что касается неосознаваемых рисков, то тут поможет только “чудо” и надежда на то, что данные риски попадут в категорию “мифических”:)
Осознаваемые риски могут быть неуправляемыми и управляемыми. Если риск неуправляемый, то необходимо убедиться, что мы можем адаптировать процесс на нашем проекте, чтобы ослабить данный риск.

рис 5

Четвертый шаг – выбираем стратегию управления управляемыми рисками. Стоит отметить, что можно и нужно сочетать несколько стратегий для качественного управления проектами.
1) Уклонение от управления
2) Избегание риска
3) Ослабление риска
4) Сдерживание последствий

Думаю, у многих возник вопрос, как же нам определить уровень воздействия? Для этого необходимо использовать следующую формулу:
RE = P x C, где RE – risk exposure (воздействие риска), P – probability (вероятность риска), С – Impact of loss (стоимость риска), т.е. сколько мы можем потерять денег.

Следует отметить, что градация шкал для определения вероятности и стоимости должна быть выбрана командой в соответствии с особенностями проекта. Можно отметить такие факторы, как специфика самого проекта, его масштаб и сложность, методология разработки и т.д.

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

Топ-доклад Вали: о требованиях
Параллельно шло 4 потока докладов + беседы «в кулуарах». На всё попасть было физически невозможно, поэтому приходилось делать трудный выбор. И пару раз я ошиблась, но в основном я своим выбором докладов довольна. Мне были интересны доклады по тематикам: качество требований, повышению эффективности, управление рисками и принятие решений.

Ну а The Best доклад в моём рейтинге – это мастер-класс Сергея Мартыненко «Жестокое обращение с ошибками в требованиях на глазах у публики».
Во-первых, сам докладчик – очень интересный человек, имеющий много опыта и прочитавший кучу литературы по теме. Его даже можно привлечь к своему проекту – он утверждает, что видит возможные ошибки наперёд и помогает сделать проект «без костылей».
Во-вторых, интересная тема и интересный материал доклада, часть которого касалась выявления и проверки требований.

Из запомнившегося:
1) Людям свойственно состояние положительной предвзятости, т.е. обычно мы задаём вопросы, чтобы подтвердить нашу гипотезу. Надо же учиться задавать такие вопросы, на которые получим ответ «Нет».
2) Требования нужно рассматривать с разных аспектов: с точки зрения BA, Dev и QA. Теоретически, это может делать и один человек. Но человек не может думать в двух аспектах мышления одновременно, и мы должны учиться сознательно переключать контекст.
Во время этого доклада произошёл и курьёзный случай – почему-то большой экран не хотел работать, а презентацию нужно было показать. И тут нам на помощь пришла хрупкая девушка, доставшая из недр своей дамской сумочки настоящий большой проектор и ноутбук с подходящим разъёмом к нему (см. фото). Для проектора повесили белый лист – доклад был спасён

рис 6

Итого, на конференции были разные доклады. Некоторые порадовали, некоторые разочаровали. Но мы довольны, что каждый из нас нашел для себя что-то новое и полезное.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *


× 6 = восемнадцать

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">