Начало диалога: часть 1, часть 2, часть 3, часть 4, часть 5.
Важное предупреждение. Все примеры, приведённые в статье, не отражают реальные ситуации, относящиеся к конкретным лицам, и являются плодом художественного вымысла. Все возможные совпадения случайны, но лишь подтверждают актуальность этих примеров.
ALM: Я только сейчас понял одну вещь. Наша история — это история про Agile, но не про проекты. Потому что когда мы начинали, мы не знали, чем всё закончится, когда и какие при этом будут затрачены ресурсы. И до сих пор эта история продолжается: новые задачи (такие как МСФО 9) стимулируют разработку. Разработка может являться частью проекта, а может сама состоять из множества проектов.
Мы совсем не обсудили один важный аспект Agile. Agile — это технология. И она требует инфраструктуру.
PM: Основой этой технологии является централизованный реестр, в котором фиксируются все тезисы, осуществляется оценка:
• приоритетности реализации,
• трудозатрат,
• затрат иных ресурсов,
а также фиксируется
• дата поступления тезиса,
• дата реализации тезиса.
Дальнейшие продвижение этапа разработки учитывает эту обратную связь заказчиков, и к моменту завершения разработки результат учитывает ранее представленную обратную связь от функциональных заказчиков.
ALM: Но ведь «эту песню не задушишь, не убьёшь». А как закончить разработку?
PM: Контроль соответствия календарному и ресурсному плану проекта продолжает быть основным инструментом управления. Но по мере формирования реестра, если решением менеджера проекта часть ресурсов перераспределяется на уже поступившие замечания и это не менее или даже более приоритетно, чем движение дальше по функциональному объёму, возникает необходимость коррекции изначальных сроков. Это неизбежно удлиняет этап разработки, но существенно экономит время на последующих этапах тестирования и подготовки к старту промышленной эксплуатации.
Таким образом, по завершении разработки на этап тестирования выносится максимально соответствующий пожеланиям пользователя программный продукт.
При таком подходе при сохранении классического подхода к управлению проектом, на определённом его этапе (с момента появления рабочих прототипов и до завершения разработки) эффективно работают agile-подобные методы.
ALM: То есть, я правильно понял, что для исключения ситуации «лучшее враг хорошему» и с учётом планового срока старта промышленной эксплуатации применение agile-подобных методов должно закончиться с этапом разработки и тестирования её результатов? Другими словами, применение Agile принципиально ограничено во времени определённым этапом календарного плана?
PM: Именно! А иначе получится как в твоей истории про ремонт квартиры. Миграция данных и обучение эффективны только на стабильной версии программного обеспечения, хотя бы стабильной с точки зрения функциональности.
Однако после ввода программного продукта в опытную или опытно-промышленную эксплуатацию (то есть с началом этапа стабилизации программного продукта), когда имеется готовый к использованию минимально жизнеспособный продукт, снова начинает эффективно работать любой из вариантов методологии разработки Agile.
Превращение этого минимально жизнеспособного продукта в полнофункциональное промышленное решение может проходить как в рамках проекта (при потенциально низкой динамике изменений), так и за его пределами после формального закрытия проекта (в условиях высокой волатильности требований по развитию). Но это решение куратора проекта.
ALM: А чем руководствоваться при принятии этого решения?
PM: Критериями принятия данного решения могут являться:
• содержательная специфика программного обеспечения: одно дело — предлагаемое на внешний рынок «коробочное решение», другое дело — заказная разработка , заточенная под уникальную специфику процессов конкретной компании;
• насколько дефицитны и дóроги ресурсы: чем дефицитнее или дороже ресурс, тем осознаннее и тоньше необходимо им управлять;
• степень профессиональной зрелости специалистов на стороне заказчика или готовность компании работать с внешним подрядчиком по схеме T&M (T&M от Time and Materials — схема работы с внешним подрядчиком, в рамках которой объём работ не ограничен, а оплачивается Заказчиком на основании актов, подготовленных Исполнителем, на основе фактических трудо- и материальных затрат, понесённых им. В строительстве обычно эти затраты регламентированы нормативными документами Госстроя, в то время как в банковской и ит-специфике такие стандартные расценки и оценки затрат не формализованы или попросту отсутствуют), что тоже требует определённого уровня квалификации как в предметной, так и в технической областях;
• методика управления расходами, принятая в компании: уже упомянутая схема работы на условиях T&M может быть неприемлемой.
Заключение
ALM: Пришло время подвести итоги?
PM: Да. И вот они.
1. Agile не может заменить классический проектный менеджмент, поскольку имеет другую область применения. Agile ориентирован на разработку программного обеспечения, допускающего существование прототипа, наличие неполной функциональности, ошибки в работающем приложении. Разработка обычно является лишь частью проекта и не покрывает все задачи проекта.
2. Проект, подразумевающий разработку прикладного программного обеспечения, может и часто должен включать в себя agile-этапы. Это может изменить цели проекта и критерии его качества, и потому на первое место выходит контроль эффективности использования ресурсов и соблюдения сроков проекта.
3. Комбинация классических подходов к управлению проектами и agile-подобных подходов предъявляет повышенные требования к квалификации и опыту всех участников проекта, как проектного менеджера так и составляющих проектную команду профильных специалистов.. Хотя, по-моему, там, где уважают свой труд, вышесказанное само собой разумеется.
Начало диалога: часть 1, часть 2, часть 3, часть 4, часть 5.
© С. А. Копылов, CFA, FRM