Возможно вы слышали такой термин, как силос, силосное мышление или силосная башня.

Впервые с этим термином я познакомился, когда изучал философию DevOps. Более менее адекватное определение этому термину я нашел по этой ссылке. А ещё есть классный перевод статьи про 12 анти-паттернов DevOps, в которой как раз упоминается про силосную башню (в 4-м анти-паттерне).

На самом деле этот термин характерен не только для DevOps. Создавая всё больше силосов на пути всего жизненного цикла разработки (SDLC) мы замедляем T2M, понижаем вовлеченность, убиваем интерес, блокируем рост, и делаем ещё кучу всего страшного.

#article #link #thought

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

Этот инструмент отлично дополняет работу со стратегическим планированием и обогащает его внешним контекстом.

После прослушивания теоретической части про этот инструмент, мы перешли к практике. Нас (60+ руководителей разного уровня, от TeamLead'ов до CIO из абсолютно разных компаний) разделили на группы по 3-5 человек. Задача группы была провести PEST анализ и определить "что будет влиять на IT отрасль в следующие 10 лет".

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

Вот что у нас получилось.

Political Factors:
Геополитическая напряженность между крупнейшими странами мира

Economic Factors:
Рецессия в США и глобальный экономический кризис

Social Factors:
Миграция и безработица

Technological Factors:
Распространение искусственного интеллекта

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

#picture #link #thought

Хочу рассказать вам про инструмент под названием "Матрица доверия и прозрачности".

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

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

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

Подробнее про этот инструмент можно почитать в статье от Александра Орлова из компании Стратоплан.

#picture #article #thought

Недавно узнал про Закон Галла.

"Любая работоспособная сложная система - результат развития простой системы, которая до этого работала" (с) Джон Галл

Сразу вспомнил про мой первый заход в Notion, когда я с первых дней собрал там кучу различных процессов, баз данных, автоматизаций, индикаторов и кучу всего ещё, а в итоге не использовал бОльшую часть из них :) Пришлось откатиться к началу и наращивать сложность постепенно и по необходимости.

P.S. Мы оказывается про этот закон делали сторис в нашем приложении :)

#thought #link

Многие слышали про SMART. Это метод постановки целей, который позволяет не забыть о важных для этого процесса аспектах.

• S - Specific - конкретная
• M - Measurable - измеримая
• A - Achievable - достижимая
• R - Relevant - значимая
• T - Time-bound - ограниченная во времени

Но мало кто знает, что у этого метода есть расширение - SMARTER.

Две последние буквы описывают не столько саму цель, сколько то, как с ней работают дальше.

• E - Evaluated - получившая оценку
• R - Reviewed - пересматриваемая и корректируемая

На самом деле буквы в этих аббревиатурах трактуют как попало, кардинально меняя смысл :)

Вообще я не понимаю почему в википедии в альтернативы SMART’у приписывают GROW. Но про GROW и коучинг мы ещё поговорим в будущем.

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

#picture #link #thought

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

На самом деле существует ещё и другая сторона - директивный коучинг. И целый спектр техник между ними :)

#picture #thought

«Я-высказывание» - одна из техник эмоционального интеллекта, которая позволяет сделать так, чтобы вас услышали и поняли. Ну или хотя бы увеличит шанс этого :)

Если коротко, то:
• Убираем все обвинения
• Начинаем с я/мне/меня
• Говорим только про себя, свои чувства, эмоции и мысли

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

#link #thought

«Учить-Лечить-Мочить» - фраза, практика, подход, который структурировал для меня работу с сотрудником в контексте его личного перформанса.

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

Тем не менее данный подход мне очень понравился и я до сих пор его использую.

Попробую коротко его описать:
• Учить - это про адаптацию и адекватную постановку задач
• Лечить - это про понимание проблемы, корректировку поведения и обратную связь
• Мочить - это уже про применение каких то кардинальных мер для решения проблемы с перформансом сотрудника

Онбордим сотрудника. Ставим задачу. Помогаем ему.

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

Не помогло? Решаем вопрос административными инструментами. Ротация, увольнение и тому подобное.

#thought

Кто ничего не записывает и держит в голове кучу информации? У кого перегружена голова от задач, которые нужно сделать?
Если у вас, то вам точно нужно почитать книги Максима Дорофеева.

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

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

Практика очень простая:
• Берем набор слов, который позволит достать из головы то, что забылось и осело тяжелым грузом. Их можно взять тут, или тут
• Берем листик и ручку (или чистую страницу в google-doc, или в Notion)
• Идем по этим словам и вспоминаем "а не хотели ли вы сделать что-то, связанно с увиденным словом?"
• Вспомнили? Записываем!

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

Я сам очень сильно кайфую от этого упражнения. Я конечно, как и многие, никогда не выполнял на 100% всё то, что выгрузил из головы с помощью этого упражнения. Но точно всегда что-то вспоминается и идёт в работу.

#link #thought

Делегирование - процесс передачи части функций руководителя другим сотрудникам.

Хочу рассказать про пару моделей, которые помогут прокачать свой скил делегирования.

5 уровней делегирования - постепенная передача ответственности.

Вот эти уровни:
1. Руководитель говорит что и как делать
2. Руководитель прислушивается к идеям и предложениям сотрудника/команды, но решение принимает сам
3. Сотрудник/команда работает самостоятельно, руководитель пассивно контролирует и иногда корректирует
4. Сотрудник/команда работает полностью автономно и информирует руководителя о своих решения. А руководитель оценивает решения задним числом
5. Полное делегирование

7 уровней делегирования (смотри картинку) - аналогичная модель, но с бОльшим количеством более интересных шагов.

В свое время эти модели помогли мне структурировать и опроцессить работу с делегированием.

#picture #link #thought

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

И я не исключение. У меня тоже были похожие ощущения.

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

В основе всего лежит концепция «присваивания себе своих же достижений».

Вот то, что мне помогло и продолжает помогать:
• Менторство и наставничество. Очень круто передавать свои знания и помогать другим людям. Но самое крутое, когда твои менти потом возвращаются к тебе со словами благодарности. А ещё круче, когда они рассказывают про свои победы, которых им получилось добиться после наших с ними менторских сессий.
• Валидация результатов твоей работы. Простой доклад о результатах проекта, в котором ты принимал ключевое участие, это то самое присваивание результата своей работы. Проще говоря - все увидели какую работу ты проделал. А если ещё респектанули тебе и сказали спасибо, то это вообще огонь.
• Регулярно писать свои достижения. Например садиться в конце каждого месяца или квартала и выписывать то, чего ты достиг за это время и чему научился.
• У меня в Notion каждая задача и проект имеют скрытое поле-чекбокс Achievement. В конце плюс-минус каждого месяца я выбираю все задачи и проекты, у которых это поле пустое. Дальше просто читаю их название, их содержимое, вспоминаю как много и круто я в них вложился и какого результата добился. И проставляю галочку в чекбоксе.

Уверен, что это далеко не всё, что можно сделать, но это то, что мне точно помогает.

А ещё есть простенький тест на синдром самозванца :)

#link #thought

Teamlead Roadmap - самая популярная карта компетенций TeamLead’а.

Teamlead Good Reads - канал с полезным чтивом для TeamLead’ов.

Teamlead Bootcamp - чат, в котором можно обсудить две ссылки выше и вообще всё, что касается TeamLead’ства.

#link #telegram

Регулярно, проводя собесы TeamLead’ов, вижу очень разные понимания Канбан-метода.

Самый частый ответ останавливается на фразе «это доска с карточками по статусам».

Кто-то говорит про «WIP лимиты». Иногда с упоминанием теории ограничений и узких горлышек.

Реже я слышу про Pull модель работы и отличия от Push модели.

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

Очень не многие имеют опыт работы с метриками процессов.

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

Ещё можно подушнить и сказать, что часто Канбан-метод называют методологией или фреймворком, коими он не является. Или упомянуть частые фразы типа «внедряем Канбан» или «работаем по Канбан», что по факту некорректно. Обо всём этом классно говорит Алексей Жеглов фразой «в Канбане нет ‘в Канбане’».

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

Крайне рекомендую почитать официальный Kanban Guide, чтобы актуализировать свои знания и лучше понимать что это за зверь.

Также в Канбан-методе есть ещё куча всего интересного. Например классы обслуживания и концепция «Cost of delay» или модель зрелости, она же Kanban Maturity Model.

Если вы хотите впервые попробовать Канбан-метод на практике, то крайне советую начать с инструмента STATIK (или с его упрощенной версии STATIK A3).

Если вы хотите почитать книгу про Канбан-метод, то рекомендую книгу «Kanban from the inside» от Майка Барроуза (есть на русском).

А если вы хотите пройти какое-нибудь обучение, то рекомендую идти на курсы Kanban System Design (KSD) и Kanban System Improvement (KSI). Русские аккредитованные Канбан тренеры (AKT) могут менять названия курсов в связи с ситуацией в стране. Самые яркие представители оных - Алексей Пименов и Артур Нек, которые вместе работают в компании Neogenda.

#link #thought

Хочу рассказать про достаточно хайповую модель о групповой динамике и стадиях развития группы - Модель Брюса Такмана, или просто Модель Такмана.

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

Ещё редко рисуют, но часто упоминают ещё одну стадию - расставание или распад команды.

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

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

Часто ещё встречал, что к стадиям этой модели дорисовывают какие-то средне-статистические временные интервалы (например по 1-3 месяца на стадию). Но мне кажется, что всегда всё очень сильно зависит от конкретных людей и лидера.

#picture #link #thought

Мы внутри компании строим прозрачный процесс для перехода в TeamLead'а и в связи с этим я хочу поделиться с вами статьей Is Management Right for Me?

Сначала автор предлагает закрыть базовые вопросы:
• Ты strong performer? Если нет, то о карьерном росте задумываться пока рано и стоит закрепиться на своей текущей позиции и показать хороший результат
• Ты готов к большей зоне ответственности? Если ответ "нет", то тебе пока рано в менеджмент. Если ответ "не знаю", то попробуй взять на себя ответственность в какой-то активности, которая больше и круче твоих повседневных задач

Затем нужно ответить себе на два вопроса:
• Нравится ли тебе помогать другим людям раскрывать их потенциал? Если ответ "нет", то менеджмент точно не для тебя. Если ответ "не знаю", то попробуй менторство и наставничество
• Готов ли ты делать всё, что потребуется, для создания крутой команды? Давать неудобную обратную связь, быть эмоционально стабильным, увольнять людей если придётся?

Если на оба вопроса ответ «да», то тебе определенно стоит попробовать себя в менеджменте.

Я лично согласен со всеми советами и выводами автора и сам прошел такой-же путь:
• Сначала набирался экспертизы, читал и пробовал всё подряд и искал то, что нравится и что интересно
• Потом начал брать больше ответственности и делать более масштабные задачи и проекты
• Затем я попробовал менторство и наставничество
• И уже после этого я стал управлять командами

#article #thought

Бывало у вас когда-нибудь такое, что вы подходите к человеку со сложным вопросом, задаёте ему его, а потом не дожидаясь его ответа говорите что-то вроде «ааа, точно, я понял», разворачиваетесь и уходите?

А знаете ли вы почему на всех IT конференциях постоянно раздают резиновых уточек?

Всему виной Метод утёнка или Rubber duck debugging.

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

#picture #link

Что-то многовато у нас разных типов вопросов. Давайте вспомним самые основные.

Закрытые вопросы
Вопросы, на которые можно ответить «да/нет», «хорошо/плохо» или например каким то числом.

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

Пример - «Считаешь ли ты этот подход уместным?»

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

Такие вопросы хороши во многих областях (собеседования и интервью, менторство и коучинг, и так далее).

Пример - «Почему тебе нравится этот подход?»

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

Обычно такие вопросы начинаются со слов «Допустим», «Представьте» или «Если бы».

Пример - «Если бы у тебя был неограниченный бюджет как бы ты применял этот подход?»

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

Пример - «Как бы Middle SDE применял этот подход?»

#thought

Уверен, что многие так или иначе сталкивались с понятием «смысл жизни».

Кто-то относит попытки копания в этом направлении к кризису среднего возраста.

Кто-то говорит фразы вроде «у самурая нет цели, есть только путь».

А кто-то придерживается позиции «живем одним днем» или YOLO.

В связи с этим хочу поделиться с вами понятием «смысл жизни по-японски» или Икигай.

Это философия, которая помогает находить удовлетворение, радость и осознанность во всех делах каждый день.

Мне очень нравится сама идея этой философии и особенно нравится визуализация (см. картинку). В своё время она натолкнула меня на ряд полезных мыслей и помогла сфокусироваться.

#picture #link #thought

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

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

Будучи TeamLead’ом я использовал подход «задача проигрыш - задача выигрыш». Идея в том, чтобы балансировать количество интересных и не интересных задач по всем членам команды и не допускать того, чтобы один сотрудник работал всегда с самыми крутыми и интересными задачами, а другой всегда делал самую душную, рутинную и скучную работу.

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

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

P.S. Важно, что под «балансировать» я ни в коем случае не имею ввиду то, что задачи должен персонально раздавать руководитель. Сыгранная команда сама может решить кто и что будет делать дальше. Руководитель тут может наблюдать за ситуацией, замечать дисбаланс, а дальше персонально работать с сотрудниками.

#thought

Недавно с одним из коллег на 1-2-1 общались за стили лидерства и я решил закрепить их постом в блоге.

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

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

Также существует термин "нативный стиль лидерства", который у каждого свой и который включается в тяжелых и стрессовых ситуациях.

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

#picture #link #thought

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

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

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

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

Ближе познакомиться с этой методологией вам помогут книги Элияху Голдратта - "Цель", "Цель 2", "Цель 3" и "Критическая цепь".
А узнать о том, как эта методология может применяться в IT, вам поможет книга "Проект Феникс".

К моему стыду я ещё не прочитал книги "Цель 2" и "Цель 3", но за остальные могу сказать, что для получения максимальной пользы книги стоит читать именно в том порядке, в котором я их перечислил - "Цель", "Критическая цепь" и уже потом "Проект Феникс".

#picture #link #book #thought