Удачный старт: важность предпроектного обследования для бизнеса

Что такое ППО и в чем его ценность

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

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

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

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

Можно ли не проводить ППО?

Нельзя. Даже если у заказчика есть подробное техническое задание и свое видение реализации проекта, это совсем не то ТЗ, которое можно отдать в работу на аутсорс внешней компании. Сначала нужно сформировать требования, иначе из условного «автомобиля» на выходе получится «микроволновая печь» или наоборот. Готовое ТЗ подойдет только в том случае, если у компании есть своя команда разработки, но и та будет проводить свое ППО, после чего реализовывать проект.

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

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

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

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

Этапы предпроектного обследования

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

1. Интервью с заказчиком

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

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

2. Анализ собранной информации и разработка верхнеуровневых требований

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

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

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

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

3. Конкурентный анализ

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

4. Формализация требований и передача готовой документации

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

Показательные кейсы

Lamoda

В предпроекте с компанией Lamoda заказчику требовалось сформировать требования к решению по ценообразованию. Заказчики хотели управлять всеми процессами в одном окне, сделав их максимально автоматизированными, удобно работать с ценами конкурентов и выстраивать иерархию ценовых правил. Для проведения ППО была сформирована опытная команда, которая смогла провести исследования бизнес-процессов, включая ценообразование, схемы лояльности и скидочные механики. После серии интервью с заказчиком команда разработала подробные юзер-стори и техническую документацию, описывающую интерфейсы и взаимодействия с системой Goal Profit, что позволило Lamoda эффективно искать контрагентов для дальнейшей разработки.

По итогам предпроектного обследования, был создан документ объема более 200 страниц, который четко описывал визуальные интерфейсы и взаимодействие с внутренними системами. Особое внимание было уделено текущему оптимизатору, который Lamoda планирует развивать как целевое решение для интеграции в систему ценообразования. Работа была выполнена за 10 недель.

Hoff

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

Проект предусматривал внедрение нового, более эффективного процесса, который должен был интегрировать и оптимизировать работу различных внутренних систем компании, таких как ERP, PIM и BI. Первым этапом стала предпроектная аналитика, в ходе которой команда Napoleon IT провела глубокий анализ, собрала и формализовала требования от ключевых сотрудников Hoff. Этот этап стал залогом успешной разработки и запуска портала, который был высоко оценен заказчиком за качество и эффективность.

{{audit}}

ППО как начало сотрудничества

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

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

Кроме того, ППО способствует более тесному взаимодействию между командами клиента и исполнителя, создавая атмосферу партнерства и готовности к совместному решению задач. Глубокое понимание специфики бизнеса клиента позволяет команде разработке оперативно реагировать на изменения и адаптировать решения под развивающиеся потребности клиента.

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