Что интересного писали про управление проектами за неделю? Мы прочитали все публикации с Хабра, VC (и не только) и выбрали самые крутые и полезные. Читайте, сохраняйте и применяйте!
Основы и гайды
Роли при использовании фреймворка Scrum
Коллеги из Product Lab - про основные роли скрама (Product Owner, Scrum master, Development team) - с примерами и деталями.
Да, внезапно она тоже нуждается в изучении - Waterfall все так же востребован и популярен. Этот материал - вводного характера, с описанием преимуществ и недостатков подхода, современного состояния (кому и для чего нужен).
Сохранить время и деньги: как прототипирование помогает разработке цифровых продуктов
Солидный, с хорошими примерами текст про MVP и прототипы, от основ и до инструментов реализации.
Метрики, которые действительно имеют значение
Продуктово-проектные метрики - основные особенности и применение. В фокусе - North star, бизнес-метрики (CAC, CLTV, MRR, Churn [отток]), метрики использования продукта (NPS, CSAT).
Мозговой штурм. Зачем он на самом деле нужен бизнесу
Сам метод в представлении не нуждается, а вот его эффективность - под большим вопросом.
Команда Scrumtrek - про эффективность мозговых штурмов, роль фасилитации в них, основные техники проведения.
Навыки, инструменты и карьера менеджера проекта
Материал спорный, но полезный. Во-первых, неплохо понять, какие вопросы будут задавать менеджеры и HR на собеседованиях; во-вторых, можно понять, к каким вопросам будут готовиться кандидаты; в-третьих, можно прийти к выводу, что все эти вопросы - не более, чем один из инструментов отбора, и далеко не определяющий.
Хороший менеджер — мертвый менеджер!
Текст от Владимира Завертайлова (Sibirix) - про то, как не стать наказанием для своей команды и в итоге для себя. Многие менеджеры горят клиентоориентированностью - и в стремлении помочь клиенту прямо сейчас и вопреки всему разрушают команду, заставляют специалистов менять продуктивный график на “форсмажор” и т.д. Автор аргументированно выступает против этого, и если именно такой “болеющий за клиента” менеджер, то текст для вас!
Почему лучше нанимать Project Manager из технических специалистов, чем управленца «с улицы»
Немного провокационный материал, который нельзя не привести в этой подборке. Позиция авторов - лучше свой технарь, хорошо знакомый с проектом и продуктом, чем сторонний гуманитарий, который легко наломает дров. В комментариях к статье - аргументы в пользу обратного)
Что поможет руководителю: рукопашный бой, серебряные пули, ловушка?
Немного теории, немного кейсов, немного воды, но в целом - про фигуру “руководителя”, его инструментов и роли в команде. Акцент на тайм-менеджменте, постановке задач, коммуникациях, а также профессионализме в предметной области.
Треугольник орг-структур компании. Часть 2 Примеры орг-структуры проектного офиса
Большой и непростой материал про построение и декомпозицию оргструктуры. Автор разбирает на примере проектного офиса функциональную, процессную, матричную и разные гибридные структуры.
Почему я больше не делаю важные дела: и еще 3 правила как не потерять себя к 40 годам
Да, не прямо про проджектов, но сами идеи интересные, дискуссионные и применимые. Кратко: гнаться за успехом и “следом в истории”, жертвуя собой и близкими, - это сомнительно. Жизнь коротка, нужно сфокусироваться на узком круге профессиональных вопросов и не отвлекаться на остальное. При этом выбранные дела могут быть тоже гигантскими, - и для этого нужно развивать навыки декомпозиции. Интересна не только сама статья (да, она довольно банальна), но и комментарии к ней - посмотрите.
Пост МТС про инструменты бизнес-анализа, в числе упомянутых - Perspective (визуализация больших и потоковых данных), Quary (платформа для моделирования данных и построения запросов), Redash (объединение данных и диаграммы), Evidence, OpenRefine и другие.
Какую систему управления требованиями выбрать: обзор инструментов
Да, многие ведут в Jira и Confluence (и аналогах), но существуют и специализированные инструменты. Авторы системно подошли к вопросу и проанализировали полтора десятка разнообразных сервисов и платформ по перечню показателей. В лидерах - Jama, Visure, ReqView, а также российские DevProm и Техэксперт.
10 шаблонов промптов для ChatGPT, которые помогут вам в управлении проектами
Как использовать ИИ в работе, если вы не писатель текстов: первые шаги
4 шага к AI Power User: как стать продвинутым пользователем ChatGPT
Целых три содержательных публикации про ИИ для менеджеров проектов (и не только). Первый - собственно промпты, от планирования и составления графиков и до поисков мотивации для команды. Два других - фундаментальный подход к теме, подробный и популярный гайд по работе с ChatGPT, который менеджеры задействуют в работе все чаще и чаще. Много примеров “правильной” работы с ИИ, которая сделает из него не развлечение, а почти что полноценного ассистента.
Команда проекта
Отвлекать программистов от работы — гораздо страшнее, чем кажется на первый взгляд
Переводной материал про deep work (сосредоточенную работу) VS работа без концентрации в контексте командного взаимодействия. Число совещаний растет, сотрудники вынуждены заниматься сразу несколькими делами, отсюда и проблемы - доля deep work падает, потока не возникает, а значит, все работают медленнее и хуже. Кроме критики, в статье есть и вполне конкретные рекомендации по изменению культуры встреч и совещаний в компании/команде, а также советы по развитию навыка погружения в работу.
Как упорядочить работу в команде с помощью визуализации
Сбер рассказывает про свои секретные методики полезной визуализации. Кратко: в ситуации, когда нужно сформировать видение и понимание проекта у всех участников, нужно визуализировать задачи, затем, “стоя у доски”, договориться, что делать в первую очередь, отметить те точки, где видны командные потери, - ну и вообще фиксировать на такой доске все этапы работы над проектом.
Влияние ретроспективы на продуктивность команды: все о методике и как она проводится во Fusion Tech
Ретро бывает разным, подчас вообще в непривычном формате и непонятно зачем, - и коллеги решили раскрыть рецепт идеального ретро. Охваченные аспекты: подготовка (и её фазы), этапы, инструменты (Metro Retro и ClickUp), частота проведения, влияние на продуктивность (сугубо позитивное!)), примеры ретро.
Чем занимается IT-архитектор: фантазии коллег и суровая реальность
Еще один текст от МТС, в котором автор сетует, что даже в больших и сложных командах роль архитектора остается неясной. Типичные мифы: архитектор - это техпис; архитектор - это аналитик; архитектор не кодит, а значит, не имеет права решать задачи; архитектор не должен заботиться, какими именно данными будет наполняться система. Всё это, пишет автор, совершенно не так, - и пошагово определяет, чем же должен в компании заниматься архитектор и как правильно сформировать нужное понимание его работы в команде.
Кто такой ИТ архитектор и чем отличается от линейного инженера?
Внезапно еще раз про архитектора, но уже с другой стороны. Якобы на архитекторов много вакансий, и причем все они скорее про инженеров. Автор считает, что главное отличие архитектора от инженера - это способность самостоятельно проанализировать ситуацию, спрогнозировать данные/сценарии и предложить обоснованное решение проблемы. Позиция не очень прозрачная и очевидная.
Онбординг без стресса. Зачем Бадди и Наставники в ИТ
Отбординг: как (не)правильно онбордить, чтобы от вас максимально быстро сбежали сотрудники
Два материала про онбординг. В первом своей практикой делится банк, столкнувшийся со страшной цифрой - 26% принятых на испытательный срок айтишников сливались. Помогла культура “наставников” (помогаторы уровнем выше) и “бадди” (помогаторы с того же уровня, что и новичок). Детали смотрите в публикации, но в целом вроде помогла - отток новеньких снизился вдвое за год.
Во втором тексте - любимый жанр многих авторов, “вредные советы”: не представлять сотрудников, не давать информации, перегрузить работой, не давать обратную связь и т.д.
Опыт и кейсы
Отвага и отвага: как мы выбирались из полного абзаца с неработающей ERP на 39 производствах
Снова кейс от ОМК ИТ - и снова отличный текст про внедрение информационных систем (1С: ERP) на производственном гиганте. Если до этого история была про падение (думали, что получится быстро реализовать проект, но не тут-то было), то здесь - позитивный рассказ о преодолении проблем. Акцент - на работе с людьми (и командой, и стейкхолдерами, и пользователями), на погружение в предметную область, на решении технических вопросов.
ГК ЛАНИТ - про внедрение сервис-деска, проблемы и их решение. На мой взгляд, очень полезный и честный материал, полезный любому проджекту. Ну, а если вы работаете с ITSM, то тем более.
Работа по методу: как методологи облегчают IT-разработку и ускоряют вывод новых продуктов на рынок
Кейс одного Г-банка про выделение в структуре компании отдельного дивизиона (роли, статуса) методологов. Они стали отвечать за методологическую основу ИТ-разработки, документируют, упрощают и переводят на человеческий язык архитектурные паттерны, выбирают лучшие практики и масштабируют их на всю компанию и т.д. Результат - рост продуктивности разработки.
Test Driven Development в Embedded, или Как увеличить производительность команды на 37%
Яндекс про TDD, условия для его применения в команде и влияние на показатели эффективности разработки (скорость, число багов и т.д.).
Как бережливое производство и prince2 ускорили разработку в 1.5 раз (лонгрид)
Очень развернутый кейс использования lean и PRINCE2 на проекте.
Agile по-конструкторски: как работает, зачем нужны встречи каждый день и кто отвечает за факапы
Интересный рассказ про “натягивание” аджайла на строительные проекты. Было сложно, но якобы существенно выросла эффективность и в коммуникациях, и, главное, в самой стройке. Возможно, сейчас вы живете в квартире, построенной по Agile…
Вот такой была неделя публикаций о проектах. Если вдруг мы пропустили интересный материал — делитесь им в комментариях.
Архивы дайджестов и новые материалы - здесь (дайджесты ведутся еженедельно с начала 2023 года).
uzverkms
В статье про "Введение в водопадную модель" написан горячечный бред. Автор якобы цитирует статью Ройса, но очевидно не читал её. Иначе бы не писал такие глупости. Ройс как раз писал, что давайте представим последовательную разработку - так не работает. И далее размышлял о более реалистичном варианте.