Жизненный цикл ПО
2026-02-26 20:45 Diff
https://ru.hexlet.io/courses/software-testing-lifecycle/lessons/project-organization/theory_unit

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

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

Организация в команде разработки

Чаще всего компании имеют в основе иерархическую структуру управления. Такая структура выглядит как граф или дерево:

  • Во главе директор
  • Дальше помощники директора
  • Дальше департаменты с начальниками во главе
  • Подразделения внутри департаментов
  • Отделы внутри подразделений
  • Отдельные сотрудники внутри отделов

Глубина вложенности такого графа зависит от величины организации.

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

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

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

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

  • Линейно-функциональная
  • Проектная
  • Матричная
  • Кросс-функциональная

Рассмотрим каждую из них подробнее.

Линейно-функциональная структура

Линейно-функциональная структура — это продолжение иерархии всей организации. Другими словами, компания делится на отделы по ролям, которые выполняют специалисты:

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

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

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

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

Проектная структура

При такой структуре компания делится не на отделы, а на команды отдельных проектов:

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

Руководитель проекта отвечает за успешную реализацию проекта на протяжении всех этапов жизненного цикла проекта:

  • Инициирование
  • Планирование
  • Выполнение
  • Мониторинг и контроль
  • Закрытие проекта

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

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

  • Объем работы к выполнению (скоуп)
  • Качество
  • График выполнения работы (план)
  • Бюджет
  • Ресурсы
  • Риски

Матричная структура

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

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

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

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

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

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

Продуктовый подход и кросс-функциональная команда

Проектная организация управления была особенно популярна в 2000-2010 годы, но постепенно ситуация меняется. Все активнее распространяется Agile — гибкий подход к разработке, который мы подробнее обсудим далее в курсе.

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

Другими словами, разница между проектным и продуктовым подходами состоит в фокусе:

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

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

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

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

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