Видео со вчерашнего мероприятия OTUS про офферы.
Обсудили, как готовить офферы, чтобы не отказывали, как проводить встречу с кандидатами, какие есть типичные ошибки и лайфхаки в этом ремесле.
Внутри снова есть немного рекламы)
https://youtu.be/8X8Lgqa8hoE

ДАЙДЖЕСТ ЗА НЕДЕЛЮ

Размышления о том, надо ли работать с чудаками

Разбор недооцененного менеджмерского инструмента Inbox

Видео с вебинара OTUS про увольнения

Анонс моего доклада на Dump в Екб

Видео с вебинара OTUS про офферы

И напоминание про фрому для вопросов/кейсов, которые хочется разобрать

Хороших выходных и до встречи на следующей неделе!

БОРЬБА С ОЧКОВТИРАТЕЛЬСТВОМ

Была у нас такая история. Была у нас матричная структура, были у нас ПМы. И топ-менеджмент постоянно был ими недоволен.

Основной проблемой была реактивность: ПМы до последнего рапортовали, что с проектом все хорошо, а потом приходили и говорили "все, полимеры просраны". И топ-менеджмент засучался и начинал разгребать, задавая один и тот же вопрос каждый раз: "да почему же ты раньше не сказал то???".

А раньше они не говорили вот почему. Помимо ПМов были ж еще и тимлиды. И глубоко в технику погружались именно они, задачи раздавали они, реальный статус проекта могли видеть только они. ПМ приходил, спрашивал все ли хорошо, и получал логичный ответ - "да". А то что спринт на 90% завершен а сделано только 5% работы? Ну это процессы такие, просто все в последний день закрывается у нас, все будет, все закроется. Но все не закрывалось. Из раза в раз.

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

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

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

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

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

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

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

МОЙ ДОЗОР ОКОНЧЕН

В пятницу завершился мой долгий и интересный путь в компании Lineate/SmartUp. Пишу сегодня уже как совершенно свободный человек 🙂

4,5 года, 6 записей в трудовой. Путь, полный взлетов и падений, успехов и разочарований. Много было разного, есть что вспомнить!

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

Поэтому я в поиске новых карьерных возможностей. Готов быть CTO, CIO, CPO, COO в IT. А в чем-то небольшом могу и на роль CEO замахнуться 🙂

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

Пишите в личку!
@ilya_prakht

ПРО 1/1

Это может показаться странным, но до Тамтэка я и не знал ничего про 1/1. Их просто не было нигде, где я работал. Вот вообще, как явления.

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

А дальше 1/1 стало мейнстримом. Стыд и позор ожидали тех, кто их не проводит и не использует в работе. Представляете, каких-то 4-5 лет прошло, и сегодня это едва ли не основной инструмент в работе руководителя. И даже не только в IT! Удивительно.

Инструмент простой, понятный. Цели, средства, методы - все ясно и давно описано. Но тем не менее, на каждой конференции нет-нет, да и проскакивает докладик про 1/1. Почему? О чем тут еще рассказывать?

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

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

Накину тоже свои 5 копеек. Или рублей. Может банальщина, а может и нет. Тут вопрос к вам.

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

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

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

Да здравствуют же метафоры в текстах, и да здравствуют 1/1 встречи в работе руководителя!

ИНСТРУМЕНТЫ АУДИТА КОМАНДЫ

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

Итак, есть команда. Она есть, что называется AS IS, и с ней нужно как-то работать. Какой линейкой можно ее померить, чтобы это информация была хоть сколько-нибудь полезной?

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

Начнем со второго - с сотрудника. У сотрудника есть 3 основных параметра, с которых следует начинать:

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

2. Мотивация - ради чего сотрудник будет работать хорошо. Мне нравится здесь модель Герчикова. Она относительно простая, но очень наглядная. Понимая истинную мотивацию, понимаешь, как сотрудником управлять.

3. Психотип - как сотрудник будет работать и какого поведения от него ожидать. Хорошим инструментом является DISC. Да, он простоват, но зато понятный и наглядный.

Важно! Прям обращаю внимание! Все 3 типа инструментов (да-да, даже матрица компетенций!) - это упрощенные модели. Не бывает одного ярко выраженного типа, всегда есть комбинация: и в психотипах, и в мотивации, и в компетенциях. Поэтому и использовать эти инструменты нужно как некоторую базу, которую потом нужно натягивать на реальных людей. Как ту самую сову на ту самую уменьшенную модель мира.

Теперь про команду. Здесь есть 4 основных параметра, характеризующих команду:

1. Общая цель - куда и ради чего команда идет. Плохо, если цели нет. Лучше, если она есть, но не та, что нужна бизнесу. Ну и хорошо, когда и бизнес и команда смотрят в одну сторону. Неплохой инструмент придумал Стратоплан и обозвал его Мамонт. Цель должна выглядит как мамонт, которого нужно всем вместе завалить, чтобы утолить голод и обогатиться рогами и шкурами.

2. Командная динамика - в каком состоянии находится команда. Преславутые шторминги, норминги, перформинги по Такману. Для каждого этапа свои подходы и инструменты, путать не стоит.

3. Закрытость команды - какие у команды внешние границы, насколько она открыта для взаимодействия и коммуникаций наружу. Модель Берна с ее кружками хорошо иллюстрирует эту идею.

4. Роли в команде - какие роли есть, каких не хватает, каков баланс/перекос на данный момент. Неплохо роли описал Белбин. Есть еще модель Бенна и Шитса, направленная больше на выявление деструктивных ролей, но тоже полезно.

Вот такие 7 основных параметров и 7 основных инструментов, которые сильно помогают в аудите команды. Хотите что-то добавить - напишите.

И удачи в работе с вашими командами!

ПРО РИСКИ

Вот вы управляете рисками в проектах? А оно вообще надо?

Я помню 2 диаметрально противоположных подхода, которые встречал.

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

Второй: риски не нужны. Реестр рисков вообще убрали. Просто забили на эти ваши риски и все.

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

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

А теперь отсебятинка. Как же надо работать с рисками?

Мое мнение таково: если у вас совершенно разные проекты каждый раз, то с рисками работать надо, как положено, прям по ПМБУКу. Если проекты похожие и отличаются не более чем на 10-20% - то ни к чему.

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

План - ничто, планирование - все. Так Эйзенхауэр говорил. Очень точные слова.

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

КАК ТОРГОВАТЬСЯ НА ОФЕРЕ

На вебинаре про оферы был вопрос: "А как торговаться, чтобы спускать на землю кандидатов, которые зажрались?".

Однозначного ответа у меня не было, и я ушел в раздумья по этому поводу. И надумал.

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

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

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

Манипуляции - это про короткое взаимодействие. Там где сотрудничество долгое, манипуляциям не место.

Вот и получается. Можно высказать свое мнение, показать факты (только очень конструктивно) почему вы не согласны с запрашиваемой ЗП кандидата. И все на этом. Убедили - хорошо. Не убедили - ну значит вам не по пути.

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

ДАЙДЖЕСТ ЗА НЕДЕЛЮ

Пост про 1/1 - немного личной истории и важный лайфхак

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

Пост про риски - надо ли ими управлять и как это делать - немного отсебятины

Пост про то, как торговаться на офере - несколько простых мыслей, ответ на вопрос, а надо ли пытаться кандидатов прогибать

Еще хочу напомнить про форму с вопросами - пишите, о чем хотите почитать обзор, обязательно сделаю.

И напоминалочка. Следующая пятница. Екатеринбург. Конференция Dump. Расскажу про работу с командой в турбулентность: личный опыт, выводы и инструменты

ВОПРОСНИК

Вопрос от Антона Голубева. Про шаринг знаний в компании.
Антон, отдельное спасибо за фидбек 🙂

Вопрос (немного сократил):
У нас в компании есть 4 МЛ команды и между ними развит шаринг знаниями. Но проблема в том, что очень маленький процент этих знаний/идей/инструментов действительно кто-то пробует у себя в команде, не говоря уже о полноценном внедрении.
Есть ощущение, что если знания никто не использует, то зачем ими делиться? Но и не делиться тоже странно, ведь тогда мы теряем большой пласт опыта, ведь в командах много схожих проблем.
Что посоветуете в нашей ситуации? Как правильно делиться знаниями?

Ответ:
Судя по всему, проблем в области шаринга знаний у вас в компании нет. Здесь все работает. Проблема, скорее, с внедрением изменений, в усовершенствовании процессов.

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

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

Так вот, может оно и не надо просто? 🙂

Если все-таки надо, то тут может быть 2 причины, на мой взгляд, почему не доходит до внедрений:
1. У команд и/или тимлидов не болит. Как в том анекдоте про собаку, которая лежала на гвозде и выла. Да, это интересная проблема, чтобы о ней поговорить, но не настолько серьезная, чтобы тратить силы на ее решение.
2. У команд и/или тимлидов не хватает скиллов во внедрении изменений. Там нет ничего сложного, но когда в этой области у руководителя пробелы, он просто избегает любых изменений. Иногда еще называет себя консерватором)

Если дело в причине 1, то ответ ясен - все работает, так как надо, ничего не надо трогать. Убирать шаринг знаний тоже не надо из-за тимбилдингового эффекта, это дорогого стоит.

А если дело в причине 2, то нужно поучить тимлидов внедрению изменений, а потом поставить им задачу попрактиковаться. Можно через личные цели в ИПР, можно в виде целей от компании, не суть важно. Важно поставить такую задачу.

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

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

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

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

МОДЕЛЬ ТАКМАНА

В продолжение темы про аудит команды. Про инструменты.

Модель Такмана. Пожалуй, самый популярный в управлении командами инструмент. Простой и понятный. Шторминг, норминг, перформинг. Любая команда при формировании проходит через этап внутреннего конфликта. А потом все стабилизируется и все работают.

Как понять, на каком этапе команда? Есть несколько основных индикаторов. Но если упростить, то получается так:
- В команде есть ярковыраженные конфликты и противостояние - шторминг.
- В команде есть конфликты, но люди научились и начали договариваться - норминг.
- В команде редко бывают конфликты, все роли четко определены и всем понятны - перформинг.

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

Здесь надо четко понять, что команда - это не группа людей. Команда - это группа РОЛЕЙ. И эти роли должны четко разложиться по тем людям, что есть в команде. Отсюда и шторминг.

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

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

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

PEOPLE STATUS

Есть такой инструмент, называется People Status. Мы его очень активно использовали у себя в работе. И в нескольких докладах я его упоминал. И в статьях писал. А здесь – ни слова. Непорядок!

Опишу сегодня вкратце сам инструмент. А потом накидаю еще реальных кейсов, как он нас выручал. Погнали!

Основа инструмента – некоторая система оценки настроения и лояльности сотрудника. Цифровая шкала (мы использовали от 1 до 6), и 3 основные лампочки:
1. Лояльность сотрудника – насколько сотрудник доволен работой в компании
2. Удовлетворенность проектом – насколько сотруднику нравится проект, на котором он работает
3. Качество работы – насколько компания удовлетворена результатами сотрудника

Оценки здесь проставляет не сотрудник, а его руководитель или HR. Да, оценка субъективна. Да, не все могут раскрыть через вопросы истинное настроение человека, будут ошибки. Но такой подход дает одно очень важное преимущество – заполняемость достигает 100%.

Конечно, мы использовали и другие инструменты: опрос тимморали, классический eNPS и т д. И у всех у них был один, но крайне существенный недостаток – заполняемость не превышает 30%. Т е у нас нет информации о ⅔ сотрудниках компании! Это серьезный пробел в данных. People Status эту проблему решает.

С точки зрения процесса, мы обязали заполнять People Status руководителей и HR-ов сразу после проведения встречи 1/1. И руководитель, и HR имели прошитые в календаре 1/1 каждый месяц. Мы немного разнесли их по времени, чтобы они чередовались через 2 недели. И вот у нас есть актуальная информацию по каждому сотруднику не реже 2 раз в месяц.

Поскольку мы оцифровываем свои лампочки, с данными дальше можно проводить различные манипуляции:
1. Эскалировать, если значение упало ниже нормы. У нас нормой было 5, все что ниже – требует обработки
2. Информацию можно агрегировать и смотреть среднюю тиммораль по командам, по отделам, по всей компании
3. Можно смотреть изменения показателей в динамике, строить графики и определять тренды. И это как раз целая большая область для грамотных управленческих решений, основанных на данных. Про это сделаю отдельный пост, как обещал.

Конечно, People Status не идеален. И помимо проблемы субъективности оценки, у него есть еще, как минимум, 2 крупных недостатка:
1. Техническая сложность – здесь нужно аккуратно показывать информацию, чтобы руководитель видел только своих сотрудников, сотрудник только самого себя и т д. Поэтому реализовать его на простых гуглодоках можно, мы это делали, но получается неудобно. Мы в итоге перенесли его в свою ERP-систему, но это уже серьезные расходы
2. Дисциплина – нужно привить дисциплину всем, кто работает с инструментом. Иначе данные становятся неактуальными и картинка сильно искажается. И тяжелее всего с тимлидами, потому что “ну у меня итак все в голове”. И ведь оно и правда в голове, приходится договариваться, чтобы из головы оно еще и в систему попадало

Вот такой классный инструмент, который можно просто взять и внедрить. Очевидная польза! А про неочевидную расскажу в следующий раз.

ПРО ЛИНЕЙНЫХ МЕНЕДЖЕРОВ

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

Это был этап, когда топ-менеджмента уже на все не хватало, а никакого другого менеджмента в компании толком и не было. Вот его активно строили. Слой мидлменеджмента из руководителей отделов/групп, а также слой линейного менеджмента.

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

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

А потом мы придумали линейных менеджеров. Это были кураторы 2.0. Это была доп. активность для синьоров и лидов. Они подчинялись и отчитывались руководителям отделов (а в инженерных отделах было по 40-50 человек). У каждого была своя фиксированная группа людей, закрепленная за ним. И основной задачей были контроль мотивации и развитие сотрудника. Работало прекрасно.

Далее мы добавили линейным менеджерам еще супервайзинг проектов и работу над целями компании. Получались такие мини-руководители. Шикарный трамплин для профессионального и личностного роста. А еще мастерски закрывался вопрос кадрового резерва. Мы это прочувствовали позже, когда в компании была реорганизация, и многие линейные менеджеры, эти мини-руководители, стали полноценными и настоящими руководителями. Легко и просто, без особых проблем.

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

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

Почему? Все банально – это очень дорого. Стоимость менеджмента достигала 30%, что просто немыслимо для небольшой IT-компании. Мы провели реорганизацию, назначили руководителей всех необходимых уровней, а линейный менеджмент перешел обратно тимлидам. Только уже теперь по-нормальному. Мы научились делать из них хороших пипл-менеджеров. Наработки эпохи ЛМов не прошли зря.

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

Написал небольшую статью по мотивам свего доклада на DUMP в прошлую пятницу.
Формат больше походит на конспект, постарался убрать лишнюю воду.
Делюсь https://habr.com/ru/articles/731444/

ВОПРОСНИК#12

Вопрос от @Skogan78 про будущее IT в РФ. Да и не только IT, я бы сказал.

Вопрос:
А отвлеченный вопрос - есть понимание, что теперь из себя будет представлять "русское ит" в новом мире, и насколько sustainable это все ? Раньше механизм был понятен - мы вытаскивали мозги из остатков промышленности в рф (благо, деградирующая промышленность не сопротивлялась). И пользовались тем, что жизненные стандарты Васи в Урюпинске, Мухосранске, Омске ниже чем в США или Европе, но одновременно он квалифицированнее чем представитель титульной нации из Бомбея... Теперь это месторождение разработчиков подошло к концу. В чем (!) будет наше конкурентное преимущество ? Как воспроизвести человеческий капитал если дети Васи-релоканта пойдут в европейскую/американскую школу и вырастут с местными представлениями об уровне жизни, о мироустройстве, итд ? У меня нет ответа…

Ответ:
Во-первых, то что я вижу сейчас, и что подтверждают цифры того же hh.ru, это серьезное такое расслоение кадрового рынка. Наблюдается высокая степень сегментирования на “крупняк” и всех остальных. Крупняк не бедствует, крупняку достаются основные поддерживающие меры государства, крупняк принимает решения через всевозможные ассоциации и комьюнити, куда будет двигаться отрасль в РФ. Как итог, крупняк готов платить нормальную рыночную ЗП, и люди стараются туда попасть. Поэтому крупняк не испытывает никакого кадрового голода, он может брать себе лучших.

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

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

Ну и в-третьих, кадрового голода в IT в РФ сейчас вообще нет. На вакансии синьоров десятки откликов, на вакансии мидлов и менеджеров – сотни. Когда такое было вообще?) Поэтому, я думаю, рынок на некоторое время стабилизируется, и приток новых специалистов не будет особо востребован. Это уронит популярность свитчинга в профессию, но, возможно, приведет к повышению качества образования. Как базового в ВУЗах, так и дополнительного.

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

Рынок IT в РФ будет развиваться сам по себе ближайшее время. В изоляции (во всяком случае с точки зрения кадров) от западных рынков. Соответственно, все вернется плавно к примерно допандемийному уровню, когда жизненные стандарты Васи из Урюпинска ниже аналогичных Пети из Москвы, и будет развитие IT в регионах за счет этого. Приток “свежей крови” будет, как и раньше, из ВУЗов и свитчинга, но объемы сократятся, ибо отрасли столько просто не нужно. Ну и как мне кажется, денег в промышленности станет больше, а значит популярность IT на фоне этого будет падать. И все придет в некоторый баланс обычных нормальных рыночных отношений.

Простое мнение простого человека. Будет интересно обсудить его с вами.
Пишите, что про все это думаете!

РОЛЕВАЯ МОДЕЛЬ БЕЛБИНА

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

В любой команде также есть набор ролей. И команда тем эффективнее, чем разнообразнее и сбалансированнее роли в ней.

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

Белбин выделил 3 группы ролей в команде:
1. Роли, нацеленные на действие
2. Социальные роли
3. Интеллектуальные роли

И обозначил по 3 роли в каждой группе:
1. Мотиватор – всех вдохновляет что-то делать
2. Исполнитель – просто делает, превращает идеи в результаты
3. Педант – доводит дело до конца, перфекционирует
4. Координатор – заставляет всех работать вместе, раздает указания
5. Душа команды – просто приятный чувак, налаживает отношения внутри команды
6. Исследователь – налаживает контакты с внешним миром и приносит оттуда новые идеи
7. Генератор идей – создает новые идеи (в отличие от исследователя, свои собственные, ну или думает, что свои собственные)
8. Аналитик – ищет истину, фильтрует все идеи
9. Специалист – эксперт, знает как надо правильно

Шик, блеск и трикота, когда в команде есть все эти роли. Но это, скажем прямо, редкость. Но нужно добиваться того, чтобы были представлены хотя бы самые необходимые. Белбин считал, что таковых 5:
1. Мотиватор
2. Координатор
3. Генератор идей
4. Исследователь
5. Исполнитель

Неоднозначный списочек. Как по мне, работает для очень сферической команды в вакууме. А как чуть копнешь в конкретику, так все разваливается. Но это мнение Белбина, кто я такой, чтобы с ним спорить)

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

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

Пример посложнее. В команде постоянный ступор на этапе принятия решений. Идеи есть, договариваются вроде быстро, делают неплохо. А вот взять и решить, что делаем А, и не делаем Б – проблема. Диагноз? Я бы сказал, здесь явно проседают координатор и мотиватор. Лечение? Можно добавить харизматичного ПМа, который закроет собой эти роли.

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

ПОБЕДА НАД НЕОПРЕДЕЛЕННОСТЯМИ

Когда-то давно со Стратопланом делали эфир про то, как планировать в условиях неопределенности. Про то есть даже подробная статья. Но основную суть я вам сегодня расскажу.

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

Суть и особенность любого проекта – нифига не понятно, что надо сделать. И с этой неопределенностью приходится бороться.

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

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

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

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

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

Хороший подход. Очень рекомендую!

ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ

Ответ на вопрос про шаринг знаний - как его правильно организовать, чтобы и польза была, и время за зря не тратилось

Пост про модель Такмана - в чем ее суть и причем тут командные роли

Пост про People Status - эффективный инструмент для мониторинга состояния сотрудников

Пост про линейных менеджеров - наша история, как мы их создавали и какие уроки из этого смогли вынести

Статья по моему докладу на DUMP 2023 - как работать с командой в условиях внешней и внутренней турбулентности

Ответ на вопрос про будущее IT в РФ - личные размышления на этот счет, не истина, но повод для дискуссии

Пост про ролевую модель Белбина - что за инструмент и как с его помощью решать командные проблемы

Пост про борьбу с неопределенностями - про наш подход с предположениями (assumptions) вместо риск-менеджмента и его применимость в обычной жизни

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

Написал небольшую статью по мотивам прошлогоднего доклада на TeamLeadConf (да, дошли руки наконец).

Там про нашу историю 21 года, про наши эксперименты со стаффингом и поиском идеального подхода для распределения людей по проектам, чтобы было хорошо не только компании, но и сотрудникам.

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

PEOPLE STATUS – ПРИМЕРЫ

В продолжение поста про People Status, как обещал, несколько реальных примеров из жизни.

Пример#1 – лояльный офер
Инженер, с высокой лояльностью к компании, высоким интересом к проекту, а также с высоким уровнем качества работы (планировали повышать в ближайший месяц) приходит с офером. ЗП в офере на 20% выше. Глядя на графики, понимаем, что вопрос единственно в размере ЗП, проводим запланированное повышение чуть раньше, догоняем офер. Сотрудник остается в компании.

Пример#2 – нелояльный офер
Аналогичная ситуация. Только лояльность к компании средняя, наблюдается ее снижение в последние месяцы. Удовлетворенность проектом средняя, и точно также падает. При этом, качество работы стабильно высокое, его работой мы довольны. И снова приходит с офером, +20% к ЗП. Понимаем, что несмотря на хорошие результаты, уход человека лишь вопрос времени. Лояльность будет снижаться и дальше, а значит удерживать или нет – вопрос сиюминутных рисков. Риски были высокими, позиция в проекте ключевая. Поэтому догоняем офер, начинаем готовить замену на проекте, мониторим ситуацию. Через 1,5 месяцев сотрудник приходит с новым офером, но у нас уже есть замена, все ожидаемо и подготовлено. Отпускаем с миром.

Пример#3 – усталость от проекта
Инженер, давно на проекте. Последние несколько месяцев жалуется на свой проект, показатель удовлетворенности проектом падает неумолимо. Параллельно падает и качество работы. А уровень лояльности высокий. Проводим беседу, уточняем обстоятельства. Переводим сотрудника на новый проект, показатели выравниваются в течение месяца.

Пример#4 – выгорание
Инженер, в прошлом отличался высокими всеми тремя показателями. Последние несколько месяцев наблюдается методичное снижение всех 3 параметров одновременно. Когда все 3 падают ниже среднего, проводим беседу, убеждаемся, что это выгорание. Принудительно отправляем в отпуск. По возвращении, прорабатываем вопрос ротации, но она становится неактуальна, человек восстановился. Показатели приходят в норму в течение месяца.

Пример#5 – интересный проект
Инженер, ключевой синьор на проекте. Стабильно низкая лояльность к компании, вот прямо ниже среднего. При этом очень высокая удовлетворенность проектом и высокое качество работы. Понимаем, что сотрудник с нами только ради проекта. Обсуждаем это с ним, по его запросу отключаем от большинства внепроектных активностей компании, оставляем его один на один с проектом. Его это устраивает, через время лояльность даже чуть-чуть подросла. По завершении проекта, ожидаемо, приходит сразу с заявлением.

Пример#6 – плохой руководитель
Наблюдаем за агрегированной метрикой по одному отделу. Видим последние месяцы плавное снижение всех 3 показателей в отделе. Начинаем разбираться в каждом кейсе (благо отдел небольшой) и определяем, что последнее время руководитель стал вести себя странно. Смотрим показатели самого руководителя: высокая лояльность, падающие удовлетворенность проектом и качество работы. Просто устал, хочет другого. Находим для него другую позицию по душе, готовим замену, меняем руководителя. Показатели отдела восстановились в течение следующих 3 месяцев.

Все эти примеры наглядно демонстрируют, что интереснее и полезнее выглядят показатели тимморали в динамике, при анализе трендов. Это сильно расширяет картинку, и помогает в принятии верных решений. И People Status в этом хорош.

ВОПРОСНИК#13

Классный вопрос от @JustManowar про особенности управления большими проектами.
И отдельное спасибо за твой фидбек!

Вопрос:
А ты сталкивался когда-то с большими проектами? Можешь подсказать, какие есть особенности менеджмента больших проектов? Что можешь посоветовать project manager'у, которому дали проект в 500 человеко-лет? Может, видел какие-то статьи или книги, которые могут помочь?

Ответ:
С такими большими проектам, сказать честно, не сталкивался. Мои самые крупные проекты доходили где-то до 20 человеко-лет. А самый крупный, с которым вообще встречался, будучи хоть как-то около менеджмента – примерно 50 человеко-лет.

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

Я вижу 4 основных нюанса, которые есть в управлении реально большими проектами:

1. Больший уровень абстракции. В таком проекте с такой большой командой ПМ уже очень поверхностно погружается в детали, управляет проектом на очень высоком уровне. Очень многое здесь будет даже из стратегии. Поэтому всякие адаптированные модели и подходы здесь уже не нужны, и на сцену выходят инструменты классического проектного управления. Вот прям самого-самого классического. Следить за планами, проектными артефактами, собирать данные, вносить изменения. Из материалов здесь помогут как раз книжки по этому самому классическому проектному управлению: PMBOOK, Лич – Вовремя и в рамках бюджета, Беркун – Искусство управления IT-проектами и т д. Их очень много разных

2. Большая команда и сложность ее управления – порождает внутреннюю иерархию и структуру, опять же управление становится менее оперативным и более стратегическим, роль трансформируется в менеджера менеджеров. Это, в первую очередь, трансформация mind-set-а, поэтому одними книгами не закрыться, нужна практика и опыт. Но из того, что точно поможет, можно полистать книжки по операционному менеджменту (их очень много разных), про управление через метрики и показатели (например, Брукс – Метрики для управления IT-услугами, Демин, Исайченко – Управление услугами на основе измерений), книги по стратегическому управлению и про менеджмент через коучинг и т п подходы (например, Уитмор – Внутренняя сила лидера)

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

4. Большая часть ежедневной операционки – разрешение конфликтов и синхронизация. Потому что, как писал выше, у вас уже сложная структура команды внутри, они сами делают результат, нужно только направлять и немного разграничивать, чтобы не стукались друг с другом лбами и не толкались локтями. Здесь также операционный менеджмент, классические подходы к управлению. И, наверное, можно добавить конфликтологию и переговоры (Орлов – Конструктивная конфронтация, Кеннеди – Договориться можно обо всем, Фишер – Гарвардский метод переговоров и т д)

С моей колокольни выглядит как-то так 🙂

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

P.S. Форма для ваших вопросов и кейсов тут https://forms.gle/aBX5PgU1CLU4FDPP8
Пишите, а я сделаю разбор. Анонимно или нет, как пожелаете.