Организационная структура управления — Жизненный цикл ПО, место тестирования

• Организация в команде разработки
• Линейно-функциональная структура
• Проектная структура
• Матричная структура
• Продуктовый подход и кросс-функциональная команда

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

Остались вопросы? Задайте их в разделе «Обсуждение»

Вам ответят команда поддержки Хекслета или другие студенты