Аналитика на проекте: главные ошибки и как мы их избегаем

Частая картина: проект стартует, выделяется этап «предпроектной аналитики», аналитики уходят в свою пещеру, копают требования, рисуют схемы, пишут ТЗ. Разработчики в это время сидят в стороне, ждут, когда всё будет готово, а потом…

❌ Оказывается, что часть требований нереально реализовать.

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

❌ Не все технические ограничения не учтены, а API, которые спроектировали в ТЗ, на практике работать будут плохо.

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

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

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

📌Почему так до сих пор делают?

💰 Проще продавать клиенту отдельный этап «аналитики», где билятся только часы аналитиков. 📊 В классических компаниях аналитики считаются «владельцами требований», и их задача – передать их дальше. 📝 Устаревшие процессы: многие до сих пор работают по модели «анализ → ТЗ → передача в разработку», не учитывая, что мир давно поменялся.

📌Как делаем мы? Если проект с фиксированными требованиями (ну или почти фиксироваными)

✅ Формируем кросс-функциональную группу, где аналитик ведёт процесс, но в команде с разработчиками и дизайнерами.

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

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

Если проект гибкий (Agile, стартап, продуктовая разработка)

✅ Аналитики не пишут ТЗ – они помогают команде формулировать требования в живом бэклоге.

✅ Бэклог формируется совместно с разработчиками, дизайнерами и маркетологами.

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

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

❗️Главный принцип: аналитики возглавляют процесс, но не делают его в одиночку

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

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

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