Часто в проектном подходе мнение клиента, как эксперта в предметной области или лица, осуществляющего финансирование, приоритизируется как основной источник истины.

Проектный подход линеен, но может включать циклы. Например, если вы разработали лендинг для здоровой еды, следующей линейной задачей может быть преобразование его в интернет-магазин по чёткому ТЗ, в определённые сроки и за фиксированный бюджет.

В проектном подходе взаимодействие с пользователями может быть менее интенсивным. Исследованиям и тестированию отводится меньшая роль, или они могут вовсе быть исключены из процесса создания продукта из-за ограниченных сроков или бюджета.

Пример из жизни: я однажды работал над интерфейсом для государственной системы. Там всё было по классике проектного подхода: заказчик заранее утвердил функциональные требования, сроки были жёсткими, а бюджет — ограниченным. Понравился ли мне процесс? Безусловно, потому что всё шло по плану, и никаких сюрпризов. Но это не всегда так...

Проектный подход более структурирован и линеен, чем продуктовый. Все этапы следуют друг за другом по принципу Waterfall (каскадная модель). Цели и задачи фиксируются в самом начале, и изменения на ходу нежелательны — они могут сорвать сроки и выбить из бюджета.

Двусторонние стрелки между смежными этапами: например, между «Исследованием» (2) и «Концептуальным дизайном» (3), или между «Концептуальным дизайном» (3) и «Детальным проектированием» (4) указывают на ситуацию, когда требуется уточнение деталей.

От «Поддержки и обновления» (8) к любому из предыдущих этапов: при необходимости значительных обновлений или изменений может потребоваться возврат к более ранним этапам.

От «Внедрения» (7) к «Тестированию» (6): после внедрения может потребоваться дополнительное тестирование.

От «Тестирования» (6) к «Детальному проектированию» (4) или «Разработке» (5): если тестирование выявляет проблемы, может потребоваться возврат к этапу проектирования или разработки.

Строгая последовательность этапов: каждый этап следует за предыдущим, как в цепочке (1 -> 2 -> 3 -> 4 -> 5 -> 6 -> 7 -> 8 ). Например, сначала идет «Анализ требований», затем «Исследование», потом «Концептуальный дизайн», «Детальное проектирование» и т.д.

Вот несколько примеров, когда подойдет этот подход:

Создание графических материалов по чёткому брифу. Например, баннеры, иллюстрации, иконки по готовому техническому заданию. Здесь от дизайнера не требуется гибкости и креативного поиска решений, так как всё уже определено заранее. Нужно лишь качественно выполнить работу в соответствии с брифом.

Дизайн интерфейса для простых приложений с предсказуемой функциональностью. Например, приложение-калькулятор или таймер. В таких проектах требования обычно чёткие и не меняются в процессе разработки. Это позволяет не отвлекаться на лишние итерации и сосредоточиться на выполнении задачи по плану.

Агентские или аутсорсинговые проекты. В агентской работе, когда клиент предоставляет точные требования, появляется обязательство следовать утверждённому плану. Здесь важно не только соблюсти сроки, но и уложиться в бюджет, при этом не допуская отклонений от первоначальной спецификации.

Разработка проектов для временных маркетинговых кампаний. Например, когда нужно создать лендинг для мероприятия, которое состоится через месяц. В таком проекте каждая минута на счету, и нет времени на глубокие исследования, постоянные итерации и изменения. Всё должно быть чётко спланировано и выполнено в срок.

Некоторые стартапы и B2B-проекты. Когда стартап хочет быстро выйти на рынок или показать продукт инвесторам, проектный подход может быть идеальным. В таких ситуациях есть определённые требования и сроки, которые нужно жёстко соблюдать. Особенно если бюджет ограничен, а время — это буквально деньги.

Государственные проекты (B2G). Эти клиенты часто приходят с уже утверждёнными спецификациями и строгими требованиями. В таких случаях гибкость — не то, что ожидают от команды разработки. Нужно просто сделать работу в срок и по утверждённому плану.

Главное преимущество проектного подхода — это предсказуемость и контроль.

Пример из жизни: В одном из моих проектов, где использовался проектный подход, клиент на финальной стадии вдруг захотел изменить структуру интерфейса. Это вызвало цепную реакцию: пришлось вернуться к этапу проектирования, пересмотреть часть пользовательских сценариев и внести коррективы в разработку. В итоге мы задержали релиз, и клиент был не в восторге от дополнительных расходов. Классическая ситуация «Ожидания vs Реальность».

Проектный подход похож на движение по рельсам: если сойти с пути, можно потерять контроль над ситуацией. Команде может потребоваться вернуться на несколько шагов назад, пересмотреть проектирование или разработку, а это — потеря времени и денег.

Проектный подход не любит изменений. Если на поздних стадиях проекта заказчик вдруг решит что-то изменить, это может стать проблемой. Вспомните, как сложно поменять детали в механизме, когда он уже запущен.

В конечном счёте продуктовый дизайнер должен уметь выбирать подход, который наилучшим образом соответствует особенностям проекта и ожиданиям клиента. Проектный подход — это один из инструментов в арсенале, и его стоит использовать там, где он действительно принесёт наибольшую пользу.

Проектный подход — это отличный инструмент, когда нужно чётко следовать плану, особенно в условиях ограниченных сроков и фиксированных требований. Он помогает структурировать работу, избежать непредвиденных изменений и держать под контролем сроки и бюджет. Однако для проектов, где важна гибкость и возможность адаптироваться к изменениям, могут потребоваться другие подходы.