Данная статья является переводом с добавлением авторских (моих) мыслей. Оригинальный текст можно найти в книге Роберта Высоцкого "Effective project management: traditional, agile, extreme". (Только на английском. Полноценных переводов всей книги нет)
Начало
Перед вами треугольник, площадь которого отражает качество продукта и то, какие фичи должны быть в него включены, а чего быть не должно. Линни описывают количество ресурсов, времени и затрат, которое запланировали для проекта. Чем длиннее линия - тем выше показатели параметра. Например, чем длиннее линия ресурсов - тем больше ресурсов мы имеем. Время - это сколько у вас есть дней до дедлайна проекта. Затраты - сколько денег у вас есть в бюджете. Ресурсы - это люди, компьютеры и так далее.
Здесь вы можете сказать, что вообще ресурсы можно перевести в деньги и принять за одну линию вместе с затратами. Но это будет верно со стороны бухгалтера, но никак не менеджера проектов. Менеджеру нужно управлять затратами по отдельности.
Итак представим, что у вас есть какой-то план. Заказчик приходит к вам с ТЗ. Как правило, если мы говорим с вами о традиционном (Не Agile!) управлении, заказчик определяет качество, функционал и сроки. Менеджер проекта управляет ресурсами и влияет на затраты.
Функциональные перемены
Перемены случаются всегда и везде. Глупо расчитывать на то, что заказчик не захочет изменить что-нибудь в продукте до релиза. Изменения происходят по разным причинам. Хочу отметить, что изменения в плане - это никак не знак глупого заказчика или плохого менеджера. Перемены случаются всегда.
Задача менеджера придумать как быть и как работать, когда вносят изменения в план. Например, заказчик хочет за то же время добавить еще одну фичу в приложеньку. Тогда, так как ресурсы ограничены, выход чаще всего один - увеличить затраты; сказать, что это будет стоить дороже и мы наймем еще одного человека, который это сделает. Таким образом мы увеличим линию и ресурсов и затрат.
Если бы заказчик сказал, что на эту фичу он добавляет время. Решение можно было бы принять немного другое - не добавлять ресурсов, а только увеличить затраты. То есть заплатить программисту за разработку дополнительной фичи.
Пузырь надежд
Это еще одна проблема, с которой сталкиваются менеджеры. Происходит она, когда разработчик один раз отстал от плана. Но каждый раз говорит вам, что он успеет все доделать вовремя к следующей дате отчёта. Разработчик боится расстроить вас и поэтому будет говорить, что он все успеет, что все хорошо, что он догонит план. Но на деле - это не так. Все эти таски копятся и в какой-то момент пузырь лопается. Заказчик недоволен.
Это не значит, что вы должны подробно выяснять, что делают работники каждый день. Достаточно просто рандомных проверок.
Новая фича
Это тоже проблема, связанная с добавлением нового функционала. Только не со стороны заказчика, а со стороны разработчиков. Иногда программисты видят, что в программу было бы клево запихнуть еще одну фичу. И представим, что разработчик ни с кем этого не согласовал и встроил её в программу.
С одной стороны - благие намерения. С другой стороны - ошибка. Это очень опасно делать, не поставив в известность управление. Потому что этот код может войти в конфликт с другим и никто не сможет разобраться в чем проблема. Потому что про эту фичу будет знать только один программист. Что если она вообще-то и не нужна заказчику?
Решение проблемы достаточно простое. Рассказать разработчикам, что все инициатива приветствуется, но нужно обязательно согласовывать с вами. Чтобы вы уже могли договориться с заказчиком.
Итог
Плохой руководитель проекта видит этот треугольник в виде смирительной рубашки, которую он наденет на проект. Хороший руководитель проекта будет использовать одну или несколько линий и сделает акцент только на одной. Лучший руководитель проектов будет жонглировать всеми тремя, как горячей картошкой, и будет принимать решения каждый день, что позволит закончить проект всрок, сохранить первоклассное качество и эффективно использовать ресурсы.
P.S.
Возможно вы много раз хотели мне прям в лицо крикнуть: "Чувак, есть Agile. Ты какую-то дичь несешь про изменения в плане. Что за дикие рамки и дедовские методы!" Так вот. Agile работает не для всего и не всегда. Я бы посмотрел на то, как вы бы строили самолёты или танки по методу Agile. Есть вообще клевая история о том, как в 17-ом веке Шведский король, сам того не поняв, строил корабль, используя гибкие методологии. И что в итоге? Его корабль затонул. Но это уже совсем другая история, кстати я описал её на своем канале :3
