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

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

Видео вчерашнего открытого урока про командные роли в лицах. То же, что и в статье, только побольше и голосом 🙂

https://youtu.be/V5GpyviWtS0

Как тимлиду пройти испытательный срок? Успешно, имеется в виду)
Моя новая статья про это:

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

Друзья!

На следующей неделе буду в отпуске, так что писать ничего не буду. Буду отдыхать и обниматься с березками (что бы это ни значило).

Не теряйте! 🙂

Друзья, привет!
Я вернулся и готов снова делать для вас полезный контент 🙂

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

Сделал небольшой опрос по формату контента. Отметьте, пожалуйста, какой вариант хотелось бы видеть больше.

И напишите в комментарии вопросы или темы, про которые было бы интересно почитать. Все соберу и распишу 🙂

ХОТИТЕ УСПЕШНЫХ ИЗМЕНЕНИЙ – ДОГОВАРИВАЙТЕСЬ С ТИМЛИДАМИ

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

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

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

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

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

3. Тимлиды находятся на самом "контактном" уровне пирамиды. Если взглянуть на пирамиду операционного менеджмента (сверху вниз ТОПы, тактики, линейные руководители, сотрудники), то увидим тимлидов на уровне 3. А это значит, что они взаимодействую с уровнем 4 – сотрудники, уровнем 2 – мидл-менеджеры. И, конечно же, между собой. А потому их мнения легко и быстро облетают практически всю компанию, и могут значительно изменить изначальную идею преобразования, которую спускали ТОПы

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

Особенно эта тема актуальна для тех самых тактических мидл-менеджеров: delivery manager-ы, руководители разработки, engineering manager-ы. Потому что своими руками они уже практически ничего не делают, а основной и главный их ресурс – именно тимлиды.

К чему я все это, коллеги. Мы в OTUS запускаем второй поток курса Delivery Manager, старт планируем в конце сентября. А завтра в 20.00 мск проведу открытый урок этого курса, как раз по теме внедрения изменений через тимлидов. Как делать это правильно, и не добиться "восстания".

Регистрируйтесь и приходите! Будет интересно.

https://otus.ru/lessons/delivery_manager/#event-3288

ЛАЙФХАК “КАК ХОДИТЬ НЕ НА ВСЕ МИТИНГИ”

Жизнь руководителя – календарная боль. Отчаяние тайм-менеджера. Куча задач, коммуникаций. И очень много встреч/совещаний и т п таймкиллеров.

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

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

Как быть? Как фильтровать встречи? Как понять, куда точно надо идти, а куда – ну нафиг?

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

Нужно ответить организатору встречи “Я не приду, сделайте запись, чтоб я потом отсмотрел, и напишите короткий итог мне текстом”. И это работает невероятно круто!

Если на встрече подразумевалась ваша роль того самого “талисмана”, то она прекрасно пройдет и без вас. А по итогу вы увидите, до чего все договорились, сможете вмешаться, если вдруг что-то не то. А на самый сложный случай у вас будет под рукой запись, которую можно отсмотреть вечерком на скорости 2х или отслушать во время пробежки (ну есть и такие маньяки гиперконтроля).

Ну а если вам планировалась роль “главной скрипки”, то организатор вам это все объяснит, попросит переставить встречу. Ну в общем, без вас она тогда не состоится.

Как говорится, все гениальное просто. Попробуйте.

P.S. Наверняка и у вас есть какие-то лайфхаки решения календарных перипетий. Делитесь в комментах, как решаете подобные проблемы?

Видео вчерашнего эфира в OTUS. Говорили про роль Delivery Manager-а, философию изменений, роль тимлида в изменениях.

https://youtu.be/K4xnjqA_xn0

КАК ОПТИМИЗИРОВАТЬ ПРОЦЕССЫ

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

В деле оптимизации бизнес-процессов есть несколько подходов и инструментов, но суть у них сводится к одному – приведение к единой системе координат. И самая надежная система координат – деньги.

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

Берем продолжительность шага процесса и ЗП сотрудника (или сотрудников) которые в него вовлечены. Получаем стоимость каждого шага процесса для компании. Собрав все вместе, получаем общую стоимость бизнес-процесса. Часто на этом шаге становится уже не по себе)

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

Как оптимизировать процессы? От обратного. Берем самые дорогие шаги, смотрим как их упростить и сократить, пробуем, закрепляем.

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

В общем, одним постом и не расскажешь. А потому, хочу пригласить вас на открытый урок курса СОО, где мы, как раз, поразбираемся в вопросах оптимизации бизнес-процессов. Завтра, 6 сентября, в 20.00. А зарегистрироваться можно тут https://otus.ru/lessons/coo/#event-3283

Видео вчерашнего открытого урока "Тайное искусство оптимизации процессов".
Поговорили про БП, про методы и подходы к оптимизации, про роль СОО в этом.

https://youtu.be/5CaKNYqZf2k

Друзья!

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

Всем, кто будет на конференции вживую - приходите на доклад и пишите в личку @ilya_prakht, буду рад встретиться!

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

Срок ожидания прошел, поэтому делюсь теперь видео 🙂

https://youtu.be/gA47oZJnTrI?list=PLRdS-n5seLRpxYCLRdKdDJJdsy2PJPgib

СИЛЬНЫЙ УВАЖАЕТ ТОЛЬКО СИЛУ?

Есть мнение, что сильный уважает только силу. А технарь уважает только другого технаря. Так ли это? Во многом.

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

Отсюда, в том числе, некоторый флер отношения к менеджерам в IT (я как-то писал про это). Технари не видят пользы от их работы, и потому не очень понимают, зачем они тут вообще есть.

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

Какая? Например, повышение комфорта. Решение проблем сотрудников. Своего рода, “защита” от другого начальства. Должно формироваться ощущение, что с этим вот менеджером лучше, чем без него. И как только оно сформировалось – поздравляю, вы можете претендовать на какое-никакое лидерство в глазах технаря.

Вроде бы мысль простая. Но раз за разом наблюдаю, как менеджеры делают все наоборот, а потом удивляются, почему их не любят. Либо пытаются, что называется, “соответствовать” (пока в какой-нибудь беседе не воткнут куда не надо некоторое умное слово, перечеркивающее все это “соответствие” раз и навсегда). Либо начинают давить формальным авторитетом, типа “я тут босс, слушайтесь!”. Это работает, конечно. Но не в сторону уважения, увы.

Тема эта непростая и многогранная. И потому мы приготовили открытый урок курса Delivery Manager, где я постараюсь сформулировать, как же, все-таки, снискать уважение у технарей, если ты сам не из таких. Завтра в 20.00 мск. А зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-3289

Видео вчерашнего эфира про авторитет у технарей https://youtu.be/lGwYztIhvDo

SAFe, LESS, Scrum of Scrums – почему они все не работают?

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

Но есть у них у всех один серьезный недостаток под капотом. LeSS и Scrum of Scrums совсем жестко ограничены использованием Scrum. SAFe чуть мягче в этом плане, но все равно требует использования какого-то Agile-фреймворка внутри проектов. И не просто какого-то любого, а унифицированного, одинакового для всех проектов в портфеле.

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

А как быть аутсорсингу? Ведь там тоже есть портфели. А внутри будут разнородные и, часто, вообще не связанные между собой проекты. Да и не только аутсорсингу. Собрали в один портфель и отдали DMу пачку продуктов, и разбирайся теперь. А тут никакие LeSS-ы и SAFe уже не помогут.

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

Завтра, 19 сентября, 20.00 мск. Завершающий открытый урок перед стартом нового потока курса Delivery Manager. А зарегистрироваться можно тут https://otus.ru/lessons/delivery_manager/#event-3290

Приходите, поговорим за метрики 🙂

А тем временем, мы вплотную подобрались к старту нового курса COO в IT на площадке OTUS. 27 сентября будем начинать!

А завтра, 20 сентября, в 20.00 мск проведу завершающий открытый урок, где обсудим аспекты финансовой эффективности IT-шного производства, чтобы раз и навсегда разобраться, а генерирует ли ваш продакшн прибыль.

Ссылочка для регистрации вот https://otus.ru/lessons/coo/#event-3284

Видео вчерашнего эфира про портфельный Agile и про метрики

https://youtu.be/fW6w_fGPrjQ

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

https://youtu.be/N5a5u3JGDnI

ПРО ЗАНУДСТВО ВОК-ОВ

Не-не, мы не про японские макароны сейчас. Хочу поговорить про BOK-и – Body Of Knowledges.

Недавно добрался прочитать, наконец, DMBOK. Да, каюсь, много работал в Data Management и Data Governance, а всю целиком книжку, чтоб вот “от корки до корки”, так и не читал. Кусками все, отрывками. Теперь исправляюсь.

Так вот, основное впечатление – нудятина. Ну вот максимально скучно и неинтересно. Хотя тема не такая, тема очень интересная. Данные же! Это везде и всюду, очень про жизнь! Но написано вот как написано.

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

Сам по себе PMBOK породил целую кучу контента аля “разбор PMBOK понятным языком”. Да я даже сам такие делал. Для других BOK-ов тоже актуально, иначе тяжело.

И вот, мой вопрос – почему так то? Какое такое “чтобы что” заложено в подобной редакции? Фильтр на восприятие? Демонстрация интеллектуального превосходства? Тест на стойкость и смирение? Или если бы было легко и понятно написано, то слишком легко было бы и сертификацию пройти в соответствующих институтах?

Кто знает, кто знает… А вы как думаете? Читали всякие разные BOK-и? Понятно? Не нудно?

Друзья!
Хочу напомнить вам про форму https://forms.gle/aBX5PgU1CLU4FDPP8
Пишите туда свои вопросы/кейсы, а я сделаю разбор. Форма анонимная, но можно подписаться.