Всем привет! В начале апреля я готовлю очередной плановый митап сообщества (в СПб). В этот раз тема: "Трудности перевода: аналитик vs разработчик". По этому поводу нахожусь в поисках спикера, кому есть что рассказать о ситуации когда команд разработки много, а аналитик один на всех. Приходите в личку, расскажу подробности.

Менеджмент в энтерпрайзе непрерывно связан с управлением ожиданиями заинтересованных сторон (stakeholder management).

Во-первых, это реально востребовано и прописано в стандартах по бизнес-анализу (а менеджмент этим занимаются вне зависимости осознает или нет), во-вторых, от таланта к этому виду менеджмента зависит твой карьерный трек. Вот тут ключевой вопрос на какую группу заинтересованных мы ориентируемся – на ту, что заказывает и платит или ту, что реально будет пользоваться. Когда на первую группу, то отказ от цели или планов происходит как правило так: «Коллеги мы не нарушаем своих договоренностей, мы планомерно их меняем» или прямо «Планы изменились, сворачиваемся». Ну что же, упал, отжался, отряхнулся и пошел дальше. А вот когда на тех, кто этим должен пользоваться, то путь получается еще более интересным. Хочу разобрать на примере разработки отечественного трамвая Russia One. Наверняка вы что-то слышали про этот проект.

За дело взялись профессиональные дизайнеры, уже имевшие прикладной опыт на производственных проектах. Наверняка у них были крутые UX-исследования, ведь трамвай имел анатомические кресла, продуманную логистику пассажиров внутри салона, AI-который подбирал музыку и ароматы, в зависимости от времени суток и погоды и много чего еще. По мне так работа с заинтересованными сторонами (пассажирами) была проведена блестящая.

Вот так выглядело интервью главного дизайнера Алексея Маслова в 16 году:

В. КАРПОВ: Можно я уточню важный момент? Этот трамвай живёт своей какой-то отдельной жизнью? У него есть сайт, например? Вы планируете его выпускать в ближайшее время или его ждёт судьба Ё-мобиля?
А. МАСЛОВ: Да, Ж-мобиля, как называют. Нет, конечно же, его не ждёт судьба Ё-мобиля, потому что сейчас уже подписан ряд стратегических соглашений, которые регулируют его серийное строительство. Мы сейчас готовим его к испытаниям, готовим ко всем тестам и ориентируемся на выпуск конец 2016 – начало 2017 года он уже, как я надеюсь, будет ездить по городам России.

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

Как говорится: береги стейкхолдера с молодости.

Подход к принятию менеджерских решений

Вчера с Димой Филипповым обсуждали его классификацию сотрудников и тут я осознал, что это очень похоже на мой подход к принятию менеджерских решений. В рамках рубрики «Мама смотри, Я – менеджер» расскажу о нем подробно.

Слушай всех, прислушивайся к немногим, решай сам - древняя мудрость.

Три уровня обсуждения и при принятии решений

🔸Уровень 1. Тактический.
По этому уровню идет оценка моей личной эффективности. Я это так формулирую: «Эффективность = попадание в потребность бизнеса». На этом уровне менеджер, занимает роль лидера. Чаще всего общение идет с сотрудниками «4 уровня» по классификации Дмитрия.

Общий алгоритм выглядит так:
▪️Проанализировать ситуацию (стация исследования). Для этого у меня есть свой алгоритм основанный на BABOKv3, но про него будет отдельно.
▪️Обратиться за советом к старшим коллегам. Руководство мои менторы и я буду приходить за консультациями на все уровни вверх на которые только могу дотянуться.
▪️Зафиксировать выводы и оповестить непосредственное руководство.
▪️Принять решение и оформить распоряжения.

🔸Уровень 2. Направление/продукт
Основная роль менеджера фасилитатор. Общение происходит уже с продактами смежных направлений, лидами, архитекторами решений и т.д. Как правило, это люди 2 и 3 уровней.
Тут появляются общие правила, по которым будет принято решение: критерии выбора описаны и заранее всем известны, вовлечение и яростные споры (челенж окружающих и выявление интеграционных рисков и т.д.).

🔸Уровень 3. Команда
Начинается работа с сотрудниками 2 и не редко 1 уровней.
Основной ролью менеджера становится - наставник.
Тут появляется новый термин «субъективная справедливость». Это прозрачная процедура и учёт всех мнений одновременно. Я приму во внимание мнение всех, кто хочет до меня его донести: прийти лично, высказаться на общих встречах, на специализированных мозговых штурмах и т.д. Если не дошли, то мнение не учитывается в дальнейшем.

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

Так можно и до этих компаний дойти:

Газпром Нефть, Авито, ВТБ, Норильский никель, ОТП Банк

#пятничныйюмор

4 апреля — круглый стол сообщества аналитиков «Трудности перевода: Аналитик VS Разработчик»

Запускаем регистрацию на первый в этом году митап (за одно и бота нового обкатаю). В прошлом декабре мы проверили новый формат ивента и он получил много восторженных отзывов. Поэтому останавливаемся на формате: круглый стол + бизнес-игра с фасилитацией. В этот раз митап пройдет на площадке Nexign.

Количество мест ограничено + нужны списки для охраны, поэтому регистрация обязательна!

Присоединяйтесь к нам и получите заряд энергии от живого общения!

📍Санкт-Петербург, Уральская,4, БЦ «Смоленский», офис Nexign
🗓 4 апреля в 19:00

Итак, что же нас ждет
🔮 Секретов чтения мыслей мы не знаем, зато можем поделиться историями продуктивного взаимодействия и совместно сформулировать подходы сотрудничества с разными типажами разработчиков.
В формате круглого стола наши спикеры поделятся опытом и мыслями как строить коммуникацию в разных аспектах работы аналитика:
🧩Роль визуализации во взаимодействии аналитика с другими ролями. Татьяна Ульданова, Nexign
🧩Бюрократия в современной разработке. Владислав Архипов, Аксеникс
🧩Специфицирование API, OAS3.0 и чем они помогают во взаимодействии аналитика и разработчика? Юлия Дробина, Nexign
🧩Вас много, а я одна: упрощение жизни аналитика на нескольких проектах. Анкель Лихтенберг, ИнфоТеКС

Во второй части мы развернем небольшую бизнес-игру, в рамках которой все вместе найдем и зафиксируем самые эффективные инструменты диалога с разработчиками.
Фасилитатор: Владислав Котов, эксперт в области цифровой трансформации и бизнес-анализа, куратор сообщества BA/SA и консультант.

📍Санкт-Петербург, Уральская,4, БЦ «Смоленский», офис Nexign
🗓 4 апреля в 19:00

🔔В прошлом посте я писал про уровни принятия решений. Давайте немного попрактикуемся работать на уровне 2. В основе любой коллективной работы и принятия решений лежит конфликт. Глобально можно их разделить на две группы: когнитивные (конфликт рабочих интересов) и аффективные (конфликт личных интересов).

На уровне 2 мы становимся фисилитаторами* и наша задача эти конфликты разжигать и поддерживать.

*Фасилитация, это набор практик применяемых, когда решение нужно принять или когда решение нужно придумать. В остальных случаях, это модерация.

Для поддержки и развития конструктивного конфликта нужны понятные правила:
- один вопрос одно решение
- высказываются все (тем, кто это делать не умеет подбирайте формат, где человек будет раскрываться)
- внимание к мнению
- смена ролей (вообще мое любимое)
- не брать первое удобное решение (почему это нехорошо описывал тут)

Не могу советовать без должной сноровки залезать сразу в обе группы конфликтов, т.к. у вас может не хватить энергии удерживать их в конструктивном русле и всё перерастет в неуправляемый срач, с выявленным виновником. Угадайте, кто будет отвечать за последствия?


🔅Давайте разберем правило «разбивать людей на коалиции», которые вы можете уже завтра использовать в своей работе. Предположим, нужно принять решение о внедрении в ваш процесс нового правила оформления «артефакта». Разбиваем всех участников дискуссии на две группы «А» и «Б». У обоих групп есть 15 минут на мозговой штурм в формате «1 записывает остальные генерят идеи». Группа «А» говорит почему хорошо и будет помогать. Группа «Б» почему плохо и будет мешать. После завершения группы рассказывают о результатах и уже совместно дополняют результаты друг друга. Вам остается выбрать самые рискованные и актуальные варианты и зафиксировать их виде распределения (определить крайности выгоды и вреда).

Такой подход применим в рамках одной встречи, учитывает мнения всех участников и демонстрирует продуманность всех за и против. Если решение все еще посередине между «за и против», тогда следует отпустить это и вернуться спустя неделю другую.

Приходите на наш бесплатный митап 4 апреля, где мы будем углубляться в тему коллективных конфликтов и разбирать варианты как из них грамотно выходить.

❗️Ссылка на регистрацию в закрепе!

Рассказ про ролевые модели и быстрый старт работ

Кросс-функциональная команда – термин, который не сходит с уст уже не первый десяток лет. И сразу представляются опытные, высокомотивированные специалисты, кто может и муку замесить и фарш сделать и воду под пельмени поставить. А как дела обстоят в коллективах, где функция представлена ни одним человеком, а многими. В одной из бизнес-игр у меня был отдел аналитиков, кто делал одну общую задачу. И из раза в раз я наблюдал следующие паттерны (П) поведения:

🔸П1. Все действия дублируются. Вместе читаем, вместе ходим, вместе пишем.
🔸П2. Все разбегаются по разным углам и производят П1, но по отдельности.
🔸П3. Коллективная прокрастинация.

В scrum-гайде сказано, что стремится выполнять кросс-функцию и делать все за всех ("каждой твари по паре"). Но нет ни слова про реальные ситуации, когда у нас не один аналитик/тестировщик/разработчик и т.д., а много. Коучи наверняка скажут "кра-кра-кря, нужно разбивать на отдельные команды", но может и нужно, то не всегда, не везде и не каждый раз.

Потом я вспомнил курс по социологии «динамика малых групп», где рассказывалось, что группа будет саморегулироваться и выстаиваться в иерархию, но на это нужно время. Ну и без жертв тут не обойдется, кто-то будет подчиняться, а кто-то подчинять. Одним словом, любому коллективу нужно время для саморегуляции и выстраивания иерархии. А что делать когда этого времени нет? Нужно делать и вчера. Наличие лидера/управленца тут может помочь, то это будет директивное управление и результат напрямую зависит от понимания нашего управленца какой результат нужен и что конкретно нас к нему приведет (а таких ну очень мало) и желания коллектива работать в режиме угнетения. Что в свою очередь тоже противоречит принципам дедушки Сазерленда.

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

На втором месте стоит не очень популярная в РФ модель-RAPID. Если очень коротко, то участники одной функции делятся на следующие роли: рекомендатели, переговорщики, сомневающиеся, решающие, делающие. В отличии от первой модели тут все проще и логичнее. Но требует практики.

Так у меня появилась немного урезанная версия модели, которую можно внедрить буквально за 10 минут. Все люди внутри коллектива разбиваются на 3 роли:

🔹«Координатор». Сосредотачивается на задачах команды, стимулирует сотрудников работать и отслеживает время.
🔹«Специалист». Дает команде глубокие знания в предметной области.
🔹«Контролер-завершитель». Делает трассировку результата на исходную задачу и тщательно проверяет на наличие ошибок в логике.

Даже при таком простом функциональном разделении коллективы начинают выходить из П1-3 и переходить к П4 – параллельность планирования/исполнения/само корректировки. Наличие Scrum-мастера в команде не противоречит возможности функционально-ролевого разделения. Это позволяет запустить работу над решением в любой группе и получать первые результаты в 2 раза быстрее. Модель отработана как на тренингах и играх, так и в рабочей практики.

Если интересны примеры использования, то задавайте вопрос в комментариях.

Кто идёт к нам на митап, то вот в эти стеклянные двери и по указанием на самый вверх. Начинаем по плану в 19.00, приходите!

Рефлексия после нашего весеннего митапа

В первой части четверо спикеров с разных сторон освещали тему взаимодействия между функциями: через образы, документацию, код и переключения себя между контекстами. Чуть позже выложу презентации или видео.

Отдельные слова благодарности HR службе Nexign и спикерам!

Сегодня хотелось бы отрефлексировать над игрой «Аналитик VS Разработчик» и поделиться мыслями.
В ходе игры команде аналитиков предстояли очень важные переговоры с разработчиками разных психотипов. Для простоты мы собрали четыре самых ярких: душнила-перфекционист, злая собака, тревожничек, ядовитый нарцисс.

Команде предстояло проанализировать тип, мотивацию, построить переговорную стратегию и дойти до «договоренности».
Основные выводы наблюдателя со стороны:
🔹Даже базовый алгоритм подготовки к переговорам приводит к хорошим результатам. Отличной иллюстрацией может послужить сказка «Волшебное слово».
🔹В случаях внутреннего конфликта непринято идти к руководителю и люди решают своим проблемы как умеют. Почему руководитель делегирует это кому-то можно только догадываться: или нет школы менеджмента или теория не перерастает в практику.
🔹Аналитик более заинтересован в признании и общем результате. Разработчик свое получают в любом случае, т.к. решение задачи в коде и есть результат. Моё личное наблюдение, с оговорками, что это не 100% продуктовая команда, доход не зависит от продаж или это какой-нибудь бизнес-архитектор, кто все еще пишет код.
🔹Конфликт нужно решать в целом. Был вопрос от участников «если бы на кону стояла не вся компания, а какая-то конкретная фича, то мы бы быстрее нашли компромисс и договорились».

Я верю, что перевести конфликт в сторону когнитивного и действительно договориться, а не найти никого не устраивающий компромисс можно только на уровне бизнес-функции или вообще всего бизнеса.

А как вы считаете?

Прямо сейчас в Ульяновске запустилась секция системного и бизнес-анализа в рамках конференции Стачка24.

В прошлом году я поучаствовал в качестве приглашенного игротехника. Организатором секции стала @zubkova_oa. В первых Стачках аналитики приписывались к разработке, поэтому для конференции это был первый опыт взаимодействия с аналитиками как отдельной и боевой единицей, а для Ольги в качестве организатора.
В этом году я присоединился уже в качестве программного комитета. Часть спикеров пришла с сайта конференции, часть от HRD партнеров, часть мы привели своих, кто хорошо вписывался в созданную нами концепцию.

Про концепцию я расскажу отдельно, ведь уже в этом сентябре в СПб мы запускаем первую Стачка вне Ульяновска. И трек BA/SA станет одним из ключевых и масштабных.

Добраться до Ульяновска не получилось из-за болезни и семейных дел, но я очень горжусь и переживаю за спикеров, которые за время супервизии и подготовки стали очень близкими духом и эмоционально.

Вчера небольшой группой бизнес-аналитиков подключились к вебинару Гая Карапетяна, где он в подробностях разбирал свой опыт бизнес-консультанта. Гай показывал различные чек-листы по первичной диагностике бизнеса и делился многолетним опытом.

В очередной раз убеждаюсь, что люди по отдельности переизобретают бизнес-анализ и приходят к типовым алгоритмам, которые существуют не одно десятилетние. С одной стороны это показывает, что алгоритмы верны и все еще актуальны, с другой стороны можно их разбирать и пользоваться без 10+ лет боли, страданий, проб и ошибок. Ну тут каждый сам себе выбирает дорогу 🙃

Ключевая мысль, которой хочу с вами поделиться:
– Чем бизнес-консультант отличается от бизнес-аналитика?
🐶Консультант приходит, приносит свои матрицы, быстро и точечно показывает «где у собачки болит». Или уходит к следующим заказчику или проводит манипуляции, через которые помогает руководству сформировать план действий. Т.е. ответственность полностью лежит на собственниках и управленцах.
🐱Бизнес-аналитики делают абсолютно тоже самое, за исключением того, что они становятся этим самым ответственным руководителем решения. И сопровождают как само изменение, так и замер результата.

p.s. Вышеупомянутые матрицы, это такие гнутые прутки, которые поворачиваются к проблеме и резонируют в голове мыслью «чегобля?». Вот если чегобля в голове не раздалась, идем дальше и проверяем следующую роль/процесс/продукт/систему.

Мир-Труд-Пиво и бурбон

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

Если интересная для вас тема, то ставьте 👍. Могу чаще про пивоварню и производство дистиллятов рассказывать.

Максим Цепков был на двух наших выступлениях и отметил формат доклада Юры Санникова. А удивить Максима довольно непростая задача. Это успех 10 из 9.

Его отчёт тут

Всем привет!

А вот и материалы с островка сообщества аналитиков «SPb BA/SA» с ITGM#16

🔹Санников Юрий, доклад "Проектирование API. Сказ о аналитике и архитектуре"
🔹Архипов Владислав, доклад "Проектирование API. Что ещё нужно знать аналитику"
🔹Московкина Анастасия, мастер-класс "Opportunity Canvas. Карта анализа проблемы и поиска решения"
— статья Джеффа Паттона
— бизнес-модель канвас «Построение бизнес-моделей, Алекс Остервальдер, Ив Пинье»
🔹Богданов Денис, доклад "Джуновый мидл или сеньерный сеньер. Как оценить, где эта грань?"
🔹Гольденберг Рая, Богданов Денис, Владислав Котов, круглый стол "Давайте жить дружно или что ожидают от аналитика".

Карта гипотез и стратегирование

Сегодня приехал в Москву на тренинг по карте гипотез от @alexanderbyndyu.

Это такой отточенный на практике и адаптированный под РФ инструмент стратегирования и дизайна стратсессий. Как раз вышел плакат с описанием - тут

Как я его применю в своем фреймворке Strategy Consulting, Саша писал отдельным постом - тут

После тренинга поделюсь результатами и покажу на примере как это работает.

Всем продуктивного дня!😜

🔔Сегодня на VC вышла новая статья «Осмысленная оценка. Нас не учат, а мы делаем», посвящённая быстрой и эффективной оценке, которая помогает досягать конкурентного преимущества и предотвращения роста затрат и упущенных возможностей.

Я разработал уникальный мыслительный шаблон для оценки альтернатив и принятия оптимальных решений, который теперь доступен в моем мастер-классе.

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

Основные шаги шаблона
🔹Объекты. Выбор и осознание объекта оценки. Это может быть задача, проект или ситуация (система).
🔹Внутреннее состояние. Определение своего текущего состояния, наличие сил и мотивации. Это опирается на осознание своей миссия, морали и жизненной стратегии.
🔹Внешняя среда. Анализ внешней среды, требований к качеству и потребителей результатов (стейкхолдеров).
🔹Прогнозирование развития альтернативы в будущем. Как выбранная альтернатива будет развиваться со временем и к чему это может приводить (не путайте прогнозирование с планированием).
🔹Выбор альтернативы. Отсечение вариантов, которые нам не подходят по той или иной причине и выбор единственной из всех равнозначных. При сложном и многомерном выборе нам помогут различные шаблоны: стоимость - эффективность – время, квадрат Декарта, Сost benefit analysis, GAP analysis.
🔹Рефлексия. В дальнейшем нужно проанализировать результаты как самого анализа, так и то, к чему нас привел выбор альтернативы, для дальнейшей корректировки предыдущих шагов.

Полный разбор метода можно посмотреть на VC - тут
Записи мастер-класса с разбором примеров - тут

Стратегический отчет HH за 23 год – люди и человечность главный тренд последнего времени. На ITGM был круглый стол, где в треке «я и компания» отметили, что «человечность» и ориентация на личность должны сменить «бездушные корпоративные культуры».