Седой директор
2.89K subscribers
50 photos
2 videos
217 links
Меня зовут Илья Прахт.
Я опытный менеджер в IT, CTO, тренер и консультант.
Пишу про менеджмент, системно и со смыслом. Разбираю ваши кейсы.
Для получения бесплатной консультации заполни форму https://forms.gle/8GJ3bgeMNjeTMpMV8
Личный аккаунт @ilya_prakht
Download Telegram
ПРО МЕТРИКИ ПРОЕКТА

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

H → Happiness — польза для клиента: метрики лояльности
E → Engagement — вовлеченность ЦА: метрики взаимодействия
A → Adoption — принятие: показатели роста новой аудитории
R → Retention — удержание клиентов: показатели удержания и оттока
T → Task Success — успех внедрения и продвижения продукта: финансовые показатели

Задумался, а есть ли что-то подобное для проектов? Иными словами, как понять, является ли ваш набор проектных метрик полным и достаточным, чтобы ничего не упустить из виду? Гуглил и искал – ничего (может плохо гуглил, конечно).

Но грустить я не стал, и решил состряпать такой инструмент сам 🙂 Не ну а чего.

Итак, представляю вашему вниманию инструмент PROJECT. Также как и HEART, он раскрывает основные фокусы внимания и наблюдения за проектом, чтобы ничего-ничего не прошло мимо вас.

P → People – команда проекта и ее состояние: метрики тимморали, текучка, eNPS и т п
R → Reliability – надежность, качество: количество инцидентов, bug leakage rate и т п
O → Operations – операционные показатели: метрики, на основании которых можно сделать вывод, что команда работает нормально, например velocity или lead time
J → Job – состояние скоупа: сколько сделано, сколько осталось, прогноз
E → Economy – финансовые показатели: бюджет проекта, маржинальность, потерянные деньги и т п
C → Customer – удовлетворенность клиента: NPS, средний чек, LTV, лояльность
T → Timetable – расписание: состояние роадмапа и деливери

Не знаю, приживется эта классификация или нет. Но как по мне, выглядит неплохо. Можно пользоваться. Выделяешь по 1-2 метрики на каждую букву, и вуаля, проект, как на ладони. Полезно будет и тимлидам, и ПМам, и delivery manager-ам, и CTO.

Как по-вашему? Стоит развивать и продвигать?

Или может надо добавить сюда что-то? Поделитесь мыслями.
ПРО УВОЛЬНЕНИЯ #3

И снова тредик про увольнения. Не подумайте, что мне нравится увольнять людей и это моя любимая задача (хотя, кто знает…). Просто тема довольно востребованная, а материалов не так уж и много. Вот хочу этот пробел восполнить.

В прошлых сериях мы говорили о том, как относиться к увольнениям, и как принимать решение, увольнять или нет. Разобрали подход “ошибка/проступок”. Сегодня рассмотрим еще один.

В свое время комбат Батырев ввел в повседневный обиход менеджеров термин, ставший уже нарицательным – “учить/лечить/мочить”. И вроде бы понятно, сначала учить, потом лечить. Но вот абстрактно как-то все равно, конкретики бы сюда.

Начнем с того, что выделяют 4 основные причины, отчего человек что-то не делает (или делает плохо):
1. Не понимает – не осознает важности задачи
2. Не умеет – просто не научил никто
3. Не может – нет ресурсов
4. Не хочет – вот тут уже без оправданий, чисто не хочет и все

Так вот, начинать свой анализ следует именно с выяснения причин. Сотрудник плохо делает свою работу – почему?

Если выясняется, что дело в пунктах 1-3 – нужно “учить”. Либо разжевать, почему задача важна и как она влияет на команду или целую компанию. Либо научить эту задачу делать, если вопрос в компетенциях. Либо выдать ресурсы (а в идеале научить ими правильно распоряжаться, сделать экскурс в мир приоритетов).

А вот если вы убедились в том, что причина 4, и сотрудник просто не хочет делать работу хорошо – сам себе буратино, надо “лечить”.

Как “лечить”? Я предлагаю 2-х шаговый алгоритм. Мы использовали его в компании и обкатали на практике. Могу сказать, что работает неплохо.

Шаг 1 – Предупреждение:
1. Донести обратную связь
2. Объяснить, что взаимоотношения под угрозой, и дальше так работать нельзя
3. Обозначить цели и сроки по исправлению – чем конкретнее здесь, тем лучше, прям все по SMART-у
4. Определить свое участие и помощь – на этом этапе не отключаемся, а помогаем сотруднику справиться с проблемой

Если сроки наступили, а цели выполнены, и работой сотрудника на этом этапе вы довольны, то вуаля! Все получилось! Если нет – переходим к шагу 2.

Шаг 2 – Последний шанс:
1. Донести обратную связь
2. Объяснить, что следующий шаг – уже увольнение
3. Обозначить цели и сроки по исправлению – здесь надо еще конкретнее, все максимально по SMART-у

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

Ну и здесь, конечно, 50/50. Кто-то проникается и исправляется. Кто-то дотапливает себя до конца. Но для случая 2 у вас есть целая куча аргументов к разговору об увольнении. Аргументов и фактов, спорить с которыми будет сложно.

Если сотрудник не сдюжил, то остается только “мочить” – увольняем. А про это будет в следующей серии.
👍6
Друзья!

В понедельник, 5 июня, в 19.00 мск приглашаю вас на вебинар "Как руководителю повысить прозрачность работы проектных команд?" от OTUS.

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

Зарегистрироваться можно тут https://meetup.otus.ru/project-optimisation
🤝2
ПРОБЛЕМА РОСТА МЕНЕДЖЕРОВ

Часто говоря про проблемы роста менеджеров. Оно наблюдается при каждом переходе на новый уровень. Сначала управлял только самим собой, стал управлять командой – проблема роста. Управлял командой, стал управлять несколькими командами – проблема роста. Управлял командами, стал управлять целой функцией – проблема роста. И т д. До самых самых высот.

Для наглядности, возьмем модель Адизеса. Ну помните, да? Там 4 роли руководителя: производитель, администратор, стратег (предприниматель) и интегратор. И для каждого уровня менеджмента (хотя сказать по чести, для каждой отдельной компании тоже) есть своя комбинация, которая необходима здесь и сейчас.

В среднем по больнице получается так:
- Инженер → Paei
- Тимлид → PaeI (иногда указывают pAeI, что встречается, но как по мне, не совсем верно)
- Delivery Manager → pAEi
- CTO → paEi

Повторюсь, комбинации могут отличаться от компании к компании. Так что, если у вас иначе – это ок, все нормально. Я усредняю.

Обратите внимание на переход тимлид → delivery manager. Он здесь самый наглядный. Чтобы совершить такой рывок, нужно значительно прокачать свои A и E. Но это полбеды. Присказка, так сказать. Все это решается обучением, практикой новых задач, наблюдением за другими руководителями.

А вот сказка начинается дальше. Чтобы рывок получился, нужно еще и “приглушить” в себе P и I. Перестать делать руками, перестать тесно работать и взаимодействовать с сотрудниками. А это уже куда сложнее. Тут и обучение не сильно помогает. И практика слабовато развивает. Потому что это уже история про изменение mind-set-а, а не про наработку новых знаний и навыков.

Что делать? Заставлять себя. Осознать четко свою роль, ее новые границы и зоны ответственности. И осознанно делегировать все, что выходит за рамки. Иногда это особенно сложно, потому что вашими руками задача будет сделана за 5 минут, а сотруднику ее только объяснять 15. А потом еще проверять, да и не знай сделает, не знай нет. Но таков путь, как говорится.

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

Учитесь делегировать смолоду! Эти инвестиции окупаются, хоть и не сразу.
👍7👎1
Друзья!

Напоминаю, в среду, 7 июня, в 20.00 мск проведу открытый урок "Как управлять тимлидами" в предверии старта нового курса Delivery Manager в OTUS.

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

Зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-2938
👍3
ПРО ПЕРЕГОВОРЫ #5

Продолжаем переговорный тред. В предыдущих сериях:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
ПРО ПЕРЕГОВОРЫ #4

Мы подробно обсудили этап подготовки к переговорам. Точнее сказать, этап стратегической подготовки. Это основа. Дальше на стратегию накладывается тактика. И это последний шаг в подготовке. Но не по значению.

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

Шаг 2 – Подача аргументов. Да-да, мало что-то говорить, важно говорить это правильно! Вот здесь как раз на сцену выходит все разнообразие переговорных техник, которыми можно усиливать ваши аргументы:
- Удержание сильных аргументов
- Заезженная пластинка
- Паузы
- Открытые/закрытые вопросы
- Внимание на общую картину
- Тайм-аут
- Эскалация
- …

Шаг 3 – Оппонент. Теперь нужно прикинуть, исходя из портрета, целей и интересов, а также переговорной позиции оппонента, какими аргументами и приемами он может воспользоваться. Фантазируем, какие у него могут быть аргументы, как он может пытаться их обосновать, как будет их вам подавать (какие переговорные техники станет использовать).

Шаг 4 – Ответы оппоненту. Разворачиваем все возможные действия оппонента обратно на него. Готовим контраргументы к его аргументам. Чем больше, тем лучше. Готовим контрприемы на его переговорные приемы. И важный момент – готовим возможные уступки. При каких “если” мы можем соглашаться на его предложения и аргументы. Обязательно готовьте этот блок заранее, чтобы во время разговора не растеряться и сохранять твердость своей позиции.

Шаг 5 – План переговоров. Теперь берем все результаты шагов 1-4 и оформляем в единый план. Что будем говорить, как будет говорить. Как будем парировать аргументы и переговорные приемы оппонента. На какие уступки можем пойти с выгодой для себя, на какие – ни в коем случае.

Вот теперь точно все. Вы готовы к переговорам. И у вас есть план. Не скрипт, а именно план. Там возможны ветвления и креатив “на местности”. Но с планом гораздо спокойнее. Даже если вы им и не воспользуетесь в итоге. План – ничто, планирование – все!

А дальше уже поговорим про сами переговоры, что делать внутри, когда вы в них попали.
👍2
ПРО СТЕК

Недавно проводил занятие с романтическим названием “Обзор стека” для тимлидов. В целом все стандартно: не разводите зоопарк, не хайпуйте, берите те технологии, что уже опробованы на аналогичных задачах. Ничего особенного.

Но там подсмотрел одну метафору, которая мне показалась элегантной. Вот делюсь.

Ваш стек – это ящик с инструментами. Чем больше там всего внутри, тем тяжелее его нести. Не всегда крутые дорогие профессиональные инструменты нужны для простых бытовых задач (перфоратор не нужен, чтобы собрать шкаф). А дешевые инструменты быстро ломаются, приходится все равно платить за нормальные.

Ну разве это не гениально? 🙂

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

Инженер – он что? Он решает задачу наиболее простым способом. Усложнениями всякие разные ученые обычно занимаются, чо-то вот там придумывают, совершенствуют. А инженер берет готовое и известное, и из этого складывает то, что ему нужно. В строительстве, в производстве, везде так!

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

И вот где тут, спрашивается, ошибка? Зря программистов инженерами назвали? Или классическое понимание инженера давно устарело и надо все пересматривать?

Я больше склоняюсь ко второму варианту. Это объясняет, почему в IT последние десятилетия движуха, а все остальные сферы жизни и производства развиваются заметно медленнее. Были бы везде такие “голодные” инженеры, глядишь совсем иначе выглядел бы мир. Но это не точно.

А вы как думаете? Кто же “не те” – программисты или инженеры? Или не надо их сравнивать, и инженер-программист – это как русский рок: рок, конечно, но очень особенный, “русский”?
👍42
Новая статья! На этот раз про метрики и управление сразу несколькими проектами.

https://habr.com/ru/companies/otus/articles/740834/

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

Приятного чтения!
👍4🔥4
ПРО НАЙМ

В минувшую субботу провел своей день в Школе CTO Стратоплана. Говорили про найм, развитие сотрудников, увольнение. Весь ЖЦ охватили, так сказать 🙂

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

Концепция унаследована из маркетинга, где принято описывать подробно портрет ЦА. Хотя, там есть мнение, что портреты уже не работают, и нужно отталкиваться от JTBD клиента. Но в найме пока не так, здесь все работает.

В портрете кандидата описываются основные стандартные блоки:
- Компетенции
- Опыт
- Личные качества
- Возможные позиции
- Специальные требования
Может быть что-то еще, но эти – основные.

Есть 3 основных способа формирования портрета кандидата:
1. Фотография – одна из крайностей, описать детально все требования, вплоть до пола и возраста, чем сильно заузить воронку для рекрутинга
2. “Ежик в тумане” – другая крайность, не описывать вообще почти ничего, потом фильтровать всех на этапах интервью
3. Конструктор – баланс, выделить главное и второстепенное, из кубиков собрать несколько потенциальных портретов

Так вот, что интересно. Обратите внимание на картинку 1 – так выглядит обычный стандартный процесс найма в IT. В среднем по больнице.

А теперь посмотрите на картинку 2 – это процесс найма тимлидов. Интервью с HR и интервью с руководителем занимают гораздо больше места, чем этап технического интервью. Логично, техника начинает уходить на второй план.

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

Почему так происходит? Потому что чем выше позиция, тем важнее проверять личностные качества, те самые Soft Skills. Важно, чтобы они матчились с корпоративной культурой. Ошибиться в этом с инженером – не страшно. Иногда даже поправимо. Если же нанять руководителя, с которым не наблюдается culture fit – это “бомба замедленного действия”, когда и как она стрельнет – никто не знает. Риски, при том неоправданные.

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

А как у вас с наймом менеджеров? Похожая история?
👍6
Картинки к посту
ПРО УВОЛЬНЕНИЯ #4

Продолжение треда про увольнения. Предыдущие посты:
ПРО УВОЛЬНЕНИЕ #1
ПРО УВОЛЬНЕНИЕ #2
ПРО УВОЛЬНЕНИЕ #3

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

Начинается все, традиционно, с подготовки. 3 шага подготовки к разговору:

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

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

3. Проработка рисков – рисков полно, и нужно учесть большую их часть. Юридические риски – законодательство специфично, и во многих странах (в том числе в РФ) оно вообще не на стороне работодателя. Репутационные – уволенные часто токсичат, как внутри коллектива, так и за пределами компании, нужно это проработать и заранее подстраховаться. Безопасность – банальные доступы, контакты с заказчиком и т п, нужно заранее подумать, как это быстро ограничить, если вдруг чего

4. Работа с командой – команда точно отреагирует. Может начаться бурление, шторминг, революция. Может все пройти спокойно, если коллеги сами устали от этого сотрудника. Как бы то ни было, нужно все это грамотно обработать, донести информацию до команды, а с кем-то, возможно, поговорить заранее (например с тимлидом, если вы решили уволить человека из его команды, ему точно стоит знать об этом чуть раньше остальных)

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

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

Думал, умещу все в этот пост, но не получилось) Сделаю еще один по теме “А если не получилось договориться?”. Покидайте в комменты, какие еще вопросы по увольнениям стоит рассмотреть и подробнее раскрыть?
👍3
ПРО ПЕРЕГОВОРЫ #6

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

Все предыдущие посты вот:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
ПРО ПЕРЕГОВОРЫ #4
ПРО ПЕРЕГОВОРЫ #5

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

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

1. “Переговорное джиу-джитсу” – уворачиваться от атак оппонента, переносить фокус на проблему, не критиковать позицию оппонента и не защищать свои идеи, а быть гибким, искать точки пересечения

2. Соблюдение “правил игры” – установить их в самом начале, и возвращайтесь к правилам, если оппонент начинает вести себя некорректно

3. Противодействие уловкам – есть уловки, чтобы бороться с уловками. Наиболее частые из них:
- Преднамеренный обман
- Психологическая война
- Позиционное давление

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

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

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

Вот и все. Так выглядит алгоритм подготовки и проведения переговоров, которым пользуюсь сам, и рекомендую пользоваться остальным. А основную мысль можно сформулировать очень просто: “к любым переговорам нужно готовиться, от этого зависит их эффективность”.

Удачи в переговорах, коллеги!
👍2🔥2👎1
Коллеги!

В следующий понедельник, 19 июня, в 20.00 мск проведу открытый урок курса TeamLead в OTUS по теме "Тимлидское искусство пофигизма".

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

Мероприятие бесплатное, зарегистрироваться можно здесь https://otus.ru/lessons/teamlead2-0/#event-2927
👍3
ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 3 НЕДЕЛИ

Ответ на вопрос про тулы для трекинга тимморали

Анонс статьи про управление тимлидами

Пост про метрики проекта - пара полезных фреймворков

Видео окрытого урока про риски для тимлидов

Пост про увольнения #3 - разбор подхода Учить/Лечить/Мочить

Пост про проблемы роста менеджеров

Пост про переговоры #5 - про тактический уровень подготовки

Видео вебинара "Как руководителю повысить прозрачность работы проектных команд?"

Пост про стек

Видео открытого урока "Как управлять тимлидами"

Анонс статьи про метрики и управление портфелем проектов

Пост про найм и портрет кандидата

Пост про увольнения #4 - подготовка и проведение разговора

Анонс статьи "Я тимлид. Что дальше?"

Пост про переговоры #6 - завершающий весь тред, про непосредственно проведение переговоров

Еще хочу напомнить про форму - напишите туда свой вопрос или кейс, а я сделаю подробный ответ. Можно анонимно, можно - нет.
👍5
Коллеги, еще хочу напомнить!

29 июня буду выступать с МК на Skolkovo Tech Week с темой “Тимлид – ключевое звено в изменении корпоративной культуры”. Ищите меня в потоке MANAGEMENT.

У меня есть несколько промиков с бесплатными билетами! Напишите в личку @ilya_prakht, кому надо. Срок у них до 23 июня.

Про мероприятие:
Что важно для современного предпринимателя?
Быть в курсе последних трендов на рынке, а также уметь собрать сильную команду.
Об этом и многом другом вы можете узнать на крупнейшей технологической конференции России - TECH WEEK 2023 @russiantechweek
Что там интересного:
• Тематические выступления по 12 потокам, выступления экспертов на актуальные темы и мастер классы;
• Нетворкинг - соберёте самые ценные контакты, найдёте партнеров и близких людей по духу, а еще можно тусануть на AfterParty;
• Практика - разберёте кейсы, сделаете задания, изучите предметно рабочие инструменты;
• Выставка актуальных решений для бизнеса в сфере технологий, инноваций и технологического сервиса.