Быть руководителем

🐱 Друзья, нужна ваша помощь! Ищем дом для малышки!
-
Сегодня обращусь к вам с необычной для этого канала просьбой.

Недавно, гуляя с собакой, мы нашли котёнка в приямке дома (это такая яма перед окнами цокольного этажа). Малышка не могла самостоятельно выбраться.

Если бы моя собака Рона её не заметила, неизвестно, чем бы всё закончилось. На улице уже холодно.

Конечно же, мы её спасли и забрали домой. ❤️

Сейчас малышка живёт у нас, освоилась, подросла и готова обрести свою семью. Себе оставить не могу, так как у меня уже 3 собаки, 2 из которых такие же спасённые.

Немного о ней:
🐱 Девочка, около 3 месяцев.
❤️ Ласковая, любопытная и активная.
✅ Уже приучена к лотку.
🏡 Находится в Москве.

Очень хочу найти ей любящую семью!

Если вы давно задумывались о котёнке, напишите мне в комментах к этому посту. Я свяжусь с вами.

🙏 А если забрать не можете, пожалуйста, поделитесь этим постом или разместите его у себя в сторис.

Возможно, именно среди ваших друзей найдётся человек, который подарит малышке дом.

Ведь иногда, чтобы изменить чью-то жизнь, достаточно просто не пройти мимо.

Буду очень благодарен за помощь! ❤️

Эмоция как призма
-
Недавно на тренинге по коммуникациям услышал мысль, которая мне очень понравилась.

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

Представьте переговоры.

Вы заходите на встречу с целью найти решение, которое устроит обе стороны.

В какой-то момент собеседник говорит что-то, что вас задевает. Появляется злость.

И постепенно цель меняется.

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

Причём в моменте можно даже не заметить, что цель уже другая.

Я представил это как луч света, который проходит через призму.

Изначально луч направлен в точку А, но эмоция становится призмой, которая его преломляет. Чем сильнее эмоция, тем дальше конечная точка может оказаться от той, куда мы собирались прийти.

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

Что с этим делать?
-
1. Знать, что такое может с вами случиться. Это уже 50% успеха.

2. Научиться с этим работать - оставшиеся 50% успеха.

Первый инструмент - подготовиться заранее по принципу if-then: «если произойдёт Х, то я сделаю Y».

Например:
«Если собеседник начнёт жёстко критиковать моё решение, я сначала задам два уточняющих вопроса и только потом отвечу».

Вы заранее программируете реакцию до того, как эмоция успела перехватить управление.

Второй инструмент - метапозиция (такое мне ближе).

Попытаться мысленно выйти из ситуации и посмотреть на неё со стороны, как будто смотрите кино:

«Что сейчас происходит?»
«Какова была моя исходная цель?»
«То, что я сейчас делаю, действительно ведёт меня к ней?»

Но самое сложное здесь - вовремя вспомнить про метапозицию.

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

Поэтому перед сложными переговорами я бы добавил себе ещё один вопрос:

«С какой целью я туда иду и как пойму во время разговора, что перестал к ней двигаться?»

#руководитель
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем"

Три уровня применения ИИ в процессах
-
В прошлом посте я писал про квадраты и стрелки в процессах.
Квадраты - этапы работы.
Стрелки - передача результата между ними.

И статья McKinsey натолкнула меня на такую модель из трёх уровней применения ИИ в процессах:

1. Ускорить квадрат
Самый распространённый вариант.
Сотрудник раньше готовил документ два часа, с ИИ делает за двадцать минут. Процесс при этом остаётся прежним. Просто один из его этапов стал быстрее.
Полезно. Но если потом документ два дня ждёт согласования, общий эффект будет небольшим. Так как мы ускорили лишь 5% от всей работы.

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

McKinsey выделяет здесь три функции: проверка, разрешение конфликтов и маршрутизация.
Так сокращается тот самый «налог на координацию». Отлично, тут мы ускорили 95% от процесса. Но и это ещё не всё!

3. Перепроектировать весь процесс под ИИ
Самый интересный уровень.
Берём конечный результат процесса и заново задаём вопрос:
Какие действия вообще нужны, если часть работы способны выполнять ИИ-агенты?
Тогда какие-то квадраты можно объединить.
Какие-то убрать.
Часть стрелок исчезнет.

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

McKinsey приводит именно такой пример: компания сначала несколько месяцев разбирала процесс, классифицировала решения и определяла границы автономности ИИ. После этого 80% планирования стало проходить без ручного вмешательства, а цикл сократился с 30 до 3 дней.

Разница между автоматизацией и трансформацией.
-
Уровень 1: ИИ делает квадрат быстрее.
Уровень 2: ИИ ускоряет движение по стрелкам.
Уровень 3: мы заново рисуем всю схему с учётом того, что теперь умеет ИИ.
Именно третий уровень может дать кратный эффект, потому что меняется уже сам процесс - та самая трансформация.

Статья McKinsey:
https://www.mckinsey.com/industries/industrials/our-insights/cutting-the-coordination-tax-how-agentic-ai-can-reshape-workflows
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем".

Картографический портал Транспортного комплекса, разработанный НИИ «МосТрансПроект», стал победителем премии «Интеллектуальные транспортные системы России»

Сегодня в сервисе больше 200 информационных слоёв — от остановок и светофоров до существующих и перспективных объектов транспортной инфраструктуры.

Собрать всё это в одном месте — отдельная задача. В транспортном комплексе участвует много организаций, данные постоянно меняются, поэтому для планирования важно видеть актуальную информацию по каждому объекту.

КИП ТК помогает специалистам оценивать влияние градостроительных решений, рассчитывать пешеходные потоки и потребность в парковках, анализировать территории.

По сути, это рабочий инструмент для принятия решений: ещё до реализации проекта можно оценить, как изменения повлияют на транспортную систему.

Для меня эта премия — прежде всего признание работы команды МосТрансПроекта, которая создала и продолжает развивать этот инструмент.

Посмотрите на стрелки между квадратами
-
В прошлом посте я писал про процессное управление: у процесса должен быть владелец, понятный стандарт, метрики и регулярное улучшение.

Недавно прочитал статью McKinsey про «налог на координацию», и там хорошо сформулирована одна из причин почему даже хорошо описанный процесс может работать медленно.

Когда мы описываем процесс, обычно рисуем квадраты:
[Подготовить данные] → [Проверить] → [Согласовать] → [Передать в работу].

А когда начинаем улучшать процесс, смотрим прежде всего внутрь этих квадратов: как быстрее подготовить данные, автоматизировать проверку, ускорить согласование.

Но большая часть времени может теряться вообще не внутри квадратов. Она теряется на стрелках между ними.

В одном из примеров McKinsey непосредственная работа занимала 12-24 часа, а весь процесс проходил за 9-18 дней. То есть непосредственно работа составляет около 5% от всего времени.

Остальные 95% времени съедала координация: ожидание, уточнения, проверки, согласования, передача информации и возвраты на доработку.

За каждый квадрат обычно кто-то отвечает.
Один сотрудник говорит: «Я свою часть сделал и отправил».
Второй: «А мне ещё ничего нормально не передали».
Оба формально правы. Процесс при этом стоит.

Поэтому при разборе процесса я бы отдельно смотрел на каждую стрелку и задавал вопросы:
- что именно здесь передаётся;
- кто должен принять результат;
- как он узнаёт, что можно начинать работу;
- сколько результат ждёт;
- какие проверки и согласования возникают;
- почему работа возвращается назад.

И ещё один вопрос ко всему процессу:
Кто отвечает за то, чтобы результат прошёл весь путь от начала до конца?

Потому что процесс заканчивается тогда, когда получен конечный результат, а не когда каждый участник качественно выполнил свой кусочек.

Поэтому, если процесс тормозит, попробуйте посмотреть не только на квадраты. Посмотрите на стрелки между ними.
Возможно, именно там вы платите свой «налог на координацию».

Статья McKinsey:
https://www.mckinsey.com/industries/industrials/our-insights/cutting-the-coordination-tax-how-agentic-ai-can-reshape-workflows
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем".

Про управление процессами
-
Продолжаю серию про разные режимы управленческого цикла:
1. Проект создаёт новое, например продукт.
2. Продукт даёт ценность для пользователей
3. Вокруг продукта возникают повторяющиеся процессы

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

Для меня оно держится на трёх вещах:
-
1. Владелец и стандарт процесса
Это, пожалуй, самое важное. В процессе может участвовать много людей, но кто-то должен отвечать за него целиком - владелец процесса.

Дальше фиксируем стандарт:
- какие этапы включает процесс;
- кто за что отвечает;
- что и кому передаёт;
- какие сроки;
- какие правила и исключения.

Это может быть карта процесса в BPMN, регламент, чек-лист или настройка в информационной системе.

Важно, чтобы все одинаково понимали, как должен работать процесс и свою роль в нём.

2. Результат процесса
Надо чётко понимать, что именно должно стабильно получаться на выходе, иными словами, какую ценность мы создаём на выходе?

Не просто «обработать обращение», а, например:
дать корректный ответ пользователю не позднее 4 часов.

То есть результат должен быть понятен и измерим.
- Что даем на выходе ?
- Для кого?
- За какое время?
- С каким качеством?

3. Метрики и улучшение
Мы не управляем тем, что не можем измерить.

Как правило, есть 3 базовых показателя выполнения процесса:
- время;
- затраты;
- качество.

Дальше запускается цикл:
- плановый показатель
- фактический показатель
- отклонение и причина отклонения
- улучшение

Ключевая мысль такая:
задача процессного управления - сделать результат предсказуемым и постепенно уменьшать отклонения.

Основа остаётся простой:
владелец и стандарт → результат → измерение → улучшение.

Хороший процесс для меня - тот, который стабильно даёт нужный результат без постоянного ручного вмешательства руководителя.

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

Среднее время выполнения заявки сократилось с 24 до 8 часов.

#управленческий_цикл
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем"

Проектное управление с продуктовым взглядом
-
У Сергея Королёва есть фраза:

«Можно сделать быстро, но плохо, а можно - медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот».

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

Но в большинстве наших проектов выбор шире, чем сделать плохо вовремя или хорошо, но позже.

Есть ещё один рычаг - объём.

Если срок фиксирован, можно сократить то, что мы собираемся сделать к этой дате.

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

Так в проекте появляется продуктовый взгляд.

В проекте мы заранее определяем результат и управляем движением к нему: что сделать, кто отвечает, когда закончить.

После появления продукта главный вопрос меняется: какую ценность получил пользователь и что нужно сделать дальше, чтобы её увеличить?

Поэтому иногда лучше выпустить меньший объём хорошего продукта вовремя, чем месяцами доводить до совершенства весь первоначальный замысел.

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

Для руководителя простой принцип:
Если дедлайн двигать нельзя - сначала пересмотрите объём. Качеством ключевого результата лучше не торговаться.

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

А идеально, конечно, как завещал Королёв: быстро и хорошо :)
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем"

Продуктовое управление
-
Проект закончился. Мы создали результат.
Если этим результатом начинают пользоваться - у нас продукт.
И здесь управленческий цикл меняется.
- В проекте главный вопрос: как прийти к заранее определённому результату?
- В продукте: что нужно сделать, чтобы продукт создавал больше ценности для пользователя?

Поэтому продуктовое управление для меня начинается с пользователя.

Кто наш пользователь?
Нужно понимать, для кого мы создаём продукт и зачем он ему.
Иногда выясняется, что продуктом пользуются совсем не те, кого мы представляли изначально. У меня такое бывало. Поэтому гипотезу о пользователе важно проверять на практике.

Какую ценность мы даём пользователю?
Какую "работу" пользователь выполняет с помощью продукта? Что для него становится быстрее, проще, удобнее или вообще возможным?

Как он пользуется продуктом?
Обратная связь, обращения, наблюдения и данные об использовании должны постоянно собираться и анализироваться.

Тут появляется роль продакт-менеджера или владельца продукта.
Для меня продакт - это человек, который понимает пользователя, представляет его интересы внутри команды и переводит его потребности на язык разработчиков продукта. В одном канале прочитал, что продакт - это айтишник с эмпатией :)

Куда развиваем продукт?
Из этого появляется продуктовая дорожная карта.
Какие проблемы решаем сначала? Какие гипотезы проверяем? Какие изменения дадут наибольший эффект?
Важно не превращать дорожную карту в план-график проекта. Это гипотеза развития продукта, которая меняется вместе с обратной связью и контекстом.

Для себя я собираю продуктовое управление в такую цепочку:
пользователь → его работа и боли → ценность → гипотезы → дорожная карта → обратная связь → новый цикл гипотез и планирования.

P.S.
Когда-то я хотел стать продакт-менеджером, когда вырасту :) Больше года учился этой профессии, учился у Аркадия Морейниса и Вани Замесина, читал литературу и телеграм-каналы, многое применял на практике. Накопилось много интересного из мира продуктового управления, поэтому теперь у меня есть моральное право этим тут делиться.

Сейчас моя роль стала шире: я больше помогаю растить продактов и руководителей продуктовых команд. А ещё развиваю собственный продукт - этот канал.

#управленческий_цикл
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем".

Как я смотрю на проектное управление
-
В прошлом посте я писал, что проект, продукт и процесс это разные режимы управленческого цикла.

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

В классическом проектном управлении есть знаменитый треугольник: результат, сроки и ресурсы.
А для себя я со временем сформулировал другой треугольник - три условия управляемости проекта:

1. Единый контекст
Все участники должны одинаково понимать, что сейчас происходит с проектом:
-где мы находимся относительно плана;
-что уже сделано;
-над чем работаем сейчас;
-какие есть проблемы;
-что планируем сделать дальше.
Когда у участников появляются разные версии происходящего, проект перестаёт быть управляемым.

2. Единый управленческий ритм
У проектной команды должен быть пульс.
У меня это обычно штаб раз в неделю. На нём сверяемся по результатам, синхронизируем план на следующую неделю, обсуждаем проблемы и принимаем решения.
Неделя → результат → синхронизация → следующий цикл.
Для некоторых проектов ритм может быть другим. Важно, чтобы он был регулярным и понятным всей команде.

3. Работа с отклонениями
В проекте почти всегда что-то идёт не по плану.
Увидел отклонение - попробуй исправить. Не получается - бей в колокол или поднимай флажок.
Срок начал ехать, не получается получить результат, появилась новая зависимость или проблема - об этом должны узнать тогда, когда ещё можно повлиять на ситуацию.
Проектное управление для меня во многом и есть управление отклонениями.

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

Из книг по теме мне особенно запомнились Том Демарко «Deadline» - про человеческую сторону проектов и Джефф Сазерленд «Scrum» - про работу короткими циклами, прозрачность и регулярную сверку результата.

Мой главный критерий управляемости проекта простой:
в любой момент участники должны одинаково понимать, где находится проект, куда он движется, какие вехи и что мешает ему двигаться дальше.

#управленческий_цикл
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем"

Проект, продукт или процесс?
-
Не все различают эти понятия. Поэтому не всегда понимают, чем именно управляют, и выбирают неподходящий подход.
Хотя проект, продукт и процесс - это разные режимы управления, которые постоянно переходят друг в друга.

Представим: мы хотим создать новую ценность для пользователя, которой пока не существует.

Запускаем проект.

Например, разрабатываем приложение. У проекта есть цель и конечное состояние: приложение создано, запущено и доступно пользователям.

Цель достигнута - проект закончился.

Его результат становится продуктом.

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

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

Продукт живёт и развивается. Пользователи дают обратную связь, появляются новые потребности и проблемы.
Хотим добавить новую ценность - запускаем следующий проект:
идея → планирование → реализация → запуск.

Проект заканчивается. Продукт меняется. Вместе с ним появляются новые или меняются существующие процессы.

Получается круговорот:
Проект → создаёт продукт → продукт порождает процессы → развитие продукта требует новых проектов → проекты меняют продукт и процессы → и всё начинается снова.

Заканчиваются они тоже по-разному.
Проект - когда достигнута его цель или принято решение отказаться от неё.

Продукт - когда организация прекращает его развивать и поддерживать.

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

Зачем руководителю это различать?
Потому что проектом, продуктом и процессом управляют по-разному.

Управленческий цикл остаётся тем же:
планирование → делегирование → контроль.

Но что именно планировать, делегировать и контролировать, зависит от того, чем вы управляете.

Об этом - дальше в серии постов про #управленческий_цикл
-
Если нравится то, о чём я тут пишу, приглашайте своих коллег и знакомых руководителей в канал "Быть руководителем"