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

Как обычно, немного вводной информации. MVP — Minimum Viable Product, или минимально жизнеспособный продукт. Его задача не в том, чтобы сразу создать идеальный сервис, а в том, чтобы как можно быстрее превратить идею во что-то работающее и проверить её на практике.

По сути, MVP позволяет: • быстро проверить идею и понять, нужна ли она вообще; • не потратить огромный бюджет на разработку того, чем никто не будет пользоваться; • получить первые отзывы пользователей; • понять, в какую сторону развивать проект дальше.

Нашим первым таким проектом стал Pentester Dashboard. ⇨ Первую версию мы сделали примерно за неделю: начали в понедельник, а уже в воскресенье появился первый публичный коммит. На разработку уходило примерно по 3–5 часов в день.

Первый релиз так и назывался: «Pentester Dashboard v1.0.0-alpha — First public testing release». ⇨ Мы сделали акцент на слове alpha. Проект был сырым и явно не готовым для широкой аудитории, но уже решал конкретную проблему, с которой мы сами сталкивались в багхантинге.

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

Но багов в mvp, конечно, хватало у нас. • Не было нормального импорта результатов других инструментов — многое приходилось заводить руками. • Импорт SQL-проекта мог ломаться и требовать перезапуска. • Данные зависели от жизненного цикла Docker, поэтому неэкспортированный проект можно было потерять. • Не было нормальных ограничений на размеры некоторых данных, из-за чего ломался визуал.

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

Именно здесь, как мне кажется, и находится главная мысль MVP: его ценность не в качестве архитектуры, идеальном UI или количестве документации. А в том, что идея перестаёт существовать только у вас в голове. Уже можно открыть, потрогать, показать другим людям и главное понять, действительно ли она решает проблему.

Уже позже, в версии 1.1.0, мы начали превращать Pentester Dashboard из MVP в полноценный продукт: • перерабатывать архитектуру, • разделять бэкенд на микросервисы • приводить к единому стилю интерфейс и функционал • писать документацию и упрощать дальнейшую поддержку проекта.

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

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

Поэтому для меня MVP — это не «плохая версия хорошего продукта». Это момент, когда ваша идея впервые оживает. А уже после этого её можно сколько угодно доводить до идеала: менять архитектуру, улучшать визуал, писать документацию, автоматизировать процессы и выпускать новые версии.

Главное — сначала дать проекту возможность вообще появиться.

А на превью наш первый релиз проекта, который мы рассмотрели сегодня на примере реализации mvp) - https://github.com/eZer-Net/pentester-dashboard

#DigitalShield #CyberSecurity #AppSec #Pentest #BugBounty #OpenSource #GitHub #SecurityTools #IT #MVP