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

Делюсь подходом к экспресс-оценке команд, в которых исполнители являются менеджерами - Click

Специально для вас собрал все бизнес и технологические тренды актуальные на 24 год.

Цифровая эпоха и наше место в ней

Хочу порекомендовать материалы Максима Цепкова, который уже не один год изучает и осмысляет тему «Менеджмент цифрового мира». За пять лет у автора накопилось более 52 статей, которые есть в открытом доступе на VC.

Максим размышляет о спиральной динамике, лидерстве, самоопределение. Последней наработкой является модель личности.

В общем, все кому хочется нарастить новых нейронных связей - Click

Как принимать плохие решения.
Так начиналась статья HBR «Методы принятия решений». Хочу поделиться своим представлением о ловушках в принятии сложных решений.

5 психологических ловушек принятия решений:

🔹 Логические ошибки (якорение). Мы переоцениваем важность первых полученных данных и строим систему основываясь на установках и заблуждениях. Самая распространённая ловушка выглядит так: я босс и моя личностная стратегия (опыт, ценности, установки, потребности) приводила меня к успеху, поэтому я буду рассуждать как правильно и неправильно опираясь только на свои суждения о предмете. Также строим решения на данных, которыми легко манипулировать ведь исходную проблему можно сформулировать по-разному и от этого мы получим разные решения.
🔹 Статус-кво и необратимые затраты. Мы боимся сносить и строить заново и относимся к положению вещей как тому, что нельзя изменить. Вчера столкнулся с таким примером: «Мы знаем, что результаты проекта провальные, но никогда не признаемся в этом вслух и следующий проект мы обязательно завяжем на результате предыдущего, еще раз подчеркнув свою значимость и умение достигать результатов». Главный показатель, что нужно сносить, когда на решение о выделении 1млн.руб уходит 10млн.руб (совещания, процедуры, комитеты и всякого рода бюрократия).
🔹 Выдача желаемого за действительное. Мы ищем зацепки, чтобы укрепиться в своих убеждениях. Увы, но так мы устроены и будем искать только те решения, которые нам понятны, а значит безопасны.
🔹 Опыт. Наши действия формируют «предыдущий опыт», и он губителен для выбора решений. На одной чаше весов страх серьезных решений, ведь за провалы следует неминуемое наказание, а на другой ошибка выжившего, когда положительный опыт сложился случайным образом.
🔹 Нет никакого процесса принятия решений. Часто попадаем в ловушку манипуляции и подстройку под личную выгоду (иногда даже не осознавая это). Маркер того, что решение изначально ошибочно – оно принято единолично и единогласно, т.к. нет процесса, который помогал формулировать альтернативы, оценивать и прогнозировать.

А какие вы знаете ловушки?

Когда следствие не имеет причины

Старинный анекдот:

Сидит старый шотландец в пабе, пивко потягивает, трубку курит. Сидел, сидел и говорит:
- Вот эту мельницу, построил я сам, ОДИН(!). Собрал камней, намесил раствор и построил, но почему-то никто не называет меня МакФларен-строитель мельниц. Посидел, отхлебнул пива, затянулся.
- Вот этот сад, в котором сейчас самые большие урожаи фруктов и ягод, посадил я сам, ОДИН(!). Все радуются и собирают плоды. Но почему-то никто не называет меня МакФларен-садовник. Посидел, отхлебнул пива, затянулся.
- Вот этот мост, построил я сам, ОДИН(!), спилил деревья, ошкурил и сделал мост, теперь по нему ездят машины, ходят люди. Но почему-то никто не называет меня МакФларен-строитель мостов. Посидел, отхлебнул пива, затянулся.
- Но стоило один раз выебать эту несчастную овцу...

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

Эффект Кнобе описывает асимметрию реакций между сценариями «пользы" и "вреда».
Если в результате выполнения задач/проектов появляется дополнительный положительный эффект, который не является следствием от основного результата, то польза от этого эффекта будет проигнорирована, ну или внимание и похвала будет минимальной. Но если аналогичный побочный эффект имеет негативную окраску, то его объявляют умышленным, и вся ответственность за негативные последствия ложится на плечи исполнителя, а успех в выполнении исходной задачи/проекта игнорируется.

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

А какие у вас есть примеры из жизни срабатывания эффекта Кнобе?

Мысль дня:
- Первый закон бизнес-анализа: "Любая проблема станет возможностью, а каждая возможность проблемой"

ITGM16 совсем скоро (23.03) и мы закончили подготовку программы островка Сообщества аналитиков. В этот раз у нас будет свое помещение на 30+ человек, в котором мы будем в дружеской и заряженной обстановке разбирать темы проектирования API, оценок и проведем большой круглый стол, посвященный ожиданиям всех от всех.
Итак, наша программа выглядит следующим образом:
🔹Санников Юрий - Проектирование API. Сказ о аналитике и архитектуре (Доклад)
🔹Леонтьев Сергей - Проектирование API. История двух подходов (Доклад)
🔹Московкина Анастасия - Opportunity Canvas. Карта анализа проблемы и поиска решения (Мастер-класс)
🔹Богданов Денис - Джуновый мидл или сеньерный сеньер. Как оценить, где эта грань? (Доклад)
🔹Гольденберг Рая - Давайте жить дружно или что ожидают от аналитика. Приглашенные эксперты. (Круглый стол)

Регистрация и участие бесплатное – тут

Мы сделали это!
На VC вышла первая статься из серии «Укрощение BABOK. Бизнес-анализ на пальцах». В этой серии мы расскажем о том, как можно применять принципы бизнес-анализа на практике, проводить диагностические бизнес-игры, работать со стратегией и стейкхолдерами и конечно о нашем эксклюзивном алгоритме поиска сложных решений.

Часть 1 - "9 принципов реализации бизнес-идеи".
Рассказ о том, как применять подходы БА к себе самому: как мы организовали комьюнити бизнес-аналитиков и архитекторов, как проверить гипотезы и собрать обратную связь. Сформулировали принципы помогающие пройти путь от идеи до массового продукта.


Этот первый опыт написания подобный статей. Если вам понравилось/было полезно, то дайте обратную связь лайком в VC и обязательно поделитесь своим мнением в комментариях.

Всем привет! В начале апреля я готовлю очередной плановый митап сообщества (в СПб). В этот раз тема: "Трудности перевода: аналитик 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, приходите!