Как делать продукт в проектном практикуме: MVP и итеративность

Цель этой страницы — задать правильный образ результата и способ движения: вы учитесь не “писать код вообще”, а делать работающий продукт итеративно, применяя инженерные практики в правильной последовательности.

Этот принцип используется в обратной связи и влияет на оценивание.

1. Сквозная компетенция: выполнять работу правильно

Как выполнять работу правильно (код, архитектура, тестирование, дизайн, анализ) обычно объясняют на профильных дисциплинах. На проектном практикуме важно применять эти подходы в правильной последовательности, учитывая:

• контекст задачи и целевую функцию,
• ограничения времени,
• способности и состав команды,
• обратную связь от куратора/заказчика.

Критическая обратная связь в проектном практикуме чаще всего направлена именно на это: не только “что сделали”, но и “как сделали”.

2. Идеальный образ результата: MVP как продукт

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

MVP — это не:

• «просто макет/дизайн» без работающей целевой функции,
• «набор модулей в репозитории» без сборки/запуска,
• «идеальный продукт» (качество растёт итерациями),
• «переписать всё заново потом» (итерации должны наращивать одну линию продукта).

Три типовых траектории (и почему две из них плохие)

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

Вариант 2 — “делаем другие продукты”
Самокат → велосипед → мотоцикл: это разные продукты, с разными требованиями и процессами. В масштабе семестра это почти всегда тупик: вы инвестируете в то, что плохо переносится в финальный продукт.

Вариант 3 — оптимальный: “вертикальный срез с постепенным улучшением”
Сразу виден целевой продукт (пусть грубый), он уже выполняет функцию. Дальше вы улучшаете качество, надёжность, UX, автоматизацию, покрытие сценариев. Так у вас на каждом этапе семестра уже есть целостный продукт, пусть и не доведенный до идеала.

3. Итеративный подход: всегда есть «вся картинка», а детали дорабатываются

Такой же подход можно рассмотреть и на подобной картинке.

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

Важно: в итеративном подходе у вас всегда существует версия продукта. Детали и качество улучшаются, но “живой продукт” не появляется в последний день.

• длина итерации: обычно 1–2 недели,
• конец итерации: демо + обратная связь + обновление backlog,
• цель итерации: улучшить определенный объём функционала (функция/качество/UX/автоматизация). Важно, что работы включенные в этап должны быть логически завершены.

4. Мини-чек-лист: что значит “у нас уже MVP”

• Есть понятная целевая функция и сценарий использования (1–3 сценария).
• Сборка/запуск воспроизводимы (хотя бы минимально).
• Можно показать результат пользователю/заказчику и получить обратную связь.
• Понятно, что улучшать в следующей итерации (backlog на 5–10 задач).

Свидетельства MVP (минимальный пакет):

• ссылка на репозиторий/артефакт,
• инструкция запуска (README: как запустить за 10 минут),
• демо (видео 1–3 мин / ссылка на стенд),
• список известных ограничений/заглушек (“что пока вручную”),
• backlog следующей итерации (5–10 задач).

Доп. чтение: Артемий Лебедев — “метод прогрессивного джипега” (Ководство), раздел 167: https://www.artlebedev.ru/kovodstvo/sections/167/