День 2201. #ProjectManagement
10 Признаков Того, Что Проект на Пути к Провалу. Начало
Как определить, что проект на пути к успеху или скатывается? Рассмотрим 10 предупреждающих знаков, которые сигнализируют о том, что вы можете сбиться с пути, и несколько идей, как это исправить.
1. Успех зависит от идеального выполнения плана
Планирование - это хорошо, но все планы неверны. Мы должны оставлять место в любом плане, чтобы исправить неизбежные ошибки по мере их обнаружения. Когда мы планируем, мы знаем о нашем проекте меньше всего. Даже если план идеален, внешние факторы изменятся и сделают его не идеальным. В краткосрочной перспективе наши планы могут быть довольно точными, потому что есть небольшой диапазон для вариаций. Но чем дальше мы планируем, тем менее определённо можем судить.
Красные флаги
- Мы вынуждены рассматривать и сроки, и объём работ как фиксированные.
- План включает некоторую подробно описанную работу далеко в будущем.
Что делать?
- Рассматривайте долгосрочные планы как результаты, особенности или пользовательские истории.
- Отслеживайте прогресс и чаще пересматривайте план, т.к. мы узнаём больше по ходу работы. Цель в том, чтобы делать подробные описания работ только внутри команды разработчиков, но не включать их как часть большого плана. Так вы сможете легче корректировать вещи, вы меньше привязаны к деталям какого-то будущего воображаемого способа реализации.
- Разделяйте план на планирование результатов и планирование работы. Если план охватывает обе части – это красный флаг. Это приводит к поведению, вроде «арбузного статуса»: зелёный снаружи, но красный в середине. Мы сообщаем зелёные части руководству, но на самом деле заняты срезанием углов, чтобы уложиться в искусственные сроки, установленные планом. А также тратим время и усилия на то, чтобы разобраться с беспорядком, которой создали, срезая углы в прошлый раз.
- Никогда не пытайтесь уложиться и в жёсткий график, и в жёсткий объём работ. Это нереально. Если невозможно сдвинуть сроки, дайте свободу команде разработчиков для сокращения объёма, чтобы уложиться в них.
Либо зафиксируйте объём, но позвольте команде определить даты релиза, когда целевой объём будет реализован.
- Составляйте любой план работы, которая выходит за рамки одной итерации или спринта только на уровне результатов. Не пытайтесь спланировать работу, необходимую для достижения этих результатов. Позволяйте людям, выполняющим работу, выяснить, что делать для достижения целей.
2. Слишком много людей, решающих проблему
Как сказал Фред Брукс в 1970-х: «9 женщин не родят ребенка за 1 месяц». Увеличение количества разработчиков замедляет проект, добавляет сложности и почти никогда не помогают двигаться быстрее. Масштабирование – это децентрализация принятия решений, разделение работы на более мелкие автономные команды, а не добавление людей. Добавление людей обычно происходит, когда менеджеры начинают паниковать из-за пропущенных сроков или нереалистичных ожиданий масштаба проекта.
Красный флаг
- Руководство внезапно нанимает кучу разработчиков в спешке, чтобы выполнить какой-то нереальный план.
Что делать?
- Решить, что важнее: время или объём работы, - и оптимизировать разработку под это. Если необходим фиксированный объём, стоило бы усомниться в этом с самого начала, т.к. это редко бывает правдой. Объём, который мы думаем, что нам нужен в начале проекта, почти наверняка будет неверным. Мы упустим вещи, которые узнаем по ходу, мир вокруг изменится, пока мы работаем над проектом. На самом деле, если вы не меняете своё мнение об объёме работ по мере продвижения проекта, вы почти наверняка что-то делаете неправильно.
- Расставьте приоритеты в функциональности, которая наиболее важна для ваших пользователей, а затем выпустите её как можно раньше. Так что, даже если список требуемой функциональности в начале проекта не полный, самая главная функциональность, которую от вас ждут, будет доступна пользователям.
Продолжение следует…
Источник: https://youtu.be/-6KHhwEMtqs
>>Click here to continue<<