Управление проектами: дайджест публикаций за неделю
Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации с Хабра, 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, на какие грабли не стоит наступать и каким принципам следовать для решения.
Вот такой была неделя публикаций о проектах. Если вдруг мы пропустили интересный материал — делитесь им в комментариях.
Архивы дайджестов и новые материалы — в телеграм-канале «Проектный дайджест».
