Чтобы проекты выполнялись в срок и без ошибок, нужны специальные инструменты управления: планировщики задач, календари, трекеры, командные доски. Но эти инструменты не работают сами по себе: они должны быть заключены в единую систему — методологию управления проектами.
● Конкретные принципы работы: способы оценки сроков, постановки задач, передачи заданий между сотрудниками и отделами, стандарты для совместной работы.
● Определённые инструменты управления проектами: диаграммы Ганта, Kanban-доски, планировщики.
● Способы оценки результатов задач и проекта в целом.
Методология позволяет менеджеру один раз выбрать инструменты и стандарты, создать «конвейер» и потом прогонять проекты по этому конвейеру, чтобы получать предсказуемый результат.
Методологии управление проектами используются везде: от разработки приложений до автомобильной промышленности и строительства космических кораблей. Везде, где есть проект и команда, применяют ту или иную методологию, сочетание нескольких или хотя бы их отдельные элементы.
Суть методологии. Проект выглядит как поток, где каждый шаг заранее определён, а все шаги следуют строго один за другим.
Так выглядит общая канва IT-проекта, построенного по методологии Waterfall
Иногда задачи могут накладываться друг на друга и идти параллельно. Например, для разработки и дизайна приложения можно назначить примерно одинаковые сроки, так как этими задачами занимаются разные команды.
Основной инструмент этой методологии — диаграммы Ганта. На них отмечают задачи и сроки их выполнения.
Так упрощённо выглядит диаграмма Ганта IT-проекта
● У проекта всегда фиксированный бюджет и сроки.
● Легко привлекать новых участников в команду, так как задачи строго сформулированы.
● По проекту просто вести подробную документацию.
● Удобно составлять отчёты: можно демонстрировать результаты прямо на диаграмме Ганта, которая используется для планирования.
● К этому методу управления проектами многие привыкли, почти все знакомы с его технологиями, так что сотрудников не придётся специально обучать.
Минусы методологии:
● В проект нельзя вносить изменения. Если появятся новые требования, планирование нужно будет начинать заново с нуля, что сильно сдвинет вперёд окончание работ.
● Любое нарушение сроков обрушит планирование.
● Невозможно параллельно вести много работ, так как нарушается принцип последовательности. Например, нельзя тестировать каждую только что разработанную функцию — нужно накопить определённый объём разработки и только потом приступать к тестированию.
● Результат проекта однозначно виден только в конце. Если он не устроит заказчика, это обесценит все предыдущие работы.
Подходящие проекты для использования метода:
● Несложные проекты, где объём работ можно легко определить и сформулировать в ТЗ.
● Проекты с очень строгими требованиями к бюджетам и срокам.
А вот для современной разработки в ИТ, где требования меняются регулярно, а обновления приложений необходимо выпускать как можно чаще, Waterfall не подходит.
Суть методологии. Вся суть Agile содержится в четырёх пунктах его манифеста:
● Люди и их взаимодействие важнее процессов и инструментов проектного управления.
● Рабочее программное обеспечение (результат проекта) важнее всеобъемлющей документации.
● Сотрудничество с клиентами важнее переговоров по контракту.
● Реагирование на изменения важнее следования плану.
Именно из-за последнего пункта семейство методологий Agile и называется гибким.
В Agile входит несколько методологий: Scrum, Scrumban, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe, AgilePM. Все они соответствуют принципам Agile и различаются только отдельными инструментами и подходами к управлению.
На практике работа по Agile означает, что команды трудятся небольшими циклами и в результате каждого цикла получают готовую функцию или продукт. А в следующем цикле дорабатывают его или улучшают. Работа часто идёт параллельно, результаты видны ещё до окончания проекта, а в случае новых требований их легко включить в следующий цикл работы.
Примерно так выглядит разработка по Agile, причём циклы могут идти параллельно
● Полная гибкость и свобода изменений. Например, если конкуренты выпустили новую функцию, её можно быстро разработать в уже начатом проекте.
● Низкие риски — прямо в процессе команда получает обратную связь от бизнеса и пользователей, поэтому в итоге проект вряд ли провалится.
● Устойчивость к срывам сроков. Даже если какой-то цикл растянется, следующие можно будет адаптировать под изменившиеся сроки и условия.
● Ориентация на людей и команду даёт большую вовлечённость в проект.
Минусы метода:
● Нет чёткого плана и структуры проекта.
● Сотрудники и заказчики со стороны бизнеса должны сотрудничать более тесно, постоянно требуются обсуждения и обратная связь.
● В процессе работы сложнее заменить команду, так как от всех требуется большая вовлечённость в задачу.
● Внедрить проектную методологию может быть сложно — потребуется отдельный сотрудник либо менеджер проекта, который хорошо в этом разбирается.
Подходящие проекты. Большинство современных IT-проектов, в которых есть общее представление о продукте, но нет видения конкретного результата. Такие проекты обычно требуют гибкости, быстрых изменений и способности подстраиваться под новые требования бизнеса и рынка — и для этого гибкие методы управления проектами подходят идеально.
Плюсы методологии:
● Удобнее вносить изменения в проект в рамках отдельных циклов.
● У проекта гораздо более чёткая и понятная структура, предсказуемые сроки.
Минусы метода:
● Иногда ради структуры всё-таки приходится жертвовать гибкостью. Например, сдвинуть сроки или внести совсем радикальные изменения не получится.
● Собирать отчёты сложнее, чем в Waterfall.
● Всё ещё требуется большая вовлечённость всех лиц, участвующих в проекте.
Подходящие проекты. Те, где требуется большая строгость в плане задач и сроков, но при этом всё ещё нужна достаточно быстрая реакция на внешние изменения. Часто это IT-проекты крупных корпораций или государственных компаний, которые готовы к изменениям, но всё ещё вынуждены соблюдать определённые формальности.
Waterfall, Agile и их сочетания — главные современные методы управления проектами в сфере IT. Но есть и другие, которые целиком или частично иногда используют на подобных проектах. Рассмотрим некоторые самые популярные.
Так вы понимаете, какие задачи нужно выполнить как можно раньше, какие можно делать параллельно, а какие точно останутся на самый конец.
● Максимально подробное планирование — вы сразу видите все задачи и точно знаете, в каком порядке их выполнять.
● Чёткая расстановка приоритетов — всегда известно, какая задача более первостепенная и важная.
● Минимизация рисков — благодаря чётким приоритетам больше уверенности, что задачи будут сделаны в срок и на них хватит ресурсов.
Недостатки:
● Как и Waterfall, методология плохо адаптируется к изменениям — новую задачу сложно вписать в строгую иерархию.
● Труднее спрогнозировать длительность выполнения задачи и назначить чёткие сроки.
● Нужно постоянно следить за ресурсами и проверять, хватает ли их для выполнения следующих пунктов проекта.
● При планировании нужно очень чётко понимать задачу и обладать большим опытом.
Подходящие проекты. Те, в которых много сложных задач, взаимосвязанных друг с другом, причём эти взаимосвязи важно учитывать. Но при этом часть задач не связаны, и их можно делать параллельно. Например, можно применить методы технологии управления проектами CPM при запуске сайта: параллельно вести разработку, готовить контент, отрисовывать дизайн и собирать аналитику для будущей рекламы.
● Максимально эффективное использование всех ресурсов компании, отсутствие простоев, переработок и срывов сроков.
● Чёткая сосредоточенность на конечной цели, так как именно с неё начинается планирование.
Недостатки:
● Неудобно использовать, если компания или команда ведёт несколько проектов параллельно. Одни и те же ресурсы могут быть задействованы в разных проектах, а методология это не учитывает.
● Есть риск задержек из-за закладки буферного времени.
Подходящие проекты. Те, где ресурсы строго ограничены, например нет времени или мало сотрудников. В идеале нужно, чтобы у компании был только один проект, без параллельных, иначе такое управление ресурсами может не сработать.
Любая из методологий — не панацея и не универсальный конвейер. В Waterfall где-то придётся проявлять гибкость, а в Agile — жёсткость. Всё зависит от каждого проекта индивидуально, и на стадии планирования важно понять, какие методы и инструменты управления подойдут для реализации конкретных задач лучше всего. А в процессе выполнения вовремя реагировать на изменения и кризисы. В этом и состоит задача менеджера проекта.