Комментарии 8
Изначально подумал, что статья про дизайн паттерн MVP
Зачем эти экскурсы в историю в части спорных психологических и религиозных противоречий — не понятно. Если это «прототип» главы книги, то читать ее будет тяжело, получается, единственная целль книги будет — для морального самоудовлетворения автора: дескать, книгу написал.
Возможно, я ошибаюсь, но решил поделиться мнением, как читатель
Эта мысль мне тоже часто приходит в голову благодаря внутреннему критику, воспитанному на написании диплома, диссертации и научных статей по физике. Он требует уменьшения лирики в пользу согласованности тезисов, ссылок на источники и доказательной базы под каждым утверждением. Однако, когда я попробовал писать в таком стиле, материал получался сухим, перегруженным и трудным для восприятия неподготовленным читателем, напоминая книги по "Теории расписаний".
Хотя это было непривычно, я решил отойти от формата "мануала", добавив исторические отсылки, активное использование аналогий, выдвижение гипотез и выражение собственного мнения. Таким образом, удалось приблизить формат к тем, которые используются в признанных книгах, таких как "45 татуировок менеджера" или "Цель. Процесс непрерывного совершенствования". Надеюсь, такой подход сделает материал более живым и интересным для широкой аудитории.
Прототипирование функционала - архаика. Гораздо правильнее проводить качественное исследование ЦА перед началом работы, делать сразу MVP, тестировать ее на early adopters, а уже v1.0 пускать на большой рынок.
PM с 18-летним стажем. :)
Спасибо за критику!
С другой стороны, если вы готовитесь к участию в конкурсе по ФЗ 44 на разработку внутрекорпоративного ЭДО или по ФЗ 223 на создание ПАК для станка на заводе, вряд ли у вас будет возможность провести полноценное исследование ЦА. В таких случаях вы будете вынуждены создать прототип, чтобы успешно конкурировать.
К тому же, любой производственный процесс всегда существует в определенном финансовом контексте. Исследование ЦА требует финансовых вложений, ресурсов и времени, которые не всегда легко получить. Руководителю необходимо обосновать эти затраты, и для этого часто приходится начинать с создания хотя бы минимального прототипа, даже если он будет реализован на уровне PowerPoint и Figma. Прототип помогает не только визуализировать идею, но и показать заинтересованным сторонам ее потенциал, что упрощает получение необходимых ресурсов для дальнейшего развития проекта.
В будущем внесу эти примеры в основную статью.
MVP достаточно сложно реализовать при создании автоматизированных систем, т.к. человеческая (люди) составляющая часть системы при превышении определенного количества участников не может реализовать из себя "ограниченный функционал", т.к. она состоит из разнофункциональных субъектов, и накладывание ограничений на отдельные части приводит к полной неработоспособности системы, состоящей из этих частей.
На мой вкус определение МВП не очень корректное. В моей практике, первая задача МВП это не собрать ОС, а ускорить delivery функционала.
Плюсом, если ключевая задача МВП - собрать ОС для определения направления дальнейшего развития, то звучит скорее как пилот или демо версия.
Ускорение поставки результатов работ путем деления на этапы — это действительно один из классических методов управления проектами. Разделение работы на несколько этапов или релизов помогает оптимизировать процессы и ускорить поставку конечного продукта. Однако, если основной целью является исключительно ускорение поставки без необходимости получения обратной связи (когда ОС этапа 1 не влияет на работу по этапу 2), то использование термина MVP в данном контексте может быть некорректным. В вашем случае более уместно говорить о этапах или релизах, а не о MVP, так как MVP подразумевает обязательное получение обратной связи для определения дальнейшего направления развития продукта.
Прототипирование и MVP