Я тут поучаствовал в одной коллаборации. Полезной, как по мне. Ребята собрали в общую папку ProБизнес несколько авторских каналов (именно авторских, это важно), где люди пишут про менеджмент (как я), про стратегию, про ведение бизнеса. Есть что почитать.
Посмотрите, вдруг и вам что-то будет полезно.
Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения
Подписывайтесь на папку ProБизнес и забирайте все, чем делятся коллеги. Можно подписаться на все каналы сразу или выбрать самые интересные для себя.
Посмотрите, вдруг и вам что-то будет полезно.
Что внутри?
✅ авторские экспертные каналы
✅ личный опыт, инсайты и кейсы
✅ свежие идеи и лайфхаки
✅ море пользы и вдохновения
Подписывайтесь на папку ProБизнес и забирайте все, чем делятся коллеги. Можно подписаться на все каналы сразу или выбрать самые интересные для себя.
👍5🔥2🤮2❤1👎1🤬1
И еще один анонс!
Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".
Поговорим об инструментах управления тимлидами и роли DM во всем этом.
Присоединяйтесь
Уже завтра, 26 апреля, в 20.00 мск проведу открытый урок курса Delivery Manager в OTUS "Слон на нитке – реально ли управлять тимлидами и как это делать?".
Поговорим об инструментах управления тимлидами и роли DM во всем этом.
Присоединяйтесь
otus.ru
Курс «Delivery Manager»: обучение онлайн - ОТУС
Образовательный онлайн-курс Деливери Менеджер (Delivery Manager) для опытных специалистов, станьте главным связующим звеном между бизнесом и разработкой. Delivery-менеджер выстраивает процесс доставки IT продукта до конечного пользователя, от идеи до выхода…
👍5🔥1
КАК ПОДРУЖИТЬ DISCOVERY И DELIVERY
Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?
Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.
Проработали требования плохо – Delivery делает не то, потом приходится долго и муторно переделывать. Проработали очень подробно – Delivery счастливо, но зато и времени уходит непростительно много. А если нам нужно быстро протестировать, скажем, пачку гипотез, то это совсем непростительная роскошь.
Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.
Конечно, с точки зрения организационного проектирования в этом есть логика. У соседних подразделений должны быть конфликтующие показатели, чтобы создавался этот самый конфликт интересов, и они могли решать проблемы и делать оптимальный результат. Но такие идеи, как видно, иногда стреляют в ноги. И иногда, сразу в две.
Как быть? Как по мне, нужно сделать 2 вещи:
1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься
2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI
Такой подход, на самом деле, можно использовать для любого конфликта интересов. Как организационного, между разными подразделениями, так и для личного, между конкретными сотрудниками.
Ну например, ссорятся все время Вася с Петей, когда Вася делает пулреквест, а Петя потом его на ревью заваливает некритичными замечаниями. Если отсыпать Пети мотивации на достижение хорошего Lead Time Васей, то он перестанет придираться по мелочам, а будет выделять только реальные и критичные проблемы. А если закрепить это все четкой инструкцией, то такая схема обречена на успех.
Или зависают разработчик и QA на тестировании. Один постоянно сажает мелкие баги, а второй старается как можно больше таких найти, вплоть до пиксельперфектов, до которых никому нет дела. Ну такой вот ему KPI придумали, чем больше багов, тем лучше работа. Добавляем обоим общую мотивацию на сдачу релиза вовремя, регламентируем правила заведения дефектов – и проблема уходит.
Что скажете? Согласны с такой идеей? Какие еще есть варианты?
Конфликт интересов Discovery и Delivery – тема классическая и распространенная. Круче и чаще только конфликт “Продажи vs Производство”. Почему так?
Оба эти этапа, и Discovery, и Delivery, находятся последовательно в одной цепочке производства ценности. И, стало быть, очень сильно зависят друг от друга.
Проработали требования плохо – Delivery делает не то, потом приходится долго и муторно переделывать. Проработали очень подробно – Delivery счастливо, но зато и времени уходит непростительно много. А если нам нужно быстро протестировать, скажем, пачку гипотез, то это совсем непростительная роскошь.
Есть еще распространенная фишка, поставить каждому из них свой KPI на Lead Time. И тогда Discovery, лишь бы сделать что-нибудь, отдает побыстрее сырой материал в разработку, а Delivery, понимая все риски для своего Lead Time, долго и нудно не принимает требования и постоянно возвращает обратно в Discovery. Вот так и живем.
Конечно, с точки зрения организационного проектирования в этом есть логика. У соседних подразделений должны быть конфликтующие показатели, чтобы создавался этот самый конфликт интересов, и они могли решать проблемы и делать оптимальный результат. Но такие идеи, как видно, иногда стреляют в ноги. И иногда, сразу в две.
Как быть? Как по мне, нужно сделать 2 вещи:
1. Формализовать процесс передачи продукта из Discovery в Delivery. Какие-то чеклисты, четкие Definition of Done и т д. Чтобы однозначно было понятно, как должна выглядеть документация и проработка требований, чтобы разработка могла начать ими заниматься
2. Добавить командам какой-то общей мотивации. Внедрить общий KPI. Например, пусть вместе гонятся за единым T2M (Time To Market). Тогда не до ругачек на стыке, иначе премия у всех погорит. При этом, их собственные KPI на Lead Time тоже можно оставить, но мотивацию на них сделать ниже, чем на общий результат. Например, делить премию 30/70 за свои/общие KPI
Такой подход, на самом деле, можно использовать для любого конфликта интересов. Как организационного, между разными подразделениями, так и для личного, между конкретными сотрудниками.
Ну например, ссорятся все время Вася с Петей, когда Вася делает пулреквест, а Петя потом его на ревью заваливает некритичными замечаниями. Если отсыпать Пети мотивации на достижение хорошего Lead Time Васей, то он перестанет придираться по мелочам, а будет выделять только реальные и критичные проблемы. А если закрепить это все четкой инструкцией, то такая схема обречена на успех.
Или зависают разработчик и QA на тестировании. Один постоянно сажает мелкие баги, а второй старается как можно больше таких найти, вплоть до пиксельперфектов, до которых никому нет дела. Ну такой вот ему KPI придумали, чем больше багов, тем лучше работа. Добавляем обоим общую мотивацию на сдачу релиза вовремя, регламентируем правила заведения дефектов – и проблема уходит.
Что скажете? Согласны с такой идеей? Какие еще есть варианты?
👍20🔥5
JOB SECURITY
На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.
Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.
Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:
1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки
2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке
3. Соответствие вас, как профессионала, среднему портрету кандидата в вакансиях – и тут рынок все выравнивает, хоть и есть много уникальных позиций
Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.
Собрал тут несколько полезных советов, по мотивам своей рефлексии. Забирайте, кому пригодится, и добавляйте свои идеи в комментарии:
1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п
2. Ходить на собеседования. Даже если не собираетесь увольняться. Даже если вы менеджер. Вот тут много холиваров на этот счет, но моя простреленная нога говорит мне, что ходить надо
3. Нетворкаться и развивать свою сеть знакомств. И обязательно иметь там хороших рекрутеров, желательно специализирующихся на позициях вашего уровня. Как минимум, они владеют невероятным объемом нужной вам информации в моменте
4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить
5. Развивать себя. Не застревать в рамках той роли и той компании, где вы сейчас. Смотреть по сторонам и постоянно подтягивать то, что рынок просит
6. Иметь план Б. В любой момент “скрипач может оказаться не нужен”. И вы должны быть к такому готовы. И морально, и материально. Мой лучший рецепт здесь – диверсификация, всего и вся
7. Всегда помнить, что вы наемный сотрудник. В нашей культуре сильно развит патриотический тип мотивации. И занимая высокую позицию, порой, кажется, что вы “уже часть корабля”. Но это не так. Вы все также наемный сотрудник, которого взяли под конкретные задачи и конкретные условия. И это легко может поменяться, такова жизнь. Важно быть патриотом компании и проявлять лояльность к ней. Но не менее важно быть патриотом самого себя, и проявлять лояльность к самому себе. Вот мой факап был как раз тут
Это мой список. Субъективный, не всем подходящий. Но реально прожитый.
А вы пишите, что еще сюда можно добавить!
P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам 🙂 Но рекомендую!
На одном интервью меня спросили: “какой ваш главный факап, как руководителя?” Задумался. Если не отделять себя от компании в моменте, то есть что вспомнить. Не успели разогнать продажи к дедлайну. Не получилось продать правильную стратегию CEO. Не удержал важнейшего сотрудника. И т д и т п. У каждого менеджера есть толстый блокнот с факапами, такое “кладбище решений”. И чем толще блокнот, тем лучше будет менеджер, как по мне.
Но это все, что называется, “вжившись в роль”. А есть ли что-то, если отделить себя от конкретной компании? Как наемный менеджер, сам по себе. И тут я понял, что такое есть, и ответ для меня однозначный: не следил за Job Security.
Что такое этот ваш Job Security? Если упростить, то ваша уверенность, что лишившись конкретной текущей работы, вы все еще окажетесь нужны рынку. И у этого понятия есть несколько составляющих:
1. Количество похожих вакансий – для программистов это десятки тысяч, для тимлидов тысячи, для EM и DM это уже сотни, для СТО десятки
2. Среднерыночный уровень ЗП – вы классный на своем месте и вам часто готовы платить много, просто потому что вы классный на своем месте, а если место поменяется, то вы уже не так уж и нужны, поэтому начинают предлагать что-то средненькое на рынке
3. Соответствие вас, как профессионала, среднему портрету кандидата в вакансиях – и тут рынок все выравнивает, хоть и есть много уникальных позиций
Так вот, оглядываясь назад, понимаешь, что полезная штука этот Job Security. И надо за ним следить. Я вот не следил, последние лет 5 до прошлого года. Не смотрел вакансии, не ходил по собеседованиям, мало общался с ЛПРами. Сам много нанимал, уровень ЗП знал, потому что мы регулярно такую аналитику заказывали. Но на этом и все.
Собрал тут несколько полезных советов, по мотивам своей рефлексии. Забирайте, кому пригодится, и добавляйте свои идеи в комментарии:
1. Регулярно следить за вакансиями на вашу позицию. Чтобы понимать требования к кандидатам, уровень ЗП, тренды в найме и т п
2. Ходить на собеседования. Даже если не собираетесь увольняться. Даже если вы менеджер. Вот тут много холиваров на этот счет, но моя простреленная нога говорит мне, что ходить надо
3. Нетворкаться и развивать свою сеть знакомств. И обязательно иметь там хороших рекрутеров, желательно специализирующихся на позициях вашего уровня. Как минимум, они владеют невероятным объемом нужной вам информации в моменте
4. Развивать свой бренд. Не надо здесь упарываться, но 1-2 раза в год можно что-нибудь интересное рассказать. Отлично работает и для понимания, что нужно рынку, и для развития нетворкинга. Да и могут на собес куда-то пригласить
5. Развивать себя. Не застревать в рамках той роли и той компании, где вы сейчас. Смотреть по сторонам и постоянно подтягивать то, что рынок просит
6. Иметь план Б. В любой момент “скрипач может оказаться не нужен”. И вы должны быть к такому готовы. И морально, и материально. Мой лучший рецепт здесь – диверсификация, всего и вся
7. Всегда помнить, что вы наемный сотрудник. В нашей культуре сильно развит патриотический тип мотивации. И занимая высокую позицию, порой, кажется, что вы “уже часть корабля”. Но это не так. Вы все также наемный сотрудник, которого взяли под конкретные задачи и конкретные условия. И это легко может поменяться, такова жизнь. Важно быть патриотом компании и проявлять лояльность к ней. Но не менее важно быть патриотом самого себя, и проявлять лояльность к самому себе. Вот мой факап был как раз тут
Это мой список. Субъективный, не всем подходящий. Но реально прожитый.
А вы пишите, что еще сюда можно добавить!
P.S. А еще мы тут со Стратопланом запилили целую конфу про фейлы и факапы. 11 мая, в субботу. Я в этот раз не уместился, поэтому излил душу сюда вам 🙂 Но рекомендую!
👍80🔥19💯9❤4
“МОЛОТОК” В КОМАНДООБРАЗОВАНИИ
Часто провожу обучения и пишу посты по темам командообразования и аудита команд. Очень уж они мне нравятся. Потому что здесь, как нигде лучше, раскрывается многообразие всяких разных менеджерских инструментов. И можно действовать не по наитию или своему креативу, а, практически, “по методичке”. Да, инструменты в менеджменте вещь условная и абстрактная, нужно все это “приземлять”. Это бесспорно. Но в теме командообразования этих инструментов так много, что точно что-нибудь свое, да подберешь.
Буквально недавно мне попался инструмент, который по праву можно считать эдаким “молотком” в теме командообразования. Потому что он столь же прост, и столь же эффективен. И имя его – пирамида GRPI (картинку закину следом за постом).
В чем суть. В рамках командообразования нам нужно проработать 4 основных блока:
1. Цели – какие цели у команды, насколько они хорошо сформулированы, насколько откликаются у всех участников
2. Роли – здесь и компетенции команды, и командные роли, чего где не хватает и каков баланс
3. Процессы – основные процессы и правила, необходимые для нормальной работы команды, все ли на месте и все ли оптимальны
4. Межличностные отношения – насколько команда “сыграна”, какие есть малые группы внутри, кто с кем конфликтует
И вот получается такая пирамидка, из которой видно, что все держится, в первую очередь, на личных взаимоотношениях. На это все накладываются эффективные и правильные процессы. Далее роли. И вишенкой будет общая цель команды. Вот прям как в определении из википедии. Ну разве не гениально?
Если мы строим команду, то нужно двигаться сверху-вниз: сначала понимаем цель, потом определяем необходимые роли, потом придумываем процессы, как эти роли будут взаимодействовать, а потом уже подбираем правильных людей, чтобы они и в роли вписались, и не конфликтовали почем зря.
Да-да, здесь вы можете справедливо заметить, что редко удается построить команду с нуля, обычно работаем с тем, что есть, пытаемся чинить и дорабатывать. Все так. Но и в этом случае, стоит сначала построить для себя идеальную картинку TO BE, по такому алгоритму, а потом уже пытаться к ней прийти через изменения.
Если мы делаем аудит и разбираемся в проблемах команды, то двигаемся наоборот, снизу-вверх: большинство проблем находятся в поле отношений между конкретными людьми, далее мониторим процессы, после ищем изъяны в ролевых моделях, и уже в конце проверяем цель команды, реже всего корень проблем здесь.
И это классный фреймворк, который можно расширять другими инструментами:
1. Цели – от Мамонта до OKR-ов
2. Роли – от матрицы и карты компетенций до ролей Белбина или Бенна/Шитса
3. Процессы – от базовых 1/1 до сложных процессов Delivery с Аджайлами и Скрамами
4. Межличностные отношения – от теории малых групп до границ Берна
Расширяй - не хочу! Приземляй – не хочу! Ну просто сказка, а не инструмент!
Пользуйтесь!
А картинка следом, как и обещал.
Часто провожу обучения и пишу посты по темам командообразования и аудита команд. Очень уж они мне нравятся. Потому что здесь, как нигде лучше, раскрывается многообразие всяких разных менеджерских инструментов. И можно действовать не по наитию или своему креативу, а, практически, “по методичке”. Да, инструменты в менеджменте вещь условная и абстрактная, нужно все это “приземлять”. Это бесспорно. Но в теме командообразования этих инструментов так много, что точно что-нибудь свое, да подберешь.
Буквально недавно мне попался инструмент, который по праву можно считать эдаким “молотком” в теме командообразования. Потому что он столь же прост, и столь же эффективен. И имя его – пирамида GRPI (картинку закину следом за постом).
В чем суть. В рамках командообразования нам нужно проработать 4 основных блока:
1. Цели – какие цели у команды, насколько они хорошо сформулированы, насколько откликаются у всех участников
2. Роли – здесь и компетенции команды, и командные роли, чего где не хватает и каков баланс
3. Процессы – основные процессы и правила, необходимые для нормальной работы команды, все ли на месте и все ли оптимальны
4. Межличностные отношения – насколько команда “сыграна”, какие есть малые группы внутри, кто с кем конфликтует
И вот получается такая пирамидка, из которой видно, что все держится, в первую очередь, на личных взаимоотношениях. На это все накладываются эффективные и правильные процессы. Далее роли. И вишенкой будет общая цель команды. Вот прям как в определении из википедии. Ну разве не гениально?
Если мы строим команду, то нужно двигаться сверху-вниз: сначала понимаем цель, потом определяем необходимые роли, потом придумываем процессы, как эти роли будут взаимодействовать, а потом уже подбираем правильных людей, чтобы они и в роли вписались, и не конфликтовали почем зря.
Да-да, здесь вы можете справедливо заметить, что редко удается построить команду с нуля, обычно работаем с тем, что есть, пытаемся чинить и дорабатывать. Все так. Но и в этом случае, стоит сначала построить для себя идеальную картинку TO BE, по такому алгоритму, а потом уже пытаться к ней прийти через изменения.
Если мы делаем аудит и разбираемся в проблемах команды, то двигаемся наоборот, снизу-вверх: большинство проблем находятся в поле отношений между конкретными людьми, далее мониторим процессы, после ищем изъяны в ролевых моделях, и уже в конце проверяем цель команды, реже всего корень проблем здесь.
И это классный фреймворк, который можно расширять другими инструментами:
1. Цели – от Мамонта до OKR-ов
2. Роли – от матрицы и карты компетенций до ролей Белбина или Бенна/Шитса
3. Процессы – от базовых 1/1 до сложных процессов Delivery с Аджайлами и Скрамами
4. Межличностные отношения – от теории малых групп до границ Берна
Расширяй - не хочу! Приземляй – не хочу! Ну просто сказка, а не инструмент!
Пользуйтесь!
А картинка следом, как и обещал.
👍27🔥16❤1
Давненько ничего не писал, каюсь. Как-то с головой ушел в работу, не получается делать лонгриды. Но зато поднакопилось других полезных референсов, буду делиться!
На прошлой неделе заходил на Неформальный Стратоплан, пообсуждали проблемы руководителей отделов и СТО. Поотвечали на вопросы вместе с Сашей Орловым и Андреем Крыловым.
О чем успели поговорить:
- Как себя вести, если хочется карьерного роста, но никак не повышают
- Что делать, если у компании нет ресурсов, т е количество проектов увеличивается, а людей - нет
- Как получить от руководства реальные ожидания от своей позиции, если они их никак не сформируют
- Как решить проблему коммуникации со стейкхолдерами, когда излишне закрываешься на внутренних задача отдела
- Куда вкладывать ресурсы, чтобы расти, как СТО
- Как поступить, если на работе все хорошо, но категорически скучно
- Где брать базу/систему по менеджменту, когда учишься через свой опыт и шишки
- Что делать тимлиду, который раньше был инженером в команде, а теперь должен ей управлять и постоянно натыкается на дерзкого и токсичного сотрудника, не принимающего его начало
https://youtu.be/Jq_-HL0fFKc
На прошлой неделе заходил на Неформальный Стратоплан, пообсуждали проблемы руководителей отделов и СТО. Поотвечали на вопросы вместе с Сашей Орловым и Андреем Крыловым.
О чем успели поговорить:
- Как себя вести, если хочется карьерного роста, но никак не повышают
- Что делать, если у компании нет ресурсов, т е количество проектов увеличивается, а людей - нет
- Как получить от руководства реальные ожидания от своей позиции, если они их никак не сформируют
- Как решить проблему коммуникации со стейкхолдерами, когда излишне закрываешься на внутренних задача отдела
- Куда вкладывать ресурсы, чтобы расти, как СТО
- Как поступить, если на работе все хорошо, но категорически скучно
- Где брать базу/систему по менеджменту, когда учишься через свой опыт и шишки
- Что делать тимлиду, который раньше был инженером в команде, а теперь должен ей управлять и постоянно натыкается на дерзкого и токсичного сотрудника, не принимающего его начало
https://youtu.be/Jq_-HL0fFKc
YouTube
Подкаст | Самые распространенные проблемы технических директоров и руководителей отделов | Часть 3
В четверг, 6 июня, мы провели эфир про самые популярные вопросы, с которыми сталкиваются руководители на разных уровнях. От маленьких команд, до руководства большими компаниями.
Вот уже 4 года мы проводим вступительное интервью со всеми студентами Школы…
Вот уже 4 года мы проводим вступительное интервью со всеми студентами Школы…
👍13🔥5
А на этой неделе в предверии очередного запуска курса COO в OTUS провел открытый урок, где пообсуждали операционные стратегии и рассмотрели основные.
Были стратегии:
1. Снижение себестоимости
2. Повышение гибкости
3. Повышение качества
4. Сокращение времени
По каждой разобрали возможные варианты реализации, плюсы/минусы, применимость. Обзорно, но с понятными примерами.
https://youtu.be/8z1ChLwXuBA
Были стратегии:
1. Снижение себестоимости
2. Повышение гибкости
3. Повышение качества
4. Сокращение времени
По каждой разобрали возможные варианты реализации, плюсы/минусы, применимость. Обзорно, но с понятными примерами.
https://youtu.be/8z1ChLwXuBA
YouTube
Строим операционную стратегию. Шаг 1. Выбираем стратегию // «COO / Операционный директор в IT»
Какую операционную стратегию выбрать? Вопрос номер 1 для каждого операционного директора.
Стратегий много, стратегии разные. У каждой есть свои плюсы и минусы, у каждой есть свои условия применимости. А еще шаблонными стратегиями никого не удивишь, нужен…
Стратегий много, стратегии разные. У каждой есть свои плюсы и минусы, у каждой есть свои условия применимости. А еще шаблонными стратегиями никого не удивишь, нужен…
😁3👍2
Друзья!
На следующей неделе, 26 июня, приму участие очередной раз в конфренции Skolkovo TechWeek. На этот раз, будет практический мастер-класс про проектные метрики.
Организаторы, как обычно, дарят несколько промокодов на бесплатные билеты. И я готов ими поделиться с вами!
Пишите в комментарии, кому нужны билеты, отдам первым троим 🙂
На следующей неделе, 26 июня, приму участие очередной раз в конфренции Skolkovo TechWeek. На этот раз, будет практический мастер-класс про проектные метрики.
Организаторы, как обычно, дарят несколько промокодов на бесплатные билеты. И я готов ими поделиться с вами!
Пишите в комментарии, кому нужны билеты, отдам первым троим 🙂
ИЗОБРЕТАЯ ВЕЛОСИПЕД
Юху! Наконец-то лонгрид!
Сегодня хочется затронуть матрицу компетенций. А конкретно – ее базу. Что должно быть основанием для определения уровня / грейда сотрудника?
Хард-скиллы? Не уверен. Не счесть, сколько встречал специалистов, которые прекрасно владели теорией и даже неплохо писали код, но положиться на них в выполнении серьезной задачи было нельзя.
Софт-скиллы? Тоже непонятно. Наверное, для лида важнее те же коммуникации, чем для джуна. Ну а если мы сменим направление и поговорим, допустим, об аналитиках? Неужто джун аналитик не должен владеть этой компетенцией? Должен, без этого он работать не сможет. Получается грейды аналитиков и грейды разработчиков никак не коррелируют? Это странно.
Мне всегда нравилась идея, что базой для определения грейда должна быть ответственность. Уровень задач и проблем, которые сотрудник может решать. Условно, джун отвечает за задачу, мидл – за фичу, синьор – за эпик, лид – за весь проект и т д. Хорошая складная концепция.
А недавно наткнулся на интересную статью на Хабре и узнал про фреймворк SFIA. Да-да, такой вот я темный. Модели уже почти 50 лет, а я про нее даже не слышал. Но готов поспорить, большинство из вас тоже ничего о ней не знали. И это нормально. Не хватило как-то ей маркетинга, видимо.
Так вот, фреймворк предполагает 7 уровней, как раз таки, зрелости специалиста, которые подразумевают разные уровни ответственности:
1. Follow (следует) – следует инструкциям, делает простые задачи
2. Assist (помогает) – работает в команде, берет на себя ответственность за результат задачи
3. Apply (применяет) – работает в рамках установленных правил и системы, делает задачу от и до со всеми ограничениями
4. Enable (поддерживает) – делает работу сам и помогает другим, вносит существенный вклад в результаты команды
5. Ensure, advice (обеспечивает, консультирует) – обеспечивает управление и результаты всей команды, дает экспертные консультации
6. Initiate, influence (определяет политику, влияет) – принимает важные решения, формирует правила, руководит направлениями работ
7. Set strategy, inspire (определяет стратегию, вдохновляет) – все понятно из названия, отвечает за стратегию и будущее
И вот вся эта моделька как нельзя прекрасно ложится на мою идею про ответственность. Более того, много где в мире ее для этого и применяют 🙂
1. Follow (следует) – стажер или начинающий Junior
2. Assist (помогает) – хороший крепкий Junior
3. Apply (применяет) – настоящий Middle
4. Enable (поддерживает) – уже Senior
5. Ensure, advice (обеспечивает, консультирует) – TeamLead в чистом виде
6. Initiate, influence (определяет политику, влияет) – уровень тактического управления: HH, DM, TGM и много других названий этой позиции
7. Set strategy, inspire (определяет стратегию, вдохновляет) – это уже директор, стратег, CTO
Вот так я изобрел велосипед, о котором знали уже 50 лет) Но отрадно, что раз такая модель есть и широко применяется, значит моя идея с ответственностью, как базой для матрицы компетенций, вполне себе верная.
P.S. Подробнее можно почитать на официальном сайте SFIA и в статье, на которую я ссылаюсь. Там про инфобез, но идея общая, универсальная.
Юху! Наконец-то лонгрид!
Сегодня хочется затронуть матрицу компетенций. А конкретно – ее базу. Что должно быть основанием для определения уровня / грейда сотрудника?
Хард-скиллы? Не уверен. Не счесть, сколько встречал специалистов, которые прекрасно владели теорией и даже неплохо писали код, но положиться на них в выполнении серьезной задачи было нельзя.
Софт-скиллы? Тоже непонятно. Наверное, для лида важнее те же коммуникации, чем для джуна. Ну а если мы сменим направление и поговорим, допустим, об аналитиках? Неужто джун аналитик не должен владеть этой компетенцией? Должен, без этого он работать не сможет. Получается грейды аналитиков и грейды разработчиков никак не коррелируют? Это странно.
Мне всегда нравилась идея, что базой для определения грейда должна быть ответственность. Уровень задач и проблем, которые сотрудник может решать. Условно, джун отвечает за задачу, мидл – за фичу, синьор – за эпик, лид – за весь проект и т д. Хорошая складная концепция.
А недавно наткнулся на интересную статью на Хабре и узнал про фреймворк SFIA. Да-да, такой вот я темный. Модели уже почти 50 лет, а я про нее даже не слышал. Но готов поспорить, большинство из вас тоже ничего о ней не знали. И это нормально. Не хватило как-то ей маркетинга, видимо.
Так вот, фреймворк предполагает 7 уровней, как раз таки, зрелости специалиста, которые подразумевают разные уровни ответственности:
1. Follow (следует) – следует инструкциям, делает простые задачи
2. Assist (помогает) – работает в команде, берет на себя ответственность за результат задачи
3. Apply (применяет) – работает в рамках установленных правил и системы, делает задачу от и до со всеми ограничениями
4. Enable (поддерживает) – делает работу сам и помогает другим, вносит существенный вклад в результаты команды
5. Ensure, advice (обеспечивает, консультирует) – обеспечивает управление и результаты всей команды, дает экспертные консультации
6. Initiate, influence (определяет политику, влияет) – принимает важные решения, формирует правила, руководит направлениями работ
7. Set strategy, inspire (определяет стратегию, вдохновляет) – все понятно из названия, отвечает за стратегию и будущее
И вот вся эта моделька как нельзя прекрасно ложится на мою идею про ответственность. Более того, много где в мире ее для этого и применяют 🙂
1. Follow (следует) – стажер или начинающий Junior
2. Assist (помогает) – хороший крепкий Junior
3. Apply (применяет) – настоящий Middle
4. Enable (поддерживает) – уже Senior
5. Ensure, advice (обеспечивает, консультирует) – TeamLead в чистом виде
6. Initiate, influence (определяет политику, влияет) – уровень тактического управления: HH, DM, TGM и много других названий этой позиции
7. Set strategy, inspire (определяет стратегию, вдохновляет) – это уже директор, стратег, CTO
Вот так я изобрел велосипед, о котором знали уже 50 лет) Но отрадно, что раз такая модель есть и широко применяется, значит моя идея с ответственностью, как базой для матрицы компетенций, вполне себе верная.
P.S. Подробнее можно почитать на официальном сайте SFIA и в статье, на которую я ссылаюсь. Там про инфобез, но идея общая, универсальная.
🔥46👍18
РАНЬШЕ РАБОТАЛИ В ОДНОЙ КОМАНДЕ, А ТЕПЕРЬ Я НАЧАЛЬНИК, А ОН – ТОКСИЧНЫЙ БУНТАРЬ
Ситуация, с которой сталкивался каждый руководитель. Прямо боль любого менеджера. А причина проблемы, зачастую, вообще не в вас. Но вот решать ее, все равно, вам.
Именно такой ситуации хочу посвятить свой переговорный поединок в Университете Стратоплана. Приходите на мое занятие 16 июля в 11.00 мск. Обсудим природу такого поведения коллег, что нам под силу, чтобы исправить ситуацию. В формате кейса и групповых переговорных поединков.
Зарегистрироваться можно тут
В этот раз, Университет полностью посвящен теме “Конфликтология”. Потому что любая работа, на уровне инженера или СЕО, завязана на взаимодействиях с людьми. Уметь договариваться – необходимый навык, который влияет не только на уровень удовольствия от работы, но и на карьеру, бизнес, деньги.
Университет для вас, если:
— для вас переговоры — нервы и вырванное время
— ваше решение/мнение не принимают и всегда находят *но*
— вы часто недовольны итогами переговоров
Формат:
— живая 2-х недельная онлайн практика (+ немного теории, без воды и домашек)
— абсолютно бесплатное участие группами от 5 человек
— личный кабинет с пожизненным доступом к записям, если что-то упустили
Старт — 08 июля. Уже в следующий понедельник!
Ситуация, с которой сталкивался каждый руководитель. Прямо боль любого менеджера. А причина проблемы, зачастую, вообще не в вас. Но вот решать ее, все равно, вам.
Именно такой ситуации хочу посвятить свой переговорный поединок в Университете Стратоплана. Приходите на мое занятие 16 июля в 11.00 мск. Обсудим природу такого поведения коллег, что нам под силу, чтобы исправить ситуацию. В формате кейса и групповых переговорных поединков.
Зарегистрироваться можно тут
В этот раз, Университет полностью посвящен теме “Конфликтология”. Потому что любая работа, на уровне инженера или СЕО, завязана на взаимодействиях с людьми. Уметь договариваться – необходимый навык, который влияет не только на уровень удовольствия от работы, но и на карьеру, бизнес, деньги.
Университет для вас, если:
— для вас переговоры — нервы и вырванное время
— ваше решение/мнение не принимают и всегда находят *но*
— вы часто недовольны итогами переговоров
Формат:
— живая 2-х недельная онлайн практика (+ немного теории, без воды и домашек)
— абсолютно бесплатное участие группами от 5 человек
— личный кабинет с пожизненным доступом к записям, если что-то упустили
Старт — 08 июля. Уже в следующий понедельник!
Stratoplan-School
Такой страницы не существует — Stratoplan
Вы попали на несуществующую страницу. Возможно, она была удалена или перенесена.
👍12❤6🔥5👏2
И СНОВА ПРО МЕТРИКИ
По мотивам мастер-класса на Skolkovo TechWeek. Сам мастер-класс выдался, мягко говоря, не очень удачным. Но материал полезный, как по мне. Так что делюсь.
Метрик много, метрики разные. Но за какими точно надо следить? Вопрос сложный, так как итоговый набор метрик очень сильно зависит от процессов и методологий управления. Что влияет на принятие управленческих решений, то и надо контролировать.
Возьмем проект. Попробуйте жестко следить за бюджетами – получите падение качества и продолбанные сроки. Фокус на сроках – снова проблемы с качеством и теперь уже с бюджетами. Ставим во главу угла качество – получите, распишитесь: всевозможные превышения по всем направлениям.
Чтобы такого не происходило, за проектами нужно следить комплексно. Набор метрик должен быть сбалансированным, должен охватывать все основные области управления проектом.
Давно уже всюду пропагандирую фреймворк PROJECT, который, как раз, решает эту проблему. Расшифруем акроним:
P → People — команда проекта и ее состояние
R → Reliability — надежность, качество
O → Operations — операционные показатели
J → Job — состояние скоупа
E → Economy — финансовые показатели
C → Customer — удовлетворенность клиента
T → Timetable — расписание проекта
Если в каждой из этих 7 областей будет хотя бы по 1 метрике – проект под контролем. Вот такая идея.
На картинках следом несколько слайдов с доклада: с примером метрик, которые мы использовали у себя (и это работало!), с вариантами других метрик под каждую область внимания PROJECT, и пример, как это все в итоге собирается в светофор проектного статуса (опять же из реальной жизни).
Надеюсь, пригодится. А вопросы пишите в комментариях!
По мотивам мастер-класса на Skolkovo TechWeek. Сам мастер-класс выдался, мягко говоря, не очень удачным. Но материал полезный, как по мне. Так что делюсь.
Метрик много, метрики разные. Но за какими точно надо следить? Вопрос сложный, так как итоговый набор метрик очень сильно зависит от процессов и методологий управления. Что влияет на принятие управленческих решений, то и надо контролировать.
Возьмем проект. Попробуйте жестко следить за бюджетами – получите падение качества и продолбанные сроки. Фокус на сроках – снова проблемы с качеством и теперь уже с бюджетами. Ставим во главу угла качество – получите, распишитесь: всевозможные превышения по всем направлениям.
Чтобы такого не происходило, за проектами нужно следить комплексно. Набор метрик должен быть сбалансированным, должен охватывать все основные области управления проектом.
Давно уже всюду пропагандирую фреймворк PROJECT, который, как раз, решает эту проблему. Расшифруем акроним:
P → People — команда проекта и ее состояние
R → Reliability — надежность, качество
O → Operations — операционные показатели
J → Job — состояние скоупа
E → Economy — финансовые показатели
C → Customer — удовлетворенность клиента
T → Timetable — расписание проекта
Если в каждой из этих 7 областей будет хотя бы по 1 метрике – проект под контролем. Вот такая идея.
На картинках следом несколько слайдов с доклада: с примером метрик, которые мы использовали у себя (и это работало!), с вариантами других метрик под каждую область внимания PROJECT, и пример, как это все в итоге собирается в светофор проектного статуса (опять же из реальной жизни).
Надеюсь, пригодится. А вопросы пишите в комментариях!
👍20🔥2
Привет!
Вернулся из отпуска, и начну неделю с анонса.
На этой неделе, вот прямо сегодня, стартует еще один интересный и бесплатный проект Стратоплана Управленческий марафон.
20 дней, разбор 20 вопросов и ситуаций из жизни руководителя. 3 лонгрида и 2 коротких эфира каждую неделю, от экспертов и преподавателей школы.
Я сделаю там несколько лонгридов на темы:
- Хотелок у бизнеса много, а ресурсов не дают
- Как обсуждать повышение зарплаты/премии для сотрудников или себя самого
- Появился новый СТО, который раньше был разработчиком, интересуется только несколькими продуктами, экспертов не слушает, люди уходят. Оставаться или нет?
Ссылки на свои я попробую дублировать сюда. Но там будет много чего почитать и кроме. Так что, не проходите мимо :)
Вернулся из отпуска, и начну неделю с анонса.
На этой неделе, вот прямо сегодня, стартует еще один интересный и бесплатный проект Стратоплана Управленческий марафон.
20 дней, разбор 20 вопросов и ситуаций из жизни руководителя. 3 лонгрида и 2 коротких эфира каждую неделю, от экспертов и преподавателей школы.
Я сделаю там несколько лонгридов на темы:
- Хотелок у бизнеса много, а ресурсов не дают
- Как обсуждать повышение зарплаты/премии для сотрудников или себя самого
- Появился новый СТО, который раньше был разработчиком, интересуется только несколькими продуктами, экспертов не слушает, люди уходят. Оставаться или нет?
Ссылки на свои я попробую дублировать сюда. Но там будет много чего почитать и кроме. Так что, не проходите мимо :)
Stratoplan-School
Такой страницы не существует — Stratoplan
Вы попали на несуществующую страницу. Возможно, она была удалена или перенесена.
👍25❤7🔥4🫡1
ЧТО ДЕЛАТЬ, КОГДА У БИЗНЕСА МНОГО ХОТЕЛОК, А РЕСУРСОВ НЕ ДАЮТ
А вот и первый лонгрид, как и обещал.
Немного порассуждал о природе подобных проблем. О том, как вести себя в такой ситуации, чтобы и свою поляну отстоять, и саботажником у начальства не прослыть.
Пишите свои мысли в комментарии!
А вот и первый лонгрид, как и обещал.
Немного порассуждал о природе подобных проблем. О том, как вести себя в такой ситуации, чтобы и свою поляну отстоять, и саботажником у начальства не прослыть.
Пишите свои мысли в комментарии!
Telegraph
[3/20] Управленческий марафон. Что делать, когда у бизнеса много хотелок, а ресурсов не дают?
«Я хочу результаты! Но лишних ресурсов у нас нет, так что пользуйтесь тем, что имеете!» Такую фразу из уст своего CEO или руководителя наверняка слышал каждый менеджер. И чем выше вы в иерархической пирамиде, тем чаще такие задачи получаете. На связи Илья…
👍10❤5🔥3👎1
КАК ГОВОРИТЬ О ПОВЫШЕНИИ ЗП
А вот и второй лонгрид с марафона подлетел. На этот раз про деньги, денюжки, деньжули!
Попытался подсветить, что важно для руководителей, за что они готовы увеличивать ЗП, как это все понять и правильно попросить повышения. И для себя, и для своих сотрудников.
Делитесь идеями в комментариях!
А вот и второй лонгрид с марафона подлетел. На этот раз про деньги, денюжки, деньжули!
Попытался подсветить, что важно для руководителей, за что они готовы увеличивать ЗП, как это все понять и правильно попросить повышения. И для себя, и для своих сотрудников.
Делитесь идеями в комментариях!
Telegraph
[5/20] Управленческий марафон. Как говорить с бизнесом и руководителем о повышении ЗП себе и команде?
Нам всем сложно обсуждать вопросы денег. Будь то наша зарплата или зарплата наших сотрудников. Да даже премия по результатам проекта или квартала — везде сложности. Почему так? С вами Илья Прахт, СТО-консультант, опытный менеджер в IT, ментор и тренер Стратоплана.…
🔥11👍6👎2❤1
КОЛБАНЫЙ ЦИКЛ В РАЗВИТИИ
Всем привет!
Возвращаюсь после некоторого молчания 🙂 Было много работы, разные интересные проекты. Ну и накопилось приличное количество интересных кейсов, про которые буду теперь рассказывать!
Так что, погнали!
Буквально сегодня на корпоративном тренинге был вопрос: “Как реагировать, если ты человека развиваешь, а он ведет себя контрпродуктивно этому?” Ну например, качаете вы разработчика в тимлида, учите его ответственности, а он вовремя проблему вам не эскалирует и потом приунывает. Не чужую даже проблему, а свою собственную. Вместо того чтобы поставить встречу 1/1 и все зарешать, сидит на кухне, смешивая аккуратно горячую и холодной воду в кулере, и грустит о жизни своей.
Вопрос понятен. Нас же как учат? Пятилистник наставничества, надо пройти по шагам:
1. Рассказать
2. Показать, как надо
3. Сделать вместе
4. Посмотреть, как делает
5. Проверить результат
Двигаешься поступательно, от шага к шагу, даешь обратную связь, падаван учится.
А тут учишь, вкладываешься, он вроде даже понимает и делает на тестовом задании верно, а потом все равно не то. Еще раз цикл проходить?
Ответ – да. Только другой цикл – цикл Колба. Это же классный кейс, классный прецедент, на основе которого можно выровняться, дать качественную обратную связь (а не пустую на выдуманных котятах).
Что есть цикл Колба (основа основ обучения, особенно, взрослых людей):
1. Негативный опыт
2. Рефлексия
3. Объяснение
4. Применение и позитивный опыт
Вот тут надо помочь сотруднику отрефлексировать его негативный опыт (для начала вообще обрисовать, что он негативный, так-то), объяснить, как и почему надо, отправить за получением позитивного опыта. Когда-нибудь он вернется снова, и тут уже можно будет делать выводы.
Вернулся “со щитом” и исправил модель поведения – красавчик, обучаемый. Продолжаем упражнение! Вернулся “на щите” и снова накосячил – не красавчик, пересматриваем свои планы. Можно не сразу, допустим, 2 желтые карточки, потом уже красную. Или 3 желтых. Ну или 1, зависит от вашего терпения и желания.
Резюмируя: косяки сотрудников – основная движущая сила наставничества, если использовать их правильно. И они же качественная метрика обучаемости. Не в том плане, что ошибок быть не должно. Наоборот, должны быть. Иначе он ничего не делает. А в плане повторяемости косяков: есть повторяемость – есть вопросики.
Что думаете?
Всем привет!
Возвращаюсь после некоторого молчания 🙂 Было много работы, разные интересные проекты. Ну и накопилось приличное количество интересных кейсов, про которые буду теперь рассказывать!
Так что, погнали!
Буквально сегодня на корпоративном тренинге был вопрос: “Как реагировать, если ты человека развиваешь, а он ведет себя контрпродуктивно этому?” Ну например, качаете вы разработчика в тимлида, учите его ответственности, а он вовремя проблему вам не эскалирует и потом приунывает. Не чужую даже проблему, а свою собственную. Вместо того чтобы поставить встречу 1/1 и все зарешать, сидит на кухне, смешивая аккуратно горячую и холодной воду в кулере, и грустит о жизни своей.
Вопрос понятен. Нас же как учат? Пятилистник наставничества, надо пройти по шагам:
1. Рассказать
2. Показать, как надо
3. Сделать вместе
4. Посмотреть, как делает
5. Проверить результат
Двигаешься поступательно, от шага к шагу, даешь обратную связь, падаван учится.
А тут учишь, вкладываешься, он вроде даже понимает и делает на тестовом задании верно, а потом все равно не то. Еще раз цикл проходить?
Ответ – да. Только другой цикл – цикл Колба. Это же классный кейс, классный прецедент, на основе которого можно выровняться, дать качественную обратную связь (а не пустую на выдуманных котятах).
Что есть цикл Колба (основа основ обучения, особенно, взрослых людей):
1. Негативный опыт
2. Рефлексия
3. Объяснение
4. Применение и позитивный опыт
Вот тут надо помочь сотруднику отрефлексировать его негативный опыт (для начала вообще обрисовать, что он негативный, так-то), объяснить, как и почему надо, отправить за получением позитивного опыта. Когда-нибудь он вернется снова, и тут уже можно будет делать выводы.
Вернулся “со щитом” и исправил модель поведения – красавчик, обучаемый. Продолжаем упражнение! Вернулся “на щите” и снова накосячил – не красавчик, пересматриваем свои планы. Можно не сразу, допустим, 2 желтые карточки, потом уже красную. Или 3 желтых. Ну или 1, зависит от вашего терпения и желания.
Резюмируя: косяки сотрудников – основная движущая сила наставничества, если использовать их правильно. И они же качественная метрика обучаемости. Не в том плане, что ошибок быть не должно. Наоборот, должны быть. Иначе он ничего не делает. А в плане повторяемости косяков: есть повторяемость – есть вопросики.
Что думаете?
🔥25👍10❤2🤝1