УПРАВЛЕНИЕ РИСКАМИ В КОМПАНИИ

Недавно делали для одного из курсов Eduson модуль по управлению рисками. И там было 2 интересные темы, которыми хочу поделиться. Про риски.

Как управлять рисками на проектах, в целом, понятно. PMBOK нам все про это рассказал: идентифицируем, оцениваем, приоритезируем, митигируем. Дальше контролируем. А как работать с рисками на уровне всей компании?

Во-первых, есть специальные стандарты. Их очень много. Есть общие и универсальные. Есть локальные. Есть специфические для отрасли, например, целая куча стандартов есть в банкинге. Наиболее интересные и популярные:

- ISO 31000
- FERMA
- COSO
- …

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

Во-вторых, есть совершенно классная модель “3 линий защиты”. Как понятно из названия, мы делаем 3 уровня работы с рисками:

1. Уровень функций – реализуется в каждом подразделении, выполняется мониторинг, контроль и реагирование на риски. Например, тимлид следит за исполнением требований ИБ своими сотрудниками.

2. Уровень мониторинга – специальные подразделения, которые определяют базовый набор рисков, формируют инструкции и регламенты по работе с ними, разбираются в каких-то нестандартных ситуациях и следят, чтобы процессы риск-менеджмента работали правильно во всех отделах. Например, все то же подразделение ИБ, комплаенс, юристы и т д.

3. Уровень внутреннего аудита – какой-то орган, чаще всего комитет, реже – прям выделенное подразделение, которое оценивает общее качество риск-менеджмента в компании, постоянно адаптирует процессы под стратегию компании. Например, изменение политик ИБ, если появились изменения ФСТЭК.

Чем интересен подход? Как по мне, он хорошо определяет не только управление рисками, но и общую методологию построения процессов в любой компании и любом отделе. Чтобы все работало, нужно 3 вещи:

1. Люди или команды, которые выполняют работу согласно процессу

2. Специальные роли, определяющие, как именно работать в рамках процесса, и контролирующие это

3. Дополнительный механизм пересмотра работы процесса и его согласованности с текущей реальностью

Вспоминаю, как мы внедряли Scrum. Тимлиды на местах и команды реализовывали фреймворк. Delivery Manager-ы определяли, как адаптировать Scrum к проекту, как его внедрять и как мониторить потом. Ну а топ-менеджмент давал добро или недобро на всякие изменения, когда того требовали новые цели компании или конкретный проект не мог раскатать тот процесс, который был нужен нам. Эдакие “3 линии внедрения Scrum”. Интересно 🙂

Вот такие мысли. И такие инструменты. Надеюсь, будет полезно.

Видео вчерашнего Openday Стратоплана "Руководитель отдела: Смена декораций в управлении людьми"

https://youtu.be/aONzCVfgxGo

Я тут поучаствовал в одной коллаборации. Полезной, как по мне. Ребята собрали в общую папку ProБизнес несколько авторских каналов (именно авторских, это важно), где люди пишут про менеджмент (как я), про стратегию, про ведение бизнеса. Есть что почитать.

Посмотрите, вдруг и вам что-то будет полезно.

Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения

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

И еще один анонс!

Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".

Поговорим об инструментах управления тимлидами и роли DM во всем этом.

Присоединяйтесь

КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY

Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?

Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.

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

Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.

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

Как быть? Как по мне, нужно сделать 2 вещи:

1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься

2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI

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

Ну например, ссорятся все время Вася с Петей, когда Вася делает пулреквест, а Петя потом его на ревью заваливает некритичными замечаниями. Если отсыпать Пети мотивации на достижение хорошего Lead Time Васей, то он перестанет придираться по мелочам, а будет выделять только реальные и критичные проблемы. А если закрепить это все четкой инструкцией, то такая схема обречена на успех.

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

Что скажете? Согласны с такой идеей? Какие еще есть варианты?

JOB SECURITY

На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.

Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.

Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:

1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки

2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке

3. Соответствие вас, как профессионала, среднему портрету кандидата в вакансиях – и тут рынок все выравнивает, хоть и есть много уникальных позиций

Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.

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

1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п

2. Ходить на собеседования. Даже если не собираетесь увольняться. Даже если вы менеджер. Вот тут много холиваров на этот счет, но моя простреленная нога говорит мне, что ходить надо

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

4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить

5. Развивать себя. Не застревать в рамках той роли и той компании, где вы сейчас. Смотреть по сторонам и постоянно подтягивать то, что рынок просит

6. Иметь план Б. В любой момент “скрипач может оказаться не нужен”. И вы должны быть к такому готовы. И морально, и материально. Мой лучший рецепт здесь – диверсификация, всего и вся

7. Всегда помнить, что вы наемный сотрудник. В нашей культуре сильно развит патриотический тип мотивации. И занимая высокую позицию, порой, кажется, что вы “уже часть корабля”. Но это не так. Вы все также наемный сотрудник, которого взяли под конкретные задачи и конкретные условия. И это легко может поменяться, такова жизнь. Важно быть патриотом компании и проявлять лояльность к ней. Но не менее важно быть патриотом самого себя, и проявлять лояльность к самому себе. Вот мой факап был как раз тут

Это мой список. Субъективный, не всем подходящий. Но реально прожитый.

А вы пишите, что еще сюда можно добавить!

P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам 🙂 Но рекомендую!

“МОЛОТОК” В КОМАНДООБРАЗОВАНИИ

Часто провожу обучения и пишу посты по темам командообразования и аудита команд. Очень уж они мне нравятся. Потому что здесь, как нигде лучше, раскрывается многообразие всяких разных менеджерских инструментов. И можно действовать не по наитию или своему креативу, а, практически, “по методичке”. Да, инструменты в менеджменте вещь условная и абстрактная, нужно все это “приземлять”. Это бесспорно. Но в теме командообразования этих инструментов так много, что точно что-нибудь свое, да подберешь.

Буквально недавно мне попался инструмент, который по праву можно считать эдаким “молотком” в теме командообразования. Потому что он столь же прост, и столь же эффективен. И имя его – пирамида GRPI (картинку закину следом за постом).

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

1. Цели – какие цели у команды, насколько они хорошо сформулированы, насколько откликаются у всех участников

2. Роли – здесь и компетенции команды, и командные роли, чего где не хватает и каков баланс

3. Процессы – основные процессы и правила, необходимые для нормальной работы команды, все ли на месте и все ли оптимальны

4. Межличностные отношения – насколько команда “сыграна”, какие есть малые группы внутри, кто с кем конфликтует

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

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

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

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

И это классный фреймворк, который можно расширять другими инструментами:

1. Цели – от Мамонта до OKR-ов
2. Роли – от матрицы и карты компетенций до ролей Белбина или Бенна/Шитса
3. Процессы – от базовых 1/1 до сложных процессов Delivery с Аджайлами и Скрамами
4. Межличностные отношения – от теории малых групп до границ Берна

Расширяй - не хочу! Приземляй – не хочу! Ну просто сказка, а не инструмент!

Пользуйтесь!

А картинка следом, как и обещал.

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

На прошлой неделе заходил на Неформальный Стратоплан, пообсуждали проблемы руководителей отделов и СТО. Поотвечали на вопросы вместе с Сашей Орловым и Андреем Крыловым.

О чем успели поговорить:
- Как себя вести, если хочется карьерного роста, но никак не повышают
- Что делать, если у компании нет ресурсов, т е количество проектов увеличивается, а людей - нет
- Как получить от руководства реальные ожидания от своей позиции, если они их никак не сформируют
- Как решить проблему коммуникации со стейкхолдерами, когда излишне закрываешься на внутренних задача отдела
- Куда вкладывать ресурсы, чтобы расти, как СТО
- Как поступить, если на работе все хорошо, но категорически скучно
- Где брать базу/систему по менеджменту, когда учишься через свой опыт и шишки
- Что делать тимлиду, который раньше был инженером в команде, а теперь должен ей управлять и постоянно натыкается на дерзкого и токсичного сотрудника, не принимающего его начало

https://youtu.be/Jq_-HL0fFKc

А на этой неделе в предверии очередного запуска курса COO в OTUS провел открытый урок, где пообсуждали операционные стратегии и рассмотрели основные.

Были стратегии:
1. Снижение себестоимости
2. Повышение гибкости
3. Повышение качества
4. Сокращение времени

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

https://youtu.be/8z1ChLwXuBA

Друзья!

На следующей неделе, 26 июня, приму участие очередной раз в конфренции Skolkovo TechWeek. На этот раз, будет практический мастер-класс про проектные метрики.

Организаторы, как обычно, дарят несколько промокодов на бесплатные билеты. И я готов ими поделиться с вами!

Пишите в комментарии, кому нужны билеты, отдам первым троим 🙂

ИЗОБРЕТАЯ ВЕЛОСИПЕД

Юху! Наконец-то лонгрид!

Сегодня хочется затронуть матрицу компетенций. А конкретно – ее базу. Что должно быть основанием для определения уровня / грейда сотрудника?

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

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

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

А недавно наткнулся на интересную статью на Хабре и узнал про фреймворк SFIA. Да-да, такой вот я темный. Модели уже почти 50 лет, а я про нее даже не слышал. Но готов поспорить, большинство из вас тоже ничего о ней не знали. И это нормально. Не хватило как-то ей маркетинга, видимо.

Так вот, фреймворк предполагает 7 уровней, как раз таки, зрелости специалиста, которые подразумевают разные уровни ответственности:

1. Follow (следует) – следует инструкциям, делает простые задачи
2. Assist (помогает) – работает в команде, берет на себя ответственность за результат задачи
3. Apply (применяет) – работает в рамках установленных правил и системы, делает задачу от и до со всеми ограничениями
4. Enable (поддерживает) – делает работу сам и помогает другим, вносит существенный вклад в результаты команды
5. Ensure, advice (обеспечивает, консультирует) – обеспечивает управление и результаты всей команды, дает экспертные консультации
6. Initiate, influence (определяет политику, влияет) – принимает важные решения, формирует правила, руководит направлениями работ
7. Set strategy, inspire (определяет стратегию, вдохновляет) – все понятно из названия, отвечает за стратегию и будущее

И вот вся эта моделька как нельзя прекрасно ложится на мою идею про ответственность. Более того, много где в мире ее для этого и применяют 🙂

1. Follow (следует) – стажер или начинающий Junior
2. Assist (помогает) – хороший крепкий Junior
3. Apply (применяет) – настоящий Middle
4. Enable (поддерживает) – уже Senior
5. Ensure, advice (обеспечивает, консультирует) – TeamLead в чистом виде
6. Initiate, influence (определяет политику, влияет) – уровень тактического управления: HH, DM, TGM и много других названий этой позиции
7. Set strategy, inspire (определяет стратегию, вдохновляет) – это уже директор, стратег, CTO

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

P.S. Подробнее можно почитать на официальном сайте SFIA и в статье, на которую я ссылаюсь. Там про инфобез, но идея общая, универсальная.

РАНЬШЕ РАБОТАЛИ В ОДНОЙ КОМАНДЕ, А ТЕПЕРЬ Я НАЧАЛЬНИК, А ОН – ТОКСИЧНЫЙ БУНТАРЬ

Ситуация, с которой сталкивался каждый руководитель. Прямо боль любого менеджера. А причина проблемы, зачастую, вообще не в вас. Но вот решать ее, все равно, вам.

Именно такой ситуации хочу посвятить свой переговорный поединок в Университете Стратоплана. Приходите на мое занятие 16 июля в 11.00 мск. Обсудим природу такого поведения коллег, что нам под силу, чтобы исправить ситуацию. В формате кейса и групповых переговорных поединков.

Зарегистрироваться можно тут

В этот раз, Университет полностью посвящен теме “Конфликтология”. Потому что любая работа, на уровне инженера или СЕО, завязана на взаимодействиях с людьми. Уметь договариваться – необходимый навык, который влияет не только на уровень удовольствия от работы, но и на карьеру, бизнес, деньги.

Университет для вас, если:
— для вас переговоры — нервы и вырванное время
— ваше решение/мнение не принимают и всегда находят *но*
— вы часто недовольны итогами переговоров

Формат:
— живая 2-х недельная онлайн практика (+ немного теории, без воды и домашек)
— абсолютно бесплатное участие группами от 5 человек
— личный кабинет с пожизненным доступом к записям, если что-то упустили

Старт — 08 июля. Уже в следующий понедельник!

И СНОВА ПРО МЕТРИКИ

По мотивам мастер-класса на Skolkovo TechWeek. Сам мастер-класс выдался, мягко говоря, не очень удачным. Но материал полезный, как по мне. Так что делюсь.

Метрик много, метрики разные. Но за какими точно надо следить? Вопрос сложный, так как итоговый набор метрик очень сильно зависит от процессов и методологий управления. Что влияет на принятие управленческих решений, то и надо контролировать.

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

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

Давно уже всюду пропагандирую фреймворк PROJECT, который, как раз, решает эту проблему. Расшифруем акроним:

P → People — команда проекта и ее состояние
R → Reliability — надежность, качество
O → Operations — операционные показатели
J → Job — состояние скоупа
E → Economy — финансовые показатели
C → Customer — удовлетворенность клиента
T → Timetable — расписание проекта

Если в каждой из этих 7 областей будет хотя бы по 1 метрике – проект под контролем. Вот такая идея.

На картинках следом несколько слайдов с доклада: с примером метрик, которые мы использовали у себя (и это работало!), с вариантами других метрик под каждую область внимания PROJECT, и пример, как это все в итоге собирается в светофор проектного статуса (опять же из реальной жизни).

Надеюсь, пригодится. А вопросы пишите в комментариях!