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

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

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

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

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

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

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

Если на встрече подразумевалась ваша роль того самого “талисмана”, то она прекрасно пройдет и без вас. А по итогу вы увидите, до чего все договорились, сможете вмешаться, если вдруг что-то не то. А на самый сложный случай у вас будет под рукой запись, которую можно отсмотреть вечерком на скорости 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
Пишите туда свои вопросы/кейсы, а я сделаю разбор. Форма анонимная, но можно подписаться.

КАК СКАЗАТЬ “НЕТ”

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

А сказать простое “нет” не можете. Почему так? Ну как почему. Есть же субординация. Он начальник, дает задачу, значит надо делать. Еще не хочется показаться каким-то нелояльным, мало ли что подумает руководитель про это. К тому же, предустановочки, куда ж без них: “челленджи развивают!”, “критикуешь – предлагай!” и т п вариации на тему.

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

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

Так как же быть? Как говорить “нет” без зазрения совести? И чтоб начальник не расстроился и не обиделся? Есть пара вариантов:

- Прямо в лоб – просто “нет” и все, без сглаживания углов, иногда так даже получается лучше всего
- “Да, если ...” – добавить условий, например, “сделаю, но если реализация будет за мной”, или “если дадите премию моим сотрудникам”, или еще чего
- Альтернативный вариант – предложите что-то другое, т е “я так делать не хочу, но знаю, как можно было бы решить эту проблему, предлагаю свой план”
- Отложенное “нет” – что-то из разряда “это не приоритет сейчас, давайте вернемся к этому вопросу завтра/через неделю/30 февраля/с восходом солнца на Западе/…”
- Пауза – похоже на предыдущее, но не кормить завтраками, а просто взять паузу, по типу “не готов сейчас что-либо сказать, дайте мне день на подумать”, и дальше реально возвращаетесь через день, подумав, с планом или безмолвным согласием

Наверняка, есть еще рецепты. Это то, что по опыту помогает и работает. Накидывайте свои в комменты!

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

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

Всем привет!

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

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

Делюсь с вами полезным каналом про HR и карьеру в IT и не только. Аня - HR директор с большим опытом управления талантами в продуктовых и ИТ компаниях, карьерный консультант и коуч.

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

Если вы планируете строить карьеру в IT читайте этот пост, а если сейчас в поиске в России или зарубежом , заходите в рубрику #впоиске и внедряйте формулу успешного поиска. Также Аня вместе со своим мужем, который построил карьеру от ИТ консультанта до CTO в крупной телеком компании, делится интересным в мире ИТ в рубрике #PROайти

Подписывайтесь и у вас появится личный карьерный наставник!

ТИПЫ ТИМЛИДОВ

В конце августа проводил небольшой вебинар для тимлидов на площадке РДТЕХ. И ребята нарезали несколько интересных видео оттуда, по узким, но востребованным вопросам.

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

https://youtu.be/-iMTfRtptOU

ПРО АУДИТ КОМАНД. СНОВА

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

https://youtu.be/mCkBfXz7GXo

Друзья, привет!

Я хочу немного трансформировать свой формат Вопросника. Запускаю Вопросник 2.0 - "Бесплатные консультации от "Седого директора".

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

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

Не буду вам втирать свои услуги ментора, или потом закидывать безликими рассылками) Если увидите в этом пользу, сами меня найдете, это не сложно. Ну а если смогу за 15 минут решить вашу проблему, буду только рад 🙂

Могу ответить не сразу, но отвечу обязательно каждому!

Пишите свои вопросы, всегда рад быть полезным! 🙂

Коллеги, сегодня хочу прям набросить)

Вопрос такой - как вы относитесь к концепции "бирюзовых организаций"? Бывает ли такое, какие бонусы дает, как этого добиться?

Я почему про них вспомнил. Думал, что хайп уже прошел с этой темой. Ан нет. Много разных материалов видел последнее время, притом нестарых. Значит свежа мысль, теплится еще идея в головах-то!

Поделюсь своим мнением на этот счет. Считаю всю идею утопической и нереальной. От слова, совсем.

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

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

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

Что думаете по этому поводу? Напишите в комментарии!

РЕФАКТОРИНГ VS ПРОЦЕССЫ – ЧТО БУДЕТ ПЕРВЫМ

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

Первым будет вопрос от Дмитрия Алина @raiserspb про приоритеты – с чего следует начинать: со сложного рефакторинга продукта или с построения процессов.

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

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

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

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

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

Для примера могу привести общие правила и фреймворки change management: сначала подготовка и “разморозка”, определение показателей для контроля и подтверждения результата, потом само изменение, а потом “заморозка”. Вот без разморозки бросаться в омут рефакторинга очень рискованно.

P.S. По словам Дмитрия, ответить на вопрос получилось 🙂