Slider Background

AnalystDays 2015

AnalystDays 2015

В конце прошлой недели мы с Олей Паламарчук отправились в Республику Беларусь, в Минск на конференцию Analyst Days 2015.
Впечатлений привезли из поездки очень много: новая страна, новый город, новые люди. И много новой, вкусной и полезной информации!
Расскажем про те доклады, которые нам оказались наиболее интересны.

"Как решить проблему, о которую уже все копья сломаны" Светланы Гончар

И в жизни, и в работе часто бывают проблемы, с которыми бьемся, бьемся, и победить не можем. Автор предложил нам довольно простой диагностический инструмент, который позволяет взглянуть на проблему под другим углом. Инструмент этот - интегральные карты Уилбера. Используем матрицу 2х2, внешнее/внутреннее, индивидуальное/коллективное. Определяем квадрат, в котором возникла проблема (по умолчанию считаем, что в рамках этого квадрата проблема не решается), и ищем способы влияния на нее из других квадратов.
Метод не дает гарантированного результата в виде решения проблемы (яблоко на голову не свалится), но мы получаем более полную картину самой проблемы, с которой уже что-то можем сделать.

"Управление рисками в реальном времени" Юрия Дайбова

Очень кратко, но ярко, с живыми примерами Юрий рассказал об управлении рисками. Про проактивное (превентивное управление рисками) и реактивное (устранение последствий реализовавшихся рисков). Что примечательно, никого не призывал управлять рисками. Но к концу доклада все были стопроцентно убеждены, что рисками управлять можно и нужно. Коротко рассказал о способах выявления рисков, об их анализе, отсеве маловероятных рисков (управлять можно рисками в количестве от 3 до максимум 7, попытка управления большим количеством рисков - уже именно попытка, а не управление), об основных стратегиях управления рисками.

"Сколько стоит идея шефа, или инвестиционный доход для менеджеров" Ольги Павловой

Как обычно, доклад собаки Павловой был очень живым и увлекательным. Ольга проводила параллели между законами макро- и микроэкономики и типовыми ситуациями в IT. Наиболее яркое впечатление на меня произвел график (слайд 30) с постулатом "соотношение количества хорошего и плохого кода по мере приближения даты релиза - чем ближе релиз, тем больше "плохого кода". Нет смысла оттягивать дедлайн, ничего хорошего уже не накодим".
Рассмотрели еще несколько ситуаций в режиме Myth Busters, из наиболее запомнившегося:
  • не успеваете к сроку? Возьмите еще людей в команду;
  • пираты ни у кого ничего не крадут;
  • не до интерфейсов, главное - функционал!

"Способ превращения горстки неинтересных задач в успешный проект" Алексея Маризы

По моему мнению, лучший доклад из всех тех, которые я слушала. Основной посыл: сотрудники - это в первую очередь люди. Пойми коллегу и сможешь найти и поставить ему любую задачу, которую тот выполнит качественно и с удовольствием. А если задача ему не подходит, но поручить ее все равно нужно, то - магия! - как преподнести задачу так, чтобы загорелись глаза.Презентация: http://www.analystdays.com/ru/talk/33435

"Метод VCM+ для выявления противоречий в требованиях заинтересованных лиц", Андрей Курьян

Одна из основных идей доклада в том, что в каждой системе есть антисистема. В то время как система приносит пользу заинтересованным лицам, антисистема создает нежелательные эффекты. Каждое решение, которое удовлетворяет требованию, как правило, порождает нежелательный эффект. В докладе Андрей рассказывал про метод инверсии требования для снижения нежелательного эффекта и улучшения тем самым решения. Метод инверсии требования предполагает выявление основного параметра требования, инвертирование значения этого параметра (выявление инвертированного требования) и поиск потенциальных заинтересованных лиц для получившегося инвертированного требования. После выявления заинтересованных лиц антитребования предполагается, согласно докладу, решение получившегося противоречия инструментами ТРИЗ. К сожалению, алгоритмы решения в докладе не освещались, но о них можно почитать отдельно (ссылки и методы в презентации представлены). Кроме того, выбор "проблемных" требований, которые порождают антисистему, из всего скоупа требований остается на опыте аналитика.

"Шаблонизируй это. Как паттерны требований облегчают жизнь аналитика", Виталий Мальцев

Часто одни и те же требования к функции или компоненту системы от одной системы к другой очень похожи, а иногда и вовсе одинаковы. При этом описание требований к функционалу необходимо описывать каждый раз. Со временем функционал кажется понятным (это же очевидно!) и либо не описывается совсем (после чего работать начинает совсем не очевидно), либо разного рода уточнения забываются, не переносятся (не копируются) из другой спецификации, либо не находится спецификация, где это уже описано и надо описать снова (наступаем на те же грабли, что и при первом описании данного функционала).
Виталий рассказывал в докладе о том, как упростить описание однообразного функционала путем создания шаблонов, в которых будут описаны все-все накопленные требования для определенной функции и при следующем ее описании достаточно взять шаблон и в пропуски вставить нужные уточнения (если это необходимо).
Мне идея понравилась, по возможности постараюсь ее применить (проблема в том, что на написание и поддержание шаблона в актуальном состоянии требуется время).
Презентация: http://www.analystdays.com/ru/talk/33401

"Customer Journey Mapping для бизнес-аналитиков и не только", Юрий Веденин

Данный доклад был вместо доклада "Анализ требований с точки зрения UX", автор которого не смог присутствовать на конференции.
Юрий рассказывал про метод построения карты путешествия потребителей для улучшения UX интерфейсов. Пользователь совершает определенные действия в системе, результат каждого действия вызывает какую-либо эмоцию у пользователя. Для создания "хорошего" интерфейса нужно предугадать желания пользователей, быть внимательными к мелочам (именно они часто создают эмоциональную окраску). В докладе приводится пример про Саху, которая заказывает пиццу. Например, факт того, что пиццу привезли не вызывает яркой эмоциональной окраски (ну ок, Саха заказала пиццу, пиццу привезли, ничего необычного). Тогда как мелочи (Саха заказывала не острую пиццу, а привезли острую или пиццу привезли раньше обещанного времени) вызывают определенную эмоциональную реакцию, от которой, как правило, зависит захочет ли пользователь снова воспользоваться системой.
Метод карты путешествия потребителя позволяет наглядно представить действия пользователя, его реакцию на те или иные особенности работы системы, предположить его мысли, выявить проблемы и придумать возможные решения этих самых проблем. Карта может быть представлена различными способами: табличными, круговыми, линейными. Например, таблица: каждый столбец представляет этап выполнения процесса (время), в строках для каждого этапа описываются цели пользователя и бизнеса, точки контакта (время, место, канал соприкосновения с системой), мысли, чувства, эмоции пользователя, проблемы, идеи устранения проблем. Первично карту можно построить на основе знаний команды, а потом общение, исследования, тестирования, изучения конкурентов и т.д.
Доклад был очень живым. Юрий рассказывал веселые и поучительные истории из жизни (в презентации представлены). Метод мне показался интересным, но, на мой взгляд, больше подходящим сервисам, нежели крупным заказным проектам. Хотя все зависит от возможностей и желаний команды.
Презентация: http://www.analystdays.com/ru/talk/36027

Лиричное отступление

И немного фотографий Минска, каким увидели его мы.
Троицкое предместье

Вид на Минск со смотровой площадки Белорусской национальной библиотеки

И снова со смотровой площадки библиотеки
Видео с конференции: https://www.facebook.com/analystdays

 Фото с конференции: Альбом "Analyst Days 4"
#Аналитика #Обмен опытом