Размышления об управлении софтовыми проектами
Первый руководитель проекта (РП) появился в первобытном обществе, когда понадобилось организовать охоту на мамонта - собрать всех вместе, наточить камни, загнать, прибить, разделать, распределить добычу, зажарить :) С тех пор задачи РП практически не изменились. По прежнему необходимо управлять командой и доводить проект до нужного результата.
Управление проектами как методология зародилось ХХ веке, а Институт управления проектами (PMI), является одним из ее основоположников. Сегодня он предлагает программы обучения и сертификации, основанные на PMBoK. Любая проектно-ориентированная организация, к которой относимся и мы, должна следовать этой методологии, иначе проекты станут неуправляемыми, а результаты будут плачевными.
Создание программного продукта это тоже проект, но со своими особенностями. Три ключевые задачи РП (сроки, бюджеты, ресурсы) обогащаются новыми смыслами и конвертируются в управление расписанием, командой, масштабом, бюджетом и коммуникациями, которые неизбежны в любом проекте, но особенно важны в проекте софтовом.
Управление расписанием
Собрать воедино все планы и наложить их на временную шкалу - задача непростая. При этом РП нужно учесть сроки начала и исполнения каждой отдельной задачи, некоторые распараллелить, а некоторые наоборот - подвязать к выполнению определенного этапа. Для визуализации всего жизненного цикла проекта используются разные программные продукты. Мы используем Microsoft Project, в частности, строим в нем план-графики работ.
Управление командой
РП также должен уметь распределять задачи внутри участников проекта, следить за тем, чтобы они выполнялись на должном уровне, контролировать загрузку исполнителей и не допускать ситуаций когда один человек перегружен, а другой “простаивает”. Для этого мы используем Jira и Confluence. Связка этих инструментов позволяет не только управлять задачами, но и обеспечивает возможность совместной работы над над документами (артефактами), создаваемыми в ходе реализации проекта.
Управление масштабом проекта
Предотвращение неконтролируемого изменения объема работ - одна из ключевых задач РП. Зачастую, в ходе проекта у Заказчика может появиться новое вИдение конечного результата, новые идеи, внеплановые задачи и другие “хотелки”. Задача менеджера в данном случае - зафиксировать дополнительные вводные, по возможности их учесть, при необходимости скорректировать ход проекта, иногда сказать “нет” и, самое главное - уложиться в установленные сроки и финансовые показатели проекта.
Управление бюджетом
Исполнение бюджета - одна из важнейших задач, вытекающая из предыдущего пункта. Дополнительные часы, которые требуются на “допиливание” какой-либо фишки или обновленное ТЗ, в совокупности, могут вывести расходы за установленные рамки. Поэтому, в бюджет закладываются риски (обычно в размере 10-15%), позволяющие сохранить плановую рентабельность.
Управление коммуникацией
80% рабочего времени любого РП - это коммуникация. С клиентом, с подрядчиком, с разработчиками, с бухгалтерией, с руководством компании, со своим уставшим отражением в зеркале (шутка). Так происходит потому, что обсуждение и общение используется в любой методологии в качестве основного инструмента решения проблем. Разработчик не понимает, что от него хочет аналитик? 15-минутная переписка в чате “на троих” с РП поможет перевести постановку задачи с одного языка на другой. Заказчик недоволен темпами работы? Еженедельный статус позволит ему почувствовать себя внутри рабочего процесса и быть информированным о ходе проекта. Есть риск срыва сроков? Вовремя проведенная встреча команды с архитектором способна расставить приоритеты между кажущимися “одинаково неотложными” доработками.
Задача РП во всех этих случаях - организация процесса. Необходимо понимать, когда именно, между кем и в какой форме нужна коммуникация. Или когда она будет лишней.
Кроме того, каждому проекту подходит свой способ реализации. Софтовые компании используют разные подходы в проектной деятельности. В числе наиболее распространенных сегодня - Agile, Scrum, Kanban т. п. Они позволяют оперативно вносить изменения в процесс создания продукта, учитывая постоянно возникающие новые обстоятельства. Но и старый добрый Waterfall не стоит сбрасывать со счетов:) Ведь каждая методология имеет свои нюансы с точки зрения управления проектами. Например, наша компания применяет гибридный подход к исполнению госконтрактов, потому что “голый” Scrum не регулируется существующим законодательством и в госзаказах не применим. Вот нами и приходится совмещать с классическим “водопадным” подходом. Тем не менее, двигаться спринтами эффективнее: заказчик регулярно видит каждый инкремент продукта, принимает активное участие в его создании и быстро даёт обратную связь.