🔥 Заждались? С вами снова самые интересные материалы по управлению проектами за 2 недели

1/2

🔫 Великая иллюзия Agile: как индустрия променяла инженерную науку на средневековый эмпиризм Тадам - и снова у нас радикальная критика Agile. Автор обвиняет индустрию в мнимой победе: классическая инженерия якобы вовсе не требовала двигаться строго по «водопаду» и давно использовала итерации. А вот проблемы аджайл принес - подменил системное проектирование короткими циклами, ритуалами, надеждой, что архитектура как-нибудь возникнет по дороге. В итоге получаем лоскутность. Текст местами сгущает краски, зато интересный.

🤨 От хаоса к системе: как мы выстроили процесс Discovery (часть 2) Как превратить подготовку требований из "шаманства" отдельных аналитиков в воспроизводимый процесс. Задача проходит преданализ, оформление постановки по шаблону, рецензирование, согласование с бизнесом и техническим руководителем, проверку тестировщиком и только затем попадает на общее обсуждение команды. Главное (хоть и банально) - не жалейте время и деньги на предпроектную работу.

😱 Внедрили Scrum, но Agile так и не случился. Почему? Эссе о том, почему установка доски, проведение ретроспектив и переименование совещаний не превращают компанию в гибкую. Коротко - из-за культуры. Там, где решения по-прежнему принимает начальник, а ошибка воспринимается как повод найти виноватого, самоорганизация обычно остаётся красивой витриной. Поэтому начинать внедрение стоит не с выбора модного фреймворка, а с диагностики управленческой среды и ее подходимости для нововведений.

😢 Как считать экономическую эффективность внедрения ИТ-решений. Переводим функционал в деньги “А сколько мы на этом заработаем?” - страшный вопрос от бизнеса) Вот автор и предлагает двигаться от решения к конкретным изменениям бизнес-показателей (снижению простоев, затрат, аварийности или продолжительности операций), а затем переводить их в денежный эффект. Полезный материал для подготовки обоснований проектов перед собственником.

😔 IT-шная конфликтология или как заказчик всегда прав О том, почему техническая правота сама по себе редко помогает выиграть спор с заказчиком. Кратко - бизнес оценивает сроки и риски не по сложности кода, а по тому, насколько понятно специалист объяснил последствия, ограничения и стоимость решения. Поэтому автор советует говорить на языке целей заказчика, фиксировать договоренности, заранее описывать неблагоприятные сценарии и привлекать коллег, когда собственных аргументов недостаточно.

😁 Книга среднего уровня — 2. Перфекционизм руководителя Классный текст про отказ от желания, чтобы вся команда делала одновременно всё и идеально. То, что помогало хорошему специалисту выделяться, на управленческой должности превращается в источник задержек у подчиненных. Доведение вообще каждого результата до совершенства хорошо съедает ресурсы, хотя часто достаточно просто качественно выполненной работы в разумный срок.

😧 RICE, ICE, MoSCoW: когда фреймворк приоритизации вас топит Про то, что все эти ваши фреймворки не панацея, а даже наоборот. RICE перемножает несколько субъективных оценок и выдаёт якобы убедительное число, ICE особенно легко ломается на разном понимании сложности, а в MoSCoW все интересанты быстро объявляют свои задачи обязательными - и всё, конец. Решение - да, надо использовать приоритезацию, но и включать голову при принятии решения. (И ответственность брать на себя, а не сваливать на инструмент)

😘 Мягкая сила в жестких дедлайнах: 7 принципов влияния для PM и тимлидов Если слышали про принципы Роберта Чалдини про влияние в маркетинге, то вот они, но в проектах. Взаимность, последовательность, социальное доказательство, авторитет, симпатия, дефицит, единство и прочее. Что-то у автора выглядит здраво, а что-то уже на грани манипуляций (с) - например намеренно начинать переговоры с завышенного срока или формировать у сотрудника чувство долга. Но и это интересно почитать, чтобы в такое не вляпаться)