Управление разработкой программного обеспечения

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

К программному обеспечению относятся:

• веб-приложения;
• мобильные приложения;
• корпоративные информационные системы;
• CRM- и ERP-платформы;
• облачные сервисы;
• внутренние программы для сотрудников;
• интеграционные решения и API;
• системы аналитики;
• программные комплексы для управления оборудованием.

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

Что входит в разработку ПО

В зависимости от проекта разработка программного обеспечения включает:

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

Для небольшого приложения часть задач может выполнять один специалист. В крупном проекте обязанности распределяются между аналитиками, архитекторами, разработчиками, тестировщиками, DevOps-инженерами и руководителями.

Чем разработка ПО отличается от написания программы

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

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

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

В каскадной модели этапы проходят последовательно. В Agile-проектах команда повторяет этот цикл для отдельных функций или небольших частей продукта.

Анализ задачи и сбор требований

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

Нужно выяснить:

• кто будет пользоваться продуктом;
• какие операции требуется автоматизировать;
• какие функции обязательны для первого релиза;
• какие системы необходимо интегрировать;
• какие требования предъявляются к производительности и безопасности;
• какие сроки и бюджет доступны;
• по каким признакам будет оцениваться результат.

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

Проектирование и техническое задание

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

Техническое задание может содержать:

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

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

Разработка программного продукта

На этом этапе программисты реализуют функции, описанные в требованиях. Работа ведётся по задачам, которые входят в текущий спринт, релиз или согласованный этап.

Разработка может включать:

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

Исходный код хранится в системе контроля версий. Изменения проходят проверку, после чего включаются в основную ветку проекта.

Тестирование программного обеспечения

Тестирование проверяет, соответствует ли продукт требованиям и как он ведёт себя в различных условиях.

В зависимости от задачи применяют:

• функциональное тестирование;
• интеграционное тестирование;
• регрессионное тестирование;
• нагрузочное тестирование;
• тестирование безопасности;
• проверку совместимости;
• автоматизированные тесты;
• пользовательское и приёмочное тестирование.

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

Тестирование не следует откладывать до конца проекта. Проверка отдельных функций во время разработки уменьшает объём переделок перед релизом.

Внедрение и релиз

Перед запуском продукт разворачивают в рабочей среде и проверяют его взаимодействие с инфраструктурой и внешними системами.

Внедрение может включать:

• настройку серверов;
• перенос данных;
• подключение доменов и сервисов;
• настройку прав доступа;
• подготовку резервного копирования;
• настройку мониторинга;
• обучение пользователей;
• подготовку инструкций;
• запуск пилотной версии;
• переход к рабочей эксплуатации.

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

Сопровождение и развитие

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

Сопровождение включает:

• исправление ошибок;
• обновление зависимостей;
• устранение уязвимостей;
• контроль доступности;
• оптимизацию производительности;
• резервное копирование;
• консультации пользователей;
• выпуск новых функций;
• масштабирование системы.

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

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

Определение целей и результата проекта

Цель должна описывать не сам факт создания программы, а изменение, которого ждёт заказчик. Формулировка «разработать удобную систему» не даёт команде критериев для работы. Гораздо полезнее определить, какой процесс будет автоматизирован, какие операции сократятся и кто получит доступ к продукту.

До начала разработки фиксируют:

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

Эта информация используется при оценке задач и выборе приоритетов.

Формирование команды и распределение ролей

В состав команды могут входить:

• владелец продукта;
• руководитель проекта;
• бизнес- и системный аналитик;
• UX/UI-дизайнер;
• ИТ-архитектор;
• frontend- и backend-разработчики;
• мобильные разработчики;
• QA-инженеры;
• DevOps-инженер;
• специалист по информационной безопасности.

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

Планирование и приоритизация задач

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

Приоритет обычно зависит от:

• влияния функции на цель проекта;
• ценности для пользователей;
• срочности;
• технических зависимостей;
• рисков;
• трудоёмкости;
• необходимости функции для запуска.

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

Управление требованиями и изменениями

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

Каждое изменение необходимо:

1. описать;
2. указать его причину;
3. оценить влияние на архитектуру, сроки и бюджет;
4. определить приоритет;
5. согласовать;
6. включить в план или отложить.

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

Контроль сроков, бюджета и качества

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

Для этого используют:

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

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

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

Каскадная модель

Водопадная модель предполагает последовательное прохождение этапов: требования, проектирование, разработка, тестирование и внедрение.

Она подходит для проектов, в которых:

• требования заранее известны;
• изменения редки;
• обязательна подробная документация;
• этапы имеют формальные критерии завершения;
• требуется заранее согласованный план.

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

Agile и итеративная разработка

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

Подход используют, когда:

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

Agile не отменяет документацию, оценки и контроль. Он меняет порядок работы с ними: часть решений уточняется по мере появления новых данных.

Scrum

Scrum организует работу короткими спринтами. В начале спринта команда выбирает задачи, а в конце показывает готовый результат и обсуждает процесс.

Основные элементы Scrum:

• продуктовый бэклог;
• планирование спринта;
• ежедневные встречи;
• демонстрация результата;
• ретроспектива;
• критерии готовности;
• владелец продукта;
• Scrum-мастер;
• команда разработки.

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

Kanban

Kanban показывает движение задач на доске. Типовые статусы: «Запланировано», «В работе», «На проверке», «Готово».

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

DevOps

DevOps объединяет разработку, тестирование и эксплуатацию. Его задача — сократить ручные операции при сборке, проверке и выпуске программного обеспечения.

К DevOps-практикам относятся:

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

DevOps не заменяет Scrum, Kanban или другую методологию управления. Он дополняет её техническими процессами.

При выборе модели оценивают:

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

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

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

Управление задачами

Для ведения бэклога и контроля работ используют Авандок Трекер, Jira, YouTrack, Trello, Asana, Kaiten и аналогичные системы.

Они позволяют:

• создавать задачи;
• назначать исполнителей;
• указывать сроки и приоритеты;
• вести подзадачи;
• планировать спринты;
• отображать статусы;
• отслеживать зависимости;
• формировать отчёты.

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

Контроль версий

Git хранит историю изменений исходного кода и позволяет нескольким разработчикам работать над проектом параллельно.

GitHub, GitLab и Bitbucket добавляют:

• репозитории;
• ветки;
• запросы на слияние;
• проверку кода;
• права доступа;
• автоматические сборки;
• запуск тестов;
• публикацию релизов.

Система контроля версий нужна даже небольшому проекту: она позволяет восстановить рабочую версию и определить, когда и почему появилось изменение.

Документация

В Авандок Документооборот, Confluence, Notion или корпоративной базе знаний хранят:

• требования;
• архитектурные решения;
• описание API;
• схемы интеграций;
• инструкции по развёртыванию;
• регламенты релиза;
• правила работы с кодом;
• итоги согласований.

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

Коммуникации

Zoom, eXpress, Slack, Microsoft Teams и корпоративные мессенджеры подходят для оперативных вопросов. Для обсуждений, которые меняют план или требования, лучше использовать задачи, протоколы встреч и базу знаний.

Так сохраняется история решений и уменьшается зависимость от личной переписки сотрудников.

Сборка, тестирование и доставка

CI/CD-инструменты автоматически собирают проект, запускают тесты и готовят новую версию к публикации. Это сокращает количество ручных действий и делает процесс выпуска повторяемым.

Для рабочих систем CI/CD обычно связывают с мониторингом, журналированием и возможностью быстро вернуть предыдущую версию.

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

Заказчик и владелец продукта

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

Он определяет:

• какую проблему решает функция;
• кому она нужна;
• насколько она срочна;
• соответствует ли результат требованиям.

Руководитель проекта и Product Manager

Руководитель проекта отвечает за план, сроки, коммуникации, ресурсы и риски. Product Manager отвечает за развитие продукта, пользовательскую ценность и порядок появления функций.

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

Аналитики

Бизнес-аналитик описывает процессы и потребности подразделений. Системный аналитик переводит их в технические требования, сценарии, правила обработки данных и спецификации интеграций.

Их задача — убрать неоднозначность до того, как требования попадут к разработчикам.

Архитектор и разработчики

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

QA и DevOps

QA-инженеры проверяют продукт, фиксируют дефекты и контролируют соответствие требованиям. DevOps-инженеры отвечают за среды, сборку, доставку, мониторинг и эксплуатационную стабильность.

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

Критерии готовности

Задача считается готовой, если:

• функция реализована;
• требования выполнены;
• тесты пройдены;
• критические ошибки устранены;
• код проверен;
• документация обновлена;
• результат доступен в тестовой среде;
• заказчик подтвердил соответствие критериям.

Code review

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

Тестирование и приёмка

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

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

Метрики разработки

Для контроля процесса используют:

• срок прохождения задачи;
• количество дефектов;
• долю возвратов на доработку;
• частоту релизов;
• стабильность сборок;
• время устранения критических ошибок;
• время восстановления после сбоя;
• объём технического долга.

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

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

Что влияет на цену

Основные факторы:

• количество функций;
• число ролей пользователей;
• сложность интерфейсов;
• тип приложения;
• интеграции;
• требования к нагрузке;
• безопасность;
• объём тестирования;
• состав команды;
• сроки;
• последующая поддержка.

Как оценивают проект

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

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

Зачем нужен MVP

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

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

Что входит в управление разработкой

Услуга управления разработкой может включать:

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

Конкретный состав работ определяется моделью сотрудничества и ролью исполнителя в проекте.

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

Собственная команда или аутсорсинг

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

ИТ-аутсорсинг позволяет привлечь готовую команду под конкретный проект или направление. Такой вариант требует понятных правил доступа к коду, отчётности, приёмки и передачи знаний.

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

Что проверить у подрядчика

До заключения договора стоит выяснить:

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

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

Какие документы нужны

До начала работ обычно согласуют:

• описание задачи;
• требования;
• техническое задание;
• архитектурные ограничения;
• план этапов;
• состав команды;
• порядок коммуникаций;
• критерии приёмки;
• процедуру внесения изменений;
• права на исходный код;
• условия поддержки.

Документация должна фиксировать договорённости, а не усложнять работу формальными шаблонами.

С чего начинается разработка

Работа начинается с ИТ-консалтинга и ИТ-аудита. После этого уточняются требования, определяется состав команды, выбирается модель разработки и формируется план первого этапа.

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

1. «КОРУС Консалтинг» разработал приложение для планирования производства на заводе Ikon Tyres

Проект по созданию приложения для Ikon Tyres рассчитан на три этапа. Первый уже завершён: специалисты «КОРУС Консалтинг» разработали MVP-системы и запустили его в работу. Решение учитывает потребности бизнеса и производственные ограничения шинного завода, помогая планировать выпуск продукции с учётом доступных ресурсов и возможностей предприятия.

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

2. «КОРУС Консалтинг» автоматизировал управление складскими гейтами Lamoda

«КОРУС Консалтинг» завершил разработку и внедрение онлайн-платформы для управления гейтами на складах Lamoda. Систему создали с нуля за шесть месяцев. Она структурировала процесс бронирования временных слотов для погрузки и разгрузки поставок и сократила объём операций, выполняемых вручную.

После запуска платформы доля самостоятельных бронирований со стороны партнёров выросла с 16% до 75%, а точность планирования увеличилась в два раза. Решение интегрировали с ERP-системой и платформой управления отношениями с партнёрами — PRM.

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

3. «КОРУС Консалтинг» создал B2B-платформу для оптовых продаж AKKERMANN cement

«КОРУС Консалтинг» разработал и запустил интернет-портал для оптовых продаж компании AKKERMANN cement. Новая B2B-платформа перевела часть взаимодействия с контрагентами в онлайн-формат и упростила оформление закупок.

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

Разработка программного обеспечения включает больше, чем создание исходного кода. В неё входят анализ требований, проектирование, разработка, тестирование, внедрение и сопровождение.

Управление разработкой необходимо, чтобы:

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

Модель разработки выбирают с учётом требований и рисков. Каскадный подход удобен для предсказуемых проектов, Agile — для задач с изменяющимися приоритетами, Scrum — для работы короткими итерациями, Kanban — для непрерывного потока задач, а DevOps — для автоматизации сборки, тестирования и поставки.

Если вы планируете создание программного продукта, модернизацию действующей системы или запуск нового цифрового сервиса, специалисты КОРУС Консалтинг помогут определить границы проекта, сформировать требования, выбрать модель разработки и организовать работу команды на всех этапах — от предпроектного анализа до запуска и дальнейшего развития системы.