Видео (+статья) про платформы, которым я хочу с вами поделиться, уже мелькнуло в подавляющем большинстве каналов, на которые я подписан :)

Поэтому не буду пытаться придумывать какие-то новые мысли, а просто поделюсь с вами ещё парочкой полезных видосов про платформы и платформенные команды:
• Applying Product Thinking to internal infrastructure
• Tips For Building Successful Platform Teams

#video #article

Изредка сталкиваюсь с тезисом "Agile, Kanban, Scrum и прочие эти ваши слова - это всё про IT. А мы то тут не разработкой занимаемся. Нам нужно что-то другое".
Слышал такие мысли как от людей "не из IT вообще", так и "из IT, но не из разработки (например DBA)".

Тот-же Джеф Сазерленд (автор Scrum) в своей книге "Scrum: The Art of Doing Twice the Work in Half the Tim" приводил несколько примеров того, как Scrum можно использовать в школе при обучении детей и при капитальном ремонте дома.

А Kanban вообще родом из бережливого производства Тойоты.

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

Также на тему хочу поделиться двумя докладами про то, как компания "HERE" ускоряла свои картогрофические процессы и как компания "Сибирский Гурман" училась работать по Scrum.

#thought #link #book #video

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

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

Самое плохое в этой истории было то, что такие мысли были не только у Individual Contributor'ов, но и у Manager'ов.

Пишу я всё это потому, что случайно вспомнил про исследование от McKinsey, которое мы использовали как один из аргументов в пользу того, что сотрудникам важно обучаться и развиваться в том числе (или даже в первую очередь) в рабочее время.

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

#article #picture #thought

Тут про наши успехи 4-5 летней давности в хакатонах статью написали. Приятно :)

Хакатоны - это круто. Такого уровня вовлеченности и потока редко можно испытать. А победы и ценные призы ещё сильнее мотивируют.

#article

Хочу поделиться упражнением на анализ мотивационных факторов. Я в своё время делал его не только сам, но и предлагал сделать своим сотрудникам, когда видел у них какую-то неопределенность и демотивированность.

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

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

PDF с детальным описанием упражнения приложу в комментах. А вот ссылка на Google Spreadsheet шаблон.

#thought #link

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

#video

Недавно размышлял на тему различных ролевых моделей и их применимости на практике в построении IT команд. Мои размышления пока не привели к чему-то конкретному и практичному, но ссылками на две ролевые модели, которые достаточно часто встречаются, я всё-же поделюсь.

- Роли по Адизесу + Тест (в нижней части страницы)
- Роли по Белбину + Тест (там нужно, чтобы в каждом блоке было по 10 баллов в сумме, чтобы можно было показать результат)

Оба теста бесплатные и сразу показывают результат.

P.S. В тред покидал ещё модели и ссылки на тесты.

#link

Эффект Даннинга-Крюгера - то, что мы достаточно часто вспоминаем, когда видим у сотрудника завышенную самооценку.

Например, это может проявляться в моменты, когда джун говорит, что он уже всё знает и что он сеньер. Или когда сеньер говорит, что достиг потолка и ему уже некуда развиваться.

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

#picture #link #thought

Очередное когнитивное искажение - Ошибка выжившего.

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

Осознавая когнитивные искажения, парадоксы и феномены можно задавать правильные вопросы, докапываться до сути, обходить провалы и чаще достигать успеха… или нет :)

#picture #link #thought

Достаточно часто приходится задавать вопрос «Чтобы что?». На SouthHub Camp даже будут проводить одноименную интеллектуальную игру :)

В связи с этим хочется вспомнить пару инструментов по поиску корневых причин и построению причинно-следственных связей:
• «5 почему» - абсолютная классика
• «Диаграмма Исикавы» (на картинке) - часто её называют «рыбья кость». Системное копание причины слой за слоем. Очень простой и эффективный инструмент
• «Дерево текущей реальности» - достаточно сложный инструмент, который тем не менее позволяет анализировать сложные и запутанные домены, находить причинно-следственные связи и, что интересно, конфликты. Я его прям полноценно использовал всего один раз, а изучал по куче разнородных материалов (поэтому нет единой ссылки)

#picture #link

Интересно, что на конференции для CTO SouthHub многие CTO говорят про бизнес, ценность для клиента, УТП и вообще очень во многом они про смысл того, что мы делаем, какие проблемы решаем, что даём людям.

На фоне докладов и нетворкинга на конференции я вспомнил, как мое погружение в «смысл» началось с фразы «Outcomes over Outputs».

Когда-то давно я услышал эту фразу и начал копать за её смысл. Тогда я перевел её для себя как «Конечная ценность/оказанный эффект (Outcomes) важнее, чем результат твоих действий (Outputs)». Например «решить для клиента проблему выпуска доп. карт для его счета важнее, чем зарелизить сервис по выпуску доп. карт».

Позднее я прочитал интересную статью от Кента Бека на эту тему, ещё сильнее обогатил эту фразу смыслом, а слова Outcome и Output обогатились словами Effort (по факту это про то, что конкретно нужно сделать) и Impact (это про обратное влияние Outcomes на компанию).

Не знаю откуда Кент Бек нашел про Effort, но позже я все чаще видел упоминания этой концепции, только вместо Effort упоминались Inputs (ресурсы на входе) и Activities (конкретные действия).

Ещё позже я узнал, что все эти слова на самом деле части концепции Logic Model.

Проявление этой концепции видны много где.

Например в OKR, а конкретно в формулировании Key Results. Они могут формироваться в виде Inputs (что конкретно нужно сделать), Outputs (что в результате наших действий должно получиться) или Outcomes (на что мы в итоге хотим повлиять, чего хотим добиться). Тренеры из Neogenda (кстати у них крутые тренинги по OKR и не только) оборачивают эту концепцию в модель зрелости OKR и говорят, что много компаний и команд, которые используют OKR, начинают с формулирования своих Key Results как Inputs, то есть в виде конкретного набора действий, которые нужно совершить, а дальше двигаются к Outputs и Outcomes.

Также эта концепция проявляется в подходе Flight Levels, который тоже призван соединить смысл того, что мы делаем, с конкретными действиями.

Другое проявление этой концепции можно найти в Scrum фреймворке.

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

#link #article #thought

Если вы попробуете загуглить строчку «OKR KPI», то вы найдёте достаточно много статей, где эти аббревиатуры противопоставляют друг другу.

Не знаю откуда это пошло, но я точно знаю, что KPI обладает каким-то налетом чего-то негативного, душного, неправильного.

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

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

А тем временем KPI - это числовые индикаторы. Это наша приборная панель. Это RUN.

В то время как OKR - это про изменения. У нас что-то есть и мы хотим это что-то поменять. Это про CHANGE.

На KPI вы можете увидеть текущее положение дел и тренды из прошлого. Решив изменить/переломить этот тренд вы ставите OKR и меняетесь.

OKR работают вместе с KPI и между ними не может стоять никаких «или» и «vs». Только «и»!

#picture #link #thought

Вчера на SouthHub собирали круглый стол с Яндекс, Авито и Азбукой Вкуса (да, там тоже есть IT) на тему «Как большие компании нанимают лидов в 2023».

С нами вы можете познакомиться на нашем TeamLead‘ском лендинге. А я расскажу про то, что я узнал о других участниках.

TeamLead’ы в Авито очень похожи на нас. И по матрицам компетенций, и по найму, и по дальнейшей карьерной линейке. Они сейчас увеличили количество секций на интервью с 3 до 4, разделив менеджерскую секцию на две - про опыт и кейс-интервью. Ребята готовят большие крутые кейсы, с контекстом, ситуацией, цифрами, задачей и вообще всем необходимым. Высылают они их кандидатам до самой секции для подготовки, а уже на секции обсуждают результаты размышлений и решений кандидата. Результаты очень крутые и по их словам эта секция действительно позволяет сильно увеличить качество кандидатов по воронке. А если вам интересна метрика «Time To Offer», то ребята очень близки к одной неделе. Очень круто!

С Яндексом всё интереснее и очень по другому. У них нет как таковой секции по проверке менеджерских компетенций, а TeamLead’ов проводят по секциям с алгоритмами и System Design как и всех остальных инженеров. А вот уже на фитах допроверяют всё остальное. Но нужно понимать, что Яндекс очень разный.

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

Со всеми участниками мы сходимся в нескольких мнениях:
• Нам нужен драйв, инициатива и огонь в глазах!
• Нам не нужны токсики!
• На рынке очень мало TeamLead’ов:(

#thought #link

Руководители часто используют понятие "Фактор автобуса" или "Bus Factor". Его можно объяснить через вопрос - "Какое количество человек должен сбить автобус, чтобы проект невозможно было завершить?". Чем больше знаний и компетенций сосредоточено в руках одного сотрудника, тем выше риск провала проекта/планов/задачи/инициативы при его потере (больничный, ротация, увольнение, ...). То есть чем значение меньше, тем хуже.

Это история не только про компетенции в каких-то стэках (Backend, Frontend, Mobile, ...) но и в знаниях домена, бизнес-процессов и так далее.

Один из инструментов, который помогает системно работать с Bus Factor - это Карта компетенций a.k.a. Звездная карта. Это карта, которая визуализирует уровень экспертности каждого члена команды в разрезе важных для команды компетенций. Не путать с Матрицей компетений, которая призвана разложить компетенции по уровням/грейдам для будущей оценки, найма, промоушена, и так далее.

Карту компетенций часто используют в динамических/проектных командах и в аутсорсинге, чтобы максимизировать эффективность команды. А в продуктовых командах её как раз можно использовать для осознания узких мест, нехватки компетенций и выявления тех самых Bus Factor'ов.

#picture #article #link #thought

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

Впервые с этим термином я познакомился, когда изучал философию 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