Что интересного писали про управление проектами за неделю? Мы прочитали все публикации с Хабра, VC (и не только) и выбрали самые крутые и полезные. Читайте, сохраняйте и применяйте!
Scrum — рак, убивающий индустрию
Статья-мнение, вызвала очень бурную дискуссию. Скрам стал индустриальным стандартом, но, по сути, отошел от своих корней – agile-философии с ее гибкостью. Вместо этого мы получаем жесткие церемонии и процедуры, неприменимость к задачам, требующим сложных исследований (R&D вообще) и… остались разве что церемонии. В отличие, например, от kanban-фреймворка, который работает эффективнее.Так считает автор, комментаторы его поправляют и критикуют, но, судя по всему, фандом скрама сокращается. 
Ловушка фичеризма: почему продукт страдает, когда мы зациклены на функциональности
Переводной материал, – про то, что мы часто фокусируемся на фичах, делаем фичи мерилом эффективности команды и роста продукта/проекта. Как и все гипертрофированное, это приводит к “фичеризму” – накачиванию продукта новыми фичами в ущерб доработке и исправлению уже действующего функционала и пользе продукта в целом.
Как составить бюджет ИТ-проекта?
Небольшой гайд по составлению бюджета проекта, – правда, некоторые риски и возможные затраты не учтены.
Что такое матрица RACI? Как этот инструмент управления проектами может повысить производительность
Инструмент определения ролей/ответственности на проекте – известный, широко применяемый. Статья рассказывает про его плюсы и минусы (долго внедрять и можно столкнуться с неоднозначными ситуациями).
Как измерить эффективность разработки через метрики?
Про метрики эффективности команд, разработки в контексте потока создания ценности, – включая метрики скорости и гибкости, результативности и т.д., а также про способы и инструменты замера метрик (Aimger).
Канбан против хаоса. Как наладить бизнес-процессы на примере реального кейса
Кейс комплексной оптимизации WIP в канбане и работы с задачами в целом от коллег из Scrumtrek. На задачи тратилось много времени, оценка исполнения конфликтовала с реальным временем, не было понимания, сколько в реальности займет выполнение задачи, – и пришлось много анализировать, считать и реорганизовывать и саму доску, и отношения с заказчиками.
Как ускорить разработку?!
Живой и интересный текст от Владимира Завертайлова, главы “Сибирикса” и автора хорошей (но специфичной) книги по менеджменту проектов. По теме – ускорить (или нет) процесс разработки можно разными способами, и один из них – проводить экспресс-ревизию проекта. От “оно мне/нам надо” и общего вайба до оценки технического долга, корректировки планов и амбиций.
6 лучших фреймворков для приоритизации задач по Agile
Отличный материал, – коротко и понятно про MoSCoW, ICE, RICE, Planning Poker, Cost of Delay, модель Кано.
“Проектное управление. Как правильно делать правильные вещи” Павла Алферова
Мой обзор на недавно вышедшую книгу, в которой предлагается новая методология, учитывающая “российскую специфику”.
Процесс работы с требованиями и роль проджекта
Вместе с постом про типологию требований – неплохой текст про управление требованиями и зону ответственности ПМа, на примерах из ИТ (разработка мобильного приложения) и ивент-менеджмента (конференция).
«Я стал тимлидом и боюсь». Что почитать и зачем
Среди книг для погружения в флоу менеджера разработки и проектов автор отмечает не только “Высокоэффективный менеджмент” Эндрю Гроува или недавнюю “Карьеру Software Engineering Manager”, но даже и «Большую книгу общения с ребенком»Юлии Гиппенрейтер, которая учит, как внимательно слушать коллег и как выявлять в них лучшие качества.
Сколько яиц у Волка: автоматизируем списание времени менеджеров на проекты
Про учет трудозатрат менеджера – в целом и с использованием конкретного инструмента (и да, это эксель!). Автору помогает не только учитывать, но и прогнозировать затраты на участие в проекте.
Методика «Eat that frog», принцип Парето и матрица Эйзенхауэра: инструменты для управления приоритетами и временем
Тоже про нужную всем штуку – самоуправление и контроль за временем. Выделенные три инструмента многим известны, и автор считает их проверенными и эффективными.
Как работать эффективно, если ты тревожный человек
Серьезная тема, важная для многих ПМв, которых я знаю. Автор – не психолог (хоть и цитирует выступления профессионалов и опирается на множество источников), и опираться только на ее рекомендации не следует, но попробовать применить приемы и методики снятия тревожности можно. Часть текста посвящена не менее важному – работе руководителя с тревожными сотрудниками. 
Как IT-специалисту расспрашивать экспертов, чтобы развиваться профессионально и извлекать знания?
Небольшой гайд по нужному навыку – быстрому освоению новой предметной области. Акцент на общении и правильном задавании вопросов профессионалам – это полезно как для собственно самообразования, так и для налаживания взаимопонимания и “химии” в команде.
Жёсткое руководство
Тот случай, когда подпишусь под каждым словом автора, – хотя он совсем даже не одинок и ничего революционного не провозглашает. Вкратце – есть тренд на “жесткий менеджмент” и быстрое достигаторство с неявным акцентом на кратковременные результаты. Результаты достигаются, лидеры идут на повышение, люди выгорают, компании закрываются или деградируют. Разумная противоположность этому – менеджмент через культуру и нарративы. Не “жесткая рука”, которая быстро наводит порядок, а “мягкая” рука, которая дольше, чем иногда хотелось бы бизнесу, прививает ценности и видение команде. 
Как вывести проект из состояния «пожара»: пять шагов
Напоследок – мини-руководство по выведению проекта из кризиса для тех, кому такие “горящие” проекты достались. Общий план действий банален, но рационален: проанализировать ситуацию, оценить плюсы/минусы команды, понять рабочие процессы, разобраться с текущим результатом работы – ну, и построить план нормализации)
Что делать, если Заказчик постоянно генерирует новые «хотелки» по ходу проекта
Практические советы на тему бесплатных “хотелок” и “правок”: закладывать на них 3-10%-ный буфер в стоимости контракта, делать аудит/ предпроектное обследование/ пилотный проект, сделать MVP и т.д. Ну, и лучшая “капитанская” рекомендация – не соглашаться на всё подряд)
Правки не бесят, если умеешь с ними работать. Основные тактики и приемы
И еще на похожую тему, от коллег из Agima. Правки (лучше называть их “замечаниями”) – это норма, у них могут быть вполне обоснованные причины, и лучший способ работать с правками – это готовить проект и документацию так, чтобы их минимизировать. А те, что все-таки возникли, нужно поместить в рамки “жизненного цикла” (управления). Авторы дают огромное количество конкретных рекомендаций по работе с правками – рекомендую!
Техдолг: как разгребать задачи, чтобы не тормозить развитие продукта. Инструкция с шаблоном
Практика закрытия техдолга внутри большой команды – используют Pipedrive Agile Framework, а с бэклогом работают на базе RICE. В итоге получилось выйти из большой ямы.
Аналитика на госпроектах – это не страшно
Факапы аналитиков: где они обитают? Кейсы Mad Brains
Про недушных аналитиков
Три интересных материала про аналитиков в команде. В первом – про от ГНИВЦ, которые рассказали, как им удается преодолеть пугающий многих специалистов “гос”-имидж (ТЗ по ГОСТам, бюрократия, устаревшие бизнес-процессы и прочее). Коротко: у них тоже “всё как у людей”.
Второй – серия занимательных факапов, когда аналитика проводилась не так, как следует. Ну, а третий – наставление аналитикам, как не быть “душным” (негативно воспринимаемая дотошность и неуместность замечаний и рекомендаций).
Собрать фулл-хаус: создаем идеальную команду на основе групповой динамики
Как знание распределения ролей в группах и понимание их динамики может спасти тимлидов. Про ролевую модель Белбина и групповую динамику (модель Такмена).
Отвага и отвага: замена ERP на действующем вагоноремонтном производстве с тестами прямо в бою
Шикарный кейс от ОМК-ИТ – переход своими силами на 1С:ERP вместо SAP, когда всё пошло не так, оценки оказались неверными, подготовка обнулилась – но с хэппи-эндом.
Agile с приставкой «Сбер»: как Sbergile меняет подход к созданию продуктов
Не знаю, что заставило Сбер внезапно написать статью на vc про знаменитый свой “эджайл” (с), – видимо, потребность в кадрах. Сам материал короткий, со ссылками на манифест, краткой историей внедрения гибких методологий в банке, и вот, собственно, с описанием сберджайла в виде принципов работы.
Когда говорила про Agile в инжиниринге, коллеги крутили у виска. Теперь на нашу систему смотрят с завистью
Про переход на гибкие методологии не в IT, – оказалось вполне реально, полезно для бизнеса, хотя и с шероховатостями.
Вот такой была неделя публикаций о проектах. Если вдруг мы пропустили интересный материал — делитесь им в комментариях.
Архивы дайджестов и новые материалы – здесь (дайджесты ведутся еженедельно с начала 2023 года).

Бизнес-анализ, IT, медиа
Ваш аккаунт
Разделы
Информация
Услуги

source