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

Учитывая 15-кратную сильную команду разработчиков программного обеспечения, работающую над отдельными проектами, а также малыми, средними и крупными проектами; как лучше всего организовать эту команду и какова наилучшая методология разработки программного обеспечения?

Предыстория:
Ранее в состав отдела входили:

  • технический директор
    • Группа поддержки разработчиков (1 ведущий специалист, 2 разработчика службы поддержки)
    • 4х разработчиков

Отдел вырос до 10 разработчиков, поэтому было принято решение разделить на 2 команды разработчиков по 5 разработчиков в каждой следующим образом:

  • технический директор
    • Команда 1 (1 ведущий/менеджер, 4 разработчика)
    • Команда 2 (1 ведущий/менеджер, 4 разработчика)

В отделе используется Scrum, у каждой команды свой цикл спринта (синхронизированный).

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

  • Фиксированные команды проблематичны из-за разрозненности знаний отдельных разработчиков.
  • Повышение роли разработчиков до ролей ведущих/администраторов/линейных менеджеров приводит к потере важных ресурсов разработчиков.

У нас также есть PMO, состоящий из 3x PM и 2x BA. Эта команда отделена от разработки (не рангом выше или ниже, а в стороне) и относится к операционному отделу (COO).

Использование Scrum имеет свои проблемы:

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

Мои мысли

  • Я думаю, что более отзывчивая методология будет работать лучше (но я здесь не эксперт — я разработчик/руководитель) и для каждого проекта, а не для каждой команды.
  • Я думаю, что команды разработчиков должны быть более гибкими, строить для каждого проекта, а не иметь фиксированное Nx разработчиков на команду. Линейное управление становится здесь проблемой. Техническое руководство и линейный менеджмент становятся здесь проблемой из-за нехватки соответствующих ресурсов/времени.
Флем, чего ты пытаешься добиться? Что должны делать команды? Есть много способов структурировать команды, причем разные структуры подходят для одной задачи, а другие — для достижения других целей.
Основные цели: быстрая разработка, качественно, для большого количества проектов. Для некоторых проектов требуется только один разработчик, тогда как для других (меньше) требуется 4 или 5. В среднем для проекта требуется 2-3 разработчика.
Поскольку вы являетесь разработчиком/руководителем, имеете ли вы влияние на своего технического директора (т.е. имеет ли этот вопрос практическую ценность)? Может ли кто-то другой взять на себя большую часть административной работы, возложенной на потенциальных клиентов, чтобы они могли сосредоточиться на своих командах? Отсутствие специальной поддержки в вашем отделе является сильным недостатком... Вы также можете попробовать меньшие команды (дает гибкость между командами, сохраняет хороший моральный дух внутри них).
@DeerHunter Да, это практический вопрос. Административные хлопоты — большая часть проблемы. Лиды — это штатные разработчики, скрам-мастер и линейные менеджеры. Это приводит к тому, что лиды работают слишком долго.
Может быть, вам нужен пул административных помощников, чтобы снять с лидов рутинные задачи... Нанять помощника намного дешевле, чем переутомлять опытного лида в приюте.
Каковы цели бизнеса? Конечно, хорошо иметь команду, которая делает все быстрее, дешевле и лучше. Но зачем там команда? Почему он вырос? Структура должна быть оптимизирована в соответствии с целями организации.
@MarkPhillips Это действительно так просто: продажи продаются больше, разработчикам нужно больше строить. У нас есть основная платформа. До роста большинство клиентов получали 80–90% платформы, 10–20% — индивидуальной. Сейчас произошел сдвиг, и цифры больше похожи на 10-20% платформы на 80-90% на заказ. Поэтому для более индивидуальной разработки нам нужна большая команда. Но большая команда бессмысленна, если она не эффективна.
Флем, вы продаете индивидуальную разработку или определенный продукт? Почему произошел сдвиг в разбивке? Понимание таких переменных действительно может изменить ситуацию к правильной структуре. Пожалуйста, поделитесь другой информацией о компании и контексте, в котором работает команда разработчиков.
У нас есть отдел продаж, который занимается продажей готового продукта, и отдел продаж, который продает такой же готовый продукт, но с индивидуальными функциями. Заказные функции раньше составляли 10-20% (2 года назад), но сейчас имеют тенденцию составлять 80-90%. Это изменение объясняется разными причинами: одна из них заключается в том, что клиенты платят больше за что-то уникальное, а другая заключается в том, что возможность создавать все, что хочет клиент, означает, что клиентов легче найти — мы можем быть более избирательными. Теперь основное внимание уделяется работе на 80-90% по индивидуальному заказу. Обычно у нас в работе находится от 3 до 8 проектов в любой момент времени. Входящий отставание длинное.

Ответы (3)

Рассматривали ли вы систему Squad? У всегда превосходного Хенрика Книберга есть статья , которая может оказаться полезной, о том, как эта система используется в Spotify.

Основной принцип заключается в следующем:

  1. Вертикальные многопрофильные группы (продукт, разработка, дизайн) работают над одним продуктом или областью разработки продукта (например, инфраструктура, обратная связь с клиентами) — они известны как отряды .
  2. Горизонтальные группы, основанные на навыках (например, разработчики PHP, разработчики интерфейса), пересекают отряды — они известны как главы . У каждого есть глава отделения, который (обычно) берет на себя ответственность за линейное управление всеми в своем отделении.
  3. Группы с особыми интересами (например, Agile-управление проектами, тестирование) пересекаются как с главами, так и с отрядами — эти группы известны как гильдии , и у каждой есть глава гильдии.

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

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

Спасибо за ссылку. Это очень интересно. Я намерен исследовать это дальше.

TL;DR

ТАНСТАФЛ. Если вы хотите масштабироваться, вам нужно добавить больше команд. Однако, если вы добавите больше команд, вам придется управлять дополнительной сложностью и накладными расходами на связь, которые возникают вместе с этим.

Прямые каналы коммуникации плохо масштабируются. Формула обычно выражается как N(N-1)/2 . Если у вас нет модели управления проектами, учитывающей этот важный факт сложности коммуникаций, у вас возникнут большие проблемы с масштабированием.

Параметры объединения

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

Переключение задач

Переключение задач всегда проблема. Даже если вы выберете методологию, отличную от Scrum, вам все равно придется группировать работу и расставлять приоритеты таким образом, чтобы каждая единица работы сводила к минимуму когнитивное переключение. Это означает, что поручить одному разработчику работать над разными задачами для разных проектов (даже если задачи упорядочены, а не псевдопараллельно) будет менее оптимально, чем позволить разработчику работать над проектом одного клиента одновременно.

Принимать работу в зависимости от мощности

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

Что касается масштабирования, Scrum of Scrums, как правило, является правильным инструментом для работы, если вы работаете в Scrum-магазине. Если вы используете другую методологию, вам нужно вместо этого использовать функции масштабирования этой платформы. Дело, однако, в том, что общение между командами становится все сложнее и сложнее по мере добавления команд; это почти аксиома.

Лучший известный мне способ решить проблему обмена знаниями в сложной среде Scrum-of-Scrums — это обеспечить, чтобы Владельцы Продукта добавили в свой Бэклог Продукта истории межкомандного обучения и обучения. Это обеспечивает возможности для перекрестного опыления между командами и снижает эффект разрозненности, не разрушая природу самих сплоченных команд.

В настоящее время пропускная способность не является проблемой, и мы можем масштабироваться для поддержки большего количества проектов. Основная проблема (я думаю) заключается в том, что у нас недостаточно руководства для управления большей мощностью. Должен ли у нас быть менеджер, работающий полный рабочий день, «руководитель отдела разработки» для всех обязанностей линейного управления/HR, позволяющий лидерам команд сосредоточиться на проекте(ах)?
@flem - тимлиды должны быть избавлены от бумажной работы, но не от управления своими командами.
@DeerHunter Хорошо ли руководителю команды быть линейным менеджером? Т.е. Скрам-мастер является линейным менеджером?
Обычно мы стараемся, чтобы люди не сообщали кому-то из своей команды, где я нахожусь. Сохраняет различие между линейным менеджментом и лидерством и помогает сделать ретроспективы более честными, я думаю.
@flem - похоже, это (линейное управление руководителями групп) является предметом еще одного вопроса.
@Охотник на оленей. Побочный вопрос, поднятый здесь .

Посмотрите, как работает Menlo Innovations в Анн-Арборе, штат Мичиган. Я думаю, что они похожи на то, что вы пытаетесь сделать.

  • Около 70 человек выполняют заказные работы для многих клиентов
  • Все объединяются в пары, и пары меняются каждую неделю — много обмена знаниями
  • Недельные спринты
  • Экстремальные практики программирования
  • Антропология высоких технологий (то, что они изобрели)
  • Проекты формируются парами, поэтому их легко увеличивать и уменьшать по мере необходимости.

См. недавно вышедшую книгу Joy, Inc. Он был написан Ричардом Шериданом, соучредителем Menlo Innovations, и описывает Menlo Way. Они также проводят экскурсии по своему магазину и предлагают занятия для тех, кто заинтересован в изучении техники. http://www.menloinnovations.com/

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

Как структурировать команду разработчиков программного обеспечения
СпросиСетьПолитика конфиденциальности1y, 0v