Этот статья первоначально был опубликован на .культ к Чамира Дуланга. .cult — это базирующаяся в Берлине платформа сообщества разработчиков. Мы пишем обо всем, что связано с карьерой, снимаем оригинальные документальные фильмы и делимся кучей других нерассказанных историй разработчиков со всего мира.
Разработка программного обеспечения — это командная работа, и хорошая структура команды жизненно важна для ее успеха. Но даже незначительное несоответствие может негативно сказаться на результатах наших команд. Вот почему мы должны быть особенно осторожны, собирая команду.
В этой статье я расскажу о некоторых важных факторах, которые необходимо учитывать при создании команды разработчиков программного обеспечения для вашей компании.
Почему важна структура команды?
Откройте для себя будущее технологий!
Присоединяйтесь к нам на конференции TNW 15 и 16 июня в Амстердаме.
Когда вы создаете команду разработчиков программного обеспечения, обратите внимание на различные факторы, влияющие на производительность и эффективность команды.
В современных agile-командах мы вряд ли измеряем эффективность количеством строк кода. Вместо этого мы уделяем больше внимания качеству и постоянным улучшениям. И команда должна быть способна добиться «желаемого результата».
Итак, нам необходимо решить следующие вопросы:
- Есть ли у нас нужный набор навыков?
- Технические навыки
- Опыт
- Мягкие навыки
2. Есть ли у нас подходящая среда для их совместной работы?
- Четкие роли и обязанности
- Средства коммуникации есть
3. Знает ли команда свои цели?
- Четкая коммуникация сверху вниз, чтобы команда знала об ожиданиях
- Точные требования, которые сокращают доработку
4. Способна ли команда добиваться более качественных результатов?
- Процессы на месте
- Руководство, обеспечивающее надлежащее руководство
- Правильная оплата
- Культура, которая ценит и празднует победы
5. Может ли команда добиться лучшего результата, чем каждый в отдельности?
- Синергия команды
- Постоянное улучшение
- Самоуправляемые и самовосстанавливающиеся команды
Мы также должны принять во внимание бюджет. У вас всегда должен быть верхний предел, чтобы найти правильный баланс для оптимальной структуры команды.
Но возникает вопрос: «Как нам выбрать идеальную структуру команды?»
Выбор лучшей структуры команды
Как видите, при формировании команды необходимо учитывать множество факторов. А некоторые из них вы узнаете только после того, как команда начнет выступать.
Тем не менее, поиск людей с проверенным послужным списком, особенно на руководящем уровне, поможет вам снизить риски.
Давайте сосредоточимся на ключевых факторах, которые мы можем контролировать при выборе людей для команды;
- Количество членов команды
2. Уровень опыта инженеров
3. Стоимость содержания команды (вознаграждение и прочие расходы)
1. Количество членов команды
Обычно мы определяем количество людей в команде на основе оценки проекта и этапов реализации. Чего не следует делать, так это запускать проект с меньшим количеством разработчиков, чем требуется, даже если они очень талантливы. Вы рискуете пожертвовать качеством и создать больше проблем в долгосрочной перспективе.
Однако все усложняется, когда вам нужно определить структуру команды. Поскольку не все люди играют одну и ту же роль, мы должны начать думать о составе команды, определяя разные роли.
- Кто руководит командой и руководит проектом?
- Нужно ли нам разбиваться на подгруппы? (что может означать больше лидеров…)
- Кто берет на себя архитектуру?
- Какие другие роли требуются, например, специалист по обеспечению качества, пользовательский интерфейс/UX, управление проектами, бизнес-аналитик?
2. Уровень опыта
Уровень опыта инженеров напрямую влияет на качество и производительность. Но это не значит, что нам нужна команда, состоящая из опытных людей. Помните, мы говорили о командной синергии.
Мы должны думать о различных уровнях опыта, доступных в команде. Поскольку люди работают вместе, они могут учиться друг у друга и добиваться желаемого результата.
Почему уровень опыта влияет на качество и производительность
Качество невозможно построить за день или два. Это приходит с опытом.
Например, предположим, вы начинаете новый проект Java и ищете разработчика. Если вы используете разработчиков, которые плохо знакомы с технологией, им потребуется время для обучения, а это означает, что проект будет работать медленнее.
Кроме того, у них не будет необходимого опыта работы с лучшими практиками, что приведет к увеличению объема доработок. Так что в этом случае обратитесь к разработчику, который хорошо разбирается в Java. Легкий!
Однако, если вам нужно, чтобы над проектом работало более одного разработчика, вы можете пересмотреть разные уровни опыта. Вы можете попросить опытного разработчика направить команду к цели без ущерба для вашей производительности. Это также означает, что с точки зрения найма вы можете рассмотреть более широкий круг разработчиков, которые могут присоединиться к вашей команде.
Наличие команды, полной опытных людей, становится сложной задачей
В первую очередь это сказывается на вашем бюджете, более опытные разработчики явно будут требовать более высокую оплату!
Вдобавок ко всему, они будут ожидать лучших возможностей, таких как игра на руководящих должностях, а это не всегда будет доступно. Весь этот опыт может стать узким местом, если цели и амбиции команд не совпадают.
Наличие баланса между младшими и старшими членами будет лучше, а также увеличит удержание разработчиков, поскольку можно лучше управлять ожиданиями и ростом.
3. Стоимость содержания команды
Команды разработчиков программного обеспечения существенно отличаются от команд других профессий. Они могут работать удаленно, иметь гибкий график работы и оттачивать свои знания посредством непрерывного обучения.
Таким образом, если мы сможем использовать эти факторы, мы сможем оптимизировать связанные с этим затраты.
Опыт имеет свою цену
Как мы обсуждали ранее, поиск опытных специалистов по определенной технологии или области требует затрат. И поскольку это не бинарное решение, иметь все или ничего, мы можем сбалансировать уровни опыта, учитывая структуру затрат.
Несколько рабочих мест
Это еще один аспект, который следует учитывать при управлении затратами на команды разработчиков программного обеспечения.
Однако наличие нескольких рабочих мест может как увеличить, так и снизить стоимость вашего проекта.
Если у вас более одного рабочего места, вам придется платить по счетам, обслуживать каждое рабочее место, и, несомненно, это увеличит расходы на коммунальные услуги.
Но, с другой стороны, мы можем искать места, чтобы привлечь больше талантов или получить налоговые льготы. Кроме того, если вы можете организовать рабочее место в стране, где расходы на проживание низкие, вы можете эффективно сократить расходы.
Удаленные работники и аутсорсинг
Итак, если вы посмотрите на другие доступные варианты, вы можете передать свою работу удаленному работнику или компании с низкими затратами.
Однако есть несколько других проблем, которые вы должны решить, чтобы сделать вашу распределенную команду эффективной.
- Увеличьте перекрытие
Если ваша команда работает в разных часовых поясах, желательно иметь разумное перекрытие, когда это возможно. Это может быть достигнуто либо за счет смены рабочего времени, либо за счет выделения времени для совместной работы.
2. Баланс между экспертизой и разделением работы
Кроме того, необходимо сбалансировать опыт отдельных лиц и разделить работу, уменьшив зависимость от часовых поясов.
3. Оптимизированные процессоры
Правильный набор процессоров необходим при работе с удаленными командами или аутсорсинге (например, гибкие процессоры, такие как Scrum, Kanban). Это поможет направить всех членов команды на достижение конечной цели.
Как видите, существуют различные способы снижения затрат за счет максимизации результата.
Резюме
В этой статье мы обсудили несколько факторов, которые необходимо учитывать при выборе структуры команды для эффективных групп разработки программного обеспечения.
Некоторые из этих решений вам нужно будет принять заранее, поэтому вы не будете знать, что нужно скорректировать, пока команда не начнет работу. Через некоторое время будет легче определить, где необходимо внести изменения, будь то затраты или совместная работа.
