Как предпроектное обследование экономит время и деньги при разработке IT-продуктов

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

Виктор Рындин

Привет, меня зовут Виктор, я основатель Wemakefab. Мы занимаемся UI/UX-дизайном и разрабатываем лучшие в России онлайн-сервисы по версии отечественных диджитал-конкурсов.

В Wemakefab предпроектное обследование (ППО) — это обязательный первый этап при работе над любым IT-продуктом. Без него мы не пойдём в разработку. Дальше я расскажу:

Что такое ППО и как оно помогает снизить уровень неопределенности в проекте

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

Этот этап помогает оценить реальную стоимость, сроки реализации проекта, а также подготовиться к возможным сложностям, которые могут возникнуть.

Результат ППО — набор документов, которые дают более полное представление о проекте. Эти материалы обычно называют «Артефакты». Дальше в статье я тоже буду их так называть.

Без ППО невозможно:

  • Сформировать точную смету на разработку;
  • Зафиксировать риски и узкие моменты;
  • Составить техническую архитектуру проекта, выбрать оптимальное решение.

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

Проект без прохождения ППО: неизвестно, где и какие риски ожидают. 
Проект после ППО: есть понимание рисков и возможностей
Проект без прохождения ППО: неизвестно, где и какие риски ожидают. Проект после ППО: есть понимание рисков и возможностей

ППО особенно полезно для предпринимателей без экспертности в IT

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

В результате ППО заказчики получат:

  • Детальный план разработки со сроками и стоимостью каждого этапа;
  • Понятное техническое задание, которое поможет избежать недопонимания с разработчиками;
  • Анализ потенциальных рисков проекта и рекомендации, как их избежать или минимизировать;
  • Варианты технических решений с оценкой их стоимости;
  • Прототипы ключевых экранов продукта, чтобы можно было «потрогать» будущее решение.

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

В ППО есть 5 основных этапов

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

Конечно, в других компаниях процесс ППО может быть организован иначе.

Ниже описал этапы, которые мы выделили как основные.

1. Глубинный брифинг и погружение в проект

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

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

Артефакт: документ с ключевыми моментами, выводами и требованиями к работе.

Часть таблицы с ответами на вопросы из глубинного брифинга
Часть таблицы с ответами на вопросы из глубинного брифинга

2. Разработка компонентной или концептуальной схемы архитектуры проекта

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

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

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

Артефакт: компонентная или концептуальная схема архитектуры проекта.

Часть компонентной схемы архитектуры проекта: структура и взаимосвязи модулей
Часть компонентной схемы архитектуры проекта: структура и взаимосвязи модулей

3. Создание Use-case и User-flow

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

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

User-flow, или карта сайта, демонстрирует, как пользователи будут перемещаться по продукту, чтобы выполнить свои задачи. Это позволяет оптимизировать UX и выявить потенциальные проблемы в навигации на ранних этапах.

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

Артефакты:

  • Use-case диаграммы для различных типов пользователей.
  • User-flow диаграммы, или карта сайта, отображающие структуру и навигацию продукта.
Часть user flow: схема взаимодействия пользователя с личным кабинетом
Часть user flow: схема взаимодействия пользователя с личным кабинетом

4. Разработка прототипов

Здесь мы создаём черновой вариант интерфейса вашего продукта — вайрфреймы (wireframes). Это схематичные макеты страниц или экранов приложения, которые визуализируют структуру и функциональность вашего продукта. Зачем они нужны?

  • Наглядно показать расположение основных элементов интерфейса.
  • Определить информационную иерархию.
  • Сфокусироваться на функциональности и структуре, не отвлекаясь на детали дизайна.

Вайрфреймы помогают проверить UX: нет ли ошибок в пользовательских путях и правильно ли выстроена иерархия контента. А также это способ внести правки на раннем этапе работы над проектом.

Артефакт: набор вайрфреймов ключевых страниц сайта или экранов приложения.

Прототипы ключевых страниц сервиса для риэлторов
Прототипы ключевых страниц сервиса для риэлторов

5. Формирование паспорта проекта

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

Благодаря этому документу проще принимать решения. Если у команды или клиента появятся вопросы либо будут какие-то спорные моменты, — все ответы найдутся в паспорте проекта.

Кроме того, если к проекту присоединяются новые люди, этот документ поможет им погрузиться в проект и понять все его особенности.

Артефакт: паспорт проекта, куда входят результаты всех пройденных этапов ППО.

Паспорт проекта платформы для переговоров

Примеры проектов с разным составом этапов в ППО

Кроме базовых этапов, которые мы описали выше, ППО может также включать другие работы. Например, анализ конкурентов, анализ готовой системы и разработка BPMN-схемы.

Вот несколько примеров того, какие этапы может включать ППО для разных типов проектов:

Как предпроектное обследование экономит время и деньги при разработке IT-продуктов

Обычно ППО проводится за 2–6 недель

В основном время зависит от сложности проекта и количества артефактов, которые нужно разработать. Например, ППО для промосайта нового продукта займёт 2 недели, а для крупного интернет-магазина — 6 недель.

Кроме того, на продолжительность ППО влияет скорость реакции заказчика. То есть то, насколько быстро он отвечает на вопросы и утверждает промежуточные результаты.

Примеры, сколько времени может занимать ППО на разных проектах с разным составом этапов:

  • Небольшая промоигра — 1,5–2 недели;
  • Обучающая платформа — 4 недели;
  • Мобильное приложение для фитнес-центра — 6 недель.

Стоимость ППО в среднем — 800 тысяч рублей

Цены на ППО начинаются от 450 тысяч рублей. Но для сложных проектов может доходить до 3 миллионов. Цена зависит от масштаба проекта и количества необходимых артефактов — как и время проведения ППО.

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

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

Примеры стоимости ППО на разных проектах, с разным составом специалистов и количеством часов:

Как предпроектное обследование экономит время и деньги при разработке IT-продуктов
Как предпроектное обследование экономит время и деньги при разработке IT-продуктов
Как предпроектное обследование экономит время и деньги при разработке IT-продуктов

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

Разработка проекта без ППО — минус деньги и время

С 2011 года у нас скопилось достаточно факапов из-за того, что мы пропускали ППО. Все они шли по похожим сценариям и были с одинаковыми последствиями.

Вот один из примеров:

К нам обратилась компания для разработки онлайн-агрегатора автомобилей. У них уже были дизайн-макеты и бот с базовыми функциями. Они не хотели тратить время на ППО из-за сжатых сроков.

Мы оценили проект в 6 миллионов рублей и 5 месяцев разработки. Однако в процессе работы выяснилось, что клиент не до конца понимал, какие функции ему нужны и как они должны работать. Макеты противоречили функциональным ожиданиям, команды по-разному представляли реализацию функций. Пришлось постоянно менять требования, переделывать макеты и пересматривать функционал.

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

Иногда ППО может привести к неожиданным, но более выгодным решениям

Показательный пример — наш опыт работы с туроператором «СканТур». Они обратились к нам с запросом на разработку кастомной CRM-системы. Мы предложили начать с ППО, чтобы лучше понять их потребности и оценить масштаб проекта. В процессе обследования выяснилось, что им вполне подойдёт готовое решение на «Битриксе».

В результате «СканТур» получил решение, которое удовлетворяет их требования и значительно экономит бюджет. А мы получили долгосрочного партнёра.

Вот что говорит о нашей работе руководство «СканТура»:

Как предпроектное обследование экономит время и деньги при разработке IT-продуктов

Если вы планируете разработку диджитал-продукта и хотите, чтобы реализация прошла без сюрпризов, начните с ППО. Свяжитесь с нами, и мы обсудим ваш проект.

Если вам интересно, как мы работаем с другими проектами, подписывайтесь на телеграм-канал Wemakefab.

Подписывайтесь на мой телеграм-канал «Вожу рукой», если хотите узнать, как делать крутые продукты, нанимать сильных специалистов и зарабатывать деньги в диджитале.

3131
55
22
22
11
20 комментариев

Наверное, это самая подробная и понятная статья про ППО

5

Откуда такая уверенность?

Какая-то надуманная шляпа это ППО. Чисто бабок срубить. Что вы делаете, когда заказчик уже знает, что ему нужно и приносит готовое ТЗ?

1
1

Рады видеть вас в комментариях, Олег:)

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

Почему обследование, а не исследование?

Ну, обследование — это более широкое понятие. Исследование же чаще подразумевает просто сбор информации. А обследование включает и диагностику текущей ситуации, и анализ, и создание решений на основе полученных данных. Например, мы не только изучаем проект, но и находим в нём узкие места, риски, плюс к этому разрабатываем архитектуру и прототипы. Это комплексный подход, поэтому «обследование» здесь точнее

3

А была ситуация, когда после ППО картина менялась радикально? Например, клиент планировал разработать систему за полгода, а в итоге выяснилось, что работа займет год из-за скрытых проблем?