Подпишитесь на наш блог
Подпишитесь на нашу электронную ежемесячную рассылку для получения полезных советов и ценных ресурсов
Процесс разработки приложений и ПО
в Omega
ДЕКАБРЬ, 2020
Наличие приложения, помимо традиционных программ на компьютерах, стало чуть ли не обязательным условием выживания бизнеса. На деле в сторах лежат миллионы невостребованных приложений, в каждое из которых вложены, как минимум, сотни тысяч рублей.

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

Первый этап

Предположим, что нулевой этап выбора компании-разработчика решён. Возникает неопределенность — что дальше? Разберемся в этом подробно и на примерах.

Кажется, что разработка приложений и ПО — дело лишь программистов. На самом деле, весь процесс начинается задолго до этапа программирования — в голове заказчика. Чем лучше проработана идея на этом этапе, тем скорее можно будет начинать разработку. Здесь же стоит обдумать вопросы, которые необходимо задать компании-разработчику, например:

  1. В каких областях и с какими заказчиками ИТ-компания реализовала проекты?

  2. Есть ли у ИТ-компании аналогичные проекты в портфолио и были ли они успешными?

  3. Сколько будет стоить ИТ-продукт?

  4. Как долго он будет разрабатываться?

  5. Как выглядит процесс разработки и готова ли ИТ-компания согласовывать результаты на каждом его этапе?


Даже если найти положительные ответы на эти общие вопросы, стоит проработать технические нюансы. Это важно для работы на перспективу. Среди них:

  1. На каких платформах будет работать софт: iOS, Android, кроссплатформенное приложение, облачное решение, иная платформа. Кстати, немного разобраться в этом поможет наша статья.

  2. Какие технологии должны быть применены?

  3. Есть ли предпочтения по языкам программирования?

  4. Предоставляет ли ИТ-компания техническую поддержку после запуска продукта?

  5. Каковы предпочтения по дизайну?

  6. Предоставляет ли компания исходный код?

Второй этап

На втором этапе подключаемся мы, как ИТ-компания. Для нас, в отличие от клиента, это вводный этап. Цель — помочь заказчику сформулировать техническое задание. Наши аналитики изучают потребности клиента, его идею, рынок и конкурентов, определяют ключевые функции продукта, собирают предварительную команду разработчиков, чтобы дать предварительную оценку.
В одних случаях мы приходим к выводу, что клиенту выгоднее обойтись более простым решением или что предполагаемая концепция не даст ожидаемого результата. В других случаях мы подтверждаем, что идея жизнеспособна, и предлагаем более эффективную конфигурацию ПО. Обычно так происходит, если заказчик уже имел опыт работы с ИТ-компаниями.
У нас в работе находится проект «NITO», заказчиком которого выступила международная ассоциация IT-специалистов. Она уже имела десятки центров, в которых специалисты сдавали экзамены и тесты. Теперь ассоциация поставила перед собой цель сократить расходы на аренду офисов и перевести сертификацию в онлайн. Это позволит экзаменуемым проходить испытание, не выходя из дома. Команда заказчика предоставила настолько подробный бриф, что в нем был даже анализ готовых решений для подсистемы прокторинга в их новой платформе.
Если у заказчика очень «сырые» входные данные, то мы самостоятельно формулируем бизнес-идею, концепцию ее реализации, техническую осуществимость и требования в свободной форме, а также модель монетизации, если это предполагает проект. Если заказчик и мы понимаем, что видим проект одинаково, то переходим на следующий этап.

Третий этап

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

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

Чем сложнее проект, тем больше времени он потребует. Это влияет на сроки и стоимость. Поэтому мы анализируем все составляющие проекта, ищем баланс между стоимостью, сроками и техническими требованиями и согласовываем оценку работ по стоимости и срокам. Кстати, итоговые сроки берутся не «из головы», а вычисляются с помощью диаграммы Гантта. Диаграмма Гантта — это таблица с графиком реализации задач проекта. Она полезна не только заказчику для отслеживания работы. Без нее не сможет обойтись ни один из членов проектной команды.
На этом этапе мы обмениваемся файлами, которые можно назвать черновиками будущих подписанных документов. Здесь всё ещё в ходе планирования у клиента могут возникнуть новые обстоятельства или идеи. В этом случае мы проходим этот этап заново, поскольку без этого не получится создать именно тот идеальный софт, ради которого мы все вместе работаем.

Четвертый этап

Только на четвертом этапе можно говорить о подписании документов:

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

  • смета — производится детализированный расчет предстоящих расходов на реализацию проекта. Основой для нее является та самая диаграмма Гантта, которая дополняется финансовыми показателями по каждой задаче.

  • договор. К этому моменту заказчику необходимо определить специалиста, который будет всегда на связи для обсуждения деталей, и контактное лицо, которое будет принимать ключевые решения. Это необходимо, чтобы в будущем мы шли «в ногу» с заказчиком практически ежедневно. В свою очередь, заказчик получает контакты наших специалистов, работающих над проектом, и доступы к программам для отслеживания работы.
Пятый этап

Пятый этап начинается с того, что все материалы проекта передаются проектной команде непосредственно в разработку, которая составляет пошаговый план-график работы. Размер команды может быть любым, исходя из необходимого срока разработки и набора технологий.
Например, над онлайн-платформой сертификации «NITO» трудились 18 специалистов Omega: технический директор компании, 2 проектных менеджера, системный архитектор, 7 backend- и frontend-разработчиков, DevOps-инженер, 2 UX/UI-дизайнера, 4 специалиста по обеспечению качества и тестированию. Но каждый проект индивидуален и требует разных специалистов.
На этом этапе видимая часть работы относится по большей части к дизайнерам. Они еще раз глубоко прорабатывают стратегию развития приложения или иного программного обеспечения и в деталях исследуют целевую аудиторию пользователей с помощью интервью, наблюдений и опросов.

Часто дизайнеры прибегают к методике JTBD (Jobs To Be Done) — это те проблемные ситуации, которые заставляют пользователя прийти за их решением к бизнесу заказчика. Через проблемы пользователя мы выходим на проблемы бизнеса, который по какой-то причине перестал решать проблемы своих клиентов.
Чтобы создать программное обеспечение, которое решает проблемы бизнеса, дизайнерам важно понять, как бизнес решал те же проблемы до сих пор. Такое исследование позволяет им создать визуальную карту путешествия пользователя по бизнесу и найти в ней болевые точки. В этом также поможет любая аналитика по работе с пользователями, имеющаяся у заказчика.

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

Шестой этап

Лишь на шестом этапе начинается разработка, но без написания программного кода. А такое возможно? Да, но обо всём по порядку.

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

Седьмой этап

Седьмой этап также остается на стороне дизайнеров. Да, заказчику может понравиться прототип, но он должен понравиться и пользователям. Им пользоваться — они и должны дать окончательный вердикт. Именно от этого зависит успех.

Всё, как в реальном производстве — тестируем прототип. Для чистоты эксперимента дизайнеры иногда готовят два варианта прототипа и дают «поиграться» ими нескольким пользователям. Сидя рядом с дизайнером, они выполняют его задания прямо в прототипах. После этого он опрашивает их, что нравится и что не нравится, какие задания они выполняют легко, а какие с трудом и почему. Это позволяет выявить проблемные точки в прототипах и оценить, какой из них лучше и быстрее решает проблему пользователя.

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

Как вы помните, прототип еще не «раскрашен». Поэтому на седьмом этапе UI-дизайнеры занимаются выбором визуальной составляющей, или графическим дизайном: разрабатывается UI Kit, дизайн-система, подробный интерактивный прототип и анимация интерфейса. Если заказчик заранее определился с цветовыми решениями или даже разработал UI Kit, то работа идет куда быстрее. Но лучше довериться профессионалам, которые много лет занимаются дизайном на крупных и небольших проектах.

UI-дизайн — это также дело вкуса заказчика, поэтому здесь часто бывают правки. Изменения бывают и тогда, когда заказчик понимает, что ИТ-продукт должен решать больше бизнес-задач, чем запланировано.
Например, в проекте «NITO» мы разработали всю дизайн-систему, а после этого оперативно поменяли и пересмотрели ее по мере изменения и трансформации требований из-за большого количества функционала и сложности модулей. Мы настолько погрузились в работу, что представили новый логотип платформы, хотя его разработка не входила в требования. Логотип напрашивался сам собой и вобрал всё то, что выражено в дизайн-системе. Приятно, когда клиент ловит драйв вместе с нами.
Восьмой этап

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

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

И даже не всегда речь идет лишь о языках. Чтобы вы поняли, сколько всего должны проработать программисты, вернемся к примеру с «NITO», онлайн-платформы для удаленного приема экзаменов.
Она состоит из семи ключевых модулей, которые должны работать синхронно, чтобы для пользователя всё происходило плавно и быстро: модуль разработки экзаменационного контента, модуль доставки экзаменационных пакетов, веб-интерфейс пользователя, модуль оценки результатов, модуль контроля качества экзаменов, модуль сбора и анализа статистики, интеллектуальный модуль генерации экзаменационных форм. За каждым из них скрываются сотни часов работы и множество технологий. Если убрать хотя бы один из этих модулей, вся система развалится.
Бывают и такие ситуации, когда дизайнер сделал свою часть работы хорошо, а программист не сумел реализовать современный визуал и удобный пользовательский путь в коде. Это скорее недоработка программиста. Чтобы такого не происходило, существует следующий важный этап, пропуск которого влечет фиаско проекта.

Девятый этап

Тестирование. Некоторые считают, что в тестировании нет необходимости, если ИТ-продукт создают профессионалы. В этом есть доля правды. Но взглянем, к примеру, на создание автомобиля — никто не выпустит его на городские дороги без тестирования, даже если это BMW, созданный лучшими в мире инженерами. И если вы хотите, чтобы пользователь ощущал себя словно владельцем комфортного автомобиля при включении вашего приложения или любого другого программного обеспечения, то без проверок и перепроверок не обойтись. Так создается абсолютно любой качественный ИТ-продукт.

Тестирование — это не дополнительный этап к процессу разработки, а обязательная часть разработки. И речь не о простой «прогулке» по приложению.

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

Тестировщики готовят практически бесконечные чек-листы тестирования со строгими правилами. Это позволяет ничего не забыть и зафиксировать все встречающиеся ошибки. Для сложных платформ готовятся еще более сложные тест-кейсы.

Какие ошибки могут быть? Например, программа, которой требуется интернет, выключается при отсутствии интернета; приложение очень долго загружает видео; после смены пользователя остается список любимых продуктов в личном кабинете нового пользователя. И еще бесконечные варианты ошибок, или, как говорят айтишники, багов.
В проекте «NITO», например, мы решали следующие проблемы: не открывался файл pdf в защищенной среде, некорректно отображались логотипы в некоторых местах, происходили сбои при изменении паролей доступа, система отправляла неправильные ссылки на почту для подтверждения регистрации. В 2020 году, к концу которого проект «NITO» находится на завершающем этапе, тестировщики разработали 10 чек-листов, состоящих суммарно из 1500 проверок, и протестировали платформу по чек-листам 80 раз. Часть проверок были выполнены с помощью автоматизированных программ, чтобы исключить человеческий фактор.
Тестировщики проводят огромное количество тестов: code review, A/B-тестирование, функциональное тестирование, тестирование пользовательского интерфейса, usability-тестирование, тестирование совместимости, нагрузочное и регрессионное тестирование, тестирование адаптивности, тестирование верстки. Непосвященному человеку будет сложно разобраться во всех видах тестирования.

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

Десятый этап

Десятый этап — самый приятный для нас. Мы передаем ИТ-продукт с технической документацией заказчику. При необходимости мы помогаем клиенту зарелизить его, например, загрузить приложение в магазин Google Play или App Store.
Эта часть работы похожа на праздник, поскольку программисты уверены в чистоте и стабильности кода, в том, что в нем нет блокирующих и критических багов. Наш код легко поддерживать и изменять благодаря грамотной архитектуре. Вся проектная команда твердо убеждена, что надежный ИТ-продукт решил боль заказчика и помог ему достигнуть бизнес-цель, поскольку создавала его по крупицам «своими руками» и современными технологичными инструментами.

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

Предлагаем пройти весь путь нашего производственного процесса. Если у вас есть интересные идеи или сложное техническое задание, обращайтесь в ИТ-компанию Omega за разработкой мобильного приложения или ИТ-проекта.
Продуманные решения для мобильной разработки!
Хотите повысить эффективность своего бизнеса?

Подпишись, чтобы получать больше наших предложений
Популярные статьи