Junior PM

#кейс_стади
Задача на подумать для менеджера

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

После этого в ход идут принципы Disciplined Agile. Вместо жесткого roadmap — адаптивное планирование. Вместо жестких процессов — Way of Working . Стоит подходить к процессам не как к жестким рамкам, а как к пересматриваемому канвасу для удобства, чтобы не разбредаться. Из XP обязательно советую утащить 2 практики как костяк:

Small Releases - команда максимально часто выкатывает изменения, даже если это небольшие куски системы. Это позволяет избежать эффекта «мы три месяца копаемся и ничего не видно».

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

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

Каждую неделю команда должна:
1. Показывать не просто код или записи, а работоспособные куски системы на стенде;
2. Получать обратную связь от тех, кто реально пользуется админкой;
3. Давать CTO возможность перепахивать бэклог, меняя приоритеты и набор задач;

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

Почему другие варианты не работают?
1. Классический WBS с процентами выполнения — дает ложное ощущение контроля. В реальности каждая новая неделя открывает столько неожиданностей, что «50% выполнено» не значит ничего;

2. Работа через списки рисков — CTO хочет не риски, а движение. Без привязки к реальным шагам риск-лог превращается в формальность;

3. Планирование по аналогии с прошлым опытом — у CTO может быть успешный бенчмарк, но если архитектура другая, этот опыт здесь не работает;

4. Прогнозирование через темп команды — пока команда занимается исследованием, темп разработки бесполезен;

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

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

P.S. Конечно это невозможно без первичного кик-офа, общих договоренностей об архитектурном стиле и подготовки окружений. Если команда тратит более 5 минут в данном случае на развертывание - к распилу монолита на самом деле вы долго не продвинетесь

#мнение #реклама

Здравствуй, читатель

Долго присматривался к курсу тимлидов в Стратоплане. Но пока думал, размышлял и осознавал, дорос чутка выше. Теперь передо мной новый вызов — руководство не просто командой, а менеджерами

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

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

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

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

Пока начало обнадеживает: меня не просто записали, а провели через тест управленческой зрелости, разбор кейсов и проверку на адекватность деловой переписки. Хороший знак — значит, подбирают тех, кто реально замотивирован

Буду учиться, расти и делиться инсайтами. Этот год должен принести большой личностный апгрейд — подтянуть техничку, базовый менеджмент, продуктовые компетенции и даже AI (куда уж без него)

P.S. Всегда было интересно, что и как преподают авторы "Чёрной книги менеджера". Надеюсь это даст мне больше уверенности в своей базе

P.P.S. А что ты для себя нашел на рынке образования и куда поступил в этом году, имея на него большие надежды?

#кейс_стади
Задача на подумать для менеджера

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

Ты вышел на новое место работы — в крупную компанию, которая занимается доставкой цветов (конкурент Flowwow). Бизнес разросся, и вместе с ним выросла глобальная админ-панель для всего бэкофиса. В ней собрано буквально всё: управление партнерами, карточками товаров, логистика, CRM, финансы, маркетинг и еще десятки других систем, которые сплелись в один большой монолит

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

Проект курирует лично Александр, CTO, который пришел из вашего крупнейшего конкурента и «знает, как это делать». Он уже участвовал в похожем проекте и уверен, что у него есть рабочий план. Тебе нужно просто обеспечить прозрачность процесса и следовать лучшим практикам

Вот только проблема в том, что никаких «лучших практик» не видно

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

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

— Сколько осталось работы? Неизвестно, потому что никто не знает, сколько вообще всего есть в монолите.

— Какие сервисы уже готовы? Никакие, потому что пока только разбираетесь в системе.

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

Ты пробовал включить CTO в рабочие обсуждения, но это быстро обернулось катастрофой.

— Во-первых, он сразу пошел в микроменеджмент. Вместо стратегии начал разбирать конкретные таски и требовать «просто запустить что-то рабочее».

— Во-вторых, команда начала зажиматься. Разработчики и так перегружены — а теперь еще им приходится защищаться от вопросов вроде «Почему так долго?» и «Я видел это решается быстрее».

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

Но как дать динамику, если проект только распутывается, а не продвигается?

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

#напутствие
Почему я работаю менеджером

Хороший процесс – это не только про то, чтобы гнать команды вперёд, но и про то, чтобы вовремя останавливаться. Так вот, ты тоже часть этого процесса

Работа – это марафон, а не спринт, и если долго игнорировать техдолг своего здоровья и психики, то однажды может прилететь такой факап, который никакими ретро не разберёшь. Хороший менеджер – это тот, кто не только умеет разруливать хаос, но и знает, когда пора сделать паузу. Давать команде передышку – это нормально. Снимать с собственной шеи маленького достигатора и отставать от себя - адекватно

#реклама

Что может быть лучше чем пет-проект?

Привет, читатель!

Сегодня хочу поговорить о том, почему пет проекты – это must-have для каждого, кто работает в IT, особенно если ты менеджер. Если коротко, то это лучший способ учиться, расти и делать что-то новое

А если подробно – вот мои мысли:

1️⃣ Это свобода учиться тому, что важно тебе
Никакой бюрократии, согласований. Просто выбираешь, что хочешь изучить, и берешься за дело. Я, например, недавно залип на 10 часов в интеграцию OpenStreetMap через разделение на кучу виджетов работу с картой для своего приложения. В процессе не только разобрался, как это работает, но и, кажется, наконец понял до конца, что такое async. Пет проекты легко увлекают, а с ними учиться – одно удовольствие

2️⃣ Это способ добрать опыта, которого тебе не хватает
Если ты начинающий менеджер, ты точно знаешь, как сложно конкурировать на рынке труда. В резюме нужны реальные кейсы, а не «общие слова». И тут пет проект - один из немногих выходов. Никогда не управлял мобильной разработкой? Сделай/поучаствуй в пет проекте. Не знаешь, как работают омниканальные маркетинговые механики? Попробуй создать их в своем мини-продукте. Всё, что ты делаешь в рамках пет проекта, легко ложится в резюме как реальный опыт

3️⃣ Это лучшая зарядка для мозга
Когда ты работаешь над пет проектом, ты решаешь сложные и интересные задачи, которые реально увлекают. Ты сути полностью в потоке и за пару недель проделываешь такую работу, которая в обычной рутине заняла бы месяцы. Количество принимаемых твои мозгом решений астрономическое. Это как играть в го или варгеймы (ну и рил тайм стратегии), только лучше

4️⃣ Это возможность получить новый опыт
На работе не всегда дают шанс попробовать что-то новое, домен или технологию которая тебе интересна или нужна в резюме. А в пет проекте ты сам себе режиссер. Например, я так делал сайт для себя и лучше разобрался в rest и socket-механиках

Что делать, если хочется начать, но не знаешь, с чего?

Загляни в канал «Твой пет проект» – там навалом полезной информации: как выбрать идею, найти первую аудиторию и протестировать на ней свою идею

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

Реклама. ИП Табунов ИНН 773379585100 erid: 2VtzqxdncPv

#кейс_стади
Задача на подумать для менеджера. Разбор

Задача с Вадимом вызвал обсуждение, и неслучайно — у многих есть похожие ситуации, когда сильный технический специалист оказывается на управленческой роли, но не справляется. У каждого был/есть свой Вадим. Это не проблема Вадима как человека, это проблема системы, которая допустила такую ситуацию и не меняет её.

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

В таких ситуациях решения нужно принимать одновременно в двух горизонтах:

1) Краткосрочное — найти костыль, который закроет управленческие провалы Вадима. Это может быть сотрудник в его команде, которому формально или неформально добавляются функции управления, или сам менеджер, который временно берет процессы на себя.
2) Долгосрочное — на позиции Вадима должен оказаться другой человек, обладающий не только техническими компетенциями, но и управленческими навыками

Обратная связь не всегда работает. И тем более не приводит к изменениям. Изменения случаются, если есть три условия:

- Представление о лучшем будущем
- Желание значимого лица изменить статус-кво
- Безопасные шаги для перехода к новой системе

Если этих факторов нет, любые разговоры о развитии останутся без последствий

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

Дальше начинаю фиксировать всё в формате: дата – ситуация – пример (ссылка, скриншот) – что стоило сделать иначе. Когда накапливается достаточно данных, собираю кейс-эффект диаграмму, где фиксирую системные проблемы, их причины и следствия. Это даёт целостную картину: какие конкретно ошибки ведут к каким последствиям

Привязывать всё к метрикам или деньгам не всегда возможно. Я использовал такой подход всего один раз, и то притянуто за уши. Гораздо важнее показать влияние на операционные процессы и стабильность продукта

В ситуации с Вадимом я поступил именно так: за месяц собрал 22 кейса, визуализировал их влияние и представил его руководству. Этого оказалось достаточно. В итоге произошло перераспределение ролей среди DevOps-лидов, и к нам пришёл новый человек, который действительно занимался процессами. Стало проще и команде, и бизнес

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

#кейс_стади
Задача на подумать для менеджера

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

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

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

И вот уже более полугода у тебя постоянное ощущение, что DevOps-процессы работают не так, как должны. Лид DevOps-команды, Вадим, технически очень силен, и это признают все. Однако как руководитель он не справляется. Он не выстраивает прозрачные процессы, не фиксирует договоренности, дает команде противоречивые указания. В результате возникают мелкие, но постоянные проблемы: задержки релизов, инфраструктурные сбои, ошибки в настройке дистрибуции и локальных сетей. Эти инциденты уже вызывают недовольство руководства и повышают риск серьезных операционных проблем

Ты обсуждал с Вадимом эту ситуацию. Он соглашается, что "не все идеально", но добродушно утверждает, что всё исправится. Каждый раз, когда что-то идет не так, он говорит: *«Разберусь»*, но ты не видишь, чтобы он брал на себя реальную ответственность или предпринимал системные шаги для решения проблем. Он скорее тушит пожары, чем предотвращает их

Ты уже попробовал несколько способов изменить ситуацию:

- Давал Вадиму развивающую обратную связь;
- Организовывал для него менторинг;
- Собирал на него широкоформатную обратную связь;
- Его руководитель даже открывал ему испытательный срок, но затем без объяснения причин закрыл его.

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

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

P.S. Весь ваш фидбэк учел и кейсы будут более конкретными, редкими, с вариантами и моим разбором

#рецепт
Cписок книг для начинающих менеджеров проектов

Привет, читатель

Я принес для тебя еще чтиво, правда, не мое, но очень уважаемых товарищей. Если ты уже умеешь ставить задачи в Jira, но не понимаешь, почему все застряло в «in progress» на третью неделю — возможно, дело не в Scrum, Kanban или волшебных методологиях, а в фундаменте.

В статье на habr, linkedin или vc можешь прочитать подробнее, а здесь будет выдержка.

Представляю 10 книг, которые помогут прокачать базу:

📌 «Общее и промышленное управление» — Анри Файоль

Файоль выделил 5 функций менеджмент*: планирование, организация, руководство, координация и контроль. Это не скучная теория, а каркас, на который ложатся все современные практики управления.

📌 «Принципы научного управления» — Фредерик Тейлор

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

📌 «Эффективный руководитель» — Питер Друкер

Главный вопрос Друкера: «Что делает менеджера по-настоящему эффективным?». Книга поможет не путать «занятость» с результативностью.

📌 «Динамика администрирования» — Мэри Паркер Фоллетт

Если Друкер — про эффективность, то Фоллетт — про лидерство и влияние. Классика, которая объясняет, как управлять не командуя, а направляя.

📌 «Экономический контроль качества продукции» — Уолтер Шухарт

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

📌 «Управление проектами: быстрый старт» — Дмитрий Завертайлов

Практическое руководство: как стартовать проект без погружения в теоретические дебри.

📌 «Канбан Метод. Базовая практика» — Алексей Пименов

Как сделать так, чтобы Kanban не превратился в «вот тебе доска, и сам разбирайся».

📌 «Антихрупкость в IT» — А. В. Бындю

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

📌 «OKR. Инструмент, который изменит вашу компанию» — Нивен, Ламорт

Не «давайте придумаем KPI», а как действительно ставить осмысленные цели.

📌 «Коучинг agile-команд» — Лисса Адкинс

Scrum-мастерам и agile-менеджерам сюда. Про командную динамику, рост специалистов и эффективное лидерство.

Вывод:

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

P.S. Да, все эти книги читаются не за один вечер, но PM без базы — это Моисей без скрижалей
P.P.S. Дополнительно советую еще 2 книги: «Проджект-менеджер маминой подруги» — Семена Колосова (кстати там есть небольшой фрагмент от меня) и «Карьера менеджера IT-проекта...» — Г. Лакман Макдауэлл, Д. Баваро, что также будет очень полезно до начинающих/

#реклама
Зачем работодателю обучать проектному управлению

Привет, читатель!

Люблю исследования – в них всегда можно найти что-то полезное. А тут мой знакомый Иван Зверев и ScrumTrek проводят классное исследование про обучение управлению проектами в 2025 году.

О чём оно?
– Почему компании отправляют сотрудников учиться?
– Что важно при выборе курсов?
– Сколько готовы тратить на обучение?
– И главный вопрос: насколько это вообще работает?

Сам недавно снова вернулся к обучению (после перерыва в 2024). Решил, что вечно тянуть нельзя, и скоро снова буду обмазываться сертификатами. Было бы для них место в резюме...

Кого зовут?
– ЛПР, которые решали, кого и зачем отправлять учиться.
– Тех, кто сам учился на курсах и готов рассказать, как это было.

Что делать?
1️⃣ Узнать, относитесь ли вы к одной из категорий;
2️⃣ Понять, готовы ли уделить 45-60 минут на интервью в Zoom;
3️⃣ Написать @ivanzverevpm

Что дадут?
Итоговый отчёт ещё до публикации. Для любителей инсайтов – это находка.

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

#иное
Итоги эксперимента с задачками и напутствиями

Последний месяц я тестировал два новых формата контента:
1. Управленческие задачи (#кейс_стади) — короткие кейсы для размышления
2. Напутствия (#напутствие) — мои поддерживающие мысли о работе, управлении и бытии руководителем

Эксперимент получился интересным, но не всё зашло так, как хотелось.

Что с задачками
Ежедневный формат не сработал так, как я рассчитывал.

— Усталость аудитории: многие отключили уведомления, часть подписчиков просто перестала читать;
— Комментариев и реакций оказалось меньше, чем ожидалось: 2–5 комментариев, 12–20 реакций на пост;
— Тайминг с утра работает: 57% просмотров в первые два часа, но вовлеченность не выросла.

Что меняю:
— Больше не каждый день, а 2–3 раза в неделю

— Буду разбирать решения и показывать своё мнение через 1–2 дня после кейса

— Добавлю голосования и варианты решений

Что с напутствиями
Этот формат работает лучше.

— Реакций на такие посты больше, чем на задачки;
— Помогает создать настроение на день, но важно не загонять себя в однообразные советы;
— Лучше заходят посты с личными историями, чем абстрактные мысли.

Что меняю:
— 1 раз в неделю, а не чаще
— Добавлю больше историй из жизни и работы

— Чередую стили: не только мотивация, но и ошибки, инсайты, неожиданные выводы

Адаптированный контент-план

📌 Понедельник — управленческая задача, голосование, обсуждение
📌 Вторник — разбор кейса;
📌 Среда — напутствие;
📌 Четверг — что-то еще;
📌 Пятница — напутствие.

Протестирую этот формат 2 недели, потом соберу обратную связь. Между ними нерегулярные средние посты и крупные. Пока я попробую еще себя в эссе и сторителинге.

Если есть мысли или предложения — пиши в комментарии!

#полезности
Вводим больше бюрократии с помощью DoD. Часть 2

Введение DoD требует участия всех, кто связан с процессом разработки. Вот ключевые шаги:

1. Собери команду. Важно, чтобы разработчики, тестировщики, менеджеры и любые другие ключевые участники обсудили, что они понимают под «готовностью»;
2. Проведи воркшоп. Вместе составьте список минимальных требований для всех типов задач (баги, фичи, техдолг). Это должна быть командная работа, чтобы все приняли DoD как свой инструмент. Важно учесть что для разных типов работы может быть разный DoD. Мы пока сделали только для фичей;
3. Протестируй DoD. Введите его на несколько спринтов, фиксируя проблемы и улучшения;
4. Закрепите DoD. После тестирования утвердите DoD как обязательный стандарт.

Важно, чтобы DoD пересматривался на ретроспективах (если их нет, то вообще была опция его обсудить и пересмотреть). Это живой документ,

Почему DoD должен охватывать весь процесс команды, а не только финальный этап

DoD часто воспринимают как чеклист для последнего этапа перед релизом. Это ошибка. Если DoD ограничивается только финальными шагами, проблемы накапливаются в процессе разработки.

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

DoD должен покрывать весь процесс. Условно:

- Стадия планирования: план разработки, систем ревью. Тут важно держать баланс с DoR;
- Стадия разработки: код проверен и покрыт тестами;
- Стадия тестирования: все критичные дефекты устранены;
- Стадия релиза: релиз-ноутсы оформлены и фича работает на проде.

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

Наш текущий DoD:

Вот текущий DoD, который мы используем в моей команде:

- Фича-флаг Firebase (если применимо);
- Ремоут-конфиг Firebase (если применимо);
- Диплинк (если применимо);
- Написан юнит-тест или заведена задача на его написание;
- Описание, как ревьюить;
- Описание, как тестировать;
- Заполнен дев-компонент;
- MR направлен в корректную ветку;
- Пройден код-ревью;
- QA обеспечивает тестовое покрытие (тест-кейс, чек-лист и т.д.);
- Задача протестирована, есть комментарий с результатом;
- MR влит в корректную ветку.

Это не-универсальный набор для любой задачи, пока только для сторей

Как я устанавливал и дорабатывал DoD заново

После периода «выключения» DoD я начал возвращать его шаг за шагом.

1. Анализ ситуации. Я оценил, почему прошлый DoD не сработал, и какие элементы команды были не готовы соблюдать. Например, отсутствие знаний в написании тестов или отсутствие документации. В нашем случае он был слишком абстрактным и неконкретным;
2. Собрание команды. Мы провели (и еще проведем) несколько встреч, где обсудили ценность DoD и его влияние на продукт. Важно было убедить команду, что DoD — это не просто бюрократия, а инструмент, который помогает;
3. Постепенное внедрение.** По-хорошему стоит добавлять элементы DoD не сразу, а поэтапно. Сначала — ревью, потом написание мануал тестов, затем тесты документации и так далее. Это позволит избежать перегрузок команды одномоментно;
4. Регулярные проверки. Мы обсуждаем, что работает, а что — нет. Некоторые пункты придется доработать. Например, упростить требования к юнитам;
5. Закрепление. После тестового периода я закреплю DoD как обязательный стандарт. Но уже он — неотъемлемая часть наших процессов.

В общем в лучших традициях ADKAR

#рецепты
Вводим больше бюрократии с помощью DoD. Часть 1

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

Сперва как обычно немного теории, чтобы выровняться и говорить на одном языке

Что такое DoD?

Definition of Done — это минимальные требования, которые должны быть соблюдены, чтобы задача считалась выполненной. Это не про конкретную задачу, а про общий стандарт качества. DoD отвечает на вопрос: как мы поймём, что работа сделана качественно? Например: тесты пройдены, документация написана, код соотв. принятому стилю. Если DoD выполняется по всем задачам, можно “почти быть уверенным” в качестве итогового продукта

Махровая теория: quality gate и shift left

DoD — это часть двух больших концепций: quality gate и shift left. Quality gate — это контрольные точки, где проверяется качество на каждом этапе работы. Shift left — это перенос проверок качества на более ранние стадии, чтобы выявлять проблемы как можно раньше. В этом контексте DoD — это финальный quality gate, который гарантирует, что результат полностью готов

Чем отличаются DoD, DoR и AC?

Их часто путают. Хотя все три — это quality gate, их роли различны:

- DoR (Definition of Ready): требования к задаче, чтобы её можно было начать. Если задача переходит от менеджера к команде, то DoR — это чеклист для менеджера. Например, задача должна быть чётко описана, иметь все входные данные и учтённые зависимости;
- AC (Acceptance Criteria): требования к тому, как должен вести себя результат задачи. Это простой перечень того, что результат должен уметь, чтобы заказчик сказал: «Да, это то, что мне нужно»;
- DoD: критерии, которые показывают, что задача выполнена с должным качеством. Это не только про соответствие ТЗ, но и про тесты, документацию, ревью — всё, что делает результат стабильным и готовым к использованию.

Почему DoD — «дорогая» практика?

DoD — это инвестиция, которая требует усилий.

1. Ресурсы. Нужно время на написание тестов, документации, проведение ревью;
2. Замедление работы. На первых этапах команда работает медленнее, но это снижает количество багов в будущем;
3. Повышение планки. Например, если в DoD прописано писать юнит-тесты или релиз-ноутсы, команда должна этому научиться;
4. Долгосрочная выгода. В будущем DoD снижает затраты на доработки, стабилизирует продукт и улучшает отношения с заказчиками.


В следующем посте я расскажу, как мы вернули DoD, какие шаги предприняли и какие трудности пришлось преодолеть

P.S. Если хочешь вспомнить и другие похожие аббревиатуры, загляни в https://t.me/junior_pm/35 😉
P.P.S. А еще мы решили вернуть DoD потому что стали забывать некоторые важные вещи делать и он позволяет не забывать

#напутствие
Почему я работаю менеджером

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

#напутствие
Почему я работаю менеджером

Половина команды в отпуске, заказчик пишет капсом, а релиз уже завтра? Ты не волшебник, но точно найдёшь, как закрыть дыры. Приоритизация, временные костыли и пара срочных звонков – и ты снова превратишь хаос в управляемый бардак. Главное, ты всегда держишь процесс под контролем. А еще не забывай про крепкие словца

#мнение
Опять про сторипойнты и эти оценки из agile

Здравствуй, читатель! Почему относительные оценки — не серебряная пуля, но работают (иногда)

Когда речь заходит об оценке задач в а-жаль, всегда найдутся те, кто скажет: "Story Points спасут мир!". Смотри, это точнее, проще, удобнее! А абсолютные оценки (в часах или днях) — прошлый век. Давай в очередной раз разберемся: так ли это на самом деле?

Спойлер: Story Points — не магия и не гарантия успеха. Они не сделают вашу команду суперточной машиной по оценке. Но есть очевидные плюсы, которые часто упускают

Почему Story Points не идеальны?

1) Неточность заложена в подход

Оценки всегда субъективны. Что абсолютные, что относительные. Разница лишь в том, что Story Points маскируют вашу неуверенность под "умные" числа. И ими проще отбиваться от чрезмерного микроменеджмента. Как выяснилось из исследования https://onlinelibrary.wiley.com/doi/full/10.1002/spe.3333, опыт команды почти не влияет на точность. Даже эксперты могут ошибаться — просто чуть реже, чем новички;

2) Они не универсальны

Если вы работаете с новичками, они могут переоценивать простые задачи и недооценивать сложные. Если команда не привыкла к Story Points, результат будет таким же хаотичным, как и при абсолютных оценках;

3) Игра в покер — это не всегда весело

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

Но у них есть плюсы. И важные:

1) Они учат команду думать вместе

Когда вы обсуждаете задачу в формате "это сложнее, чем то, что мы делали вчера?", появляется общая картинка. Команда начинает лучше понимать друг друга и проект;

2) Они помогают избежать споров про часы

Story Points не про время, а про усилия. Это убирает ненужные разговоры вроде: "Как ты можешь делать эту задачу 8 часов, если я бы сделал за 3?";

3) Они проще адаптируются под реальность

Если что-то пошло не так (а в Agile это почти гарантировано), Story Points легче перенастроить, чем абсолютные оценки;

4) Они делают планирование менее неприятным

Никто не уходит с планирование с ощущением, что ему "выставили счёт". Все понимают (если это адекватно внедрено), что оценки — это инструмент, а не правда в последней инстанции.

Что важно помнить, работая с Story Points?

1. Planning Poker — это не про числа, а про общение

Не нужно затягивать процесс. Если вся команда согласилась на одну оценку — не тратьте время, идите дальше;

2. Делайте ретроспективы оценок

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

3. Не превращайте Story Points в часы

Как только начнёте говорить "1 SP — это примерно 2 часа", весь смысл метода исчезнет;

4. Сравнивайте внутри спринта

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

На эту тему я уже писал раньше:
- Почему Story Points — это не ловушка https://t.me/junior_pm/99
- В целом про оценки https://t.me/junior_pm/167

И рекомендую заглянуть в исследование и его ссылки. Оно подтверждает, что Story Points эффективны, если команда сфокусирована на процессе, а не на числах. Те как не забавно и не контринтуитивно, но относительные оценки приносят пользу только когда фокус смещен с оценок на коммуникации

P.S.
Story Points — это не серебряная пуля. Но если использовать их правильно, они делают команду сплочённой, а процесс оценки — осознанным и менее токсичным. А если вы ещё не пробовали Planning Poker — самое время начать.

Что думаете? Как у вас проходят оценочные сессии? Делитесь опытом в комментария

#напутствие
Почему я работаю менеджером

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

#напутствие
Почему я работаю менеджером

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

#напутствие
Еще новый тип постов

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

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

#кейс_стади
Задача на подумать для менеджера. Итоги эксперимента

Привет, читатель!

Как ты уже, наверное, заметил, последние 5 рабочих дней я публиковал каждый день с утра по одной управленческой задаче. Это был экспериментальный контент. Хотелось проверить, зайдёт ли такой формат, оживит ли он активность в канале и не станет ли мне накладно его писать

Спойлер: "накладно не стало!" Более того, я пишу посты примерно на неделю вперёд, и проблема скорее в том, чтобы выбрать из кучи тем для кейсов, чем придумывать что-то новое

Теперь к сути. Перед запуском этого эксперимента у меня было несколько гипотез:

1. Если выпускать задачи утром (в районе 9–10 по Москве), это будет удобно для аудитории. Думал, что такой тайминг даст 2–3% прироста вовлечённости;
2. Ежедневный контент покажет, что канал более живой и активный чем обычно. Это должно было привлечь новых подписчиков — хотя бы на 20–30% больше обычного;
3. Если публиковать кейсы в формате открытых вопросов, это увеличит количество реакций и комментариев.** Ожидал прироста на 20% день ото дня.

Что же получилось на практике?


1️⃣ Утренний тайминг
Утро оказалось действительно удобным временем. Большинство просмотров собирается в первые 1–2 часа после публикации (до 57% от общего охвата). Но, увы, прироста вовлечённости на 2–3% не случилось. ERR держится в привычном диапазоне 16–24.8%.

2️⃣ Ежедневные посты
Тут интересно. Активность подписчиков стабильна, но бури новых подписчиков не случилось. За месяц +14 человек — это примерно в рамках стандартного роста. То есть аудитория оценила регулярность, но это не сделало канал виральным

3️⃣ Формат открытых кейсов
Комментарии есть, но их мало (0–2 на пост). Реакций тоже немного (в среднем 12–20). Ожидаемого прироста на 20% не произошло. Видимо, чтобы разговорить аудиторию, нужно искать другие подходы — пока этот формат работает, но без фейерверков

Дополню двумя наблюдениями

4️⃣ Длина постов.
Я пробовал оставлять задачи максимально лаконичными, без лишней воды. И это сработало. Длинные кейсы не дали никакого прироста в охвате или вовлечённости. Короткие формулировки удобнее воспринимаются.

5️⃣ Регулярность
Честно, ежедневный постинг требует дисциплины, но для меня это пока нормально. Заметил, что слишком частые публикации (каждый день) могут слегка "примелькаться", и ERR остаётся на том же уровне, что и при менее частом постинге. Может, стоит подумать над форматом "пост через день" или миксовать с чем-то большим и более глубоким

А теперь мне интересно твоё мнение! Понравился ли тебе этот эксперимент с задачами? Стоит ли продолжать?

👉 Оставить детальную обратную связь можно по этой ссылке

А если хочется просто поделиться своими мыслями — пиши в комментарии в свободном формате, буду рад почитать!

P.S. Что будет дальше - я возьму паузу до конца недели собрать обратную связь и подумать что делать с форматом. А еще вечером сегодня запущу новый, также ради теста!

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

#кейс_стади
Задача на подумать для менеджера

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

Ситуация

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

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

Проблема

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

Екатерина — тот человек, к которому все идут за советом. Она умеет слушать, поддерживать и помогает другим чувствовать себя комфортно в команде. Атмосфера с ней точно будет хорошей. Но она не всегда уверена в себе, особенно когда нужно принять сложное техническое решение или столкнуться с жесткой критикой. При этом она недавно взяла курс системного архитектора

Максим — самый энергичный и амбициозный. Ему нравится решать проблемы и брать ответственность за сложные задачи. Он горит желанием развиваться и готов работать сверхурочно, чтобы доказать свою ценность. Но у него пока не так много опыта, и не все в команде воспринимают его как равного. Однако лучше всех разбирается в новых технологиях и у него отличные навыки ментора, так как он участвует во многих менторских программах и является энтузиастом разработчиком, контрибьютящим в Open JDK и некоторые крупные npm пакеты

Вопрос

Ты выбрал Екатерину, потому что веришь, что её подход поможет команде стать более сплочённой. Но что, если её нерешительность или недостаток уверенности приведут к проблемам? Это правильное решение?

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

#мнение
Нейросети всех заменяют!

Полно таких кликбейтных лозунгов (тут кстати тоже). Но что я пока вижу на деле поделюсь ниже.

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

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

Тут не будет рекламы конкретного курса или очень классных нейросетей. Зато будут полезные ссылки на действительно полезные ресурсы, которые могут помочь как в промпт-инжиниринге, так и в выборе нейросети:

- LLM Arena — актуальные по мощности нейросети и их ранкинг: https://lmarena.ai/?leaderboard
- AI For That — нейросетевой поисковик для нейросетей. Позволяет легко подбирать под конкретную задачу сервис и смотреть его юзкейсы: https://theresanaiforthat.com/
- Промтгайд — вводный тестовый курс про промптинг: https://www.promptingguide.ai/
- Промпт хиро — сборник хороших промптов: https://prompthero.com/
- Ведущие принципы качественных промптов — https://github.com/VILA-Lab/ATLAS. Ребята провели крутое исследование и опубликовали результаты.

P.S. Для чего я сам планирую использовать нейросети и что мне удалось накопать. А особо ничего — сейчас больше это для развлечения и совсем небольшой помощи. Действительно что-то автоматизировать или заменить, не на уровне говорящей головы, ничего не может. Но я в процессе поисков.

Генерация идей
Да, нашел пару сервисов. Но мое буйное воображение все равно справляется лучше

Создание скелетонов и набросков
Ничего нет толкового.

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

Грамматика и ошибки
Тут навалом, много крутых сервисов.

Суммаризация и упрощение информации
Есть 2–3 игрока, но они достаточно бестолковые и под капотом GPT-3.5.

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

Репурпойзинг (когда из большой статьи делается сторис в инстаграм)
Ничего нет на рынке

Генерация визуала
Тут много крутого, и уже очень далеко продвинулись. Но нормально писать текст на картинке еще никто не умеет.

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

Шутки, мемы, геги, реддит-триггеры
Действительно что-то забавное ничего особо делать не умеет

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

Написание автоматизаций и файлов
Есть пара крутых игроков, но по сути gpt-o1-pro справляется лучше.

Факт-чекинг
Никто пока не справляется

Поиск среди научных публикаций и обоснованных исследований
Есть несколько попыток, но результаты грустные

Вовлечение аудитории
Навалом сервисов, которые генерят заголовки, seo/aso теги

Выдержка тон-оф-войс и бренд стиля
Есть 3 хороших сервиса, но за просто космический прайс

#кейс_стади
Задача на подумать для менеджера

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

Ваша роль

Вы — Скрам-мастер в компании, разрабатывающей решение для визуализации данных для трейдеров. Основная задача — обеспечивать бесперебойную работу команды, помогать устранять блокеры и улучшать процессы, чтобы спринты завершались вовремя и с ожидаемым качеством. Вы не очень жестко следуете скраму, но у вас PSM II

Контекст

Компания специализируется на создании высоконагруженных систем для анализа и визуализации данных, которые используют трейдеры. В команде — 8 разработчиков, 3 тестировщика, дизайнер, и 2 аналитика. Процессы построены на Scrum, задачи распределяются через Jira,. Ключевые клиенты компании требуют быстрой реакции на изменения и высокую точность работы системы.

Проблема

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

Эти разногласия приводят к:

- Постоянным пересчетам капасити команды.
- Задержкам с датой код-фриза.
- Ругани в кулуарах.

Ваша цель

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

Другие действующие лица

- Разработчики. Их интерес — делать задачи с хорошими техническими решениями, которые легко поддерживать.
- Тестировщики. Хотят, чтобы их время на проверку учитывалось наравне с разработкой.
- Дизайнер. Настаивает на том, что его работа должна стать частью приоритетов.
- Продакт-овнер. Заинтересован в соблюдении дедлайнов и запросов от клиентов.

#кейс_стади
Задача на подумать для менеджера

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

Ваша роль

Вы — руководитель проектного офиса в IT-ГАЗМЯС, отвечаете за управление программами проектов, процессы проектного управлеиня, распределение ресурсов и отчетность перед топ-менеджментом.

Ваш контекст

Ваша компания разрабатывает IT-продукты для родительской компании ГАЗМЯС, структура матричная. Новый топ-менеджер делает акцент на детализации отчетов и личном участии руководителей в работе над проектами.

Ваша проблема

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

Ваши действия

Вы уже предприняли следующие шаги:

1. Уточнили, что на уровне руководителя важнее фокус на общей картине и рисках, чем знание деталей.
2. Подготовили более подробный отчет для следующей встречи с включением ключевых метрик и статусных данных.
3. Попытались объяснить, что регулярное участие всей команды в таких встречах снизит их продуктивность.

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

Главный вопрос

Как вам убедить топ-менеджера в необходимости разделения стратегического и операционного управления, сохранив доверие к своей работе?

#кейс_стади
Задача на подумать для менеджера

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

Ситуация:

Вы — проджект-менеджер в продуктовой компании, занимающейся разработкой CRM-системы для корпоративных клиентов. Один из ваших крупных заказчиков запросил отчет по эффективности внедрения продукта спустя 3 месяца после релиза. Отчет должен содержать конкретные метрики, подтверждающие успех внедрения.

На стороне клиента есть три заинтересованных отдела:

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

Проблема:

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

Вопрос:

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

#полезности
Амбулаторное обследование процессов

Привет, читатель!

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

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

➡️ Лови список:

О человеке

- Чем занимаешься в компании
- Какая цель твоей работы
- Что именно ты делаешь?
- Какие ожидания от твоей работы, как тебя оценивают?
- В какой команде/подразделении работаешь, кто под твоим руководством?

О бизнесе в целом

- Какая бизнес-цель стоит перед подразделением/твоим продуктовым направлением?
- Что сейчас хорошо в подразделении/бизнесе?
- Что сейчас плохо в подразделении/бизнесе?
- От кого/чего зависит успех подразделения/бизнеса?

О команде

- Какая цель работы твоего подразделения/команды/направления?
- Кто для тебя заказчики?
- От кого/чего зависит успех вашей команды?
- Что сейчас работает хорошо?
- Чем ты сам сейчас не доволен?
- Чем сейчас довольны и недовольны заказчики
- Какие ожидания не выполняются? Сроки? Предсказуемость сервиса?
- Понятно ли на какой стадии работа? Когда будет завершена?
- Качество работ устраивает?
- На какие темы чаще всего возникают дискуссии?
- Возможно, есть какие-то явные или скрытые конфликты отделов/сотрудников, которые ты ощущаешь?
- Чем сейчас довольны и недовольны участники команды/отдела
- Нравится ли формат и режим работы?
- Что замедляет их работу?
- Часто прерывают?
- Часто ли задача заблокирована другими?
- Хорошо ли ставятся задачи?
- Возможно, что-то мешает улучшать процесс работы/совершенствоваться?
- Есть ли что-то, что регулярно мешает делать работу так качественно, как хотелось бы?
- Есть перегрузка? Переработки?
- Какие планы по развитию команды и бизнеса? Что ждет всех в ближайший год?

О процессах

- Что вы выпускаете? Что для тебя является единицей завершенной работы? Перечисли
- Откуда обычно появляются задачи?
- Опиши по любой задаче ваш процесс работы
- Как вы выбираете что делать? Как работают приоритеты?
- Как вы ведете учет своей работы, визуализируете её?
- У вас есть доска команды? Поделись ссылкой
- Как узнать текущий статус работ?
- Как узнать, что задача заблокирована и работа не ведется?
- Часто ли у вас задачи с дедлайном?
- Как измеряете процесс?
- Какие есть регулярные встречи, ритуалы, какие действия предпринимаете после них?
- Бывает ли, что делаете работу, которая потом оказывается не нужна?

Советы

- Что можно быстро изменить?
- На что нужно обратить внимание в первую очередь?
- Чего нужно остерегаться?
- С кем еще стоит пообщаться? Что нужно прочесть и изучить?
- Дай мне любой совет

Автор @britishpop
А еще там же мелькал ассесмент https://docs.google.com/document/d/1GxBAhQbhz_86Fd2qpH1qhh8Vtf_wbUyAYI5ZLhmVJbo/edit?tab=t.0

#кейс_стади
Задача на подумать для менеджера

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

Ситуация:

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

Проблема:

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

Вопрос:

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

#кейс_стади
Новый тип постов

Добавляю новый формат в блог — задачки для менеджеров. (Да как у Колганова или Ковалеского, но иначе). Это ежедневный контент, который позволит размять немного мозг, пока вливаешь в себя жизнеобеспечивающие жидкости с утра, и подготовиться к работе.

Задачки не про правильные или неправильные ответы — их вообще нет. Важно задать допущения и подумать, как бы ты действовал в такой ситуации.

Первая задача уже здесь! Читай, размышляй, пиши свои варианты в комментариях 👇
Обсуждаем!

#мнение
Что будет дальше

Привет, читатель!
Давно не виделись. Как ты заметил, последние полгода я постоянно пропадал, хотя всеми силами пытался вернуться к активным публикациям. Для меня прошлый год прошел под лозунгом «выжить». Сложности со здоровьем, рабочая нагрузка — все это заставило меня притормозить. Но я решил воспринимать это не как шаг назад, а как паузу для накопления сил.

Этот год я хочу провести по-другому — с горящими глазами и вдохновением. Планирую активно учиться и развиваться: сдать IELTS General на B2, пройти сертификацию PMP, подтянуть технические навыки. Кстати, я уже работаю над своим сайд-проектом на Flutter с использованием Clean Architecture и Bloc. Помогает мне в этом GPT и немного claude — и, что приятно, получается довольно здорово!

А теперь о главном — о блоге.
---
О будущем блога
Я всегда сторонился монетизации и слишком простого контента. Был страх превратиться в «типичного блогера» или, того хуже, «инфоцыгана», который пишет ради цифр и видит в читателях лишь аудиторию. Но в какой-то момент я понял, что блог для меня больше, чем просто место для размышлений. Это уже инструмент, по которому судят обо мне, и через который я могу влиять на людей.

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

Сейчас я хочу сделать блог более системным. Это не значит, что я откажусь от своей искренности и стиля. Наоборот, я намерен еще больше углубиться в темы, которые считаю важными, и буду структурировать работу над контентом. В том числе — добавлю элементы монетизации, такие как реклама.
---
Чего я хочу достичь в 2025?
К концу 2025 года я хочу, чтобы блог стал для меня мощной мотивацией. Чтобы мои посты вдохновляли, цитировались и вызывали обсуждения. Я хочу, чтобы меня приглашали выступать, звать на подкасты, брать интервью . Хочу, чтобы мой опыт стал примером для других, чтобы я показывал: проектный менеджмент — это не просто процессы, сроки и бюджеты, это настоящее искусство, в котором можно расти и получать удовольствие от процесса.
---
О миссии блога
Я хочу быть тем, кого мне не хватало в начале пути. Не просто человеком, который учит, а коллегой, который делится опытом, дает инструменты и показывает: управление может быть проще и эффективнее. Мой блог — это место, где можно найти поддержку, вдохновение и материалы для решения реальных задач.
---
Чем я отличаюсь?
Я не гуру, а вечный ученик. Поэтому название Junior PM будет всегда актуально. Я пробую новое, ошибаюсь, делаю выводы и делюсь этим. Моя сила в честности, практичности и умении признавать, что я тоже расту. Блог — это моя личная учеба, и я рад, что могу разделить ее с тобой.
---
О формате
Будет много разного, но в целом можно считать что будет примерно так:

- Большие статьи: кейсы, шаблоны, лайфхаки, теория
- Средние посты: размышления, ответы на вопросы, полезное из сообществ менеджеров
- Краткие посты: напутствия, задачи, любопытный контент

Будет также много нового:
- Новый каналы - medium, reddit, instagram и еще несколько
- Новые форматы. Например, хочу попробовать себя в коротких видео с размышлениями
- Буду использовать больше сервисов-помогатор. Как-нибудь поделюсь что там есть среди нейросетей и сервисов от райтинга до автопостинга и репурпозинга.
---
Зачем мне это нужно?
Этот блог — не только способ делиться знаниями, но и инструмент моего роста. Это моя мотивация учиться, пробовать, экспериментировать. Это возможность становиться лучше и вдохновлять других.
---
P.S. Если у тебя есть темы которые ты бы хотел чтобы я раскрыл, вопросы или просто обратная связь, я буду тебе рад, мои личные сообщения всегда открыты!

#рецепт
Управление ожиданиями через информирование по форме

Привет, читатель!

Сегодня разберём важную тему — управление ожиданиями стейкхолдеров. Это не просто “пиши в чатик, что всё ок”, а фундаментальный навык, который помогает избежать паники и сохранить доверие. Управление ожиданиями — это неотъемлемая часть проектного управления, и я расскажу, как делаю это на практике.

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

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

Обычно у меня десятки стейхолдеров и есть несколько ЛПР. Без управления ожиданиями никуда, так как мы активнее всего в рабочих коммуникациях используем Slack, то я информирую через него. В Яндекс деньгах была создана специальная группа стейкхолдеров по нашему направлению в аутлуке (алиас) и писались письма сразу на всю группу, а на текущем я создал специальный слак-канал. Бывают и инциденты на проде, они требуют особого внимания — тут уже не обойтись без чёткой структуры сообщения и пост-мортем анализа, если инцидент крупный. Когда происходит что-то серьёзное, подключаются L2/L3 и проводится разбор полётов, чтобы избежать повторений.

Структура сообщения, которую я использую
Я делю сообщение на такие разделы:

1. Ситуация или проблема — что именно случилось.
2. Причина — почему это произошло.
3. Влияние — чем это грозит бизнесу и пользователям.
4. План действий — что уже сделано и что ещё нужно сделать.
5. Предыдущие действия — если это повторяющийся или сложный инцидент, я добавляю хронологию проблем.

Пример сообщения с такой структурой
"Ситуация: Релиз версии 1.14.0, запланированный на утро 16 октября 2024 года, пришлось перенести из-за необходимости включения двух критичных задач, которые влияют на стабильность приложения:

1. [X-6152] — Определить, почему в 'connection' отправляется 'unknown'.
2. [X-6056] — Изменение логики отображения сообщения 'нет интернета'.

Причина: Добавление этих задач необходимо для улучшения качества работы с сетью и устранения проблемы с некорректным отображением статуса соединения. Это позволит точнее отслеживать состояние сети, избежать лишних сбоев и улучшить пользовательский опыт. Задачи также связаны с исправлениями, которые были выполнены в прошлых спринтах, но не попали в релизные сборки за последний месяц.

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

План действий:
- Завершение разработки и тестирования задач [X-6152] и [X-6056] до конца среды, 16 октября.
- Проведение полного регресс-тестирования — до конца дня среды.
- Выпуск релиза перенесён на утро четверга, 17 октября.

Подробный статус задачи по релизу доступен в отчёте о релизе.

FYI: ЛПР1, ЛПР2, ЛПР3"

Управление ожиданиями — это не просто про передачу информации, а про удержание доверия и контроль ситуации. Структурированный подход позволяет стейкхолдерам чувствовать себя уверенно даже в моменты непредвиденных проблем. Так что не забывай: ясность и точность — твои лучшие друзья.

А как ты управляешь ожиданиями? Делись опытом!

#мнение
Специфика поиска работы. Часть 2

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

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

Я, например, выбрал путь 70 на 30. 70% усилий я трачу на перекрытие слабых сторон.

Если говорить про 70% на усиление слабых сторон:

- За чуть меньше года мой английский продвинулся с A0 до B1-. Я в целом могу поддержать разговор в общих чертах, читать и писать, причём в первую очередь развиваю developing conversations;
- Я уже не так спешу по карьерной лестнице и больше уделяю внимание степенному росту как личности;
- В сообществах я не устраиваю широкие дискуссии, лишь включаюсь изредка с помощью и поддержкой;
- Плотно работаю с психологом и изучаю себя.

Про 30% фокуса на сильных сторонах:

- Я потихоньку ковыряю протоколы и сети;
- Изучаю prompt-инжиниринг и работу нейросетей;
- Погружаюсь в крипту и трейдинг;
- Уделяю время погружению в задачи своих подчинённых и смежных сотрудников;
- Готовлюсь к поступлению на клинического психотерапевта в европейский вуз.

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

P.P.S. Я в данный момент работаю, и меня всё устраивает, однако я нахожу важным и полезным ходить на собеседования — это освежает и позволяет держать себя в тонусе. Как фитнес

#мнение
Специфика поиска работы. Часть 1

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

Полагаю некоторые, кто читают этот блог могут подумать что у меня нет проблемы при поиске работы. Особенно начинающие свой путь менеджеры. У меня есть:

- 5+ лет опыта работы;
- Технический бэкграунд, ведь я начинал карьеру в IT как Android разработчик;
- Профильное образование, я закончил кафедру управления проектами, по специальности менеджер программных продуктов и инноваций в области экономики;
- Послужной список из таких компаний как ex Яндекс.деньги и МТС;
- Опыт работы со всеми типами проектов, отраслями от HoReCa и до Финтеха и до датаинжиниринга и медицины;
- Нахождение на позициях системного аналитика, скрам-мастера, деливери менеджера, проджекта, аджайл лида, хеда проектных менеджеров и тп;
- С десяток всяких международных сертификаций;
- Личный бренд и этот блог

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

- Молодость - мне около 25, это на самом деле очень смущающий фактор для работодателя;
- Слабый английский. Я начал его изучать лишь недавно и у меня явно не B2+;
- Репутация токсичного человека в сообществе, так как на заре карьеры я был весьма категоричным и острым на язык;
- Широкий кругозор в методах управления проектами, процессами и тп. Я обычно не выбираю Scrum или Kanban, я конструирую кастомную систему под текущую ситуацию;
- Нежелание находиться в позиции “между бизнесом и исполнителями” когда нужно выступать каналом перевода от одних к другим и наоборот
- Большие запросы на условия труда. Я ожидаю оплату труда выше среднего, в стабильной валюте. Хочу иметь либо широкие полномочия либо находиться на короткой ноге с теми, кто их имеет. Не говоря уже о “плюшках”, “корп. пакете” и тд
- Завышенные ожидания от места работы. Я ожидаю что у меня будет или возможен в теории понятный карьерный трек, у компании есть план развития, понятная бизнес модель, условия для масштабирования, у высшего руководства есть стратегия, пусть даже и не на бумаге

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

#полезности
Оказывается диаграмма ганта давно была в гугл таблицах

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

Начнем с моего удивления. Я был очень поражен, когда обнаружил что диаграмму Гантта (вот эти червячки задач по времени) можно уже как 3 года строить в гугл таблицах. Конечно с оговоркой, что это только для платных аккаунтов, однако!

Как любому менеджеру мне часто приходится строить планы и получать на них обратную связь от заказчиков, ЛПР и прочих заинтересованных лиц. Как перфекционист я симпатизирую MS Project, но планами в нем так просто не поделишься. Последние 3 года я в основном работаю в Jira Structure и Jira Plans, но и их стейкхолдеры недолюбливают. А вот к планам во всем экселеподобном питают слабость. Поэтому да, приходится заполнять таблички. Надеюсь ты понимаешь какая это морока)

Полагаю каждый читатель использовал один из перечисленных способов:

1. Закрашивание ячеек. Например, как тут https://docs.google.com/spreadsheets/d/1jERZMnzW27ZbzLQGzNdIKl0E8QOumXOPeb0CgQ_Y4GE/edit?gid=676685432#gid=676685432
2. Установка расширений браузера. Например, как тут https://workspace.google.com/marketplace/app/gantt_chart_builder/127610222824 или тут https://github.com/takuya0206/ganttchart_generator
3. Написание макросов. Например, как таблица из этого поста https://t.me/junior_pm/191
4. Использование кодогенерируемых графиков. Например, с использованием App Scripts https://gsuite-developers.googleblog.com/2012/12/managing-projects-with-gantt-charts.html

Однако вот уже с 2022 года можно строить обычные диаграммы Гантта из коробки. Называется функция Timeline https://support.google.com/docs/answer/12935277?hl=en#zippy=%2Cthese-workspace-editions-can-use-timeline-view

Недавний кейс использования:

У нас случилось серьезное влияние на ABC-тест, пытались отловить где проблема. С помощью Jira AI я собрал все задачи которые затрагивали определенные компоненты и MR затрагивали эту часть системы. Их я расположил на таймлайне, в дальнейшем этом помогло на основе сопоставления временных рамок понять какая задача из сотен повлияла на это откатить изменения

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

P.P.S. Да, знаю что оплатить или вообще иметь доступ к Google Workspace в текущих реалиях проблематично, но некоторые из нас находится заграницей и кому-то это может быть полезно

#полезности
Крутое исследование по ПМ-ам от коллеги

В прошлом году мы делали исследования зарплат Менеджеров проектов. Опрос охватил более 1500 респондентов в разных странах. Он получился мощным)

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

Подобных исследований не проводилось, и тем более они не проводятся на международном уровне. Что ребята хотят выяснить:
1. Какие инструменты современный менеджер проекта использует в работе?
2. Что повлияло на успех и неудачи проектов, которые они делали?
3. Как на эту оценку влияют компетенции менеджеров проектов?
4. Есть ли проникновение в работу менеджера инструментов AI, в каких странах и в каких сферах?

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

Вы можете помочь ребятам и внести свой штрих в портрет современного проектного менеджера:
1. Найдите время в вашем плотном расписании и поделитесь опытом - пройдите опрос
2. Поделитесь опросом с вашими коллегами. Наверняка у вас в компании есть те, кто связывают себя с проектным управлением: https://surveys.meet-deadlines.kz/
3. Поделитесь в ваших социальных сетях опросом, чтобы помочь ребятам выйти за пределы их пузыря!

Спасибо каждому!

Результаты будут опубликованы в начале следующего года и я обязательно расскажу о них

https://surveys.meet-deadlines.kz/

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

- Умей учиться на ошибках: Фиксируй наблюдения. Ищи причины и устраняй их. В этом очень важна вера в себя. Настойчивость также поможет преодолеть трудности.
- Рефлексия: Как я уже говорил в посте https://t.me/junior_pm/217, заботьтесь о своем ментальном здоровье уже сейчас. Либо раскачивая рефлексию и занимаясь самостоятельно, либо со специалистом.

P.S. Если что-то новое не получилось с первого раза, это не значит, что тебе с этим не по пути. Пробуй снова и снова, совершенствуй навыки, и со временем успех придёт. Не сдавайся — каждый новый опыт делает тебя лучше
P.P.S. А что бы вы посоветовали товарищи-подписчики новичку, чтобы как можно проще и эффективнее провести свитч? Я немного оторван от рынка начинающих и мои советы могут быть не супер релевантны)

#почтовый_ящик
Начинаем путь в Project Management-е

Привет читатели! Вот и рубрика “Почтовый ящик” ожила. Есть 1 вопрос)

"С чего начать путь в IT Project Management, если мне за 20, я уже работаю руководителем группы на крупном предприятии, но хочу развиваться дальше, сменить сферу и попробовать себя в управлении IT-проектами?"

Текущие реалии рынка IT

Рынок IT в СНГ действительно изменился под влиянием геополитических и экономических факторов. Ты наверняка заметил, что Agile и другие децентрализованные практики уже не на первых ролях. Компании всё чаще предпочитают более строгие и управляемые структуры, где риски минимизируются за счёт концентрации контроля. Падающая толерантность к рискам привела к сокращению стажировок и возможностей для новичков. Например, по данным исследования HeadHunter за 2024 год https://hh.ru/article/research , количество стажировок в крупных IT-компаниях СНГ сократилось на 20% за последний год, что лишь усиливает конкуренцию среди начинающих специалистов.

1. Нетворкинг: Твой главный инструмент

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

- Строй сеть контактов: Найди способы выйти на нужных людей через общих знакомых. Каждый новый контакт может привести к нужной вакансии или полезному совету. Помни, как я упоминал о важности активного участия в профессиональных сообществах. . Используй такие возможности, как Random Coffee , чтобы знакомиться с новыми людьми и обмениваться опытом.
- Используй социальные сети: Активно взаимодействуй с HR, HR BP и нанимающими менеджерами на таких платформах, как LinkedIn. Не бойся стучаться в личные сообщения — это увеличивает твои шансы на успех.

2. Фундаментальный управленческий опыт

Если ты уже освоил четыре основных функции менеджера — мотивацию, организацию, планирование и координацию, — ты на правильном пути. Важно понимать, что роль PM в IT — это стык специфических управленческих практик, доменных знаний и отраслевой специфики.

- Проектные практики на первом месте: В управлении проектами важны методологии, управление рисками и способность вести инициативы в условиях неопределённости. Именно эти навыки определяют успешность менеджера в любой сфере. https://t.me/junior_pm/190
- Доменные знания на втором: Понимание технологий и процессов, специфичных для твоей области, поможет быть более эффективным.
- Отраслевая специфика на третьем: Понимание особенностей отрасли важно, но не критично на начальном этапе.

3. Собственная база знаний

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

- Создай свою систему знаний: Раздели информацию на модули, темы и подтемы, добавляя теорию и практику.
- Объясняй себе каждую тему: так, как если бы ты объяснял её ребёнку (по принципу Фейнмана). Обязательно примеры и картинки с визуализацией
- Практикуй немедленно: Узнал что-то новое? Сразу пробуй это в деле. Например, узнал о Канбане — создай доску для личных или рабочих проектов и начни использовать её на практике.

4. Пет-проекты и доменный опыт

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

- Создай свой проект: Используй современные инструменты для моделирования ролей и реализации идей с нуля. Эти инструменты позволяют моделировать роли, от аналитика и до сис. админа, что даёт возможность попробовать себя в каждой из них.
- GPT-4: https://chat.openai.com/
- Claude от Anthropic: https://www.anthropic.com/index/claude
- Практикуй на реальных задачах: Пройди все этапы проекта — от ТЗ до тестирования через ADB, чтобы развить навыки и показать реальные результаты своей работы.

Друзья, приветствую вас на борту канала, который, как вы знаете, не просто информирует, но и помогает думать, расти и, безусловно, совершенствоваться в роли проджект-менеджера. Сегодня у нас небольшие изменения — так сказать, реструктуризация навигации. Старая система остается, но я решил, что вам будет полезно видеть, как именно будет делиться контент теперь. Итак, вперед, к новым горизонтам!

1. Примеры и шаблоны — 15%
Тег: #артефакты Этот раздел — ваш главный источник реальных инструментов и шаблонов, которыми я пользуюсь в своей практике. Они здесь не для того, чтобы вы просто копировали, а чтобы вы поняли, как и зачем их использовать. Если вы ищете то, что можно сразу внедрить в работу — добро пожаловать.

2. Что использую и что работает — 25%
Тег: #рецепт Здесь я делюсь теми методами и инструментами, которые уже доказали свою эффективность в моих проектах. Это не просто советы, это проверенные временем и практикой шаги, которые стоит попробовать. Повторюсь, это не значит, что они сработают везде и всегда — важно понимать контекст и адаптировать под свои нужды.

3. Мнение автора — 30%
Тег: #мнение Иногда важно остановиться и задуматься. Здесь я делюсь своими размышлениями на различные темы, которые, как мне кажется, могут быть полезны для вашего профессионального развития. Это не просто мысли вслух, а попытка побудить вас к рефлексии и критическому мышлению. В конечном счете, ваше мнение может отличаться от моего, и это нормально — главное, чтобы оно было обосновано.

4. Рекомендации — 5%
Тег: #рекомендация Стоит обратить внимание: в этом канале рекламы не было и не будет. Никогда. Здесь не публикуются платные посты, и все, что может показаться рекламой — на самом деле моя искренняя рекомендация того, что я действительно считаю ценным и полезным. Если что-то советую, значит, я в этом уверен на 100%. Это продукты и сервисы, которые я сам использую или которые создают люди, которым я доверяю. Только так.

5. Утащенное — 15%
Тег: #полезности Этот раздел — для тех, кто, как и я, любит копаться в интернете в поисках чего-то нового и полезного. Здесь я делюсь своими находками — краткими постами о том, что меня заинтересовало. Возможно, это вас вдохновит или натолкнет на новые идеи. В конце концов, умение вовремя подметить и адаптировать чужие идеи — важное качество проджекта.

6. Забавное — 5%
Тег: #perl Иногда полезно отвлечься от серьезного и взглянуть на мир через призму юмора. В этом разделе я делюсь забавными наблюдениями, ироничными ситуациями и тем, что вызывает улыбку, но при этом заставляет задуматься. Ведь даже в легкости есть своя глубина.

7. Почтовый ящик — 5%
Тег: #почтовый_ящик Ваши вопросы всегда приветствуются. Если вам нужно мнение, совет или просто взгляд со стороны — пишите мне. Я отвечу в формате поста, чтобы и другие могли извлечь из этого пользу. Ведь в конечном счете, развитие — это путь, который мы проходим вместе.

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

Оставайтесь с нами, думайте, применяйте, анализируйте и двигайтесь вперед — это наша общая цель.

— Артем, Junior PM

#мнение
Смена эпохи

Дорогие читатели пришло время для небольшой рефлексии. В 2021 году, когда я основал канал «Junior PM», моя аватарка идеально подходила для того времени. Молодой, амбициозный, начинающий, (с волосами), беззаботный—в общем, та аватарка отражала меня самого в тот момент. Я писал посты про сертификации, полезные каналы и даже делился своим опытом в таск-трекерах. Время летело, и я развивался как профессионал, рос в проектах, набирал опыт.

Поначалу был драйв, было время для активного участия в профессиональных сообществах, написания постов и даже менторства. Но вот что забавно: чем больше я узнавал, чем больше проектов проходил, тем яснее осознавал, что ещё больше предстоит изучить. Это, видимо, и есть синдром вечного «джуна». Никогда не чувствуешь, что знаешь достаточно.

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

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

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

Так что, друзья, аватарка канала меняется вместе со мной. Но несмотря на всё это, «Junior PM» остаётся тем же самым. Ведь учиться и развиваться мы будем всегда.

P.S. И да, «джуном» я быть не перестану—хотя бы для того, чтобы не заскучать

P.P.S. Контент как заметили начинает выходить все регулярнее)

Channel photo updated

"Показатели эффективности (KPI) для сотрудников ИТ"
Почему стоит обратить внимание: Обсуждение различных подходов к определению KPI для сотрудников ИТ, с акцентом на адаптацию метрик к специфике компании и команды.

"KPI внедрили, а аналитика спросить забыли…"
Почему стоит обратить внимание: Рассматриваются проблемы и ошибки при внедрении KPI, с предложениями решений и рекомендациями. Интересные идеи включают важность аналитического подхода и вовлеченности команды.

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

Выбор метрик: Разные подходы к выбору метрик - одни рекомендуют использовать количественные показатели (время выполнения задач, количество багов), другие - качественные (удовлетворенность клиента, командная работа).

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

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

​#мнение
KPI не про эффективность

Привет, друзья!

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

Что такое KPI?
KPI — это пороговые значения метрик, которые используются для оценки состояния процессов. Применять KPI имеет смысл только к стабилизированным и устойчивым процессам. Применение KPI к новым процессам или в условиях хаоса — это бессмысленно.

Как выбирать метрики?
Выбор метрик должен быть осмысленным и связанным с конкретными целями и состоянием вашего процесса. KPI помогают оценить производительность и качество работы. Один из полезных инструментов для выбора метрик — Fit for Purpose Indicators Wheel.

Подробнее об этой модели:

Defining KPIs to Drive Fitness for Purpose: https://medium.com/@agilemanager/defining-kpis-to-drive-fitness-for-purpose-c3ad2af46738
Как определить KPI продукта: https://filipyev.ru/2022/08/30/kak-opredelit-kpi-produkta/
Набор метрик из Fit for Purpose Indicators Wheel:
Для оценки эффективности команды можно использовать следующие метрики:

Health Indicators (индикаторы здоровья) — показатели текущего состояния и работоспособности системы.
Value Drivers (драйверы ценности) — метрики, которые способствуют увеличению ценности продукта или услуги.
Quality of Service (качество обслуживания) — показатели, характеризующие удовлетворенность клиентов и качество предоставляемых услуг.
Vanity Metrics (метрики тщеславия) — показатели, которые могут выглядеть привлекательно, но не обязательно указывают на реальные улучшения или эффективность.

Технический пример: Ошибки 500
Есть тривиальный KPI, дефолтно использующийся во многих командах разработки. Такой же как uptime. Возьмем как пример 500 ошибки.

Как это работает с технической точки зрения:
Сбор данных:

Логи ошибок собираются из разных сервисов. Эти логи обычно включают информацию о времени ошибки, URL, который вызвал ошибку, и стэк-трейс для детального анализа.
Логи отправляются в систему мониторинга, такую как Grafana, через логгер, встроенный в код приложения, или через систему сбора логов, такую как Prometheus.
Мониторинг:

Grafana используется для визуализации и мониторинга данных. Метрики из логов отправляются в Grafana через Prometheus, который собирает и агрегирует данные.
Настраиваются дашборды, которые показывают количество 500 ошибок по различным параметрам, например, по времени или по микросервисам.
Анализ и реагирование:

Настраиваются алерты для критических 500 ошибок. Например, если количество ошибок превышает определенный порог, срабатывает алерт, который отправляется в Slack или PagerDuty для оперативного реагирования.
Вводятся дежурства и отчётность для разборов инцидентов. Это помогает быстрее находить и устранять причины ошибок.

Разнообразие мнений в сообществе
Когда дело доходит до KPI, в сообществе IT нет единой точки зрения. Нет методички, и это делает процесс выбора и внедрения KPI таким сложным. Каждый случай уникален, и неправильное использование KPI может легко навредить, как если забивать гвозди микроскопом. Я проанализировал все 48 статей на Хабре про KPI и выделил 4 наиболее примечательных. Во всех 48 +- одни и те же противоречащие выводы, про которые все и так в курсе. Давайте взглянем на некоторые мнения и подходы, чтобы лучше понять эту тему.

Топ-4 статьи о KPI на Habr
"KPI разработчика: какие метрики можно использовать и эффективно ли их внедрение"
Почему стоит обратить внимание: Статья подробно разбирает различные метрики для оценки разработчиков, акцентируя внимание на балансе между количественными и качественными показателями. Интересные идеи включают метрики безаварийности и попадания в оценку.

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

#полезности
Как ChatGPT может помогать в работе менеджеру

Hello, приятели и подписчики! Давненько однако не выходил на связь. Был в затяжном релизе на новое огромное гео — Индию. This project was really huge and required a lot of my attention. Плюс, разбирался с пошатнувшимся здоровьем, но сейчас всё окей. Кстати, прогрессирую в английском — уже смело могу называть себя A2 💪

Теперь к теме. Хочу поделиться, как джипити помогает мне в работе лидом проектных менеджеров. Компании оплачивает подписку на ChatGPT Plus, и в сочетании с GitHub Copilot это просто бомба для нашего стрима. Вот несколько примеров, как он меня выручает:

1. Резюмирование тредов в Slack и создание задач:
- Иногда в Slack такой хаос, что не разобраться. ChatGPT помогает быстро и точно перевести все эти бесконечные треды в конкретные задачи для команды. Экономит кучу времени и нервы

2. Генерация рисков:
- Загружаю описание новых проектов или ситуаций, и ChatGPT помогает выявить potential risks. Это позволяет заранее предусмотреть возможные проблемы и быть готовым к ним

3. Работа с JQL-запросами в Jira:
- Иногда просто выгружаю задачи в .csv формате и прошу бота написать нужные JQL-запросы или резюмировать их. Хотя AI в Jira тоже помогает, но chat gpt часто выручает, особенно когда нужно объединить сотни задач по сложным критериям

4. Резюмирование записей встреч и больших обсуждений:
- ChatGPT просто находка для резюмирования записей встреч и больших discussions в чатах. Это помогает быстро понять основные моменты и принять необходимые решения

5. Более конкретные постановки задач для системных аналитиков:
- С помощью него я могу ставить системным аналитикам более конкретные и детализированные задачи. Это улучшает качество работы и понимание задач в команде

6. Консультации по ошибкам и работе в разных приложениях:
- Решение багов в приложениях или оптимизация работы с инструментами, такими как WebView или различные SDK, стало проще благодаря джипу. Он всегда дает полезные советы и инструкции

7. Анализ истории изменений документов и статус обновлений:
- Загружаю историю изменений документов, и жипити предоставляет статус updates. Это позволяет быстро получить актуальную информацию о проекте

Ключевые кейсы, где ChatGPT особенно выручил:

- UPI редиректы: Помог найти решение для UPI редиректов в нашем приложении, что значительно улучшило пользовательский опыт (UPI это индийский СБП).
- OAuth авторизация: Предложил решение для проблемы с блокировкой устройства и аккаунта при неудачных попытках авторизации через Google OAuth.
- Live broadcasts: Помог сделать обсуждение интеграции live broadcasts через WebView и SDK более продуктивным, предложив возможные решения и улучшения.
- Конфликты в команде: Анализировал транскрипции встреч из сервиса tl;dv, где обсуждались конфликты между ПМом и тимлидом. ChatGPT помог выделить ключевые моменты и предложил стратегии для разрешения конфликта, что улучшило взаимодействие в команде.
- Технические проблемы с приложениями: Помог разобраться с багами и оптимизировать работу приложения, когда возникали проблемы с GMS на не-GMS устройствах.

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

P.S. Делитесь в комментариях своим опытом использования подобных инструментов и какие еще полезные фишки вам удалось внедрить в свою работу!

P.P.S. Да, тема избитая и я не писал об этом когда трубили изо всех утюгов, просто пришла идея написать и написал)

#иное
Проектный кофе: результаты исследования

Меня тут позвали на один кофетолк, заходите если любопытно)


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

📆 1 апреля, в 19-00
💬 онлайн в zoom
🔗 ССЫЛКА ДЛЯ РЕГИСТРАЦИИ

Артем Летюшев - Lead PM, автор канала Junior PM
Ольга Романова - ex-PMO Газпромнефть, автор канала Про Проекты и карьеру в ИТ
Дмитрий Ирешев - руководитель проектного офиса e-com, автор канала Управление проектами и продуктами в IT

​#мнение
Благодарность за вклад в исследование зарплат 2023

Дорогие читатели)

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

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

- Андрей Малахов | от проектов к изменениям- 902 Менеджера
- Agile events [Online & Moscow]
- Black product owner | Тигран Басеян о продакт менеджменте
- glebkudr
- PMCLUB — про проекты, продукты и людей
- PMP Сертификация
- ROSLOVETS
- Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки
- Берлога РП
Про проекты и карьеру в ИТ
- - Токсичный манагер
- Управление проектами и продуктами в IT
- УПРАВЛЕНИЕ-ПРОЕКТАМИ.РУ
- Черновик будущего

Также отдельная благодарность группам, которые оказали информационную поддержку и познакомили свою аудиторию с этим проектом:

- @meetupteam
- Agile Belarus
- Agile Jobs - Вакансии
- Agile, Scrum, Lean, Kanban, XP
- EnterAgility
- ITMAE Community Chat
- Kanban Talks
- Leanconsult
- PM Lunch
- Project Russia Community
- ПроПроекты Chat
- Продакты СПБ
- Project Managers KZ
- Projects KZ
- Projects Jobs — вакансии и аналитика
- Scrum Community @ Raiffeisenbank
- Scrum Russia
- SPB Product Managers Meetup
- SPB SPM
- TIO: Test interview online ( Project, Product, QA )💯
- Академгородок руководителей проектов
- Гильдия СМ Питера
- Закрытый чат руководителей проектных офисов

Еще раз огромное спасибо всем за ваше ценное участие и вклад в развитие нашего сообщества. Без вашей поддержки это было бы невозможно!

​#мнение
Психолог это мастхев для менеджера

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

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

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

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

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

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

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

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

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

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

P.S.
Я занимаюсь с психотерапевтом уже год. У меня был крайне негативный опыт до этого, так как специалисты вели себя не очень профессионально. Не так давно я решил попробовать еще раз онлайн (нет, здесь не будет нативной интеграции платформ на букву З или Я). В этот раз я все таки изучил как работают психологи, понял что хочу работать с человеком с мед. образованием, поэтому психотерапевт, а не психолог. А также изучил основные методы и понял что для меня подходит именно КПТ и схематерапия

P.P.S. Занятно что изначально я пришел с вопросом развития эмоц. интеллекта, а потом была цепочка переходов эмоц. интеллект→эмпатия→понимание себя→принятие себя→уход от внутренней критики→укрепление здоровой взрослой части. Проделанная работа мне очень помогла в жизни и карьере

#полезности
Вот и появились Результаты исследования проектных менеджеров 2023!

Новые вершины - более 1500 респондентов из 375 компаний приняли участие в опросе. В прошлом году исследование проводили силами всего 2 людей - Димы и Артема, в этом же целой командой - 21 человек. Огромное вам спасибо за это ребята!

Какие инсайты?
⚡ Большинство начинающих менеджеров проектов - женщины;
⚡ Медиана зарплаты без премии в Москве составляет 258.000 рублей. Медиана зарплаты без премии в России (без учета Москвы) составляет 170.000 рублей;
⚡ Наличие высшего образования влияет на размер заработной платы (но совсем немного);
⚡ 2/3 опрошенных получают премии. Чаще всего это годовые, привязанные к результатам по проектам;
⚡ Самые высокие зарплаты в крупных компаниях - если хотите деняк, вам туда;
⚡ Самые популярные сертификации: от PMI и по Scrum.


👍 Ссылка на интерактивный дашборд 2023
🗄 Ссылка на pdf версию

​#мнение

Иллюзии у новичков
Многие начинающие менеджеры думают, что проектный менеджмент – это про организацию процессов, систематизацию хаоса и выстраивание долгосрочной системы. Он, прежде всего, требует индивидуального героизма. Работу проектного менеджера хорошо описывает сказка про Федота Стрельца - “пойди туда не знаю куда принеси то не знаю что”

Работая над проектом, ты сталкиваешься с некой здоровенной инициативой, у нее определена цель(ХА!), ограничен бюджет (чаще всего айтишный ПМ про него не в курсе), жесткие сроки и минимальным объемом работы (двойное ХА, он будет постоянно расти), при этом не всегда ясно, как достичь поставленных задач

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

Также многие думают, что PM – это супер востребованная, оплачиваемая и уважаемая работа

Во-первых. Соотношение менеджеров на вакансию редко бывает ниже 50 к 1. Обычно больше. Я чаще всего сталкиваюсь с тем что в день, даже не синьорские позиции приходит ближе 80 откликов и только 6-7 из них проходит фильтр hr. Вакансий относительно немного, требования часто неадекватные. На дуде-игрец, это про среднего ПМа с вакансий на hh
Во-вторых. Стоит сразу привыкнуть, что зарплаты твоих подчиненных будут выше. Аналитиков и разработчиков так точно. Даже смежные продакты будут получать больше с тем же опытом или ниже

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

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

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

P.S. От каких иллюзий пришлось отказаться, когда ты стал PM или просто попал в айти айтишным PM?)
P.P.S. Не стесняйся писать в комментриях)

#perl

(Да, нормальный пост будет в ближайшее время)

#полезности
🔥 Повторим исследование зарплат руководителей проектов. Только больше и круче!

Цель: выяснить зарплаты руководителей проектов и факторы, от которых они зависят, по выборке больше 1500 респондентов до 20 января 2024 года

Прошлогодний рекорд не побит - 564 чел 💪 Давайте поднажмем в этом году 🚀

Ссылка на опрос (~5 минут)

#полезности
Обучение найму от очень крутого товарища
С Артёмом я знаком давно, и Артём мне очень нравится. Судя по тому, что он разрешил запостить в свой канал инфу о том, что я делаю обучалку — видимо, я ему тоже кажусь неплохим в плане знаний о менеджменте 🙂

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

Вот эту большую проблему найма и хочу я с Ярославом Астафьевым постепенно помочь людям порешать.

Организовали что-то вроде курса, 13 двухчасовых созвонов-занятий, первое занятие уже в эту пятницу.

Осталось 3 места, если кому интересно — приходите, будем рады!

Больше инфы тут: https://t.me/vsharovatov/356

​#мнение
Норма управляемости
Привет, читатель 🫶. Рад к тебе вернуться)

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

Это норма управляемости. Занятная штука, которая сводится вот к чему - какой количество объектов управления может потянуть субъект управления. Те сколько подчиненных может иметь у себя руководитель

Ее можно записать как конкретным числом, например 5, так и интервалом 7+-2. Кстати последнее - это число Миллера, которое в том числе упоминает скрам как рекомендацию размера команды. Сначала его обнаружили при экспериментах над краткосрочной памятью, а потом подтвердилось что это удобное для мозга количество людей, на котором удается удерживать фокус внимания без существенной потери качества коммуникации

Норму управляемости можно посчитать 3 разными способами:
- Взять из справочника по экономике. Для нематериального инженерного труда (привет, айти!) на исполнительном линейном уровне она равна от источника к источнику 5-8 и 6-10;
- Рассчитать по формуле Розенкраца (или ее аналогах);
- Эмпирически, посмотреть в целом при какой конфигурации количества подчиненных лучше всего

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

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

Если вдруг ты задумался, а что если у меня 20 человек и я еле-еле их тяну, что делать, то ответ прост - делить команду. Например на 3. Дальше 2 пути - самоуправление и повышение уровня управления. Первое высший пилотаж, однако требует больших инвестиций времени, второе сводится к тому что в каждой новой после деления команде должен появиться свой руководитель, который будет уже подчиняться тебе

P.S. Ты можешь стимулировать выпуск поста и вообще упростить постинг, если задашь вопрос используя почтовый_ящик

#иное
Мало кто знает, но каждый 1 четверг ноября это один важный праздник)

#perl
Рабочая рутина