Удаленная работа, срочная замена Notion и Confluence, текучка кадров — всё это усложняет управление командой. Как сохранить продуктивность и мотивацию людей в трудных обстоятельствах, а заодно не сорвать проекты?
Начать стоит с тщательного выбора управленческого метода. Agile и Waterfall — два самых популярных подхода. Рассказываем, в чем их отличия и что нужно учесть, чтобы выбрать тот самый.
Начать стоит с тщательного выбора управленческого метода. Agile и Waterfall — два самых популярных подхода. Рассказываем, в чем их отличия и что нужно учесть, чтобы выбрать тот самый.
Что такое Agile — основные характеристики
Agile — это в первую очередь философия гибкой разработки. Она включает набор принципов и ценностей, которые закреплены в Agile-манифесте. Вот некоторые из них:
Одновременно это понятие объединяет несколько подходов — фреймворков, которые помогают командам быстро учитывать изменения в проекте и постоянно улучшать продукт.
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Одновременно это понятие объединяет несколько подходов — фреймворков, которые помогают командам быстро учитывать изменения в проекте и постоянно улучшать продукт.
Самые известные — Scrum и Kanban. В первом работа организована по спринтам (1-4 недели), во время которых задачи фиксируются до конца итерации. Каждый спринт завершается ретроспективой, на которой команда анализирует результаты.
В Kanban специалисты работают на визуальной доске, перемещая задачи по этапам выполнения. Задания добавляют без жёстких сроков и могут менять в процессе.
Что такое Waterfall — основные характеристики
Waterfall — классический подход к управлению проектами, в котором работа над продуктом идёт в строгом порядке. Сначала утверждение требований, затем проектирование, разработка, тестирование, и, наконец, запуск и поддержка. Поэтому фреймворк и называется «водопадом» — одна стадия логично «перетекает» в другую, без возврата к пройденным шагам.
В отличие от Agile, в Waterfall задачи спускаются сверху вниз от руководства, и команда выполняет их без обсуждений. Подход предполагает составление четкого техзадания и подробной документации на старте проекта.
В отличие от Agile, в Waterfall задачи спускаются сверху вниз от руководства, и команда выполняет их без обсуждений. Подход предполагает составление четкого техзадания и подробной документации на старте проекта.
Waterfall vs Agile — разбираем по пунктам
Методология — это не жёсткий свод правил. Каждый бизнес адаптирует их под себя. Даже наше описание может вызвать споры среди айтишников. Поэтому мы не объясняем, как нужно работать по Agile или Waterfall, а рассказываем про опыт разных компаний.
Предлагаем сравнить подходы по нескольким критериям, а также оценить возможности и риски каждого из них.
Предлагаем сравнить подходы по нескольким критериям, а также оценить возможности и риски каждого из них.
Гибкость и адаптивность
Agile
В этом заключается главная разница Waterfall и Agile. Задачи в спринте проходят по кругу: их разрабатывают, тестируют, получают обратную связь, улучшают — и так до нужного результата. Этот цикл может повторяться несколько раз в рамках одного спринта.
Waterfall
В отличие от Agile, в Waterfall проект движется по строгому плану. Все требования фиксируются на старте, и команда не переходит к следующему этапу, пока текущий не завершен.
В этом заключается главная разница Waterfall и Agile. Задачи в спринте проходят по кругу: их разрабатывают, тестируют, получают обратную связь, улучшают — и так до нужного результата. Этот цикл может повторяться несколько раз в рамках одного спринта.
- Возможности: команда сразу реагирует на изменения и обновляет продукт, не расходуя бюджет на переделки в конце. Это удобно для MVP: можно быстро запустить базовую версию и дорабатывать её по запросам пользователей или клиента.
- Риски: частые правки могут затянуть сроки и размыть фокус, если заказчик вносит новые идеи на каждом шагу. Без четких приоритетов есть риск «разрастись» по функционалу и потерять изначальную цель проекта.
Waterfall
В отличие от Agile, в Waterfall проект движется по строгому плану. Все требования фиксируются на старте, и команда не переходит к следующему этапу, пока текущий не завершен.
- Возможности: специалисты не отвлекаются на постоянные изменения — это помогает уложиться в сроки и бюджет.
- Риски: если под конец проекта понадобятся правки, придется вернуться к начальным этапам, пересмотреть планы и переделать часть продукта. Бюрократизированный процесс может затянуть работу и повысить расходы.
Контроль сроков и бюджета
Agile
Задачи оценивают либо в трудозатратах (часах или днях), либо в сторипойнтах — баллах сложности, которые показывают, сколько нужно сил и времени на работу.
Например, «добавить кнопку на страницу» может получить 1 сторипойнт, а «подключить новую платёжную систему» — все 8, потому что задача объективно сложнее.
Задачи оценивают либо в трудозатратах (часах или днях), либо в сторипойнтах — баллах сложности, которые показывают, сколько нужно сил и времени на работу.
Например, «добавить кнопку на страницу» может получить 1 сторипойнт, а «подключить новую платёжную систему» — все 8, потому что задача объективно сложнее.
- Возможности: бюджет проекта распределяют по спринтам, и у каждого есть свои рамки. Если что-то затягивается, команда это видит и переносит менее срочные дела на потом. Так деньги остаются под контролем, а в работе — только приоритетные задачи.
- Риски: сторипоинты — условная оценка, и часто разработчики вообще не понимают, как ими пользоваться. Баллы ставят «на глаз», и реальное время на задачу на практике может сильно отличаться. В итоге план спринта срывается — технический долг растет, а расходы выходят за рамки бюджета.
Waterfall
Сроки и стоимость каждой задачи устанавливают перед началом проекта. Все члены команды знают, сколько времени и ресурсов у них в запасе.
К примеру, при разработке приложения на задачу «создать интерфейс» могут выделить 2 месяца и заложить бюджет в 400 тысяч рублей.
Сроки и стоимость каждой задачи устанавливают перед началом проекта. Все члены команды знают, сколько времени и ресурсов у них в запасе.
К примеру, при разработке приложения на задачу «создать интерфейс» могут выделить 2 месяца и заложить бюджет в 400 тысяч рублей.
- Возможности: жесткий контроль помогает избежать лишних расходов и не срывать дедлайны.
- Риски: как мы упомянули в предыдущем разделе — если заказчик внесет изменения на финальных этапах, весь план проекта может пострадать. А вместе с ним расходы и сроки на релиз.
Порядок выполнения задач
Agile
Подход предполагает горизонтальное управление. Это существенная разница между Waterfall и Agile. Все члены команды участвуют в создании бэклога, обсуждают, что делать дальше и какие задачи сейчас в приоритете.
Waterfall
Задачи спускают сверху вниз. Лид проекта, проджект и другие руководители решают, что нужно делать, а команда выполняет указания.
Подход предполагает горизонтальное управление. Это существенная разница между Waterfall и Agile. Все члены команды участвуют в создании бэклога, обсуждают, что делать дальше и какие задачи сейчас в приоритете.
- Возможности: экспертиза разных специалистов может быть полезной для проекта. Допустим, при планировании спринта дизайнер говорит, что новая функция усложнит интерфейс и повлияет на UX. Команда сможет отложить задачу на «подумать» до следующего релиза.
- Риски: бывает, что мнения членов команды не сходятся. Начинаются дискуссии, порою — конфликты. Все это мешает проекту: решения принимаются долго, специалисты заняты обсуждением, а не работой.
Waterfall
Задачи спускают сверху вниз. Лид проекта, проджект и другие руководители решают, что нужно делать, а команда выполняет указания.
- Возможности: понятная иерархия помогает держать проект под контролем. Люди знают, что и когда нужно сделать, меньше отвлекаются от задач.
- Риски: бывает, что руководители плохо фильтруют «хотелки» клиентов и перегружают команду ненужной работой. В таком случае выпуск продукта часто переносится, и заказчик может остаться недовольным.
Тестирование и проверка качества
Agile
В идеале подход предполагает полноценный quality control. На этапе составления требований QA-инженеры выясняют, как будет выглядеть результат каждой задачи, находят риски и потенциальные проблемы. Эту информацию используют для составления тест-кейсов и автотестов еще до начала разработки.
В идеале подход предполагает полноценный quality control. На этапе составления требований QA-инженеры выясняют, как будет выглядеть результат каждой задачи, находят риски и потенциальные проблемы. Эту информацию используют для составления тест-кейсов и автотестов еще до начала разработки.
- Возможности: команда может заранее создать прототип, чтобы понять, как функции будут взаимодействовать с интерфейсом. Когда он будет готов, QA сразу запускает автотесты. Затем тестирование проводят параллельно с разработкой: сначала «прогоняют» старые баги, а потом — новые доработки. Это называется регрессионным тестированием. Оно помогает убедиться, что ошибки исправлены, и снизить риск того, что они появятся снова.
- Риски: на практике Agile рискует превратиться в «плохой» Waterfall. Как это выглядит? Над проектом работают тестировщики, а не QA. Они получают MVP и проверяют его без заранее написанных тест-кейсов. Кроме того, требования к проекту могут описать неясно и без деталей, а задача на тестирование проводится в спринте и ограничена стори-поинтами. Чаще всего времени на качественную проверку не хватает — это снижает точность тестирования и повышает риск того, что серьезные баги попадут в релиз.
Waterfall
Процесс напоминает заводскую приёмку: когда функция разработана, её передают тестировщикам, чтобы проверить все детали. Чаще всего они тестируют продукт вручную по списку требований, находят баги и возвращают на доработку. Цикл продолжается до тех пор, пока все недочёты не будут устранены.
Процесс напоминает заводскую приёмку: когда функция разработана, её передают тестировщикам, чтобы проверить все детали. Чаще всего они тестируют продукт вручную по списку требований, находят баги и возвращают на доработку. Цикл продолжается до тех пор, пока все недочёты не будут устранены.
- Возможности: из-за того, что сроки работы ограничены только дедлайном приемки, тестировщик даже без автоматизации может долго и тщательно его проверять. Задачи не делятся на стори-поинты, и специалисту могут выделить условную неделю. За это время можно найти все ошибки, и до тех пор, пока они не будут исправлены, тестировщик не дает одобрение на релиз. Это означает, что на рынок попадет исправный продукт.
- Риски: высокая зависимость от человеческого фактора, потому что проект «завязан» на одном или нескольких руководителях. Они могут неправильно оценить время на тестирование, из-за этого разработчики не успеют исправить фичу, и релиз сорвётся.
Степень участия заказчика
Agile
Клиент активно вовлечён на каждом этапе: участвует в планировании, присутствует на демо, корректирует задачи.
Waterfall
Заказчик утверждает требования к продукту, после чего команда работает по плану. Как правило, дальше клиент подключается к процессу только на этапе приёмки MVP и доработанных версий.
Клиент активно вовлечён на каждом этапе: участвует в планировании, присутствует на демо, корректирует задачи.
- Возможности: заказчик контролирует проект, и если у него возникнут идеи или уточнения, команда может их учесть. Это снижает риск того, что финальный продукт не будет отвечать его ожиданиям.
- Риски: постоянные доработки могут перегружать команду и затягивать сроки, если приоритеты меняются слишком часто.
Waterfall
Заказчик утверждает требования к продукту, после чего команда работает по плану. Как правило, дальше клиент подключается к процессу только на этапе приёмки MVP и доработанных версий.
- Возможности: специалисты не отвлекаются на правки, ниже вероятность срыва дедлайнов.
- Риски: из-за того, что приемка проводится реже, чем демо в Agile, клиент может увидеть, что продукт не соответствует требованиям, только по факту. Кроме того, сами детали могут быть описаны нереалистично или неточно, но команда не сможет на это повлиять. В обоих случаях доработки займут много времени.
Делаем выводы
Agile — гибкий подход, при котором все члены команды с разной экспертизой влияют на процесс разработки. Такой метод помогает быстрее запустить продажи и параллельно улучшать продукт. Однако из-за ограниченного времени на спринты релизы часто выходят с багами и недоработками, которые откладывают на следующие обновления. Это может снизить общее качество продукта.
Waterfall — структурированный подход с четкой организацией. Здесь меньше суеты в сравнении с Agile, но результат сильно зависит от грамотного управления. Если руководитель размыто описал требования и неверно оценил сроки, Waterfall превращается в бюрократизированный процесс, при котором выпуск продукта постоянно откладывается.
Waterfall — структурированный подход с четкой организацией. Здесь меньше суеты в сравнении с Agile, но результат сильно зависит от грамотного управления. Если руководитель размыто описал требования и неверно оценил сроки, Waterfall превращается в бюрократизированный процесс, при котором выпуск продукта постоянно откладывается.
Как работают разные подходы — три примера
Стартап
Допустим, молодая команда из пяти человек собирается запустить приложение для отслеживания привычек. У них есть базовое исследование рынка и несколько идей о том, что нужно пользователям, но чётких требований ещё нет.
В этом случае лучше всего подойдет Scrum. Стартап начнет с создания MVP, чтобы быстро проверить свои гипотезы. Каждые две недели команда будет показывать результаты фокус-группе и собирать обратную связь. Так они смогут на ходу вносить изменения и развивать приложение под запросы аудитории.
А вот если выберут Waterfall, есть риск потратить деньги инвесторов на продукт, который придется переделывать после релиза.
Разработка корпоративного ПО
Допустим, разработчик платформы кибербезопасности кастомизирует свой продукт для крупного банка. Со стороны заказчика — директор IT-департамента и директор по ИБ. Они сформировали четкое техзадание с детальным описанием функций, требований к интеграции и соблюдению политик безопасности.
С учетом того, что банку критически важны надежность и предсказуемость подрядчика, здесь однозначно стоит выбрать Waterfall. Подход поможет работать по плану и минимизировать изменения.
Запуск интернет-магазина
Команда создает онлайн-магазин для производителя одежды. У них есть готовый каталог товаров, и заказчик хочет запустить сайт как можно скорее.
На первом этапе можно использовать Waterfall для создания базовой структуры магазина и всех ключевых элементов — от дизайна до функционала корзины. Как только сайт заработает, команде стоит перейти на Agile — периодически добавлять новые функции, такие как система рекомендаций, на основе обратной связи от пользователей.
Допустим, молодая команда из пяти человек собирается запустить приложение для отслеживания привычек. У них есть базовое исследование рынка и несколько идей о том, что нужно пользователям, но чётких требований ещё нет.
В этом случае лучше всего подойдет Scrum. Стартап начнет с создания MVP, чтобы быстро проверить свои гипотезы. Каждые две недели команда будет показывать результаты фокус-группе и собирать обратную связь. Так они смогут на ходу вносить изменения и развивать приложение под запросы аудитории.
А вот если выберут Waterfall, есть риск потратить деньги инвесторов на продукт, который придется переделывать после релиза.
Разработка корпоративного ПО
Допустим, разработчик платформы кибербезопасности кастомизирует свой продукт для крупного банка. Со стороны заказчика — директор IT-департамента и директор по ИБ. Они сформировали четкое техзадание с детальным описанием функций, требований к интеграции и соблюдению политик безопасности.
С учетом того, что банку критически важны надежность и предсказуемость подрядчика, здесь однозначно стоит выбрать Waterfall. Подход поможет работать по плану и минимизировать изменения.
Запуск интернет-магазина
Команда создает онлайн-магазин для производителя одежды. У них есть готовый каталог товаров, и заказчик хочет запустить сайт как можно скорее.
На первом этапе можно использовать Waterfall для создания базовой структуры магазина и всех ключевых элементов — от дизайна до функционала корзины. Как только сайт заработает, команде стоит перейти на Agile — периодически добавлять новые функции, такие как система рекомендаций, на основе обратной связи от пользователей.
Как выбрать подход — чек-лист
- Условия проекта — подумайте, насколько понятны требования к продукту и возможны ли изменения по ходу работы.
- Команда и участие заказчика — учтите размер команды и как часто нужно взаимодействовать с клиентом или пользователями.
- Требования к качеству и безопасности — оцените, насколько важны стабильность и предсказуемость для проекта, особенно если он связан с финансами или медициной.
- Ресурсы и сроки — проанализируйте, сколько времени и людей нужно для работы.
- Возможность протестировать подход — проверьте, можно ли использовать методологию на небольшой части задач, чтобы оценить её эффективность.
- Мнение команды — узнайте у сотрудников, насколько им удобно работать в выбранном подходе.
- Гибридный подход — подумайте, можно ли комбинировать методы чтобы учесть фиксированные части проекта и те, которые могут меняться.
Эффективность как Agile, так и Waterfall зависит от того, насколько грамотно выстроены и налажены процессы. Тщательно планируйте проект, заранее уточняйте все требования и регулярно собирайте обратную связь от команды.
