Прибор тимлидского зрения

Будем как Стратоплан Стратоплан -- это школа менеджмента, очень крутая. Как я с ними познакомилась и чему у них научилась -- в другой раз, а сегодня поделюсь фактом, который я рассказываю каждому, с кем о Стратоплане говорю: У Стратоплана все созвоны начинаются ровно вовремя. Но это умеют многие. А еще у них все созвоны заканчиваются ровно вовремя -- и такое не умеет практически никто. "Будем как Стратоплан" -- говорю я, когда надо закончить встречу вовремя. Будем как Стратоплан!

Особенности оффлайна На конференции собирают мнения участников: в чем ты лучше чем ИИ? Сбор клёвый, без QR-кодов, ботов и регистраций: отрывай стикер, пиши маркером, клей на стенд. Все ответы классные, но особенно меня улыбнул "Могу научить правильно отрывать стикеры!" (Между прочим, я тоже могу 📝) А правильное и неправильное отрывание стикеров демонстрирует прямо этот стенд: где стикер лежит гладко -- правильно оторван, где топорщится -- неправильно

Конференция SaintTeamLead идет сейчас в СПб

Одна важная мысль для руководителя: Опираться можно только на то, что сопротивляется. Прочитайте ещё раз. А теперь честно ответьте себе: Ваши подчиненные вам сопротивляются?

👇 хорошо Лёша сформулировал

Предвзятый выбор: мнение лектора Про задачу с предвзятым выбором у меня несколько мыслей, которые я бы организовала вот так: 1️⃣ Что за катастрофа? "Неправильный выбор — катастрофа через несколько лет" конечно выглядит как заблуждение, ложь или манипуляция. Один-единственный выбор никогда не формирует большое будущее сам по себе. Если выбор хороший, он еще должен быть поддержан последующими систематическими усилиями; а если выбор неудачный — ну, его можно с разным количеством усилий отменить, поменять, скорректировать. Если вы обнаруживаете себя в ситуации, которую полностью серьезно оцениваете как "выберу неправильно — верная катастрофа", найдите способ посмотреть на ситуацию иначе. Возможно, не в этом выборе ваши главные проблемы. 2️⃣ А вы там кто? В условиях задачи я обошла важный кусок: из какой роли/позиции предлагаю рассматривать ситуацию. А позиции могут быть разные, и в каждой — своя ответственность (подотчетность), свои побочные цели, свои ресурсы и инструменты. В той ситуации можно повоображать, что вы: 🔹 Большой руководитель ("они там должны хорошо решить, чтобы моя компания не обанкротилась") 🔹 Фасилитатор-модератор обсуждения 🔹 Непредвзятый участник рабочей группы по обсуждению решения 🔹 Тот самый участник рабочей группы, который уже точно знает, какое решение правильное 🔹 (и чтобы весело было) Сам себе рабочая группа — пытаетесь принять решение про свою жизнь, и опасаетесь что принимаете его предвзято и непродуманно Какая позиция кажется самой близкой? Самой сложной? 3️⃣ Инвентаризация контекста Полезно вспомнить самому и напоминать другим (пропорции зависят от вашей роли в ситуации и прочей конкретики): 🔹 мы на самом деле что-то решаем, или делаем что-то другое, например успокаиваем себя относительно уже принятого решения? Для каждой задачи свои инструменты 🔹 зачем мы принмаем это решение? Какая цель выше уровнем? 🔹 кому я доверяю, кому нет (и почему, и хорошо ли это)? 🔹 каков запасной план? 🔹 какие у нас требования к процессу принятия решения? Почему такие, для чего это важно? 🔹 какие есть настоящие или гипотетические минусы у решения, в пользу которого есть предвзятость? Не халявить, придумать сколько можно, и потом еще парочку 🔹 какие есть настоящие или гипотетическип плюсы у решения, против которого есть предвзятость? Не халявить! 🔹 какое могло бы быть гипотетическое решение, которое объединяет все плюсы рассматриваемых вариантов, и свободно от всех минусов? Не халявить! 🔹 присутствует ли здесь конфликт интересов? (не "я хочу одно, а они другое", а настоящий из корпоративного права — "минимум две роли одного и того же человека служат источником интересов, противоречащих друг другу") 🔹 а что на самом деле будет, если примем такой вариант? Какие последствия выше уровнем? 🔹 моя жизнь, мой выбор, мне жить с последствиями Про что написать подробнее?

#задача: "Предвзятый выбор" Вот здесь Лёша описывает случай с конференции: клик. Мне кажется, прям распространенный сценарий. Что там на конференции было: участники приносят ситуации сложного выбора, эксперты обсуждают доводы за разные решения. В одном случае владелец кейса не хотел "лучшего" выбора, а под видом сравнения продавливал вариант, который лично ему нравился. Знакомо? "Давайте обсудим, надо ли делать рефакторинг", а глаза у тимлида уже горят "конечно будем делать". "Давайте сравним технологии и выберем лучшую", но решение у CTO уже решено. "Надо ответственно решить, менять ли машину", а где-то глубоко понятно "так-то не надо, но безумно хочется". ✍✍✍ Итак, условия задачи: команде/компании надо взвешенно и обоснованно принять сложное и дорогое организационно-техническое решение. Купить или писать свое, ввязываться ли в мега-рефакторинг ("переписать все на Rust"), оптимизировать ли сборку под ARM, монорепозиторий или нет, табы или пробелы, ну вы понимаете. Неправильный выбор -- катастрофа на горизонте N лет. Главный технический эксперт абсолютно предвзят: топит за один из вариантов, при этом не по объективным критериям, а по личным. Типа "чтобы весело было". Что делать будем? 🔬 <Прибор тимлидского зрения> Семь раз отмерь, а главное не забудь, зачем резать собрался

Схема для совещания: мнение лектора Я конечно считаю, что главное свойство схемы, которую мы хотим использовать, чтобы договариваться со смежниками -- это редактируемость. Точнее: совместная интерактивная редактируемость. Возможность на встрече со смежниками вместе уточнить схему, изобразить корнер-кейсы, добавить подробностей или наоборот убрать их -- вот что важно. Если это есть, остальное докрутите (вместе со своими смежниками). А если редактируемости нет... С одного раза всего все равно не предусмотрите. И на следующем раунде обсуждений или остнетесь без визуализации, или будете перерисовывать с нуля. Редактируемость, но неинтерактивная -- это PlantUML, Mermaid, Graphviz. Интерактивная редактируемость, но не совместная -- это Dia, LibreOffice Draw, Inkscape Интерактивная совместная редактируемость -- это Miro. Точка )) На самом деле прочие коллаборативные доски сюда же. А отсутствие редактируемости -- это бумага, фоточка маркерной доски, или "привет, LLM, вот мой транскрипт встречи, нарисуй аккуратную схему системы, которую мы обсудили". Я частенько вижу в обсуждениях схемы, составленные LLM, и каждый раз мне завидно "какая же она красивая, конфетка для глаз" и горько "да блинский блин, а как на ней думать? Что будет, если вот этот интервал удлинить, а те два события придут в обратном порядке?" В общем, если вы носите на совещания схемы, нарисованные LLM, подумайте хорошенько, что вы теряете и что приобретаете, и нарисуйте диаграммку в Miro. Респект читателям, написавшим свои варианты, и особенно читателю Сергею, который сразу сказал, что схему пойдем переделывать. Чувствуется опыт 👍 🔬 <Прибор тимлидского зрения> Не откладывай на завтра то, что не надо делать вообще совсем никогда

Дополнительный вопрос ко вчерашней задаче! Злободневная часть, которая вчера осталась подразумеваемой: Как использовать ИИ при подготовке схем-диаграмм в описанной ситуации? Как "правильно", и как на самом деле происходит у вас или коллег?

Сегодня несу вам задачу! Называться будет "Схема для совещания"; вопрос серьезный и злободневный. Итак. Вы -- менеджер команды разработки в большой IT-компании. Ваша команда прорабатывает реализацию <сложной логики поведения>. Приоритизация заказов, распределение ресурсов между клиентами, рекламный автобюджет, автоскейлинг, что-нибудь в таком духе. Логика поведения сложная, то есть нетривиально зависит от многих факторов; а еще в реализацию вовлечена не только ваша команда, но и смежники. Заинтересованных много, обсуждений много, много споров. И вот вы решаете заготовить схемы-диаграммы, которые помогут проиллюстрировать все важные особенности планируемой логики. Будете приносить схемы на встречи, и договориться станет легче. Вопрос: какое главное свойство схем-диаграмм вы будете обеспечивать при подготовке? 🔬 <Прибор тимлидского зрения> Если план A не сработал, у тебя есть ещё 25 латинских и пара десятков греческих букв.

Как тимлиду облажаться с похвалой: 3 базовых способа Часть первая, про критику: https://t.me/fisheye_pm/16 Итак, как облажаться с похвалой (подкрепляющей обратной связью): 😭 Не хвалить вообще. Я как-то своими ушами слышала, как руководитель говорит своим подчиненным: "похвалить себя вы сами похвалите, а я сейчас расскажу где надо лучше". Не будьте такими 😭 Хвалить только тогда, когда надо покритиковать; как часть бутерброда "похвала - критика - похвала". "Хвалит -- значит ругать будет"? Не надо так 😭 Хвалить и сразу нагружать дополнительной работой: "ты классную презентацию сделал, давай теперь всегда презентации будешь делать ты". Работала я как-то экспертом-инструктором на курсе для начинающих руководителей; так в эту ловушку попадался каждый первый. Награда за хорошую работу -- еще больше работы? Попробуйте как-нибудь по-другому 🔬 <Прибор тимлидского зрения> Доброе слово приятно и разработчику, и дизайнеру, и тестировщику, и девопсу, и аналитику, и тимлиду, и сейлу, и CTO, и гендиру

Хвалите сотрудников, помогайте экономить на психотерапевтах

Маленькие радости системного мышления Типизация -- супер-полезная основополагающая концепция. Тем кто программировал, идея близко знакомая: у штук, с которыми мы сталкиваемся в жизни (объектов) есть типы. Тип — это ответ на вопросы "как оно может выглядеть и что с ним можно делать". Например: - книга (сшитые листы или файл; можно читать) - обувь (ботинки/кроссовки/сапоги/босоножки, можно надевать на ноги) - транспортное средство (метро, трамвай, поезд, автобус, автомобиль, мотоцикл, велосипед, самокат; можно перемещаться, обычно быстрее чем пешком и с меньшими затратами энергии) - разработчик на Java (человек, можно нанять, поручить задачу) - заменитель гантели (предмет весом 1-2 кг, удобный для хвата; можно использовать в тренировках) В разных-разных ситуациях мы можем не знать, какой фактически объект присутствует/будет присутствовать, но можем сказать, объект какого типа нужен. Как мне сегодня доехать от дома до офиса? — В ответе должен быть объект типа "транспортное средство". Ответ "ковер" не подойдет. Когда будет готова задача? -- В ответе должна быть дата, или интервал, или интервал с вероятностью. А если на вопрос "когда" дают ответ "мы очень заняты", возможно ваш вопрос звучал как "не балду ли вы там пинаете?" Сверять ожидаемый и фактический типы штук, которые появляются в коммуникации — полезно, рекомендую

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

Менеджерское болото Попался клёвый список чтобы измерять токсичность? Бесчеловечность? В общем, отстойность места работы. Насколько это самое место провоцирует истощение и выгорание. Список исходно был про продактов, но вполне применяется и к проджектам, и к другим управленцам. Считаем: 1. Постоянная неопределённость; отсутствие реальной власти при полной персональной ответственности за результат. 2. Непрозрачны методы оценки; лояльность часто стоит выше результата. 3. Красная вертикальная структура плюс культура, маскирующаяся под горизонтальную. 4. Ожидание проактивности в рамках культуры героизма, но совершенно определённой, зафреймленной сверху. 5. Отсутствие культуры ошибок: выдвигайте гипотезы, экспериментируйте, но как вы смеете жечь ресурсы, гипотезы должны подтверждаться, иначе это слабые гипотезы! Список отсюда: https://t.me/undisrupt/1383 Там кроме списочка еще про последствия есть. Первый пункт кстати перекликается с моделью успеха, про которую писала раньше (https://t.me/fisheye_pm/24) -- если нет нужных ресурсов, успеха не жди. Ну а если ресурсов нет, а требования есть -- 😰 У кого сколько -- сейчас, в худшие, в лучшие времена? 🔬 <Прибор тимлидского зрения> С волками жить -- провести анализ неформальной структуры коллектива и идентификацию ключевых лиц; соблюдать субординацию и установленный в организации регламент делового общения

Две идеи, очень простые, при этом очень помогают если о них помнить, и при этом в управлении командами и проектами про них легко забыть: ▪ ресурсы ограничены ▪ есть выбор Если забываем об ограниченности ресурсов, то попадаем в состояние "все важно, делаем сразу все, успеваем мало". Если теряем из виду выбор -- "на нас насыпаются срочные задачи, отказаться не можем, выполнение основных проектов непредсказуемо и неуправляемо; никаких оценок давать не можем". Если помним -- можем приоритизировать, фокусироваться, находить лучшие способы выполнять задачи и вообще получать все лучшие и лучшие результаты. Ресурсы ограничены. Выбор -- есть 🔬 <Прибор тимлидского зрения> Сделал дело -- начинай следующее

Модель успеха процесса Сформулировала формулу: Чтобы какой-то процесс или работа успешно происходили, надо иметь: - знание подходящей методики - умение по этой методике работать - достаточные ресурсы на выполнение работ по методике - приоритет или мотивацию для выполнения работы или процесса При выпадении любого из этих факторов работа или процесс будут выполняться плохо или совсем не будут выполняться. Исправлять надо то, чего не хватает. Если не хватает умения работать по методике, не надо это компенсировать мотивацией. Если не хватает мотивации, не надо затевать обучение. Если принята неэффективная методика работы, может быть лучше найти другую методику, а не заливать задачу ресурсами. (Но с новой методикой может просесть умение работать по ней!) Если обнаруживаем себя в ситуации "мы <такой-то метод> пробовали, и это не сработало", то часто делаем вывод "значит, метод плохой". А стоит задаться вопросом: какого именно слагаемого не хватило? Это действительно может быть неподходящий метод, но также может быть и недостаток умения по этому методу дейстаовать, недостаток ресурсов или приоритета/мотивации. Вот такая формула; пользуйтесь! Хочу еще красивую аббревиатуру для нее придумать. Пока получается прямолинейное MSRP -- method, skills, resources, priority 🔬 <Прибор тимлидского зрения> АББРЕВИАТУРА: Анализ требований, Бюджетирование, Бэклог, Реестр рисков, Еженедельный отчет, Верификация, Итерация, Автор проекта, Трекер задач, Устав проекта, Результат, Адаптация

Почему у сильных технарей-программистов проблемы с планированием Свежеподуманная #мысль: В планировании и вообще в управлении нет сложных структур данных, хитрых алгоритмов и неуловимых багов; и это может сбивать с толку программистов, особенно сильных. Вот ты программист, разработчик, строишь большую и сложную систему, знаешь все алгоритмы консенсуса, в голове моделируешь произвольный сценарий отказа и диагностируешь любую проблему по мутному скриншоту дашборда с графиками. А потом тебе надо делать планирование, трекинг выполнения и подведение итогов. А в планировании и вообще в управлении из структур данных -- массивы и хеш-таблицы, из алгоритмов -- сортировка, проход по массиву и подсчет наростающего итога, а из фреймворков -- выполнение по расписанию, как в crond. И сильный технарь-программист путается. Не верит, что "все так просто" (не все так просто, но сложности не технические); пытается найти или придумать мега-фреймворк; оверинженирит; не замечает настоящих сложностей (а мы помним, они не технические); отчаивается; бросает все со словами "этот ваш менеджмент -- бесполезная фигня" и возвращается к коду, багам, сценариям отказа и дашбордам с графиками. Как вам? Похоже на кого-нибудь из знакомых? Как считаете, какие главные сложности в менеджерской работе? 🔬 <Прибор тимлидского зрения> Назвался груздем -- выполняй Гантт