РОЛЕВАЯ МОДЕЛЬ БЕЛБИНА
Мы все играем роли. На работе, в отношениях, в социуме. Какие-то роли нам нравятся больше, и мы исполняем их качественно. Какие-то – сильно меньше, и мы их исполняем из-под палки. Какие-то вообще стараемся избегать.
В любой команде также есть набор ролей. И команда тем эффективнее, чем разнообразнее и сбалансированнее роли в ней.
Вопросом ролевых моделей команд много занимался Белбин. В итоге вывел свою модель, которая сегодня довольно популярна. Это хороший инструмент для аудита команды, а потому давайте его разберем.
Белбин выделил 3 группы ролей в команде:
1. Роли, нацеленные на действие
2. Социальные роли
3. Интеллектуальные роли
И обозначил по 3 роли в каждой группе:
1. Мотиватор – всех вдохновляет что-то делать
2. Исполнитель – просто делает, превращает идеи в результаты
3. Педант – доводит дело до конца, перфекционирует
4. Координатор – заставляет всех работать вместе, раздает указания
5. Душа команды – просто приятный чувак, налаживает отношения внутри команды
6. Исследователь – налаживает контакты с внешним миром и приносит оттуда новые идеи
7. Генератор идей – создает новые идеи (в отличие от исследователя, свои собственные, ну или думает, что свои собственные)
8. Аналитик – ищет истину, фильтрует все идеи
9. Специалист – эксперт, знает как надо правильно
Шик, блеск и трикота, когда в команде есть все эти роли. Но это, скажем прямо, редкость. Но нужно добиваться того, чтобы были представлены хотя бы самые необходимые. Белбин считал, что таковых 5:
1. Мотиватор
2. Координатор
3. Генератор идей
4. Исследователь
5. Исполнитель
Неоднозначный списочек. Как по мне, работает для очень сферической команды в вакууме. А как чуть копнешь в конкретику, так все разваливается. Но это мнение Белбина, кто я такой, чтобы с ним спорить)
Так вот. Суть. Многие проблемы в командах можно рассматривать с точки зрения отсутствия/дисбаланса ролей. Ну и решения этих проблем, соответственно, находятся в добавлении/исключении ролей.
Простой пример. В команде хорошая атмосфера, много идей и разговоров, но работа движется слабо, постоянно факапят дедлайны. Диагноз? Скорее всего, перекос в сторону социальных ролей и недостаток результативных ролей. Лечение? Нужно добавить мотиваторов, исполнителей, педантов, может поубавить представителей социальных ролей.
Пример посложнее. В команде постоянный ступор на этапе принятия решений. Идеи есть, договариваются вроде быстро, делают неплохо. А вот взять и решить, что делаем А, и не делаем Б – проблема. Диагноз? Я бы сказал, здесь явно проседают координатор и мотиватор. Лечение? Можно добавить харизматичного ПМа, который закроет собой эти роли.
Вот такая модель в копилочку инструментов управления. Как по мне, полезная. Попробуйте, расскажите, как оно вам?
Мы все играем роли. На работе, в отношениях, в социуме. Какие-то роли нам нравятся больше, и мы исполняем их качественно. Какие-то – сильно меньше, и мы их исполняем из-под палки. Какие-то вообще стараемся избегать.
В любой команде также есть набор ролей. И команда тем эффективнее, чем разнообразнее и сбалансированнее роли в ней.
Вопросом ролевых моделей команд много занимался Белбин. В итоге вывел свою модель, которая сегодня довольно популярна. Это хороший инструмент для аудита команды, а потому давайте его разберем.
Белбин выделил 3 группы ролей в команде:
1. Роли, нацеленные на действие
2. Социальные роли
3. Интеллектуальные роли
И обозначил по 3 роли в каждой группе:
1. Мотиватор – всех вдохновляет что-то делать
2. Исполнитель – просто делает, превращает идеи в результаты
3. Педант – доводит дело до конца, перфекционирует
4. Координатор – заставляет всех работать вместе, раздает указания
5. Душа команды – просто приятный чувак, налаживает отношения внутри команды
6. Исследователь – налаживает контакты с внешним миром и приносит оттуда новые идеи
7. Генератор идей – создает новые идеи (в отличие от исследователя, свои собственные, ну или думает, что свои собственные)
8. Аналитик – ищет истину, фильтрует все идеи
9. Специалист – эксперт, знает как надо правильно
Шик, блеск и трикота, когда в команде есть все эти роли. Но это, скажем прямо, редкость. Но нужно добиваться того, чтобы были представлены хотя бы самые необходимые. Белбин считал, что таковых 5:
1. Мотиватор
2. Координатор
3. Генератор идей
4. Исследователь
5. Исполнитель
Неоднозначный списочек. Как по мне, работает для очень сферической команды в вакууме. А как чуть копнешь в конкретику, так все разваливается. Но это мнение Белбина, кто я такой, чтобы с ним спорить)
Так вот. Суть. Многие проблемы в командах можно рассматривать с точки зрения отсутствия/дисбаланса ролей. Ну и решения этих проблем, соответственно, находятся в добавлении/исключении ролей.
Простой пример. В команде хорошая атмосфера, много идей и разговоров, но работа движется слабо, постоянно факапят дедлайны. Диагноз? Скорее всего, перекос в сторону социальных ролей и недостаток результативных ролей. Лечение? Нужно добавить мотиваторов, исполнителей, педантов, может поубавить представителей социальных ролей.
Пример посложнее. В команде постоянный ступор на этапе принятия решений. Идеи есть, договариваются вроде быстро, делают неплохо. А вот взять и решить, что делаем А, и не делаем Б – проблема. Диагноз? Я бы сказал, здесь явно проседают координатор и мотиватор. Лечение? Можно добавить харизматичного ПМа, который закроет собой эти роли.
Вот такая модель в копилочку инструментов управления. Как по мне, полезная. Попробуйте, расскажите, как оно вам?
👍4🔥2
ПОБЕДА НАД НЕОПРЕДЕЛЕННОСТЯМИ
Когда-то давно со Стратопланом делали эфир про то, как планировать в условиях неопределенности. Про то есть даже подробная статья. Но основную суть я вам сегодня расскажу.
Перед тем, как делать проект, его нужно оценить. Чтобы правильно все распланировать, посчитать, выставить счет заказчику.
Суть и особенность любого проекта – нифига не понятно, что надо сделать. И с этой неопределенностью приходится бороться.
Самый методически верный, но не особо популярный подход – управление рисками. Мы пробовали, получается сложно. А там где сложно, подход быстро себя изживает и превращается в формальность. Ну я про это тоже писал. Сплошные шаблоны и копипасты.
Поэтому выбрали немного упрощенную версию – предположения (assumptions). В чем суть. Мы анализируем все имеющиеся требования к проекту, разделяем на понятные и непонятные. Понятные оцениваем и считаем. Непонятные покрываем предположениями и возвращаем их заказчику.
Простой пример. В требованиях неоднозначно указано, кто делает дизайн. При этом, дизайн нужен в самом начале, чтобы далее можно было делать фронт и мобилки. Пишем в предположения, что дизайн делает заказчик, выдает его не позднее 2 недель от старта проекта. Включаем это во все брифы и КП, утверждаем с заказчиком, что так оно и будет, включаем в роадмап проекта. Просто, человеческим языком, и без всяких разных реестров рисков на десятки страниц.
Прелесть этого подхода в том, что он не только про проекты. Можно и в обычной жизни этим пользоваться. Выделяем неопределенности, покрываем различными “если”, и вот у нас есть четкий план.
А мозг, он же хитрый. Ну или тупой, тут кому как больше нравится. Если плана нет, то он волнуется, стрессует. Если план есть, даже с кучей вложенных IF-ов внутри, ему спокойно. Кажется, что ситуацию вы контролируете, и стресса гораздо меньше.
Хороший подход. Очень рекомендую!
Когда-то давно со Стратопланом делали эфир про то, как планировать в условиях неопределенности. Про то есть даже подробная статья. Но основную суть я вам сегодня расскажу.
Перед тем, как делать проект, его нужно оценить. Чтобы правильно все распланировать, посчитать, выставить счет заказчику.
Суть и особенность любого проекта – нифига не понятно, что надо сделать. И с этой неопределенностью приходится бороться.
Самый методически верный, но не особо популярный подход – управление рисками. Мы пробовали, получается сложно. А там где сложно, подход быстро себя изживает и превращается в формальность. Ну я про это тоже писал. Сплошные шаблоны и копипасты.
Поэтому выбрали немного упрощенную версию – предположения (assumptions). В чем суть. Мы анализируем все имеющиеся требования к проекту, разделяем на понятные и непонятные. Понятные оцениваем и считаем. Непонятные покрываем предположениями и возвращаем их заказчику.
Простой пример. В требованиях неоднозначно указано, кто делает дизайн. При этом, дизайн нужен в самом начале, чтобы далее можно было делать фронт и мобилки. Пишем в предположения, что дизайн делает заказчик, выдает его не позднее 2 недель от старта проекта. Включаем это во все брифы и КП, утверждаем с заказчиком, что так оно и будет, включаем в роадмап проекта. Просто, человеческим языком, и без всяких разных реестров рисков на десятки страниц.
Прелесть этого подхода в том, что он не только про проекты. Можно и в обычной жизни этим пользоваться. Выделяем неопределенности, покрываем различными “если”, и вот у нас есть четкий план.
А мозг, он же хитрый. Ну или тупой, тут кому как больше нравится. Если плана нет, то он волнуется, стрессует. Если план есть, даже с кучей вложенных IF-ов внутри, ему спокойно. Кажется, что ситуацию вы контролируете, и стресса гораздо меньше.
Хороший подход. Очень рекомендую!
Хабр
Привыкаем к новой реальности: как планировать в условиях неопределенности
«Какой план на неделю? Я не знаю, чем сегодня день закончится!» «Да зачем планировать, если все равно ничего не понятно!» Знакомо? Наверняка! Эта та реальность, в которой мы сейчас находимся. Уровень...
👍6❤4
ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ
Ответ на вопрос про шаринг знаний - как его правильно организовать, чтобы и польза была, и время за зря не тратилось
Пост про модель Такмана - в чем ее суть и причем тут командные роли
Пост про People Status - эффективный инструмент для мониторинга состояния сотрудников
Пост про линейных менеджеров - наша история, как мы их создавали и какие уроки из этого смогли вынести
Статья по моему докладу на DUMP 2023 - как работать с командой в условиях внешней и внутренней турбулентности
Ответ на вопрос про будущее IT в РФ - личные размышления на этот счет, не истина, но повод для дискуссии
Пост про ролевую модель Белбина - что за инструмент и как с его помощью решать командные проблемы
Пост про борьбу с неопределенностями - про наш подход с предположениями (assumptions) вместо риск-менеджмента и его применимость в обычной жизни
И хочу напомнить еще про форму для вопросов - пишите сюда свой вопрос или кейс из жизни, а я его обязательно разберу. Форма анонимная, при желании можно подписаться.
Ответ на вопрос про шаринг знаний - как его правильно организовать, чтобы и польза была, и время за зря не тратилось
Пост про модель Такмана - в чем ее суть и причем тут командные роли
Пост про People Status - эффективный инструмент для мониторинга состояния сотрудников
Пост про линейных менеджеров - наша история, как мы их создавали и какие уроки из этого смогли вынести
Статья по моему докладу на DUMP 2023 - как работать с командой в условиях внешней и внутренней турбулентности
Ответ на вопрос про будущее IT в РФ - личные размышления на этот счет, не истина, но повод для дискуссии
Пост про ролевую модель Белбина - что за инструмент и как с его помощью решать командные проблемы
Пост про борьбу с неопределенностями - про наш подход с предположениями (assumptions) вместо риск-менеджмента и его применимость в обычной жизни
И хочу напомнить еще про форму для вопросов - пишите сюда свой вопрос или кейс из жизни, а я его обязательно разберу. Форма анонимная, при желании можно подписаться.
🔥5👍3
Написал небольшую статью по мотивам прошлогоднего доклада на TeamLeadConf (да, дошли руки наконец).
Там про нашу историю 21 года, про наши эксперименты со стаффингом и поиском идеального подхода для распределения людей по проектам, чтобы было хорошо не только компании, но и сотрудникам.
Приглашаю почитать https://habr.com/ru/articles/732728/
Там про нашу историю 21 года, про наши эксперименты со стаффингом и поиском идеального подхода для распределения людей по проектам, чтобы было хорошо не только компании, но и сотрудникам.
Приглашаю почитать https://habr.com/ru/articles/732728/
Хабр
Дар и проклятье аутсорсинга: как сделать так, чтобы сотрудники кайфовали на своих проектах
Главная особенность заказной разработки – это сложный стаффинг, распределение людей по проектам. Людей много, они разные. Проектов много, они тоже все разные. Получается многомерный пазл, который не...
👍6
PEOPLE STATUS – ПРИМЕРЫ
В продолжение поста про People Status, как обещал, несколько реальных примеров из жизни.
Пример#1 – лояльный офер
Инженер, с высокой лояльностью к компании, высоким интересом к проекту, а также с высоким уровнем качества работы (планировали повышать в ближайший месяц) приходит с офером. ЗП в офере на 20% выше. Глядя на графики, понимаем, что вопрос единственно в размере ЗП, проводим запланированное повышение чуть раньше, догоняем офер. Сотрудник остается в компании.
Пример#2 – нелояльный офер
Аналогичная ситуация. Только лояльность к компании средняя, наблюдается ее снижение в последние месяцы. Удовлетворенность проектом средняя, и точно также падает. При этом, качество работы стабильно высокое, его работой мы довольны. И снова приходит с офером, +20% к ЗП. Понимаем, что несмотря на хорошие результаты, уход человека лишь вопрос времени. Лояльность будет снижаться и дальше, а значит удерживать или нет – вопрос сиюминутных рисков. Риски были высокими, позиция в проекте ключевая. Поэтому догоняем офер, начинаем готовить замену на проекте, мониторим ситуацию. Через 1,5 месяцев сотрудник приходит с новым офером, но у нас уже есть замена, все ожидаемо и подготовлено. Отпускаем с миром.
Пример#3 – усталость от проекта
Инженер, давно на проекте. Последние несколько месяцев жалуется на свой проект, показатель удовлетворенности проектом падает неумолимо. Параллельно падает и качество работы. А уровень лояльности высокий. Проводим беседу, уточняем обстоятельства. Переводим сотрудника на новый проект, показатели выравниваются в течение месяца.
Пример#4 – выгорание
Инженер, в прошлом отличался высокими всеми тремя показателями. Последние несколько месяцев наблюдается методичное снижение всех 3 параметров одновременно. Когда все 3 падают ниже среднего, проводим беседу, убеждаемся, что это выгорание. Принудительно отправляем в отпуск. По возвращении, прорабатываем вопрос ротации, но она становится неактуальна, человек восстановился. Показатели приходят в норму в течение месяца.
Пример#5 – интересный проект
Инженер, ключевой синьор на проекте. Стабильно низкая лояльность к компании, вот прямо ниже среднего. При этом очень высокая удовлетворенность проектом и высокое качество работы. Понимаем, что сотрудник с нами только ради проекта. Обсуждаем это с ним, по его запросу отключаем от большинства внепроектных активностей компании, оставляем его один на один с проектом. Его это устраивает, через время лояльность даже чуть-чуть подросла. По завершении проекта, ожидаемо, приходит сразу с заявлением.
Пример#6 – плохой руководитель
Наблюдаем за агрегированной метрикой по одному отделу. Видим последние месяцы плавное снижение всех 3 показателей в отделе. Начинаем разбираться в каждом кейсе (благо отдел небольшой) и определяем, что последнее время руководитель стал вести себя странно. Смотрим показатели самого руководителя: высокая лояльность, падающие удовлетворенность проектом и качество работы. Просто устал, хочет другого. Находим для него другую позицию по душе, готовим замену, меняем руководителя. Показатели отдела восстановились в течение следующих 3 месяцев.
Все эти примеры наглядно демонстрируют, что интереснее и полезнее выглядят показатели тимморали в динамике, при анализе трендов. Это сильно расширяет картинку, и помогает в принятии верных решений. И People Status в этом хорош.
В продолжение поста про People Status, как обещал, несколько реальных примеров из жизни.
Пример#1 – лояльный офер
Инженер, с высокой лояльностью к компании, высоким интересом к проекту, а также с высоким уровнем качества работы (планировали повышать в ближайший месяц) приходит с офером. ЗП в офере на 20% выше. Глядя на графики, понимаем, что вопрос единственно в размере ЗП, проводим запланированное повышение чуть раньше, догоняем офер. Сотрудник остается в компании.
Пример#2 – нелояльный офер
Аналогичная ситуация. Только лояльность к компании средняя, наблюдается ее снижение в последние месяцы. Удовлетворенность проектом средняя, и точно также падает. При этом, качество работы стабильно высокое, его работой мы довольны. И снова приходит с офером, +20% к ЗП. Понимаем, что несмотря на хорошие результаты, уход человека лишь вопрос времени. Лояльность будет снижаться и дальше, а значит удерживать или нет – вопрос сиюминутных рисков. Риски были высокими, позиция в проекте ключевая. Поэтому догоняем офер, начинаем готовить замену на проекте, мониторим ситуацию. Через 1,5 месяцев сотрудник приходит с новым офером, но у нас уже есть замена, все ожидаемо и подготовлено. Отпускаем с миром.
Пример#3 – усталость от проекта
Инженер, давно на проекте. Последние несколько месяцев жалуется на свой проект, показатель удовлетворенности проектом падает неумолимо. Параллельно падает и качество работы. А уровень лояльности высокий. Проводим беседу, уточняем обстоятельства. Переводим сотрудника на новый проект, показатели выравниваются в течение месяца.
Пример#4 – выгорание
Инженер, в прошлом отличался высокими всеми тремя показателями. Последние несколько месяцев наблюдается методичное снижение всех 3 параметров одновременно. Когда все 3 падают ниже среднего, проводим беседу, убеждаемся, что это выгорание. Принудительно отправляем в отпуск. По возвращении, прорабатываем вопрос ротации, но она становится неактуальна, человек восстановился. Показатели приходят в норму в течение месяца.
Пример#5 – интересный проект
Инженер, ключевой синьор на проекте. Стабильно низкая лояльность к компании, вот прямо ниже среднего. При этом очень высокая удовлетворенность проектом и высокое качество работы. Понимаем, что сотрудник с нами только ради проекта. Обсуждаем это с ним, по его запросу отключаем от большинства внепроектных активностей компании, оставляем его один на один с проектом. Его это устраивает, через время лояльность даже чуть-чуть подросла. По завершении проекта, ожидаемо, приходит сразу с заявлением.
Пример#6 – плохой руководитель
Наблюдаем за агрегированной метрикой по одному отделу. Видим последние месяцы плавное снижение всех 3 показателей в отделе. Начинаем разбираться в каждом кейсе (благо отдел небольшой) и определяем, что последнее время руководитель стал вести себя странно. Смотрим показатели самого руководителя: высокая лояльность, падающие удовлетворенность проектом и качество работы. Просто устал, хочет другого. Находим для него другую позицию по душе, готовим замену, меняем руководителя. Показатели отдела восстановились в течение следующих 3 месяцев.
Все эти примеры наглядно демонстрируют, что интереснее и полезнее выглядят показатели тимморали в динамике, при анализе трендов. Это сильно расширяет картинку, и помогает в принятии верных решений. И People Status в этом хорош.
👍7🤔1
ВОПРОСНИК#13
Классный вопрос от @JustManowar про особенности управления большими проектами.
И отдельное спасибо за твой фидбек!
Вопрос:
А ты сталкивался когда-то с большими проектами? Можешь подсказать, какие есть особенности менеджмента больших проектов? Что можешь посоветовать project manager'у, которому дали проект в 500 человеко-лет? Может, видел какие-то статьи или книги, которые могут помочь?
Ответ:
С такими большими проектам, сказать честно, не сталкивался. Мои самые крупные проекты доходили где-то до 20 человеко-лет. А самый крупный, с которым вообще встречался, будучи хоть как-то около менеджмента – примерно 50 человеко-лет.
Поэтому, вполне возможно, мое видение будет не совсем верным. И я буду крайне благодарен коллегам, у кого был опыт работы с такими проектами, кто сможет дополнить, подтвердить или опровергнуть мое мнение.
Я вижу 4 основных нюанса, которые есть в управлении реально большими проектами:
1. Больший уровень абстракции. В таком проекте с такой большой командой ПМ уже очень поверхностно погружается в детали, управляет проектом на очень высоком уровне. Очень многое здесь будет даже из стратегии. Поэтому всякие адаптированные модели и подходы здесь уже не нужны, и на сцену выходят инструменты классического проектного управления. Вот прям самого-самого классического. Следить за планами, проектными артефактами, собирать данные, вносить изменения. Из материалов здесь помогут как раз книжки по этому самому классическому проектному управлению: PMBOOK, Лич – Вовремя и в рамках бюджета, Беркун – Искусство управления IT-проектами и т д. Их очень много разных
2. Большая команда и сложность ее управления – порождает внутреннюю иерархию и структуру, опять же управление становится менее оперативным и более стратегическим, роль трансформируется в менеджера менеджеров. Это, в первую очередь, трансформация mind-set-а, поэтому одними книгами не закрыться, нужна практика и опыт. Но из того, что точно поможет, можно полистать книжки по операционному менеджменту (их очень много разных), про управление через метрики и показатели (например, Брукс – Метрики для управления IT-услугами, Демин, Исайченко – Управление услугами на основе измерений), книги по стратегическому управлению и про менеджмент через коучинг и т п подходы (например, Уитмор – Внутренняя сила лидера)
3. Еще больший объем неопределенностей. А стало быть, всяких буферов, итераций и т д. Здесь снова работают инструменты классического проектного управления, не знаю, что еще можно сюда добавить
4. Большая часть ежедневной операционки – разрешение конфликтов и синхронизация. Потому что, как писал выше, у вас уже сложная структура команды внутри, они сами делают результат, нужно только направлять и немного разграничивать, чтобы не стукались друг с другом лбами и не толкались локтями. Здесь также операционный менеджмент, классические подходы к управлению. И, наверное, можно добавить конфликтологию и переговоры (Орлов – Конструктивная конфронтация, Кеннеди – Договориться можно обо всем, Фишер – Гарвардский метод переговоров и т д)
С моей колокольни выглядит как-то так 🙂
Надеюсь, получилось ответить на вопрос.
P.S. Форма для ваших вопросов и кейсов тут https://forms.gle/aBX5PgU1CLU4FDPP8
Пишите, а я сделаю разбор. Анонимно или нет, как пожелаете.
Классный вопрос от @JustManowar про особенности управления большими проектами.
И отдельное спасибо за твой фидбек!
Вопрос:
А ты сталкивался когда-то с большими проектами? Можешь подсказать, какие есть особенности менеджмента больших проектов? Что можешь посоветовать project manager'у, которому дали проект в 500 человеко-лет? Может, видел какие-то статьи или книги, которые могут помочь?
Ответ:
С такими большими проектам, сказать честно, не сталкивался. Мои самые крупные проекты доходили где-то до 20 человеко-лет. А самый крупный, с которым вообще встречался, будучи хоть как-то около менеджмента – примерно 50 человеко-лет.
Поэтому, вполне возможно, мое видение будет не совсем верным. И я буду крайне благодарен коллегам, у кого был опыт работы с такими проектами, кто сможет дополнить, подтвердить или опровергнуть мое мнение.
Я вижу 4 основных нюанса, которые есть в управлении реально большими проектами:
1. Больший уровень абстракции. В таком проекте с такой большой командой ПМ уже очень поверхностно погружается в детали, управляет проектом на очень высоком уровне. Очень многое здесь будет даже из стратегии. Поэтому всякие адаптированные модели и подходы здесь уже не нужны, и на сцену выходят инструменты классического проектного управления. Вот прям самого-самого классического. Следить за планами, проектными артефактами, собирать данные, вносить изменения. Из материалов здесь помогут как раз книжки по этому самому классическому проектному управлению: PMBOOK, Лич – Вовремя и в рамках бюджета, Беркун – Искусство управления IT-проектами и т д. Их очень много разных
2. Большая команда и сложность ее управления – порождает внутреннюю иерархию и структуру, опять же управление становится менее оперативным и более стратегическим, роль трансформируется в менеджера менеджеров. Это, в первую очередь, трансформация mind-set-а, поэтому одними книгами не закрыться, нужна практика и опыт. Но из того, что точно поможет, можно полистать книжки по операционному менеджменту (их очень много разных), про управление через метрики и показатели (например, Брукс – Метрики для управления IT-услугами, Демин, Исайченко – Управление услугами на основе измерений), книги по стратегическому управлению и про менеджмент через коучинг и т п подходы (например, Уитмор – Внутренняя сила лидера)
3. Еще больший объем неопределенностей. А стало быть, всяких буферов, итераций и т д. Здесь снова работают инструменты классического проектного управления, не знаю, что еще можно сюда добавить
4. Большая часть ежедневной операционки – разрешение конфликтов и синхронизация. Потому что, как писал выше, у вас уже сложная структура команды внутри, они сами делают результат, нужно только направлять и немного разграничивать, чтобы не стукались друг с другом лбами и не толкались локтями. Здесь также операционный менеджмент, классические подходы к управлению. И, наверное, можно добавить конфликтологию и переговоры (Орлов – Конструктивная конфронтация, Кеннеди – Договориться можно обо всем, Фишер – Гарвардский метод переговоров и т д)
С моей колокольни выглядит как-то так 🙂
Надеюсь, получилось ответить на вопрос.
P.S. Форма для ваших вопросов и кейсов тут https://forms.gle/aBX5PgU1CLU4FDPP8
Пишите, а я сделаю разбор. Анонимно или нет, как пожелаете.
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
❤2👍1
МОДЕЛЬ БЕРНА
Продолжаем разбирать инструменты аудита команды.
Многие слышали про Эрика Берна и его трансакционный анализ. Знаменитые состояния “Я родитель”, “Я взрослый”, “Я ребенок”, взаимодействия этих состояний. А книга про это “Игры, в которые играют люди” является, наверное, одной из mast have для прочтения каждого руководителя.
Но помимо этой книги, есть у него еще одна, не менее прекрасная: “Лидер и группа”, в которой он очень просто описывает модель командного взаимодействия. Вот ее давайте и разберем. Модель, не книгу 🙂
Если по-простому, любая команда представляет собой некоторый набор кругов влияния. Чаще всего их 2. Первый круг – внешний. Он отделяет команду от остального мира. Второй круг – внутренний. Он отделяет лидера (или группу лидеров) от остальной команды. В больших-пребольших группах уровней вложенности этой матрешки может быть гораздо больше. Но в командах уровня проекта/отдела/компании, зачастую, только 2.
Сила границ кругов влияния определяется самоидентификацией “своих” в команде. Чем выше сплоченность внутри, тем сложнее эту границу преодолеть. Именно поэтому в хорошо сработанные команды всегда тяжело влиться новичку.
И именно от этого же зависит, а будет ли шторминг по Такману при приходе кого-то нового в команду. Если сплоченность высокая, то роли поделены и зафиксированы, новичок сможет получить только то, что дадут, и шторминга не будет. Если же сплоченность низкая, то любой, кто грязными сапогами врывается через границу вовнутрь команды, сразу же возбуждает в ней процесс бурления. И как итог – штормит.
Обратная сторона медали этой сплоченности – прозрачность. Круговая порука. Как у мушкетеров: “Один за всех и все за одного!”. Сплоченная команда будет воспринимать любое вмешательство извне (даже просто запрос статуса работ) как угрозу, и будет защищать свои границы. И чтобы получить правдивую информацию придется сильно постараться.
Но самое интересное – это внутренний круг. Точнее сказать, по каким правилам и законам можно его пересекать и попадать в группу лидеров. Зачастую этот фактор – лакмусовая бумажка состояния команды.
Где-то попасть в лидеры довольно просто: делай работу хорошо, приноси инициативы, тебя заметят. Где-то очень и очень сложно, особенно при таком, тоталитарном руководителе. Там надо выиграть какую-то “битву” с боссом, или дождаться, пока “Акелло промахнется”.
Здесь все зависит от этого самого лидера (или лидеров) и его стиля управления. Во многом, от его уверенности в себе. А еще от легитимности его положения. От кучи факторов, в общем, все это зависит.
И если все эти факторы разобрать, то перед вами четкая и понятная картинка, кто он, этот самый лидер, и как с ним надо взаимодействовать. А отсюда и какая культура сложилась в команде, какие подходы считаются нормой, а за какие вас мигом выпихнут за самый внешний круг.
Вот такая вот модель.
Итого надо определить:
1. Кто в каком круге находится
2. “Толщину” границ этих кругов
3. Правила пересечения границ
Это даст вам хорошее понимание, что за команда перед вами и как с ней работать.
Продолжаем разбирать инструменты аудита команды.
Многие слышали про Эрика Берна и его трансакционный анализ. Знаменитые состояния “Я родитель”, “Я взрослый”, “Я ребенок”, взаимодействия этих состояний. А книга про это “Игры, в которые играют люди” является, наверное, одной из mast have для прочтения каждого руководителя.
Но помимо этой книги, есть у него еще одна, не менее прекрасная: “Лидер и группа”, в которой он очень просто описывает модель командного взаимодействия. Вот ее давайте и разберем. Модель, не книгу 🙂
Если по-простому, любая команда представляет собой некоторый набор кругов влияния. Чаще всего их 2. Первый круг – внешний. Он отделяет команду от остального мира. Второй круг – внутренний. Он отделяет лидера (или группу лидеров) от остальной команды. В больших-пребольших группах уровней вложенности этой матрешки может быть гораздо больше. Но в командах уровня проекта/отдела/компании, зачастую, только 2.
Сила границ кругов влияния определяется самоидентификацией “своих” в команде. Чем выше сплоченность внутри, тем сложнее эту границу преодолеть. Именно поэтому в хорошо сработанные команды всегда тяжело влиться новичку.
И именно от этого же зависит, а будет ли шторминг по Такману при приходе кого-то нового в команду. Если сплоченность высокая, то роли поделены и зафиксированы, новичок сможет получить только то, что дадут, и шторминга не будет. Если же сплоченность низкая, то любой, кто грязными сапогами врывается через границу вовнутрь команды, сразу же возбуждает в ней процесс бурления. И как итог – штормит.
Обратная сторона медали этой сплоченности – прозрачность. Круговая порука. Как у мушкетеров: “Один за всех и все за одного!”. Сплоченная команда будет воспринимать любое вмешательство извне (даже просто запрос статуса работ) как угрозу, и будет защищать свои границы. И чтобы получить правдивую информацию придется сильно постараться.
Но самое интересное – это внутренний круг. Точнее сказать, по каким правилам и законам можно его пересекать и попадать в группу лидеров. Зачастую этот фактор – лакмусовая бумажка состояния команды.
Где-то попасть в лидеры довольно просто: делай работу хорошо, приноси инициативы, тебя заметят. Где-то очень и очень сложно, особенно при таком, тоталитарном руководителе. Там надо выиграть какую-то “битву” с боссом, или дождаться, пока “Акелло промахнется”.
Здесь все зависит от этого самого лидера (или лидеров) и его стиля управления. Во многом, от его уверенности в себе. А еще от легитимности его положения. От кучи факторов, в общем, все это зависит.
И если все эти факторы разобрать, то перед вами четкая и понятная картинка, кто он, этот самый лидер, и как с ним надо взаимодействовать. А отсюда и какая культура сложилась в команде, какие подходы считаются нормой, а за какие вас мигом выпихнут за самый внешний круг.
Вот такая вот модель.
Итого надо определить:
1. Кто в каком круге находится
2. “Толщину” границ этих кругов
3. Правила пересечения границ
Это даст вам хорошее понимание, что за команда перед вами и как с ней работать.
👍9
Всем привет!
Написал небольшую статью про офферы (для руководителей) - почему к ним надо относиться, как к продаже, как построить встречу, как выглядит правильная структура оффера, как делать офферы, которые будут принимать.
Не очень давно делал по этой теме вебинар. Теперь вот текстовая версия, на почитать https://habr.com/ru/articles/734094/
Написал небольшую статью про офферы (для руководителей) - почему к ним надо относиться, как к продаже, как построить встречу, как выглядит правильная структура оффера, как делать офферы, которые будут принимать.
Не очень давно делал по этой теме вебинар. Теперь вот текстовая версия, на почитать https://habr.com/ru/articles/734094/
Хабр
Про оффер: нормально делай – нормально будет
Многие руководители (если не сказать большинство) делают офферы плохо. Бездарно. Потом удивляются, что силы-время-деньги на найм потрачены, а офферы не принимаются. А некоторые умудряются даже...
👍6
Настало время для новостей!
Мы запускаем новый курс на платформе OTUS для Delivery Manager-ов (с одноименным названием). Курс для руководителей среднего звена, между тимлидом/ПМом и CTO.
Курс был разработан мной и опытными Delivery Manager-ами, а также ребятами - экспертами из продуктового и проектного менеджмента. Они же будут и тренерами. Классная команда с разнообразным профессиональным опытом.
В эту пятницу, 12 мая, в 20.00 мск проведу первый открытый урок, чтобы рассказать про курс, про наше понимание роли Delivery Manager-а. Обсудим, куда можно дальше развиваться тимлиду и какие навыки для этого надо прокачивать.
Приглашаю поучаствовать! Регистрируйтесь и подключайтесь https://otus.pw/E6O8/
Мы запускаем новый курс на платформе OTUS для Delivery Manager-ов (с одноименным названием). Курс для руководителей среднего звена, между тимлидом/ПМом и CTO.
Курс был разработан мной и опытными Delivery Manager-ами, а также ребятами - экспертами из продуктового и проектного менеджмента. Они же будут и тренерами. Классная команда с разнообразным профессиональным опытом.
В эту пятницу, 12 мая, в 20.00 мск проведу первый открытый урок, чтобы рассказать про курс, про наше понимание роли Delivery Manager-а. Обсудим, куда можно дальше развиваться тимлиду и какие навыки для этого надо прокачивать.
Приглашаю поучаствовать! Регистрируйтесь и подключайтесь https://otus.pw/E6O8/
otus.ru
Курс «Delivery Manager»: обучение онлайн - ОТУС
Образовательный онлайн-курс Деливери Менеджер (Delivery Manager) для опытных специалистов, станьте главным связующим звеном между бизнесом и разработкой. Delivery-менеджер выстраивает процесс доставки IT продукта до конечного пользователя, от идеи до выхода…
👍5
МОДЕЛЬ ГЕРЧИКОВА
Пожалуй, самая излюбленная HR-ами модель мотивации. Обходит даже пирамиду Маслоу. Простая, как валенок. И эффективная также. Но есть нюансы, как говорится.
Начну с истории. Жил был крупный заказчик, которому мы делали крупный проект. Ну для нас крупный, кто-то улыбнется, конечно) Порядка 20+ человек команда, внутри 4-5 подкоманд. Хороший такой проект, флагманский.
И вот однажды они решили нарушить все уставы delivery-процесса, и задеплоили в пятницу вечером. А это Америка. Их пятница вечером это наше раннее-раннее утро субботы. Карма их мигом настигла, и выяснилось, что залили они какаху, а не релиз. И нужно было срочно все допиливать и исправлять. Там был какой-то важный апдейт по требованию законодательства, поэтому просто откатить все взад было не вариант. Откатить-то откатили, но и исправлять тоже надо было. А времени – до понедельника.
Ранним утром субботы с нами связываются наши американские боссы и просят вывести команду в выходные. Делать нечего, идем вызванивать команду. Поделили с тимлидом и деливери-менеджером людей, чтобы быстрее обзвонить, и погнали сообщать сотрудникам приятные новости.
Звоню первому. Предлагаю нормальную оплату выходных. Соглашается.
Звоню второму. Говорю, что компания и проект в опасности, родина не забудет и все такое. Соглашается.
Звоню третьему. Говорю, что мне надо от него 4 пофиксенных бага к понедельнику, выбор способов и времени работы оставляю за ним. Соглашается.
Звоню четвертому. Говорю, что есть шикарная возможность поковыряться в чужих модулях проекта, правда только в выходные. Соглашается.
Звоню пятому. Говорю все вышеперечисленное в разной последовательности. Отказывается.
Как вы понимаете, все эти 5 сотрудников демонстрируют соответствующие типы мотивации по Модели Герчикова: инструментальная, патриотическая, хозяйская, профессиональная, избегательная. И конечно пример я сильно упростил, для наглядности. Почему упростил? А вот тут как раз тот самый нюанс.
На самом деле второй уточнял у меня условия по оплате. Третий спрашивал, кто еще из команды участвует и как компания отблагодарит. Четвертый сказал, что не сможет уделить все 2 дня, но готов оговорить объем работы и оплату.
Иными словами, у всех у них был некоторый основной мотиватор, и несколько дополнительных. И вырожденных случаев почти никогда не бывает. Там всегда OR, а не XOR. Поэтому тип мотивации сотрудника – это, скорее, не чекбокс или радиобаттон, а что-то вроде колеса баланса или розы ветров (кому как больше нравится). И если вы хотите повлиять на мотивацию, то обеспечьте основной мотиватор (это как гигиенический фактор), и дальше добавляйте мотиваторов дополнительных. Чаще всего, именно за счет дополнительных мотиваторов чаша весов сотрудника склоняется в сторону вашего предложения.
Пожалуй, самая излюбленная HR-ами модель мотивации. Обходит даже пирамиду Маслоу. Простая, как валенок. И эффективная также. Но есть нюансы, как говорится.
Начну с истории. Жил был крупный заказчик, которому мы делали крупный проект. Ну для нас крупный, кто-то улыбнется, конечно) Порядка 20+ человек команда, внутри 4-5 подкоманд. Хороший такой проект, флагманский.
И вот однажды они решили нарушить все уставы delivery-процесса, и задеплоили в пятницу вечером. А это Америка. Их пятница вечером это наше раннее-раннее утро субботы. Карма их мигом настигла, и выяснилось, что залили они какаху, а не релиз. И нужно было срочно все допиливать и исправлять. Там был какой-то важный апдейт по требованию законодательства, поэтому просто откатить все взад было не вариант. Откатить-то откатили, но и исправлять тоже надо было. А времени – до понедельника.
Ранним утром субботы с нами связываются наши американские боссы и просят вывести команду в выходные. Делать нечего, идем вызванивать команду. Поделили с тимлидом и деливери-менеджером людей, чтобы быстрее обзвонить, и погнали сообщать сотрудникам приятные новости.
Звоню первому. Предлагаю нормальную оплату выходных. Соглашается.
Звоню второму. Говорю, что компания и проект в опасности, родина не забудет и все такое. Соглашается.
Звоню третьему. Говорю, что мне надо от него 4 пофиксенных бага к понедельнику, выбор способов и времени работы оставляю за ним. Соглашается.
Звоню четвертому. Говорю, что есть шикарная возможность поковыряться в чужих модулях проекта, правда только в выходные. Соглашается.
Звоню пятому. Говорю все вышеперечисленное в разной последовательности. Отказывается.
Как вы понимаете, все эти 5 сотрудников демонстрируют соответствующие типы мотивации по Модели Герчикова: инструментальная, патриотическая, хозяйская, профессиональная, избегательная. И конечно пример я сильно упростил, для наглядности. Почему упростил? А вот тут как раз тот самый нюанс.
На самом деле второй уточнял у меня условия по оплате. Третий спрашивал, кто еще из команды участвует и как компания отблагодарит. Четвертый сказал, что не сможет уделить все 2 дня, но готов оговорить объем работы и оплату.
Иными словами, у всех у них был некоторый основной мотиватор, и несколько дополнительных. И вырожденных случаев почти никогда не бывает. Там всегда OR, а не XOR. Поэтому тип мотивации сотрудника – это, скорее, не чекбокс или радиобаттон, а что-то вроде колеса баланса или розы ветров (кому как больше нравится). И если вы хотите повлиять на мотивацию, то обеспечьте основной мотиватор (это как гигиенический фактор), и дальше добавляйте мотиваторов дополнительных. Чаще всего, именно за счет дополнительных мотиваторов чаша весов сотрудника склоняется в сторону вашего предложения.
❤5👍2
ПРО ПЕРЕГОВОРЫ #4
Возрождаю забытый тредик. В продолжение предыдущих постов про переговоры:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
Итак, у нас есть цели и интересы сторон. Мы определили переговорные позиции. Даже разобрались, где слабости и смогли усилиться. Что дальше?
А дальше последний шаг в стратегическом этапе подготовки. Это сама стратегия 🙂
Что есть стратегия в переговорах? Если упростить, это некий базовый сценарий, без детализации, который будет неизменным. Почему неизменным? Потому что войдя в переговоры и начав их, вы уже сделаете несколько шагов. Таких, что сказать “ой не, давай назад, начнем сначала” уже не получится. Поэтому стратегии надо уделить достойное внимание.
Простой бытовой пример. Есть у вас сосед-чудак, который громко включил музыку. Вы идете к нему провести переговоры. Стратегий здесь может быть несколько:
1. Бить морду
2. Угрожать (силой, связями, законом)
3. Давить на соседские человеческие чувства (“ну мы же соседи, ну что мы не договоримся что ли”)
4. Давить на жалость (“дети спят”, “я со смены”, “собака пугается и воет”)
5. Договариваться (“давай щас тишина, а я после 6 свалю и врубай сколько хочешь, чтоб стекла тряслись”)
Ну и т д. Много вариантов стратегии.
И обратите внимание. Выбрав одну, изменить стратегию будет уже сложно или почти невозможно. Да, можно попробовать угрожать, а потом бить морду, если не получилось. Здесь прям исключение из правил, хорошо сработает. Можно давить на соседские чувства, если не получилось – давить на жалость, если не получилось – договариваться. Но с каждым таким “переобуванием” ваша переговорная позиция будет все менее и менее устойчивой, и победить будет сложно. Ну а вариант сначала бить морду, а потом давить на жалость совсем не прокатит. Поэтому над стратегией надо думать заранее.
Как выбрать правильную стратегию? Это я не знаю. Да и никто не знает. Это чисто креативное решение, как вести себя в каждой конкретной ситуации. Поэтому для конкретного кейса я могу нагенерить идей, а вот абстрактно – нет. Какого-то правила или модели я не знаю.
Но здесь важно вот что. Стратегию вы выбираете заранее и только 1 раз. А значит она должна учитывать все гипотезы и допущения, которые у вас появились на предыдущих этапах подготовки к переговорам. Ошибаться здесь нельзя, от этого зависит ход переговоров.
Но есть и хорошая новость! Иногда стратегию можно провалидировать. Придумать себе проверочный вопрос или действие, за которым последует безоговорочный выбор стратегии и дальнейшие переговоры по ней.
С тем же соседом. Позвонить в дверь и посмотреть на него. Если он шкаф – ну как уж тут бить морду. Придется давить на жалость. А перед тем как давить на жалость, можно спросить: “а вот у вас есть дети?”. Если скажет “да”, то вот вам и стратегия – давить на жалость через детей. Если скажет “нет”, то просто договариваться и все. Или еще задать пару проверочных вопросов. Только не увлекайтесь.
Но еще раз, проверить стратегию можно только в самом начале, пока вы ей не воспользовались. Дальше уже давите до конца по выбранному плану. Если победить не получается, выходите из переговоров и готовьтесь к новым, с другой стратегией.
Продолжение следует.
Возрождаю забытый тредик. В продолжение предыдущих постов про переговоры:
ПРО ПЕРЕГОВОРЫ #1
ПРО ПЕРЕГОВОРЫ #2
ПРО ПЕРЕГОВОРЫ #3
Итак, у нас есть цели и интересы сторон. Мы определили переговорные позиции. Даже разобрались, где слабости и смогли усилиться. Что дальше?
А дальше последний шаг в стратегическом этапе подготовки. Это сама стратегия 🙂
Что есть стратегия в переговорах? Если упростить, это некий базовый сценарий, без детализации, который будет неизменным. Почему неизменным? Потому что войдя в переговоры и начав их, вы уже сделаете несколько шагов. Таких, что сказать “ой не, давай назад, начнем сначала” уже не получится. Поэтому стратегии надо уделить достойное внимание.
Простой бытовой пример. Есть у вас сосед-чудак, который громко включил музыку. Вы идете к нему провести переговоры. Стратегий здесь может быть несколько:
1. Бить морду
2. Угрожать (силой, связями, законом)
3. Давить на соседские человеческие чувства (“ну мы же соседи, ну что мы не договоримся что ли”)
4. Давить на жалость (“дети спят”, “я со смены”, “собака пугается и воет”)
5. Договариваться (“давай щас тишина, а я после 6 свалю и врубай сколько хочешь, чтоб стекла тряслись”)
Ну и т д. Много вариантов стратегии.
И обратите внимание. Выбрав одну, изменить стратегию будет уже сложно или почти невозможно. Да, можно попробовать угрожать, а потом бить морду, если не получилось. Здесь прям исключение из правил, хорошо сработает. Можно давить на соседские чувства, если не получилось – давить на жалость, если не получилось – договариваться. Но с каждым таким “переобуванием” ваша переговорная позиция будет все менее и менее устойчивой, и победить будет сложно. Ну а вариант сначала бить морду, а потом давить на жалость совсем не прокатит. Поэтому над стратегией надо думать заранее.
Как выбрать правильную стратегию? Это я не знаю. Да и никто не знает. Это чисто креативное решение, как вести себя в каждой конкретной ситуации. Поэтому для конкретного кейса я могу нагенерить идей, а вот абстрактно – нет. Какого-то правила или модели я не знаю.
Но здесь важно вот что. Стратегию вы выбираете заранее и только 1 раз. А значит она должна учитывать все гипотезы и допущения, которые у вас появились на предыдущих этапах подготовки к переговорам. Ошибаться здесь нельзя, от этого зависит ход переговоров.
Но есть и хорошая новость! Иногда стратегию можно провалидировать. Придумать себе проверочный вопрос или действие, за которым последует безоговорочный выбор стратегии и дальнейшие переговоры по ней.
С тем же соседом. Позвонить в дверь и посмотреть на него. Если он шкаф – ну как уж тут бить морду. Придется давить на жалость. А перед тем как давить на жалость, можно спросить: “а вот у вас есть дети?”. Если скажет “да”, то вот вам и стратегия – давить на жалость через детей. Если скажет “нет”, то просто договариваться и все. Или еще задать пару проверочных вопросов. Только не увлекайтесь.
Но еще раз, проверить стратегию можно только в самом начале, пока вы ей не воспользовались. Дальше уже давите до конца по выбранному плану. Если победить не получается, выходите из переговоров и готовьтесь к новым, с другой стратегией.
Продолжение следует.
👍9
ДАЙДЖЕСТ ЗА ПОСЛЕДНИЕ 2 НЕДЕЛИ
Статья про стаффинг и распределение людей по проектам - наша история 21 года, эксперименты и подходы, которые сработали
Пост с примерами использования People Status - несколько реальных кейсов, где инструмент нам помогал
Ответ на вопрос про особенности управления большими проектами - мое скромное мнение, поскольку реально большими проектами я не управлял, не приходилось
Пост про модель Берна - границы, круги, влияние и вот это вот все
Статья про офферы - как их делать правильно, так, чтобы их принимали
Анонс нового курса Delivery Manager - курс на OTUSe, в разработке которого я принмал самое непосредственное участие
Пост про модель Герчикова - типы мотивации, особенности применения, OR или XOR
Пост про переговоры #4 - продолжение треда про то, как готовиться к переговорам
Также напоминаю про форму, через которую можно задать вопрос или прислать свой кейс, а я сделаю подробный разбор. Хотите - анонимно, хотите - нет
Статья про стаффинг и распределение людей по проектам - наша история 21 года, эксперименты и подходы, которые сработали
Пост с примерами использования People Status - несколько реальных кейсов, где инструмент нам помогал
Ответ на вопрос про особенности управления большими проектами - мое скромное мнение, поскольку реально большими проектами я не управлял, не приходилось
Пост про модель Берна - границы, круги, влияние и вот это вот все
Статья про офферы - как их делать правильно, так, чтобы их принимали
Анонс нового курса Delivery Manager - курс на OTUSe, в разработке которого я принмал самое непосредственное участие
Пост про модель Герчикова - типы мотивации, особенности применения, OR или XOR
Пост про переговоры #4 - продолжение треда про то, как готовиться к переговорам
Также напоминаю про форму, через которую можно задать вопрос или прислать свой кейс, а я сделаю подробный разбор. Хотите - анонимно, хотите - нет
Напоследок перед выходными!
Буду выступать с МК на Skolkovo Tech Week с темой “Тимлид – ключевое звено в изменении корпоративной культуры”. Ищите меня в потоке MANAGEMENT.
Как спикер, получил промокод PRAHT на скидку 20%, для активации переходите по ссылке https://techweek.moscow/ticket?utm_source=sm_spkr
Про мероприятие:
Что важно для современного предпринимателя?
Быть в курсе последних трендов на рынке, а также уметь собрать сильную команду.
Об этом и многом другом вы можете узнать на крупнейшей технологической конференции России - TECH WEEK 2023 @russiantechweek
Что там интересного:
• Тематические выступления по 12 потокам, выступления экспертов на актуальные темы и мастер классы;
• Нетворкинг - соберёте самые ценные контакты, найдёте партнеров и близких людей по духу, а еще можно тусануть на AfterParty;
• Практика - разберёте кейсы, сделаете задания, изучите предметно рабочие инструменты;
• Выставка актуальных решений для бизнеса в сфере технологий, инноваций и технологического сервиса.
Буду выступать с МК на Skolkovo Tech Week с темой “Тимлид – ключевое звено в изменении корпоративной культуры”. Ищите меня в потоке MANAGEMENT.
Как спикер, получил промокод PRAHT на скидку 20%, для активации переходите по ссылке https://techweek.moscow/ticket?utm_source=sm_spkr
Про мероприятие:
Что важно для современного предпринимателя?
Быть в курсе последних трендов на рынке, а также уметь собрать сильную команду.
Об этом и многом другом вы можете узнать на крупнейшей технологической конференции России - TECH WEEK 2023 @russiantechweek
Что там интересного:
• Тематические выступления по 12 потокам, выступления экспертов на актуальные темы и мастер классы;
• Нетворкинг - соберёте самые ценные контакты, найдёте партнеров и близких людей по духу, а еще можно тусануть на AfterParty;
• Практика - разберёте кейсы, сделаете задания, изучите предметно рабочие инструменты;
• Выставка актуальных решений для бизнеса в сфере технологий, инноваций и технологического сервиса.
👍6🔥3
Видео вчерашнего вебинара "Я тимлид. Что дальше?".
Там рассказывал про роль Delivery Manager-a и про курс, который запускаем.
https://youtu.be/088kMp_L8Ok
Там рассказывал про роль Delivery Manager-a и про курс, который запускаем.
https://youtu.be/088kMp_L8Ok
YouTube
Я тимлид. Что дальше? // Демо-занятие курса «Delivery Manager»
Роль тимлида сложная и интересная. Это первый шаг в менеджерском треке развития, но далеко не последний.
Какой шаг будет следующим? Иногда сразу CTO. Но чаще – это руководитель уже нескольких проектов. И, конечно же, нескольких команд. Роль, которая носит…
Какой шаг будет следующим? Иногда сразу CTO. Но чаще – это руководитель уже нескольких проектов. И, конечно же, нескольких команд. Роль, которая носит…
МОДЕЛЬ МАМОНТА
Продолжая тредик про инструменты аудита команды, хочу немного поговорить про общую цель. И один из инструментов для этого за авторством Стратоплана - модель Мамонта.
Идея инструмента простая. Команда будет лучше работать, эффективнее взаимодействовать и быстрее проходить все сложные кризисные этапы, если у них будет единая общая цель, в которую верят и которую разделяют все ее члены.
Возможно ли это? Ведь не зря есть разные модели мотивации, например. Очевидно, что все хотят чего-то своего и разного. Вот тут то нам и приходит на помощь Мамонт.
Есть некоторая команда, группа первобытных людей. И у них есть общая цель команды - завалить Мамонта. Мамонт - это еда, чтобы поесть. Это шкура, чтобы было тепло. Это кости, из которых можно делать оружие. Ну а кроме того, завалить мамонта - это же престиж, уважение в племени. Вот и получается, что цель вроде бы одна и общая, но каждый найдет в ней что-то для себя: голодный - еду, тщеславный - уважение, и т д.
Таким образом первая идея модели Мамонта - цель должна формулироваться вдохновляюще и не особенно конкретно, и должна легко декомпозироваться на составляющие, которые будут интересны каждому члену команды.
Например, целью может быть “вовремя сдать релиз”. Что это значит? Да кто бы знал) В том и прелесть, конкретные ключевые результаты превратят цель в проект, и мотивации конец. Поэтому нужен вектор и какой-то конкретный критерий, без лишней детализации. Например, когда в роадмапе поменяется статус на “Сделано”. А там, сколько багов должно остаться, какой уровень качества и т п вопросы - операционка, это не про вдохновение.
И опять же, в общей цели “вовремя сдать релиз” каждый найдет что-то свое. Кто-то премию, кто-то повышение, кто-то ощущение причастности к большому общему достижению, кто-то возможность больше не работать по выходным.
Ну а вторая идея модели - слона нужно есть по кусочкам. Нельзя просто взять и завалить мамонта. Сперва нужно собрать народ, раздать всем оружие. Потом найти мамонта, окружить его. Далее напасть и победить. Несколько шагов, которые прозрачно демонстрируют, что вы на верном пути, и мамонт вот-вот будет побежден.
Также и с релизом. Нужна декомпозиция, на майлстоуны, поставки, этапы процесса. Как угодно, но чтобы было понятно, что команда движется к цели, а не стоит на месте.
В такой форме общая командная цель будет работать правильно, и команда будет к ней двигаться сообща. И завалит в итоге своего “мамонта”.
Продолжая тредик про инструменты аудита команды, хочу немного поговорить про общую цель. И один из инструментов для этого за авторством Стратоплана - модель Мамонта.
Идея инструмента простая. Команда будет лучше работать, эффективнее взаимодействовать и быстрее проходить все сложные кризисные этапы, если у них будет единая общая цель, в которую верят и которую разделяют все ее члены.
Возможно ли это? Ведь не зря есть разные модели мотивации, например. Очевидно, что все хотят чего-то своего и разного. Вот тут то нам и приходит на помощь Мамонт.
Есть некоторая команда, группа первобытных людей. И у них есть общая цель команды - завалить Мамонта. Мамонт - это еда, чтобы поесть. Это шкура, чтобы было тепло. Это кости, из которых можно делать оружие. Ну а кроме того, завалить мамонта - это же престиж, уважение в племени. Вот и получается, что цель вроде бы одна и общая, но каждый найдет в ней что-то для себя: голодный - еду, тщеславный - уважение, и т д.
Таким образом первая идея модели Мамонта - цель должна формулироваться вдохновляюще и не особенно конкретно, и должна легко декомпозироваться на составляющие, которые будут интересны каждому члену команды.
Например, целью может быть “вовремя сдать релиз”. Что это значит? Да кто бы знал) В том и прелесть, конкретные ключевые результаты превратят цель в проект, и мотивации конец. Поэтому нужен вектор и какой-то конкретный критерий, без лишней детализации. Например, когда в роадмапе поменяется статус на “Сделано”. А там, сколько багов должно остаться, какой уровень качества и т п вопросы - операционка, это не про вдохновение.
И опять же, в общей цели “вовремя сдать релиз” каждый найдет что-то свое. Кто-то премию, кто-то повышение, кто-то ощущение причастности к большому общему достижению, кто-то возможность больше не работать по выходным.
Ну а вторая идея модели - слона нужно есть по кусочкам. Нельзя просто взять и завалить мамонта. Сперва нужно собрать народ, раздать всем оружие. Потом найти мамонта, окружить его. Далее напасть и победить. Несколько шагов, которые прозрачно демонстрируют, что вы на верном пути, и мамонт вот-вот будет побежден.
Также и с релизом. Нужна декомпозиция, на майлстоуны, поставки, этапы процесса. Как угодно, но чтобы было понятно, что команда движется к цели, а не стоит на месте.
В такой форме общая командная цель будет работать правильно, и команда будет к ней двигаться сообща. И завалит в итоге своего “мамонта”.
🔥5👍4
КАК РАЗВАЛИТЬ КОМАНДУ
Вот мы всегда с вами обсуждаем, как сделать правильно, как сделать хорошо. А сегодня хочу накидать наоборот, вредных советов. Ну а как их применять – уже решать вам.
Для того чтобы развалить, заруинить абсолютно любую команду не нужно сложных комбинаций и многоходовок. Достаточно методично выполнять несколько простых действий, которые под силу совершенно любому руководителю:
- Врать / недоговаривать – ни слова правды, только удобная и правильная информация
- Молчать, ничего не рассказывать – утаивать любые сведения, ставящие под угрозу спокойствие в коллективе
- Рассказывать, как все плохо – побольше и почаще, желательно с эмоциями и примерами
- Обещать и не выполнять – открыли коробочку с обещаниями, достали нужные, выдали, а как спросили за результат – снова открыли коробочку, достали новое обещание, выдали
- Включить гиперконтроль и микроменеджмент – кризис, не время для инициативностей и свободы, все это от лукавого
- Все изменения пропускать через людей – не зря же ваш менеджмент их придумывает, все должно сразу же докатываться до конечных исполнителей
- Снимать с себя любую ответственность – “а я чо, это все начальство куролесит” и все в таком роде
- Забить на сотрудников – да просто не тратить на них время, зачем
Конечно, в каждой шутке есть доля шутки. И на самом деле это не советы никакие, а типичные ошибки, которые начинают делать руководители в работе с командами. Особенно, когда ситуация начинает двигаться в сторону кризиса.
И прочитав их, я уверен, каждый подумал: “Да это же очевидно, блин!”. Очевидно, все так. Но люди снова и снова наступают на одни и те же грабли, хотя часто знают заранее, где они лежат.
Наверняка, список неполный. Накидайте своих идей вредных советов, чтобы мы обогатили вместе этот материал.
Погнали!
Вот мы всегда с вами обсуждаем, как сделать правильно, как сделать хорошо. А сегодня хочу накидать наоборот, вредных советов. Ну а как их применять – уже решать вам.
Для того чтобы развалить, заруинить абсолютно любую команду не нужно сложных комбинаций и многоходовок. Достаточно методично выполнять несколько простых действий, которые под силу совершенно любому руководителю:
- Врать / недоговаривать – ни слова правды, только удобная и правильная информация
- Молчать, ничего не рассказывать – утаивать любые сведения, ставящие под угрозу спокойствие в коллективе
- Рассказывать, как все плохо – побольше и почаще, желательно с эмоциями и примерами
- Обещать и не выполнять – открыли коробочку с обещаниями, достали нужные, выдали, а как спросили за результат – снова открыли коробочку, достали новое обещание, выдали
- Включить гиперконтроль и микроменеджмент – кризис, не время для инициативностей и свободы, все это от лукавого
- Все изменения пропускать через людей – не зря же ваш менеджмент их придумывает, все должно сразу же докатываться до конечных исполнителей
- Снимать с себя любую ответственность – “а я чо, это все начальство куролесит” и все в таком роде
- Забить на сотрудников – да просто не тратить на них время, зачем
Конечно, в каждой шутке есть доля шутки. И на самом деле это не советы никакие, а типичные ошибки, которые начинают делать руководители в работе с командами. Особенно, когда ситуация начинает двигаться в сторону кризиса.
И прочитав их, я уверен, каждый подумал: “Да это же очевидно, блин!”. Очевидно, все так. Но люди снова и снова наступают на одни и те же грабли, хотя часто знают заранее, где они лежат.
Наверняка, список неполный. Накидайте своих идей вредных советов, чтобы мы обогатили вместе этот материал.
Погнали!
👍3
ПРО УВОЛЬНЕНИЯ #1
Давайте сегодня поговорим о самой неприятной задаче менеджера – об увольнениях.
Увольнять сложно. И я не встречал людей, которые бы получали от этого процесса удовольствие или заряд энергии. Чаще всего, наоборот, требуется потом время, чтобы прийти в себя и вернуться к работе.
Почему так? Виной всему наш мозг и психика. Руководитель – он же для чего? Он про бизнес, достигать целей компании, добиваться результатов. И с этой точки зрения, любое увольнение – просто задача. Специфическая, но задача. Ни больше, ни меньше.
И все бы ничего, но мы люди. Все руководители! И ни одному человеку (если он здоров) не хочется причинять боль и страдания другому человеку. А увольнение для сотрудника – это то самое и есть, как минимум хороший такой выход из зоны комфорта. Поэтому вторая наша половина хочет избежать такой задачи всеми силами.
Вот и получается внутренняя шизофрения – внутри борются менеджер и человек. Кто победит?
Чаще всего, человек побеждает ровно столько, сколько может это делать. Все время пытаешься оправдать сотрудника, дать ему второй-третий-двадцатый шанс. Еще мое любимое – копаешься в себе и ищешь причину там. Вроде как “это не сотрудник делает фигню, а это я ему недостаточно качественно задачу разжевал”. Ну и т п.
А потом человек сдается. Либо когда уже “ну все, хватит это терпеть”, либо когда просто все попытки исчерпаны и менеджер внутри победил. И в этот самый момент наступает точка принятия решения – “все, увольняю”.
Но принять решение мало, надо еще и реализовать. Хотя, сказать по чести, сложнее решиться, нежели поговорить с сотрудником. Ну во всяком случае, про себя могу так сказать.
Чтобы победить этот внутренний конфликт менеджера и человека в своей голове, в определенный момент я придумал для себя некую мантру, которую с радостью всем рассказываю. Вдруг кому-то тоже подойдет.
“Принимать решение об увольнении нужно как менеджер, а реализовывать его – как человек”.
Иными словами, решение должно базироваться исключительно на интересах бизнеса. И все эмоциональные аспекты здесь нужно отключать. А уже потом, когда решение принято, нужно включить в себе человека, и сделать все так, чтобы ваш сотрудник не страдал и не печалился.
Во-первых, нормально и по-человечески с ним поговорить и все объяснить. Без казенщины и бюрократщины. Во-вторых, предложить помочь: рекомендации, контакты и т п. В-третьих, быть честным, не пытаться сэкономить навариться на этом. И в-четвертых, искренне поблагодарить его за работу и нормально попрощаться. Мир гораздо теснее, чем нам порой кажется.
Вот такой совет. Забирайте, надеюсь, пригодится!
А дальше расскажу, что может вам помочь с решением, и как потом подготовиться и провести разговор с сотрудником.
Давайте сегодня поговорим о самой неприятной задаче менеджера – об увольнениях.
Увольнять сложно. И я не встречал людей, которые бы получали от этого процесса удовольствие или заряд энергии. Чаще всего, наоборот, требуется потом время, чтобы прийти в себя и вернуться к работе.
Почему так? Виной всему наш мозг и психика. Руководитель – он же для чего? Он про бизнес, достигать целей компании, добиваться результатов. И с этой точки зрения, любое увольнение – просто задача. Специфическая, но задача. Ни больше, ни меньше.
И все бы ничего, но мы люди. Все руководители! И ни одному человеку (если он здоров) не хочется причинять боль и страдания другому человеку. А увольнение для сотрудника – это то самое и есть, как минимум хороший такой выход из зоны комфорта. Поэтому вторая наша половина хочет избежать такой задачи всеми силами.
Вот и получается внутренняя шизофрения – внутри борются менеджер и человек. Кто победит?
Чаще всего, человек побеждает ровно столько, сколько может это делать. Все время пытаешься оправдать сотрудника, дать ему второй-третий-двадцатый шанс. Еще мое любимое – копаешься в себе и ищешь причину там. Вроде как “это не сотрудник делает фигню, а это я ему недостаточно качественно задачу разжевал”. Ну и т п.
А потом человек сдается. Либо когда уже “ну все, хватит это терпеть”, либо когда просто все попытки исчерпаны и менеджер внутри победил. И в этот самый момент наступает точка принятия решения – “все, увольняю”.
Но принять решение мало, надо еще и реализовать. Хотя, сказать по чести, сложнее решиться, нежели поговорить с сотрудником. Ну во всяком случае, про себя могу так сказать.
Чтобы победить этот внутренний конфликт менеджера и человека в своей голове, в определенный момент я придумал для себя некую мантру, которую с радостью всем рассказываю. Вдруг кому-то тоже подойдет.
“Принимать решение об увольнении нужно как менеджер, а реализовывать его – как человек”.
Иными словами, решение должно базироваться исключительно на интересах бизнеса. И все эмоциональные аспекты здесь нужно отключать. А уже потом, когда решение принято, нужно включить в себе человека, и сделать все так, чтобы ваш сотрудник не страдал и не печалился.
Во-первых, нормально и по-человечески с ним поговорить и все объяснить. Без казенщины и бюрократщины. Во-вторых, предложить помочь: рекомендации, контакты и т п. В-третьих, быть честным, не пытаться сэкономить навариться на этом. И в-четвертых, искренне поблагодарить его за работу и нормально попрощаться. Мир гораздо теснее, чем нам порой кажется.
Вот такой совет. Забирайте, надеюсь, пригодится!
А дальше расскажу, что может вам помочь с решением, и как потом подготовиться и провести разговор с сотрудником.
👍18
Немного похвастаюсь :)
На этой неделе провел небольшой корпоративный тренинг про НАСТАВНИЧЕСТВО. Компания активно растет, много найма, и потому для них тема актуальна. Наставничество становится важнейшим инструментом онбординга сотрудников, а значит и неким базисом для дальнейшего развития самой компании.
Курс состоял из 3 занятий:
1. Роль наставника - обсудили функции и задачи наставника, его компетенции, варианты, как эти самые компетенции развивать, ребята сформировали свою собственную карту компетенций
2. Инструменты наставника - разобрали основные инструменты в работе наставника: обратная связь, целеполагание, коучинг, 1/1, а также потренировались в их применении
3. Сложные кейсы и ситуации - чисто практический воркшоп, отрабатывали различные нестандартные ситуации, которые могут возникать в работе наставника: подопечный плохо работает, не сходимся характерами и т п
Получилось живо и интересно. Если верить отзывам, то ребята считают также)
Курс обкатали, замечания все учтем. И, надеюсь, повторим!
На этой неделе провел небольшой корпоративный тренинг про НАСТАВНИЧЕСТВО. Компания активно растет, много найма, и потому для них тема актуальна. Наставничество становится важнейшим инструментом онбординга сотрудников, а значит и неким базисом для дальнейшего развития самой компании.
Курс состоял из 3 занятий:
1. Роль наставника - обсудили функции и задачи наставника, его компетенции, варианты, как эти самые компетенции развивать, ребята сформировали свою собственную карту компетенций
2. Инструменты наставника - разобрали основные инструменты в работе наставника: обратная связь, целеполагание, коучинг, 1/1, а также потренировались в их применении
3. Сложные кейсы и ситуации - чисто практический воркшоп, отрабатывали различные нестандартные ситуации, которые могут возникать в работе наставника: подопечный плохо работает, не сходимся характерами и т п
Получилось живо и интересно. Если верить отзывам, то ребята считают также)
Курс обкатали, замечания все учтем. И, надеюсь, повторим!
👍10