Саморазвитие крайне важно и полезно, и вряд ли кто-либо станет это отрицать. И хотя мнения о прошедшей 17-18 марта конференции IT-Spring сложились не столь однозначные, безусловно, нужно отметить, что, в большинстве своем, впечатления остались весьма положительные. Для тех, кто по тем или иным причинам не смог посетить сие значимое мероприятие, мы подготовили краткий обзор основных моментов конференции, сопроводив его личными комментариями и оценкой на предмет пригодности бизнес-аналитикам.
Первый день показал, что конференция вызвала значительный интерес в среде местных IT-специалистов: как и докладчики, слушатели были весьма активны. Темы докладов обсуждались как в процессе самих докладов, так и в кулуарах, во время “кофе-пауз”, да и после окончания первого дня.
Среди докладов мы выбрали для обзора несколько, хотя это не значит, что остальные не вызвали у нас интереса. Мы осветим лишь те, на которых нам довелось лично присутствовать; аннотации же ко всем докладам вы cможете найти здесь.
Открывала конференцию Анжела Ястреб со своим мини-докладом на тему “Почему мы не достигаем целей?”. В отведенные ей полчаса Анжела рассказала про основные проблемы в постановке и достижении целей. Вопросы, которые она постаралась затронуть, касались того, почему мы так любим ставить себе цели и так тяжело их достигаем, какие ловушки подстерегают нас на пути к нашим целям, чем цель отличается от мечты и как определить, “истинные” ли цели мы себе ставим. Анжела крайне профессионально подала материал, и, на наш взгляд, докладчик для открытия конференции был выбран удачно. К сожалению, доклад бы явно рассчитан на значительно больший промежуток времени, и конец получился немного смазанным. К тому же стоит отметить, что тема далеко не нова и уникальной информации донесено не было. Поэтому доклад запомнился, в первую очередь, харизмой самой Анжелы, которая профессионально занимается коучингом бизнес-аудитории.
Следующим шел доклад Усхата Уразбаева, который, как всегда, очень позитивно и с юмором познакомил нас с понятием “Value Stream Map”. Используемая в методологии Lean, данная нотация позволяет идентифицировать узкие места в каких-либо процессах, получить конкретные показатели и на основе их разработать стратегию улучшения процесса. Причем отметим, что использовать данный инструмент можно практически для любых процессов, поэтому, например, при анализе бизнес-процессов с целью определить слабые места или причины задержек использование Value Stream Map может оказаться полезным. Стоит, конечно, понимать, что использовать эти самые Value Stream Maps стоит только тогда, когда предполагаемый выигрыш будет превышать затраты на встречи, обсуждение и детальный анализ процессов.
После Асхата мы послушали доклад Дмитрия Безуглого на тему “Ключевые архетипы системного мышления и анализ ситуаций в продуктовой и проектной деятельности c их применением”. Поначалу шел долгий разбор того, что такое системное мышление и архетипы. Но уже к середине доклада стала ясна практическая применимость знаний об этих самых архетипах. Поскольку любая система характеризуется наличием в ней обратной связи, важно понимать что большая задержка обратной связи может привести к тому, что человек не будет воспринимать связь между событиями-триггерами и событиями-результатами. Управляя любой системой, следует учитывать, что слишком энергичное воздействие на систему приводит систему к нестабильности и снижению чувствительности. Перенеся это на область бизнес-анализа, получаем, к примеру, понимание процесса разработки требований в Agile-методологиях. Короткая итерация позволяет получить более частую обратную связь и, следовательно, изменять требования к системе нужно менее кардинально, чем в классических методологиях разработки.
Интересным архетипом нам показалась “Подмена проблемы”. Непонимание сути проблемы приводит к неправильному, симптоматическому решению. Например, предложить владельцу бизнеса увеличить количество сотрудников, работающих с документами, чтобы ускорить документооборот, будет именно симптоматическим решением. А вот оптимизировать сам документооборот — решением кардинальным. Но всегда ли симптоматические решения бесполезны? Над этим Дмитрий и предлагает подумать на досуге.
Владимир Горшунов в своем докладе “Как совместить Scrum и Kanban” систематизированно и доходчиво объяснил, как можно удачно совместить две популярные методологии, выбрав из них лучшие практики. На примере трех ситуаций (маленькие проекты, стартапы со стороны заказчика и поддержка production-приложений) была рассмотрена применимость элементов этих методологий и их комбинация в едином подходе — Scrumban. Доклад Владимира бы крайне интересным, с четкой и разложенной по полочкам подачей материала и, что самое главное, вызвал непреодолимое желание внедрять и экспериментировать с методологией Scrumban. Ценность доклада для аналитика показалась скорее научной, однако, как показывает практика, знания такого рода никогда лишними не бывают.
Были мы и на докладе Александра Кольцова с темой “Как выглядят ИТ-проекты в глазах Заказчика”. В целом, хороший доклад. Интересно было послушать о том, как нужно писать коммерческое предложение (а аналитик часто принимает участие в написании этого документа), как оценивать затраты на проект, как и зачем составлять матрицу коммуникации, как проводить kick-off meeting и о многом другом. Истинная ценность доклада заключалась в том, что все это было подано как взгляд со стороны заказчика: на тендер, анализ КП, оценку стоимости проекта и ключевые ошибки в этом процессе. Александр делился своим личным опытом в качестве заказчика IT-проектов в довольно жесткой, но тем не менее харизматичной и напористой манере. Многие моменты показались весьма спорными и сугубо субъективными, но тем не менее зачастую проскальзывала мысль “О! А вот этого мы не знали, а ведь звучит весьма логично…”
Александр Калугин поделился с нами знаниями об ошибках в коммуникации с заказчиком. В своем докладе “Как вести коммуникацию с заказчиком в нелетную погоду” Александр весьма доходчиво объяснил типичные ошибки, которые совершает менеджер проекта (а иногда и аналитик, если через него ведется коммуникация с заказчиком), когда на проекте срабатывает технический риск, т.е. появляется проблема, связанная с техническими трудностями реализации функционала. Типичными ошибками можно считать следующие:
- попытаться исправить дефекты сразу же после их локализации;
- попытаться исправить ситуацию, устанавливая “костыли” в системе (а мы ведь с вами уже знаем, что поскольку “костыли” — это симптоматическое решение, у него всегда будут негативные последствия);
- предлагать заказчику, далекому от области IТ, выбор из нескольких технических альтернатив (-“А что вы предпочитаете: PHP или .NET?” -”Че?”);
- затягивать с ответом, не объясняя при этом, чем команда занимается в текущий момент и решается ли проблема;
- обещать решение, когда уже сработал технический риск. Не следует заверять заказчика, что вы нашли решение и все будет работать завтра, при этом не убедившись окончательно, что решение действительно сработает.
Из негативных моментов отметим, что Александр, подобно Анжеле, попытался вместить огромное количество информации в получасовой интервал, что в реальности привело к крайне беглому обзору проблем. Вместе с абсолютным несоответствием мест в аудитории и количества слушателей это оставило не совсем позитивное общее впечатление от доклада, хотя Александр и показал себя профессионалом в области управления проектами и коммуникаций.
Доклад Николая Фролова “Учимся на ошибках. Подробно о ретроспективе в Agile”, к сожалению, пришлось сделать короче, чем планировалось, но тем не менее прозвучало много полезной информации для IT-специалистов (включая аналитиков), использующих Scrum. Ретроспектива дает возможность получить опыт, которым нужно воспользоваться в следующих итерациях. Состав участников определить довольно просто: участвовать должны вся scrum-команда. Важную роль играет лицо, ответственное за проведение ретроспективы (facilitator).
Структура ретроспективы:
- Настройка (определяем цель, соглашение и ценности);
- Сбор информации (собираем факты об итерации и мнения каждого члена команды);
- Генерация идей (фиксируем все предложений по улучшению);
- Решение о том, что можно изменить (выбираем 3 наиболее оптимальных решения);
- Заключение (благодарим всех за внимание и уделенное ретроспективе время, определяем следующие шаги и ответственных лиц).
Отметим, что если у вас уже есть опыт проведения ретроспективных встреч в рамках Scrum-методологии либо если вы читали специализированную литературу на данную тематику, вы бы вряд ли почерпнули для себя что-либо новое в докладе, так он был явно ориентирован на начинающую аудиторию.
Завершил первый день конференции Михаил Завилейский с докладом на тему “Введение в эмоциональный интеллект для ITшников”. Среднее арифметическое впечатлений и отзывов слушателей показало, что доклад оказался одним из лучших на конференции. Была затронута весьма своеобразная, но от этого не менее актуальная, тема: эмоции и их влияние на характер принимаемых решений. Михаил показал себя экспертом в этой области и дал ряд крайне полезных советов о том, как научиться действовать в гармонии со своими эмоциями, не пытаясь их подавлять. На наш взгляд, тема является крайне насущной и полезной для IT-специалистов всех областей, поэтому советуем скачать и посмотреть видео и презентацию доклада, которые Михаил обещал выложить (скорее всего, на сайте конференции) вскоре.
День второй начался довольно бодро: Сергей Бережной в своем докладе “Инженерный подход в общении с заказчиком” описал различные проблемы в коммуникации с клиентами. К таким типичным ошибкам относятся следующие:
- Объем передаваемой информации слишком большой. Это, безусловно, актуально практически для всех заинтересованных лиц, в том числе и бизнес-аналитиков. Если сообщение слишком объемное, становится сложно понять его структуру и предоставить обратную связь. Поэтому при передаче большого объема информации стоит сопровождать сообщение описанием его структуры. Например, если вы пишете письмо, которое может занять больше страницы, очень желательно включить в такое письмо краткое содержание. Также эффективным приемом является BLUF (Bottom Line Up Front) — краткое предоставление главной идеи сообщения в самом начале этого сообщения.
- Неполнота информации, или отсутствие контекста. Если в сообщении не передается контекст, затраты на коммуникацию возрастают, т.к. вам все равно придется тратить время на последующие пояснения. Также это относится и к использованию специфической терминологии: необходимо объяснять потенциально непонятные для получателя сообщения термины.
- Соотношение “СигналШум”. Чаще всего при эмоциональной перегрузке или при необходимости прикрыть пятую точку в сообщении появляется большое количество лишней информации. Сергей Бережной предложил несколько решений: “Не знаете, что написать — не пишите”, “Знаете — напишите и выбросьте все, что связано с эмоциями”, “Оставляйте время на подготовку, чтобы структурировать сообщение”.
- Отсутствие обратной связи. Эффективность коммуникации будет достигнута, только когда вы, отправив сообщение, убедитесь, что оно дошло до адресата (имеется в виду не только почта, но и звонок, личное общение), что адресат понял его содержание, а также получите обратную связь от адресата. Не стоит забывать и о том, что чем больше одновременных участников в коммуникации, тем меньше пользы от обратной связи.
- Неправильный выбор канала коммуникации. Рецепт прост: “Не заменяйте живое общение на email’ы, если в этом нет необходимости”
Сергей рассмотрел также важность доверия заказчика и влияние доверия на эффективность коммуникации, важность соответствия вашего сообщения внутренним ценностям и убеждениям заказчика. Завершил выступление хорошей мыслью: “Заказчик будет реагировать и предоставлять обратную связь только тогда, когда и вы своевременно реагируете на его действия”. В целом, доклад Сергея Бережного оказался одним из наиболее практически полезных для аналитиков и оставил крайне положительное впечатление.
Далее выступали небезызвестные Слава Панкратов и Александр Орлов с докладом «Большой квадрат работы с людьми». Они предложили “универсальный инструмент разрешения конфликтов”, который представляет собой матрицу 2х2, описывающую алгоритм действий и принятия решений, который будет полезен менеджеру (и аналитику, на наш взгляд, не в меньшей степени) при работе с командой. При возникновении проблемы стоит в первую очередь выяснить ее причину. Причиной того, что люди ничего не делают, всегда является одна из следующих: человек 1) не понимает / не видит цель, 2) не умеет, 3) не может, 4) не хочет. Причем последний пункт стоит исследовать лишь тогда, когда вы твердо уверены, что первые 3 не актуальны.
После того, как мы локализовали проблему и выяснили причину, следует узнать, всегда ли человек так себя вел, или что-то его побудило изменить свое поведение. Это поможет более точно сфокусироваться на причине проблемы и, собственно, ее устранить. Последним пунктом выступает конструктивная конфронтация как способ разрешения конфликта или проблемы.
В итоге мы получили довольно полезный и удобный инструмент. Мы также узнали о матрице “КомпетентностьИнтерес” и подробно рассмотрели алгоритм конструктивной конфронтации. Хотелось бы отдельно отметить, что Панкратов и Орлов не зря вызывают настолько активный интерес у наших IT-специалистов — их доклад действительно был крайне увлекательным, а в сумме с великолепным владением аудиторией и отличным чувством юмора, мы можем смело сказать, что он явился наиболее ярким моментом всей конференции, что и подтвердили заслуженные бурные аплодисменты зала.
Последним докладом, на котором мы побывали, стал доклад Григория Печенкина “Блеск и нищета регламентов”. Григорий поделился своими взглядами на формальные регламенты, описывающие различные процессы в команде, и выделил их положительные и отрицательные стороны. Несмотря на то, что доклад носил скорее образовательный характер, некие полезные идеи мы все же почерпнули. Например, мысль о том, что шаблоны, если их применять без предварительного анализа и осмысления, — зло. В качестве примера он привел использование шифра документа, разработанного по ГОСТ, отражающего код отдела, тип документа, код проекта и иные детали. Если на предприятии нет специальной картотеки, в которой содержатся эти данные и которая делает поиск эффективнее, то и резона применять подобные техники, только лишь потому, что они навязаны стандартом, нет. Для аналитика доклад, несомненно, представлял некий интерес, однако на фоне Панкратова и Орлова довольно монотонная и сухая подача материала слегка подпортила общее впечатление от выступления.
Конечно, как мы уже заметили ранее, другие докладчики также не остались без внимания слушателей. К сожалению, мы покрыли не все доклады, так как не везде удалось побывать. С нетерпением ждем обещанные видеозаписи докладов и презентации. Были, конечно, некоторые нюансы, как нехватка кофе, иногда переполненные и душные аудитории, но общие впечатления о конференции сложились весьма положительные. Выражаем благодарность всем докладчикам и желаем удачи организаторам в следующем году! Ну а тех читателей analyst.by, кому посчастливилось поучаствовать в конференции, призываем делиться впечатлениями и мнениями здесь.
P.S. За предоставленные фотографии отдельное спасибо Антону Марченко.
