Вопрос задан интересный, но ответа не дано. Между тем это действительно серьёзная проблема, когда перед началом большого проекта требуется сформировать для демонстрации заказчику обладающей хотя бы начальной функциональностью макет. Если исключить варианты, когда проект выполняется на основе уже существующих решений (которые можно показать в законченном виде и упомянуть лишь, чем будущая система будет отличаться), то исполнитель встаёт перед не самым лёгким выбором.
В современных системах конечный пользовательский функционал, как правило, является лишь сравнительно тонким слоем над ядром и универсальными промежуточными сервисами и платформами. Соответственно, он не реализуется отдельно сверху донизу - поскольку такая реализация предполагает практически обязательные проблемы в будущем с развитием, поддержкой и интеграцией этого функционала в случае изменения процессов заказчика, им обслуживаемых. Одновременно задачей макета является именно демонстрация конечного пользовательского функционала.
Соответственно, остаётся либо формировать "поддельный" макет, повторяющий лишь внешние признаки будущей системы и не имеющий практически ничего общего с ней в архитектурном смысле, либо выстраивать в каком-то приближении весь невидимый для зрителя архитектурный "фундамент" под демонстрируемый функционал.
В первом случае сравнительно быстро получается макет, который относительно легко можно сделать привлекательным для заказчика, но который является не реальной моделью, а лишь своеобразной формой презентации или интерактивного видеоролика. После демонстрации этот макет будет практически наверняка выкинут - соответственно, то, что заказчик видит в макете, и то, что он реально получит в конце проекта, может сильно отличаться.
Во втором случае макет реально будет нести полезную информацию о планируемом решении и может, скажем, уже на этапе своей реализации указать на ранее пропущенные неоднозначности в ТЗ и других проектных документах. Но построение такого макета обычно требует больше времени и усилий. При этом остаётся возможным, что заказчик по результатам показа если не откажется от своего задания, то изменит его условия - а заметные усилия, требующие оплаты (причём усилия более комплексной, чем в первом случае, команды - нужны и архитекторы, и аналитики, и т.д.), уже будут затрачены. Опять же, демонстрируемый функционал тоже будет в этом случае более бедным.
Задача подобного выбора облегчается, если эксперты заказчика обладают некоторой ИТ-компетенцией - в этом случае они понимают, что более информативным будет второй вариант, и могут как обосновать более длительные сроки перед начальством, так и с пониманием отнестись к нежеланию исполнителя делать такой макет подробным. Если же заказчик не предоставляет в процессе общения этих своих компетенций, то задача для исполнителя становится, с одной стороны, более простой, но цена ошибки (риск выдачи несбыточных в реальной системе обещаний) одновременно возрастает.
Posts
6 comments:
по-моему, они нужны для разных целей - макет несёт маркетинговую информацию, а прототип - потенциал реализации. на мой взгляд, лучше всего делать макет всемте с прототипом небольшого кусочка функционала
В идеале, конечно, это разные ступени, которые должны идти последовательно. Но часто приходится выбирать между этими подобными вариантами, особенно в ситуациях, когда непонятно, будет ли вообще эта следующая ступень.
На мой взгляд, "отвязанный" макет - это потеря времени. То есть понятно, зачем он нужен и почему, но с этой ролью с тем же эффектом справляются презентации и прочие инструменты, не требующие заметного участия технического персонала.
Потому, собственно, и озадачился, что сейчас навскидку вспомнил несколько таких бесполезных макетов, с которыми приходилось иметь дело в разное время. Т.е. более распространённая практика, чем хотелось бы.
отвязанный макет - да, пустышка. рекламка, фактически
вот только оговорка про сочетание уже существующих решений - это может быть как раз оправданием. то есть, если уверен, что функционал - не проблема, и вопрос только в позиционировании и маркетинге
Ну, в общем, в статье по ссылке рассказано о том, коротко говоря, не нужно делать интерфейс раньше логики. Я как-то задумался, откуда вообще может взяться такой странный вопрос с очевидным ответом и вдруг понял, в каких случаях это действительно проблема.
Не такой уж ответ очевидный: во всяком случае, есть целая идеология - с процессами разработки, статьями - рекомендующая начинать с интерфейса, и внутренности строить исходя из его возможностей и ограничений. Фактически, интерфейс и его use-case трактуются как подробное задание.
Разумеется, это может работать только при сильной изоляции интерфейса от модели - но, опять же, большинство процессов считают это хорошей практикой.
И, да, макет получается сам собой из первой версии.
Это конечно плоховато стыкуется с итерациями, но в некоторых случаях, на мой взгляд, может быть оправдано.
Post a Comment