Свеженькая статья про MVP: что такое, какие бывают, как правильно его создавать и какие инструменты помогают в этом. Приглашаю почитать!
https://habr.com/ru/companies/otus/articles/744776/

Друзья!

Хочу поделиться с вами своим новым проектом - серия воркшопов для тимлидов и руководителей "Инструменты начинающего руководителя" на площадке Инфостарт.

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

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

Посмотреть и зарегистрироваться можно здесь https://infostart.ru/edu/1889930/

Коллеги!

Я снова к вам с анонсом очередного крутого проекта 🙂

Запускаем на площадке OTUS новый курс "CTO / Технический директор". Старт планируем 29 августа. Посмотреть описание и программу можно тут https://otus.ru/lessons/cto/

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

Регистрируйтесь и приходите поучаствовать!

СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА

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

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

И в таком случае, это задача. Нельзя просто взять и прекратить наставничать, если, например, не получилось нормальные отношения выстроить. Терпишь и делаешь, как еще.

Знакомо? Бывало такое?

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

1. Личная неприязнь – никак не получается подружиться, иногда доходит даже до запросов на смену наставника

2. Плохие результаты – менти работает заметно хуже, чем от него ожидается

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

Что делать? Для каждой проблемы решение свое. Начнем с первого кейса – личная неприязнь.

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

Что делать? Совет простой: забить на эти самые отношения. Вам работать надо, а не дружить. Переводите все взаимодействие в конструктивное русло. Установите основные “правила игры” и работайте по ним, достигая общих результатов по задаче.

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

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

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

Много текста получилось. Остальные 2 проблемы разберу тогда в следующем посте.

Делитесь своими историями. Как решали? Насколько откликается?

ДОКУМЕНТАЦИЯ

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

Топ-5 проблем с документацией:
1. Документации нет. Вообще. Совсем
2. В документации свалка. Бардак, стало быть
3. Документация неактуальная. Когда то давно написали и больше не обновляли
4. Документация слишком сложная. И по структуре, и по содержанию. Пользоваться лишний раз не хочется
5. Документации ПОКА нет. Мое любимое) “Мы сейчас релиз сдадим, и потом спокойненько все напишем, как положено”. Только вот это ПОТОМ уже не наступает

Почему так? Ответ на поверхности.

Есть 4 причины, почему человек что-то не делает: не понимает, не может, не умеет и не хочет. Распространенная когнитивная ловушка думать, что всегда это пункт 4 – не хочет. Чаще всего, причина какая-то другая.

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

Что делать? Ответ также на поверхности. Варианта тут 2:
1. Добавить им мотивации (скорее всего, это будет морковка сзади, т е наказывать за плохую документацию)
2. Снижать дискомфорт до минимума (совсем убрать не выйдет, но хорошенько оптимизировать этот фронт работ можно)

Про первый вариант подробно писать не буду, итак все понятно. Давайте про второй.

Как снижать дискомфорт:

1. Показывать и доказывать пользу от документации. Через примеры. “Вот Петя заболел, без связи, а тебе надо поправить багу в его модуле. Ты документацию взял, все быстро понял и поправил. А без документации сидел бы неделю, расшифровывал эту Петину тайнопись”

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

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

4. Ввести правила и регламенты. А еще назначить ответственного, пусть следит за качеством документации. Попахивает вариантом про мотивацию, но сюда тоже подходит

5. Хороший удобный инструмент. Конечно же! Чтоб не бесил. Чтоб простой и понятный. Чтоб удобно было и созидать доки, и потом их находить и использовать

Вот такие рекомендации. Нам помогало. Попробуйте и вы!

СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА #2

Продолжение поста СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА

Разобрались с проблемой #1 – личная неприязнь. Теперь давайте поговорим про #2 – плохие результаты.

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

Здесь есть 2 момента, о которых следует подумать.

Первое – классические 4 причины. Почему сотрудник делает что-то не очень хорошо? Не понимает? Не умеет? Не может? Не хочет? Надо проверить первые 3, прежде чем вешать ярлык “лентяй” или “лоуперформер” на человека.

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

Таким образом, первое, что нужно сделать – “понять и простить”. Подтвердить или опровергнуть эти 2 гипотезы. Если что-то подтверждается – помочь человеку справиться с проблемой, оказать поддержку. Ну а если уж наблюдения показывают, что стресса нет и чувак просто “не хочет” работать нормально, то тут классические “учить/лечить/мочить”.

Бывает кейс другой. Подвид исходного. Когда сотрудник работает нормально, но времени при этом тратит на себя уйму. Вашего времени. Самого ценного ресурса руководителя и наставника. Это тоже отклонение от нормы, с этим тоже нужно работать.

Скорее всего, если такое происходит – это ваша заслуга. Сами позволяете так тратить ваше время. Помните мы говорили о “правилах игры”? Вот здесь снова они. Нужно их задать, договориться, и дальше соблюдать. А если сотрудник их нарушает – возвращать его к правилам.

Так вот. Если эти “правила игры” вы не зададите явно, то их придумает сотрудник. Просто определит свою зону комфорта и будет в ней работать. И в его картине мира будет все ок, он ж сам у себя в голове “договорился”. Поэтому правила и границы нужно проговаривать. Лучше сразу, изначально. Определить график и формат взаимодействия, круг вопросов, формы эскалации и т д.

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

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

Новая статья про выбор каналов привлечения для IT-продуктов. Про CJM и как им пользоваться в этом деле.
https://habr.com/ru/companies/otus/articles/747046/

Друзья!
13 июля в 19.00 мск проведу онлайн митап на тему "Гореть, но не сгорать. Топ-5 лайфхаков для руководителя в IT". Поговорим про правильную зону ответственности тимлида, про баланс, про ресурс.
Зарегистрироваться можно здесь https://meetup.otus.ru/corp-burnout

Видео вчерашнего эфира в OTUS https://youtu.be/ID00rQLV-hQ

Разговаривали о том, как руководителю сохранять трезвость ума, не перегорать и не афигивать от происходящего

Школа менеджмента «Стратоплан» проводит два бесплатных онлайн курса Teamlead:101 и СТО:101

Вам на Teamlead:101, если:

— хотели попробовать себя в роли тимлида в безопасной среде, в окружении тренеров и опытных коллег
— вы тимлид, но не хватает инструментов и точек опоры в управлении; люди саботируют, вы овертаймите
— не можете перейти из роли специалиста в “лида”

22-23 июля, с 9 — 12 Киев/Мск по этой ссылке: https://bit.ly/3Od8umL

А СТО:101 в случае:

— если хотите идти к позиции, но не знаете, в какую сторону двинуться; понять про вас ли это
— если «играете на всех дудках и барабанах сразу» и выгораете
— нет инструментов и метрик; решения принимаются на основе «я так чувствую», а не на основе фактов и цифр

22-23 июля, с 10 — 13 Киев/Мск по этой ссылке: https://bit.ly/3XUW0TZ

Что получите на выходе:

— протестируете себя, как руководителя, на реальной практике
— набор инструментов, решающих 90% проблем в работе с командой и проектами
— сертификат, за вашу работу в эти два дня

Регистрируйтесь!

Коллеги, к посту выше - буду оба дня на СТО101. Расскажу немного про типы СТО, что там у СТО про менеджмент, и про стратегические функции.
Бесплатное мероприятие с целой кучей полезного контента!

Написал подробную статью про жизненный цикл продукта (по мотивам одного из постов). Про саму концепцию, про особенности каждого этапа, про правильные фокусы продуктового менеджера.
https://habr.com/ru/companies/otus/articles/748178/

СИНДРОМ САМОЗВАНЦА

Откуда берется синдром самозванца? Сидишь такой, работаешь работу, и вдруг бац! “Я недостаточно хорош…”. “А правильно ли я понял задачу?”. И другие похожие вариации одного и того же вопроса.

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

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

Очень опасная штука для начинающих руководителей. Особенно тимлидов. Потому что делаешь свои новые тимлидские задачи, пытаешься как-то для себя “закрепиться” здесь. Ловишь самозванца. Хочешь работать лучше. И идешь делать то, в чем ты уже был хорош раньше, например, код писать. В итоге топишь себя еще больше в рабочих часах, не успеваешь делать нормально свою новую тимлидскую работу, еще больше сомневаешься в своих достижениях. Жуть, одним словом. Порочный круг.

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

Варианты:

1. Требовать ОС от своего руководителя. Может даже, какой-то процесс завести, аля 1/1 пару раз в месяц, чтобы быть в тонусе все время

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

3. Посмотреть на других людей вокруг и убедиться, что они тоже лажают. И разрешить себе лажать. Не хочется говорить банальностей, но не лажает тот, кто ничего не делает

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

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

СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА #3

Продолжение постов СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА и СЛОЖНЫЕ КЕЙСЫ НАСТАВНИЧЕСТВА #2

Разобрались с проблемами #1 – личная неприязнь и #2 – плохие результаты. Настало время проблемы #3 – подопечный больший эксперт, чем наставник.

Бывает нередко. Особенно в небольших командах. Наняли Java-архитектора, а в команде нет человека с Java выше мидла. Или наняли GO-программиста, а в команде вообще никто GO в глаза-то не видел. Или наняли директора по маркетингу, и только CEO чутка в зуб ногой за маркетинг, а остальные вообще ничего. Логично, для этого и нанимали, чтоб закрыл пробел.

И вот берут этого несчастного мидла по Java и говорят ему: “теперь ты наставник для архитектора”. И много вопросов сразу рождается в голове его. Что логично. Чему мидл может научить архитектора? Как мидл поймет, что архитектор хорош/не очень хорош? Как мидл сможет обоснованно донести обратную связь архитектору по его работе? Можно продолжать, список внушительный.

Но онбординг то делать надо. Кто-то же должен. Полноценно никто не может, а тут хотя бы есть общее слово – Java.

Бывало? Встречались?

И перед тем, как перейти к ответу, хочу задать вопрос. А должен ли ментор быть “круче” своего подопечного? Должен ли он быть бОльшим экспертом, чем его менти?

Ответ “да, должен”. Иначе зачем он нужен. А теперь вернемся к целям. Зачем нужен наставник? Если “прокачать” своего подопечного, приготовить его к повышению, то тут край, ничего не выйдет, смысла тратить время нет. А вот если цель “адаптировать” подопечного, помочь ему с онбордингом, с успешным прохождением испытательного срока – тогда все работает.

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

Итого, если вы оказались в такой ситуации, когда ваш подопечный значительно скилловее и опытнее, нужно делать следующее:

1. Выключить самозванца – вам есть что ему показать и рассказать, уж поверьте

2. Определить свою пользу – в каких вопросах вы эксперт, с чем можете быть полезным

3. Обсудить это с менти – прям вот так по-чесноку все и проговорить: “я, мол, не эксперт, Java тебя не научу, хато умею в компанию, расскажу что тут да как работает”

4. Работать и наносить пользу – в том объеме, в котором вы договорились

Вот и все. Все 3 проблемы разобрали. Делитесь, насколько помогло?

Новая статья про EJM (Employee Journey Map) - путь сотрудника в компании.

Отличный инструмент, основа для построения HR-системы. Немного поразмышлял о том, как правильно этот EJM строить, какую информацию можно из него узнать, как потом применять все это.

Приглашаю почитать!
https://habr.com/ru/companies/otus/articles/751492/

ВОПРОСНИК #15

Вопрос от @Merallisa про аудит команды разработки.

Вопрос:
Как провести аудит в командах разработки? На что смотреть? Что почитать по теме? Что должно быть в чек-листе?

Ответ:
Юлия, спасибо за ваш вопрос!

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

Если вкратце. Аудит предусматривает 2 основные плоскости анализа: каждого сотрудника в отдельности и команды в целом.

При анализе сотрудника следует обращать внимание на 3 вещи:
1. Компетенции
2. Психотип
3. Мотивация

При анализе команды нужно фокусироваться на 4 аспектах:
1. Общая цель
2. Командная динамика
3. Закрытость и сплоченность команды
4. Роли в команде

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

Для отправной точки аудита могу предложить модель “5 пороков команд Ленсиони”. Проанализировав 5 пороков и определив, какие присущи вашей команде, можно дальше углубляться в каждый порок и использовать уже более узкие инструменты.

Я как раз по этой теме готовлю доклад на CrossConf 15 сентября. После обязательно сделаю follow-up, либо выложу видео доклада, либо напишу статью про это.

Если абстрактно и в общем, то вот так. Если нужно больше конкретики, напишите в комментарии, разберем более узкие вопросы.

P.S. Форма для ваших вопросов и кейсов тут https://forms.gle/aBX5PgU1CLU4FDPP8

Выходные выдались продуктивными, публикую еще одну статью 🙂

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

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

А еще, по этой теме сделаем открытый урок курса Тимлид в OTUS не далее, как завтра! Ссылочку на регистрацию положу в комментарий.

ВОПРОСНИК #16

Сегодня вопрос про матрицу компетенций и прозрачность.

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

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

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

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

Плюсы:
- Единый контекст – не надо каждый раз и каждому сотруднику объяснять, почему вы его повысили или не повысили, дали премию или не дали, есть четкие правила
- Прозрачная схема развития – каждый сотрудник знает, что нужно знать/уметь/делать, чтобы его повысили, каждый наставник сотрудника понимает, про что нужно ставить цели и т д
- Мотивация – сотрудники могут видеть требования, примерять их на себя, заряжаться дофамином и идти работать, чтобы развитие свое обеспечивать и повышение потом получать
- Обратная связь – одна голова хорошо, но если пользоваться мнениями сотрудников, то ваша матрица будет в разы качественнее, лучше, продуманнее
- Операционный инструмент – каждый сотрудник в рамках своего плана развития может, например, сделать копию матрицы и засветофорить свои достижения и планы, или даже можно запихать все это в ERP-систему и значительно автоматизировать процесс

Минусы:
- Буквы и слова одинаковые, а предложения – не всегда – очень часто возникают ситуации, что какой-то сотрудник понял неверно требования матрицы, исказил их по своему, и потом требует чтобы его повысили ибо вот он такой готовый
- Перекосы в развитии – бывает, что сотрудник недозакрыл какие-то важные компетенции прошлых уровней, но уже закрывает компетенции следующих ступеней (у нас был такой пример в QA, когда у сотрудника оставались пробелы в мануальном тестировании, но была уже круто прокачана автоматизация, и непонятно, что делать)

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

Чтобы закрыть эти минусы нужно работать системно, объяснять сотрудникам, в чем состоят их цели по развитию, почему они именно такие, почему “закрывание” пунктов матрицы есть обязательное условие, но совсем не достаточное.

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

Надеюсь, получилось ответить на вопрос.

P.S. Форма для ваших вопросов и кейсов тут https://forms.gle/aBX5PgU1CLU4FDPP8

Коллеги, анонс!

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

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

Зарегистрироваться можно тут https://stratoplan-school.com/ctohandbook/

Видео вчерашнего ОУ про календарь https://youtu.be/XkX4028Y-M4

Коснулись потенциальных возможностей календаря, календарной этики. Рассмотрели несколько полезных календарных лайфхаков.

ITBizRadio - ИТ-менеджеры в России больше не нужны | Илья Прахт

Хорошо ли идут дела в IT? Реально ли найти работу People-менеджером или сейчас нужны универсальные менеджеры-технари? Обсудили ситуацию с Ex-CTO IT-компании и тренером популярных обучающих курсов для IT-менеджеров - Ильей Прахтом. Посмотрели на ситуацию рынка вакансий, перспективы развития и роста из лида в менеджера, из менеджера в СТО и из СТО в ... Скорее слушайте подкаст ITBizRadio, все ответы внутри!

https://www.youtube.com/watch?v=s4ws6SXjXB0

4:27 - Какие вакансии есть для IT-менеджеров?
8:20 - Чего хотят от СТО работодатели?
14:40 - Нужно ли обучаться на IT-менеджера или оно само придет?
17:31 - Советы по поиску работы IT-менеджерам.
21:43 - Куда податься СТО после роли СТО?
26:05 - Тренинги и другие способы вырасти в крутого IT-менеджера.
34:33 - Кого назначают тимлидами и почему?
44:08 - Где обучиться на IT-менеджера - советы и рекомендации.
46:53 - Даунгрейд и просадка по ЗП, как новая реальность - принимать или нет?
52:00 - Выводи и инсайты.

Ссылка на наш ролик с Ильей Прахтом про жизнь IT-директора в России:

- Жизнь IT директора в России | Илья Прахт: https://www.youtube.com/watch?v=7JiRoQGI0xw

Ссылки на ролики с Кирой Кузьменко о том, как искать работу:
кандидаты глазами рекрутера - https://www.youtube.com/watch?v=0NqNyGF8I6I
рынок глазами кандидата - https://www.youtube.com/watch?v=CwYdHWGWaEY

*************************************
Наши контакты
Telegram - https://t.iss.one/ITBizRadio_chat
VK - https://vk.com/itbizradio
YouTube - https://www.youtube.com/@ITBizRadio
RuTube - https://rutube.ru/channel/7634084/
LinkedIn - https://linkedin.com/company/itbizradio/
Наш сайт - https://itbizradio.ru/
*************************************
#itbizradio #itmanagement #itmanagers #development