Проектирование как способ не слить бюджет на разработку приложения

Разработка — важно, дизайн — решает, проектирование — а это что? Так реагируют 7 из 10 заказчиков InfoShell, когда мы рассказываем, из чего состоит бюджет проекта. Человеческими словами объясняем, почему проектирование — основа любого проекта.

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

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

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

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

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

Итак, тезис:

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

Проектирование выполняет несколько задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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