Зачем нужно проектирование?

1920x1080 (3)

Разработка — важно, дизайн — решает, проектирование — это что? Так реагируют 7 из 10 заказчиков, когда мы рассказываем, из чего состоит бюджет проекта. Словами максимально отдаленными от “разработческих” терминов рассказываем, почему проектирование —  основа любого проекта.

Когда мы рассказываем заказчику, как устроен процесс создания продукта, не нужно объяснять, зачем нужна разработка и почему важно проработать дизайн. Когда начинаем разговор  о проектировании, в глазах читается “а можно без этого?”. Критерий прост: результатом разработки и дизайна является конечный продукт, а в ходе проектирования получаем только прототипы, которые будут дорабатываться по ходу разработки. Так почему нельзя сразу начать разработку, без “лишнего” промедления?

Объясняем на примере, как проектирование уменьшит временные затраты на других этапах:

Представьте, что в одном из концов Санкт-Петербурга вам назначена встреча. Вы можете:

а) используя навыки ориентирования и интуицию, сменить несколько автобусов, поблуждать по переходу Садовая/Cпасская/Сенная, пару раз поинтересоваться у прохожих, как добраться от метро до желанного места назначения и, наше любимое, минут 15 поискать вход. Конечно, в итоге в точке Б вы окажетесь. Возможно, даже в нужный день.

б) используя навигаторы, карты и друзей-местных проложить точный маршрут, приехать заранее и выпить чашечку кофе перед встречей. Догадываетесь, к чему мы?

Попробуйте прикинуть риски, денежные и временные издержки на поиск дороги. Такая логика действует и в разработке!

Главный тезис на сегодня:

Разработка с использованием проектирования — это способ создания продукта, при котором есть объективные возможности гарантировать сроки и стоимость.

Приступим к доказательству.

Каким образом происходит оценка сроков и стоимости?

Проектирование выполняет несколько задач, поэтому удобно его делить на этапы.
01 (1)

 

1. Аналитическая часть

Определяем первостепенные и второстепенные цели продукта, рисуем портрет целевой аудитории, анализируем конкурентов. В результате получаем начальное видение продукта, на основе которого переходим к следующему этапу.

Результат: концепт продукта.

2. Функциональное проектирование

Определяем “функциональную начинку” приложения: рассматриваем все возможные технологии и думаем, как они повлияют на конечный продукт, проектируем модель взаимодействия пользователей с системой. Здесь фантазия не ограничена ничем — собираем на бумаге продукт мечты, чтобы лучше всего реализовать цели продукта и удовлетворить целевую аудиторию (об этом говорили на предыдущем этапе, помните?)

Результат: предварительный функционал приложения, основанный на аналитике; сценарии взаимодействия пользователя с системой.

3. Интерфейсное проектирование

Этот этап про нахождение формы, в которую можно облечь результат двух предыдущих: как мы представим функции в интерфейсе системы? Продумываем способ, с помощью которого весь оговоренный функционал будет максимально понятным.

Результат: предварительная структура экранов.

4. Техническое проектирование

Самый сложный для понимания, но решающий для разработки этап.

Проводим поиск способов реализации системы, с учетом предыдущих этапов. Здесь мы отвечаем на вопросы: могут ли существовать эти функции на данной платформе? как будет происходить взаимодействие между частями системы? с помощью каких технологий будет реализован функционал?

Результат: основные нефункциональные и функциональные требования, сформированный Product Backlog.

В Product Backlog пишем, как система функционирует с точки зрения пользователя

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

02

Допустим, мы решили обойтись без проектирования

Ведь все вышеописанное должно выясниться во время разработки, правда? Правда. Вспомните пример в начале статьи. Проектирование в любом случае происходит, но менее качественно, дольше, путем проб и ошибок, которые и предотвращает этап проектирования. А значит, экономит время и деньги.

Почему результат проектирования — не просто перечень требуемого функционала?

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

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

Заключение

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