Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации с Хабра, VC (и не только) и выбрали самые крутые и полезные. Читайте аннотации, сохраняйте и применяйте!

Основы управления проектами и роль менеджера проектов

Важные элементы при работе в Scrum
Статья на самом деле про роль и структуру спринтов - этапы, планирование, продуктовые инкременты, роли в команде и результат (продуктовый инкремент).

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

Как мечтать быть переводчиком, а стать Project Manager-ом и быть счастливым
Очень интересный опыт карьерного трека, от разработчика к продакту, затем к проджекту и… Куда-то дальше. Признаюсь, завидую автору, которая очень много успела сделать за 10 лет

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

«Когда будет готово?». Декомпозируем задачи и оцениваем сроки без фатальных ошибок
Прогноз по срокам всегда будет ошибочным, но как сделать его более реалистичным? Поможет декомпозиция, - технологическая (раскладываем по частям технологию решения) и маршрутная (идем по этапам пути пользователя). Первый хорош, когда вы владеете темой, второй - когда знаний мало и приходится отталкиваться от user-story. Ну, и конечно, третий смешанный вариант. Также автор пишет про критический путь и модель наивных сроков, когда каждая задача якобы занимает не больше одного спринта.

Как провести демо: о подготовке, презентации и способах работы с обратной связью заказчика
Два этапа - “подготовка” и “экшен”. Начинаем со сценария (демо-документа), думаем, что именно подсветить/показать на демо, готовим среду для демонстрации, распределяем роли, тренируемся на кошках (репетируем на своих), делаем чек-лист готовности. На самом демо - задаем правильные ожидания, упаковываем в нарратив, собираем фидбек. В целом, добротный мини-гайд по встречам с заказчиком.

Заметки для новичка: Как провести первую ретроспективу и не облажаться?
Про организацию ретро, от планирования и до фиксации результатов, с шаблонами и примерами. Правда, в комментариях уже написали: “Шаг #1 - Удаляешь ретроспективу у всех из календаря; Шаг #2 - Все счастливы и работают”.

Как писать требования к проекту. Шаблон документации
Подход автора: 1) BRD&SRS (цели, история, потребности, ценности, стейкхолдеры, границы, ФТ, НФТ), 2) бизнес-логика (диаграммы, API, компоненты), 3) UI-логика (UI экранов, локализация, навигация), 4) продуктовая аналитика и логика (метрики, события, логи).

Просветлённый выживший: кто такой фичекрайний и зачем это всё разработчику?
Еще одна роль, - она прижилась в 2ГИС, но, судя по статье, это что-то между проджектом и продактом. Тот, кто ответствен за доставку фичи и кому приходится вникать во все продуктовые и технические сложности ее реализации.

Как эффективно планировать проекты и не тратить на это недели: гайд для современных проджектов
Из “современного” - про использование ИИ-инструментов для транскрибации митингов, составления целей и этапов проекта, визуализации декомпозиции и даже составления диаграммы Гантта. Инструментов перечислено много, часть можно потестить бесплатно и даже без VPN.

Как избавиться от синдрома самозванца, перестать себя обесценивать и бояться участвовать в крутых проектах
“Синдром самозванца” - широко известная и уже мемная штука, но автор дает несколько практических советов, как преодолеть страх и неуверенность в своих силах.

Команда проекта

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

Чем отличаются «мягкие» навыки (soft skills) от «жестких» (hard skills) и как их измерить?
Очередной экскурс в хард/софт-скиллз. Увы, пропитан рекламой, но зато обоснованно ставит “управление проектами” в ранг hard skills.

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

Релиз-менеджер — почему он вам нужен
Или не нужен. Статья - про роль менеджера, ответственного за выпуск релиза. В случае автора - выделенный человек, но чаще - как одна из функций ПМа или тимлида. Описан воркфлоу выпуска релизов в RuStore.

Быть жестким, но не жестоким: как разойтись с сотрудником по хорошему?
Несколько лайфхаков и советов по организации расставания с сотрудником. Из оригинального - совет не увольнять перед выходными, т.к. (цитата) “ваш уходящий сотрудник будет снедаем чувствами потери и страха за будущее все выходные до понедельника, где он, наконец, сможет начать общаться с другими работодателями”.

Оффбординг и точка + чек-лист с вопросами после расставания
И еще один текст про увольнение, главная ценность - опросник для уходящего сотрудника из 10 пунктов.

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

Опыт и кейсы

Сферический конь в вакууме: как (не)работает Agile в России
Порция примеров, когда не нужно использовать “аджайл” в компании и в команде, - в основном, про соответствие подхода цели и культуре компании, освобождение от культа новизны.

Поезд «Jira – Kaiten». Путь Х5
Прекрасный рассказ про импортозамещение джиры, - что им занимаются не только стартапы, но и крупняк. У X5 все получилось, миграция прошла успешно, что-то доработал

Нет, мы так не работаем
Кейс: вы - проектная команда на аутстаффе, делаете свою работу, а у заказчика внезапно меняется продакт (или ПМ на стороне заказчика), у которого совсем (!) другое видение и стиль работы. И все идет не по плану. Что делать? По опыту автора, такую проблему можно успешно локализовать.

Их Айти VS наш Айти: чем отличается разработка в Европе и в РФ
Коротко: в Европе нет универсальной системы грейдов, разработчики сами ставят себе задачи, тестировщиков часто нет, к багам относятся терпимее, редко двигают дедлайны, а переработки вызывают непонимание. Ну и ЗП внезапно побольше)

Лист бумаги, матрица Эйзенхауэра или таск-трекеры: опыт синьора из «Майкрософта»
Про инструментарий для эффективной работы. Для задач - бумага и ToDoist, для контроля бесполезной активности - RescueTime и Toggl Track. Результат - рост продуктивности.

YouTube

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

О работе аналитиков (и ПМ) с бизнесом - зачем мы ему нужны? Чего заказчики от нас хотят? Почему они иногда ведут себя странно? И как можно выполнить работу и выполнить задачи, не сойдя с ума.

Что такое Job crafting и как его применять при развитии информационной системы компании.

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

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

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

Кто виноват в конфликте бизнеса и IT, на какие грабли не стоит наступать и каким принципам следовать для решения.

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

Архивы дайджестов и новые материалы - в телеграм-канале "Проектный дайджест".