Компания по разработке программного обеспечения

Основные типы компаний-разработчиков программного обеспечения:

• разработка решений COTS (англ. commercial off-the-shelf) — готовых к использованию коммерческих продуктов;
• услуги по разработке программного обеспечения на заказ для других компаний и предприятий;
• производство специализированного коммерческого готового программного обеспечения;
• модель обслуживания SaaS (англ. software as a service) — программное обеспечение как услуга;
• API как услуга, позволяющая сторонним разработчикам взаимодействовать с программным обеспечением компании.
• производитель компонентов программного обеспечения.
• провайдер доступа к приложениям (англ. Application service provider — ASP) — компания, предоставляющая услуги аутсорсинга приложений.
• производство заказного программного обеспечения для отраслей с вертикальной интеграцией или определённых географических регионов.
• независимый поставщик программного обеспечения (ISV) — создаёт, разрабатывает и продаёт потребительское или корпоративное программное обеспечение, используемое конечными пользователями.

Как правило, профессиональная компания по разработке программного обеспечения состоит как минимум из трёх основных специализированных подгрупп:

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

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

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

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

Руководитель направления разработки в компании-разработчике ПО (англ. Head Of Development HOD)^[2] — это ключевая фигура в IT-команде, которая отвечает за организацию процесса разработки, управление командой программистов и достижение бизнес-целей проекта. Этот специалист должен не только разбираться в технологиях, но и обладать лидерскими качествами, понимать бизнес-процессы и уметь выстраивать эффективную коммуникацию между всеми участниками проекта^[3]. HOD отчитывается перед заинтересованными сторонами, руководит подгруппами напрямую или через менеджеров/руководителей в зависимости от размера организации. Как правило, наиболее эффективными являются команды численностью до 10 человек. В более крупных организациях обычно существуют две модели иерархии:

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

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

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

Компании-разработчики программного обеспечения могут использовать различные методологии управления проектами:

• каскадная (или модель водопада), включая такие методологии управления проектами, как PRINCE2^[4] или PMBoK^[5];
• гибкая разработка программного обеспечения, такая как экстремальное программирование^[6] и SCRUM^[7].

Существуют также некоторые методологии, которые сочетают оба подхода, такие как спиральная модель, Rational Unified Process (RUP)^[8] или MSF^[9].

Независимо от используемой методологии, жизненный цикл продукта всегда состоит, как минимум, из трёх этапов:

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

В идеале каждый этап должен занимать 30 % от общего времени, а оставшиеся 10 % должны быть в резерве.

UML- диаграмма последовательности взаимодействия между основными ролями может выглядеть следующим образом:

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

• Аналитики (англ. analyst), после завершения разработки бизнес-спецификации, управляют изменяющейся бизнес-ситуацией, минимизируя вероятность изменений с течением времени. Они также поддерживают как программистов, так и тестировщиков на протяжении всего процесса разработки, чтобы обеспечить соответствие конечного продукта бизнес-потребностям, обозначенным на начальном этапе. В идеале, этот процесс предполагает, что бизнес-аналитики играют ключевую роль на этапе окончательной поставки решения заказчику, поскольку они лучше всего подходят для обеспечения оптимального бизнес-уровня.

• Программисты (англ. programmer) разрабатывают техническую спецификацию (англ. technical specification) на этапе проектирования, поэтому их и называют программистами/дизайнерами(англ. designer), а во время тестирования они исправляют ошибки (англ. bug).

• Тестировщики (англ. tester) завершают тестовые сценарии на этапе проектирования и оценивают их на этапе написания исходного кода (англ. coding).

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

• Инструменты моделирования, такие как Sparx Systems Enterprise Architect или IBM Rational Rose

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

• инструменты анализа кода и стандарты кодирования, проверенные вручную или автоматически;
• механизмы развёртывания

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

• системы и процедуры управления корпоративными проектами (EPM);
• управление портфелем продуктов (PPM);
• системы и процедуры управления изменениями.

Существуют также системы управления жизненным циклом приложений (ALM), которые объединяют некоторые из этих функций в один пакет и используются во всех группах. Они поставляются различными вендорами (Borland, ECM, Compuware и др.).

Успешные компании-разработчики ПО, как правило, используют определённые методы оценки собственной эффективности. Обычно это достигается путём определения набора ключевых показателей эффективности (KPI), таких как:

• среднее количество ошибок, допускаемых разработчиком за единицу времени или строк исходного кода;
• количество ошибок, обнаруженных тестировщиком за цикл тестирования;
• среднее количество циклов тестирования до достижения нулевого отказа (англ. Zero Bug Bounce — ZBB)^[10];
• среднее время цикла испытаний;
• расчётное время выполнения задачи в сравнении с реальным временем выполнения задачи (точность планирования);
• количество корректировок к базовой линии проекта^[11].

Ряд организаций стремятся достичь оптимального уровня модели зрелости возможностей создания ПО (CMM), где «оптимальный» уровень не обязательно означает наивысший. Существуют и другие системы, такие как «SEMA»Университета Карнеги-Меллона или отдельные стандарты ISO.

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

Согласно исследованию компании TeamStorm 2023 года^[12], было выяснено, что общепринятых стандартов по сбору метрик, которые позволяют оценить эффективность процесса разработки ПО, в России нет. Причина — слишком разные подходы к менеджменту и разнообразие используемых методологий.

Был проведён опрос около трёх десятков респондентов, среди которых: компании-разработчики ПО, группы разработки в компаниях других отраслей: банки, страховые компании, ритейлеры и медтехнические организации.

Основные результаты исследования:

• Стандарты по сбору и оценке метрик применяют только 30 % респондентов (в основном небольшие компании).
• Несмотря на отсутствие общего стандарта по сбору метрик, есть показатели, которые рассматривают все без исключения участники опроса — это метрики тестирования и выполнения планов.
• Регулярно оценивают метрики только 30 % компаний, остальные 70 % делают это только в тех случаях, когда становятся очевидными острые проблемы в разработке.
• Метрика динамики рабочего процесса обязательна к применению во всех опрошенных компаниях, но только 20 % респондентов отслеживают полный жизненный цикл продукта, а подавляющее большинство, 80 %, не включают в метрику динамики рабочего процесса этапы, которые предшествуют разработке.