Управление проектами: дайджест публикаций
Что интересного писали на этой неделе про управление проектами? Мы прочитали все публикации и выбрали для вас самые крутые и полезные. Читайте, сохраняйте и применяйте!
Основы и гайды
В мире победившего эджайла, SCRUM, как один из наиболее популярных методологических фреймворков, казалось, имеет все шансы стать отраслевым стандартом. Однако в результате врождённых недостатков она стала чем-то средним между религией для занятых проектным управлением и воздухом для продажи эджайл-коучами.
За кликбейтным названием - статья про положительные стороны скрама (и его пользу) и про негативные: сложности с адаптацией, негибкость, высокие затраты на внедрение. Особенно достается скрам-мастерам, из-за неопытности и избыточности которых проекты идут ко дну.
А для тех, кто не хочет дискуссий - вики-материал про историю скрама, роли скрам-команды, принципы фреймворка, отличия от канбана и бонусом - инструкция по внедрению скрама в управление проектом.
Добротный гайд по работе с бэклогом: для чего нужен, как формируется, как приоритезировать (MoSCoW). В качестве примера автор взял подготовку к подходу в магазин - пример не идеальный, но понятный.
Если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным.
Текст от разработчиков Компас-3D, среди инструментов повышения / достижения качества - декомпозиция требований, использование и тщательная подготовка и приоритезация user-story, управление изменениями требований.
Материал скорее для стратсессий, портфельного управления проектами и поиска новых решений. Эвристический подход, который позволяет команде анализировать текущую ситуацию и определять приоритетные направления и новые фичи.
Коллеги из Naumen выбрали 6 частых ошибок сбора требований. В том числе: не звать на встречу функциональных (?) пользователей, не выяснять детали, не фиксировать для всех договоренности, использовать размытые формулировки, соглашаться на нереализуемые требования, а также не использовать блок-схемы.
Рецепт авторов - фреймворк P3.express, один из самых молодых в проектном управлении. В статье дается пошаговый гайд по его применению на примере софта Directum Projects.
Интересный текст про сторипойнты (если кто забыл, это способ/единица оценки задач, принятая в гибких фреймворках). Автор честно признается, что принятые абстрактные СП (которые “в попугаях”) работают плохо и эффективны менее, чем “конкретные” СП, выраженные в часах и днях. В итоге получилось, что термин “СП” в команде остался, но по сути был подменен на привычные “трудозатраты в днях” (один сторипойнт = 1 день). В комментариях отметили, что СП - прежде всего для задач с высокой неопределенностью, но, похоже, подмена СП на человекодни - это общая практика)
Менеджер проекта
Руководитель проектов должен соблюдать границы проекта, он не волшебник. У него нет бесконечного бюджета и сроков, а значит, иногда придется спорить и отстаивать границы. А значит, говорить «НЕТ». Как это делать так, чтобы не разрушать отношения на проекте, в команде, на аккаунте, а, наоборот, их укреплять?
Кратко: не говорить «нет», а говорить «давайте поглядим, что мы можем сделать».
Автор считает, что грейды могут быть не только у разрабов, но и у менеджеров, и приводит свою таксономию, что должен уметь джун/мидл/сеньор-проджект. Все основано на реальном опыте и собесах. При этом внезапно РП-джуны у него могут рассчитывать на зарплату в 180 - 230k…
Если вы устали от рутины и хотите “расширить сознание” (и заодно доход), то автор советует изучить несколько полезных тем (и дает рекомендации, на что обратить внимание), в том числе базы данных, интеграция и API, PlantUml, Python etc.
Рассказ РП о своем карьерном пути - что помогло, что помешало, как за 9 месяцев из гуманитария стать типа настоящим “проджектом в ИТ”.
Статья от Авито, чей подход к менеджменту лично мне очень симпатичен. Эта статья детализирует роль техлида и показывает, что главным в ней становятся не столько технические навыки, сколько навыки развития команды, планирования, взаимодействия с подрядчиками, декомпозиции задач и ответственность за реализацию фичей.
Все РП знают эту проблему - поток информации и необходимость коммуникации с командой и заказчиком сносит на своем пути все “помидоры” и другие техники фокусировки. Автор рассказывает о своих удачных (и неудачных) инструментах, которые позволяют сохранять “мыслетопливо”.
Для тех, кто любит подкасты - 1,5-часовой разговор с опытным РП на больные темы: как строится рабочий день РП, как решать конфликты, на какую ЗП рассчитывать, что делать, если коллеги игнорируют, надо ли сертифицироваться, куда расти и т.д.
Команда проекта
85% успеха на работе зависит от социальных навыков и умения работать с людьми. И лишь 15% приходится на технические навыки, то есть то, что мы
Материал о том, как развивать эти самые софт-скиллы у команды и (шире) сотрудников компании от Яндекса. Основное: вводите практику обратной связи, формируйте комьюнити с общей микрокультурой , поощряйте межкомандное взаимодействие, предлагайте задачи за рамками прямой ответственности - и поменьше гиперконтроля.
“Круглый стол” о сценариях роста СА. Можно стать “лидером компетенции”, который отвечает за развитие компетенций других СА в команде. Можно - “solution-архитектором”, стоящим на границе между техническим решением / техническими специалистами и бизнесом. И можно Product Owner’ом, - в этом случае новой задачей станет определение точек развития и привлекательности продукта.
Про трудности онбординга и авторские рецепты его оптимизации. Онбординг делится на две категории - общий (в компанию) и локальный (в команду), со своими разными наборами активностей. Заниматься им нужно не ad hoc, а целенаправленно, с актуальными инструкциями. Важно формировать и транслировать сотрудникам правильные (адекватные) ожидания и не забывать делать промежуточный контроль. В целом, материал большой и полезный, безусловно рекомендую.
Про важность общих целей для команды - и про то, что весьма немногие действительно заботятся о формировании общей “целевой культуры” в коллективе.
Все мы разные, со своим подходом к работе, своими циркадными ритмами (жаворонки/совы), своими горизонтами планирования и т.д. Как только разные люди объединяются в одну команду, встает вопрос о синхронизации работы, без которой неизбежно возникнут проблемы. Материал о том, как сделать команду из участников с разными стилями работы продуктивной.
Опыт и кейсы
Когда наша команда начала расти, мы заметили, что поддерживать документацию актуальной стало сложнее, а связанные с этим проблемы только усилились. Например, на релизе происходил полный хаос: результат не соответствует первоначальной задумке; половина сотрудников не в курсе, что должно было получиться; тестировщики отмечают баги, которых нет, потому что используют устаревшую информацию. Приходилось останавливаться и объяснять каждый момент отдельно, рискуя сорвать дедлайн.
Как преодолели: тщательно продумали структуру, встроили документацию в производственный процесс, сделали удобные шаблоны, организовали непрерывную актуализацию.
Lamoda использует для приоритезации фич/инициатив показатель ROI - коэффициент окупаемости инвестиций. Не продуктовые метрики, а вот именно “за сколько времени окупятся затраты на фичу”. Публикация раскрывает, как в компании устроен процесс оценки ROI фич, как работает команда таких оценщиков, как инициативы превращаются в проекты.
Сотрудник металлургического завода - о том, как реализовали для производства проект автоматизированного мониторинга цвета (и соответственно стадию готовности) руды в процессе сепарации.
Инструменты
Инструмент для продактов, но взглянуть на него можно и остальным. Product brief состоит из 5 полей - аудитория, проблема (точка роста), гипотеза, решение, метрики.
Демонстрация реального использования сервиса для управления ИТ-проектами, с картинками и примерами.
Попытка сравнения трекеров - рабочее пространство, инструментарий, работа с задачами и командой, ведение документации и т.п.
Да, там личный опыт использования. Любопытный, конечно, мув в сторону Трелло (в нынешних условиях), но в итоге остановились авторы на другом отечественном сервисе.
Авторская методология, похожая (и родственная) на карту историй Александра Бындю, развивающая технику User Story Mapping.
На фоне проблем с Miro - еще один текст про “импортозаменители”. В списке - Эсборд, Pruffme, GetLocus, МТС Линк, Flip, Microboard.
Расширенная презентация сервиса от разработчиков.
Про то, зачем wiki и для чего, какие типы могут быть, а также как создать эффективную wiki - пошагово, от определения аудитории и до управления актуализацией. Плюс выборка сервисов для их создания.
Спасибо, что прочитали! Если вдруг мы пропустили интересный материал — делитесь им в комментариях.
Архивы дайджестов, новые материалы, обзоры книг и курсов для РП и аналитиков - здесь.