В разработке ИT-продуктов участвуют две стороны: заказчик и аутсорсинговая компания. Заказчику нужен результат, который поможет сделать его бизнес успешнее. Аутсорсинговая компания же заинтересована в качественном выполнении работы с технической стороны.
Обе стороны работают над одним продуктом, и основная проблема заключается в налаживании партнерской коммуникации между заказчиком и разработчиками. Заказчик должен грамотно изложить свои пожелания и предоставить всю необходимую информацию. А разработчик — суметь объяснить все этапы разработки на понятном языке.
Поэтому разработку ИT-продукта следует разделить на этапы, каждый из которых имеет четкую цель и результат. При этом, хотя этапы выполняются последовательно, к некоторым из них можно возвращаться для внесения корректировок.
В статье разберем основные этапы разработки и рассмотрим существующие схемы создания новых ИТ-продуктов.
Этапы разработки
Каждый новый программный продукт уникален. Тем не менее существует общий алгоритм процесса разработки, который позволяет проделать путь от идеи до готового продукта максимально быстро и эффективно. Основные этапы разработки ИТ-продукта — это планирование, аналитика, проектирование, дизайн, разработка, тестирование, запуск и поддержка. Разберем их подробнее.
Планирование
На этом этапе клиент и разработчик садятся за стол и начинают разговаривать. Клиент выдвигает идеи, излагает пожелания и описывает, как он видит конечный продукт. Разработчик, в свою очередь, внимательно слушает, отвечает на вопросы и корректирует ожидания клиента, сверяясь с техническими возможностями.
В итоге клиент и разработчик должны прийти к общему знаменателю в вопросах понимания целей и задач проекта.
Аналитика
Далее необходимо все зафиксировать на бумаге — создать техническое задание. Для этого аутсорс-компания анализирует данные, собранные от клиента, на возможность реализации. Здесь важно продолжать вести открытый диалог с клиентом, рассказывая, что из его пожеланий невозможно реализовать. Если есть более простые пути решения поставленной задачи, следует указать на это.
В самом простом варианте итогом является ТЗ от заказчика. В более сложном — создание презентации, в которой детально описываются:
- модель продукта;
- временные и финансовые затраты на проект;
- оценка проекта;
- потенциальные риски;
- варианты решения задач, если их несколько;
- дорожная карта — примерный план разработки;
- условия и прочие детали.
Проектирование
Теперь, когда вы обсудили с клиентом все детали, пора спроектировать будущий продукт. Для этого необходимо:
- Создать дорожную карту с ключевыми точками, в которых будет происходить контроль и оценка результатов.
- Спроектировать архитектуру программного обеспечения.
- Выбрать технологии и инструменты разработки для создания продукта — языки программирования, систему управления баз данных и т.п.
Дизайн
Далее дизайнер должен создать макет приложения. При этом нужно задумываться не только о визуальной части, но и отвечать себе на вопросы: «Будет ли это удобно для пользователя?», «Сможет ли юзер быстро найти нужную кнопку?», «Захотят ли посетители вернуться в приложение?». Пользователь должен чувствовать себя комфортно — это принципиальная позиция, ведь неудобное приложение может привести к большим финансовым потерям бизнеса.
Технически дизайн состоит из двух основных блоков:
- UI — как приложение выглядит. Отрисовка кнопок, блоков, полей для ввода текста и других элементов.
- UX — как приложение работает. Адаптивность под разные платформы, логика взаимодействия и построения системы.
Разработка
Один из ключевых этапов разработки ИТ-продукта. Здесь происходит практическая реализация всех идей и концепций. Весь графический интерфейс начинает приобретать рабочий вид.
Этот этап — наиболее длительный и трудозатратный. Поэтому его необходимо выполнять пошагово. На каждом шаге полезно демонстрировать результат заказчику, чтобы оперативно получать обратную связь.
Многие команды разработчиков используют методологию спринтов. Спринт — это короткий, ограниченный по времени период, в течение которого команда работает над выполнением определенного объема работы.
Это позволяет прорабатывать все компоненты программного обеспечения с регулярными отчетами. Процесс разработки становится прозрачным и предсказуемым, повышается гибкость: чем больше спринтов (итераций), тем чаще можно вносить изменения.
Тестирование
Здесь на сцену выходят QA-инженеры. В их арсенале есть много инструментов, которые помогут «сломать» продукт. Это нам и нужно. На данном этапе важно выявить все критические ошибки, с разных сторон проверить функциональность приложения и провести комплексный анализ работы программы.
Результатом должен быть итог — все работает, но это в идеальной ситуации. В реальности на данном этапе формируется список ошибок и рекомендаций по улучшению ПО. После чего в программу вносятся изменения и происходит повторное тестирование.
Операции тестирования и доработки программного продукта можно проводить много раз. Но не стоит зацикливаться на бесконечной «полировке» приложения. Многие ошибки несущественны и на основную функциональность не влияют, поэтому их можно устранить в процессе опытной эксплуатации.
Запуск
После успешного тестирования запускаем готовый продукт в работу. На данном этапе оценивать приложение будут реальные пользователи. Здесь главное:
- настроить инструменты мониторинга для отслеживания поведения пользователей;
- собрать обратную связь;
- организовать возможность оперативной доработки продукта.
Кроме того, запуск подразумевает передачу прав на программный продукт заказчику. Вместе с правами передается вся техническая документация и контроль над программной частью.
Поддержка
Поддержка программного продукта может осуществляться двумя путями:
- Компанией-разработчиком. Временное или постоянное сопровождение. Это решение требует затрат, но позволяет уменьшить простои и ускорить устранение возникающих неполадок.
- Собственными силами. Это неплохое решение для случаев, когда в компании есть программист или штат ИT-специалистов. Собственные сотрудники заинтересованы в бесперебойной работе приложения и быстрых решениях возникающих проблем.
Модели жизненного цикла разработки ПО
Итак, мы разобрались с пошаговым управлением проектами и привели общий план, который характерен для большинства разрабатываемых продуктов независимо от масштаба. Но подходов к реализации этих шагов очень много. Разберем основные концепции.
Водопадная модель
Самая базовая и понятная концепция. В ней все этапы разработки ИТ-продукта выполняются последовательно, друг за другом. Такая модель подойдет для небольших проектов, в которых ясны требования и ожидаемый результат.
Несмотря на свою простоту методология негибкая, а на практике занимает много времени. Дело в том, что каждый последующий этап проекта зависит от предыдущего.
V-образная
В отличие от водопадной модели V-образная методология подразумевает, что на каждом этапе параллельно выполняется тестирование. За счет ориентации на тестирование и проверку данная модель является более гибкой и адаптивной.
Прототипная модель
Заключается в создании модели-прототипа приложения, которую наделяют ограниченными функциональными возможностями и менее эффективной реализацией программного кода. Главная цель — заранее выявить запрос и потребности пользователя.
Прототип дорабатывается до тех пор, пока не удовлетворит все запросы клиента. Прототипная методология ценится за максимальную вовлеченность клиента, что позволяет избежать ошибок и двусмысленности в понимании желаемой функциональности продукта.
Стоит учитывать, что при такой модели сложно просчитать сроки разработки — они могут меняться при каждой доработке или выявлении проблемы.
Спиральная
Особенностью спиральной модели разработки является комплексный учет рисков. Методология состоит из четырех основных процессов:
- Планирование.
- Анализ рисков.
- Разработка.
- Оценка.
Процесс разработки представляет собой последовательный переход по спирали, витки которой проходят через все процессы. Количество витков зависит от масштаба проекта и степени проработки. Модель удобна и востребована для крупных проектов со сложными условиями и требованиями.
Итеративно-инкрементальная модель
Метод заключается в разбиении большой задачи на ряд маленьких подзадач и их выполнении с постепенным соединением частей в целый продукт. Подход удобен, но требует четкого понимания требований и целей проекта.
Модель большого взрыва
В основе метода лежит хаос. Здесь нет четкого планирования — глаза боятся, руки делают. Команда разработчиков собирает требования, проводит их анализ и приступает к созданию продукта. Это простейшая модель, которая подойдет для маленьких проектов.
Agile-модель
Гибкая методология, популярная у большинства команд разработчиков. Единственный принцип у Agile-модели выделить не получится. Это комплексный подход, который объединяет множество методов. Суть состоит в следующем:
- Проект делится на небольшие сборки (билды).
- На одну сборку выделяется период (спринт).
- Длительность спринта составляет от 1 до 4 недель.
- В конце каждого спринта клиент может оценить результат и внести правки.
- Постепенно билды собираются в единый продукт.
Заключение
Разработка ИT-продукта с нуля — это долгий и кропотливый процесс. Для его качественной реализации нужен системный подход. Сейчас существует множество методов, позволяющих формализовать весь процесс и сделать вовлеченность всех участников максимально полной. Поэтому не нужно изобретать велосипед, а требуется лишь подобрать методологию под свои нужны и следовать ей.
