Мы здесь регулярно говорим про микроменеджмент. Но что, если эта тема не только про доверие, а в первую очередь, про внимание руководителя?
Когда вокруг всё меняется, именно внимание становится самым дефицитным управленческим ресурсом. И если оно начинает уходить на постоянные проверки, перепоручения и контроль каждой детали, у руководителя просто не остается ресурса на стратегию, принятие решений и развитие команды.
В июне состоялся прямой эфир «Как делегировать, когда всё вокруг меняется: доверие, контроль и результат в нестабильные периоды». Тему поддержали:
🎙️ Дмитрий Безуглый - эксперт по стратегическому управлению продуктами и командами с опытом более 20 лет, основатель школы стратегического управления Master Strategy, консультант Яндекс Практикума, Авито, Wargaming, Acronis, Лаборатории Касперского, Т Банка, Сбера, ВТБ.
🎙️ Наталья Косинова - системный аналитик с 20+ лет опыта, прошла путь от технического писателя до руководителя отдела анализа, управляла командой из 25 аналитиков, работала на проектах Билайн, МТС, Тинькофф Страхование, Росгвардии, Утконоса, а также в сфере энергетики и промышленности.
Обсудили важное
➡️ Делегирование задач в условиях изменений и нестабильности.
➡️ Границу между делегированием и микроменеджментом.
➡️ Почему в кризис руководители переходят к чрезмерному контролю.
➡️ Доверие в команде и способы его выстраивания.
➡️ Влияние уровня зрелости сотрудников на стиль управления.
➡️ Выгорание руководителя и команды.
💡 А главное - разобрали реальный кейс слушательницы эфира о делегировании на нескольких уровнях управления
Один из главных выводов, который для меня прозвучал в этом разговоре: делегирование — это не отказ от контроля. Это способность удерживать внимание на своем уровне управления.
Пока руководитель погружен в операционные мелочи, стратегия остается без внимания. А значит, самые важные решения оказываются отложенными именно в тот момент, когда они нужны больше всего.
Включайте на удобной платформе и смотрите прямо сейчас:
📺 YouTube
📺 Рутуб
📱 LinkedIn
С вас — репост, с меня — новые гости и новые крутые интервью 😉
Коммуникация
Очень много всего разного есть, и я решила посчитать какое количество у меня мессанджеров и способов коммуникацией.
Начнём с того, что:
Телега жива и больше всего мне нравится)
Дальше, сорян, меня нет в макс, так что появились альтернативы, где я общаюсь - VK, express, на проекте, куда я вышла работать, был выбран - mattermost, с друзьями я много, где общаюсь, тут нельзяграм, обычные звонки, смски. Забугорные человеки - вотсап, пара человек точно.
Промежуточный итог: 7
Что ещё?)
Аааа, видео конференции!
Тут лидер у меня пока телемост, за ним идёт неправославный зум, гугл мит иногда, на работе dion, очень мало было звонков в МТС линк, кстати контур мне очень нравится, жаль, что он думает больше про корпорации, если есть возможность, я всегда за контур!
А ну куда же без сбер.джазз 😂
Выходит тоже 7.
Ох, если выстроить мою карту коммуникаций, и способов общения, можно прифигеть. Фактически способ общения исходит из того, с кем общаешься и где этот человек находится. Просто уже знаю, кто на что реагирует. Но городской телефон я убрала 😂
Для полноты нужен скайп и аська, если бы они были живы, чтобы они развивались, надо было бы там общаться... Говорят скайп у кого-то жив ещё.
Итого: 14, и добавлю ещё обычную электронную почту - и будет 15!
У кого список больше❓
Делитесь)
P. S. Ждём решений или ИИ-агентов, которые бы это всё многобразие собирали и синхронизировали
Напишу свой вариант ответа, по ситуации, что описала выше.
Спасибо за активность, непростая задача, и я вижу, что потребовалось время осознать, что я вообще тут намоделировала 😂
Пишу по пунктам алгоритм анализа, начиная с бизнес уровня:
1. Выяснить политический контекст ситуации. О чем договорились уже. Кто за что отвечает и какие есть, и есть ли, рычаги влияния. Тут по-хорошему карту заинтересованных лиц описать. И некий приоритет, кто в первом приоритете влияния.
2.Понять, что есть на нашей территории, и что мы делаем в рамках проекта. Иногда реально сложно понять, мы работаем над проектом или продуктом. Часто руководители говорят о продукте, но фактически его нет и идёт работа по проекту. У меня есть статья про разницу проекта и продукта, можно вот тут почитать.
3.Раз уже есть продукт или подобие продукта, а документы от заказчика противоречивые, то стоит изучить существующий вариант, по нему зафиксировать некий концепт. Проще всего предложить заказчику, то что уже есть.
4.Поговорить с коллегами, кто уже общался с заказчиком. По этим договорённостям составить тоже некий концепт. Я люблю графы, поэтому составляю mind maps по проектам.
5.Понять насколько то, что хочет заказчик или якобы хочет, отличается от текущей версии реализации (совместить один граф с другим, можно взять приложение yed, или если не нарушаем nda, то взять ИИ, и коллег).
6.Писать ТЗ за основу беря, то что уже реализовано. Тут подключать менеджеров для того, чтобы презентовать заказчику вижен по автоматизации.
7.Когда мы поймём разницу и то, что нужно доработать, пойти к тим лидам и архитекторам и с ними проговорить. Обозначить будет ли этот набор фич риском или нет. Если да, то в оценку включать риски.
Нет смысла уходить в детали, для таких задач лучше выходить на уровень пользовательско-функциональных требований (тут мне хорошо оперировать use cases), и брать системный контекст, для понимания возможных интеграций.
Насчёт того, задача эта для какого уровня аналитика, я бы брала сеньора ну или крутого миддл. И соглашусь, что тут большой кусок менеджмента, чтобы продакт, руководитель проекта, заказчик выровняли своё понимание. Но с другой стороны крутить концепты и прыгать по абстракциям на разных уровнях, это сеньор конечно. Если есть архитектор, то тоже его задача и тим лида разработки.
🎯Главная цель - не написать в ТЗ, то, что будет "замедленной бомбой", а писать то, что 100% есть, а с другой стороны нужно заказчику и мы это 100% понимаем, если не понимаем, то лучше не писать)
Ну и конечно в идеале получить доступ к заказчику, с ним обсудить, на каком основании был составлен его документ и как его рассматривать, раз в нём откровенная чепуха.
Сильно бы на подобные документы я не опиралась и обозначала их как риски, потому что сложно из них что-то адекватное брать и двигаться дальше.
Но! Нужно понимать, что для нас любая документация от заказчика это исходник!
Я тут резво на него забила, но это вопросики...
Вот тут это тоже уровень сеньора, уметь сказать "нет", и аргументировать. Потому что сложный момент, который требует переговоров с заказчиком для корректировки его понимания. И аналитик, как детектив, примерно пытается понять, первопричину запроса заказчика. Это просто "хотелки" руководства, которые неправильно поняли, или же что-то под этим есть более глубокое?
Есть ещё такая, я бы сказала #ошибка_джуна или #смертельные_грехи_аналитика, когда не понимая процессы As Is, сразу пробуют зафиксировать To Be. И вот документ выходит некой чепухой, хоть и могут топить за то, что он To Be.
Всех с летней пятницей, и для закрытия рабочей недели предлагаю подумать над кейсом. Рубрика #кейссолвинг
Я описываю ситуацию, вы предлагаете варианты выхода, задаёте вопросы, я на следующий день или позже пишу свой ответ)
Предыдущий кейс 🚀
Итак, вы системный аналитик на проекте, только пришли.
Проект уже как-то существует без вас, есть заказчик, есть коллеги (например, 3 человека и человек 10 разработки), они больше в теме договорённостей, и кто чего говорил заказчику и почему. Уже были какие-то встречи с заказчиком. И вот аналитику дают пакет документов от заказчика. Аналитик эти документы рассматривает, как исходный документ для выявления требований. Что вцелом логично. Но по факту оказывается, что это некая версия вижена от заказчика, как он хочет решать свои задачи. И конечно документ противоречит всему, что уже есть в команде, что разработано и зафиксировано в предыдущих итерациях общения.
У аналитика типичное поведение - "с этим работать невозможно", у руководителя проекта типичное поведение "ТЗ до завтра сделаешь?" и прекрасная речь, которая заканчивается вопросом "да, ведь?"
Исходно: аналитику доступно общение с коллегами, кто на проекте, восновном это руководство проектом и продуктом, который есть, есть описание продукта, его в том числе предлагают заказчику.
Продукт реализован в рамках другого проекта, для другого заказчика.
Доступа к новому заказчику нет, как вы уже поняли цель аналитика - написать ТЗ, для согласования с заказчиком.
❓Что посоветуете аналитику?
Какой видите план действий?
Я тут не написала уровень квалификации аналитика, даже интересно, что вы скажите какого уровня нужен аналитик на проекте? 😁
#кейссолвинг #выаналитик
---
😎О системном и бизнес анализе. Подписывайтесь и рекомендуйте друзьям, коллегам
Вчера мы провели первую сессию интервизии с аналитиками и лабораторией системного анализа в лице модератора Сергея Нужненко.
Мы говорили о взаимодействие аналитика и разработчика. Тема больная и все через неё проходят.
Я несколько инсайтов опишу, которые мне больше всего запомнились:
1.Если разработчик не читает ТЗ от аналитика, то тут нужна помощь старших товарищей, это не задача джуна.
2.Разработка часто перегружена, фокус внимания смещен, в голове очень много других задач, поэтому первая реакция чаще всего - как много вы написали, когда мне это всё читать! О ужас!
3.Если такая ситуация возникает, то тут вопрос к процессу и значит плохо работает скрам мастер, теряется смысл ретроспектив.
4.Стоит понимать свои эмоции, которые возникают в связи с ситуацией, потому что эмоции они перекрывают кострутив и сложно в такой ситуации, что-то адекватно сделать. Человек может брать на себя реакцию разработчика, хотя тут может быть что угодно и причина скрыта и неочевидна.
5.Каждый выбирает свою стратегию поведения, исходя из того опыта и ресурсов, что есть.
Для меня тут скорее самое важное это #инстайт того, что разработчики просто банально могут быть перегружены. И это большая боль руководителя проекта или продакта, когда ты такой на подъёме, сейчас как расскажу команде, как мы заживём и какие у меня крутые идеи! А тебя встречает "морда кирпичом", или безразличие. Ну вот опять нам подкинули новое, а мы ещё старое никак не переварим.
И тут совет руководителям, что стоит быть готовым к подобной реакции. А где-то дозированно уметь вбрасывать новое.
Если у вас есть запрос на для разбора вашей ситуации, пишите мне, приходите. Мы создаём бережное пространство, и призываем соблюдать конфиденциальность и NDA.
-----
🙂О системном и бизнес анализе. Подписывайтесь и рекомендуйте друзьям!
😄СУП в ВК
-------
😄Подписаться на ЛСА в ВК