вступление
Я работаю в сфере ИТ уже чуть более 7 лет, и, несмотря на небольшое количество компаний или проектов, я регулярно вижу, как крупные компании добавляют все больше и больше участников в команду или объединяют несколько команд еще до того, как проект или продукт еще не запущен. Не поймите меня неправильно, эти компании или проекты, о которых я упоминал ранее, не делают этого в основном потому, что они не могут позволить себе большую команду, иначе у них она наверняка была бы.
Эта статья в основном является моим мнением о том, почему компании, менеджеры, генеральные директора и даже клиенты должны придерживаться KISS (Keep It Short and Simple). Все сводится к одному: пустая трата времени. А время-деньги!
Чем больше, тем лучше! Это ты?
Я не собираюсь поднимать здесь обсуждение того, сработала ли гибкая культура на самом деле или нет, но она, безусловно, принесла много пользы для нашей текущей рабочей среды. В SCRUM мы знаем, что отряд определяется следующим образом:
Они обладают всеми навыками и инструментами, необходимыми для проектирования, разработки, тестирования и запуска в производство, являясь автономной, самоорганизующейся командой, являющейся экспертами в своей области продукции.
При этом в команде должны быть члены с достаточными навыками для завершения своего проекта или продукта. Если мы говорим о эксперте в каждой области, то можно утверждать, что нам нужно не более 4 разработчиков. (Я не включаю сюда ни владельца продукта, ни скрам-мастера)
- Дизайнер
- Front-End разработчик
- Back-End разработчик
- Тестер
Иметь по одному из них, безусловно, опасно (никогда не знаешь, когда твой кот будет спать на клавиатуре и мешать ему работать), но опять же, объем постоянной работы, которую дизайнеру придется выполнять за проект можно обсуждать, но, допустим, он посвятит проекту все свое время. Так что, возможно, хорошее распределение для команды разработчиков:
- Дизайнер
- Старший (или средний) Front-End разработчик
- Начинающий Front-End разработчик
- Старший (или средний) Back-End разработчик
- Начинающий бэкенд-разработчик
- Тестер
Таким образом, у нас в команде до 6 разработчиков, и этого достаточно для большинства проектов!
Проблемы со связью
Больше участников в отряде означает, что вам придется следить за тем, как они общаются друг с другом, и следить за тем, чтобы они общались друг с другом в чистоте и порядке. До сих пор я не видел ни одной компании, которая действительно беспокоилась бы о том, что общение между участниками может быть реальной проблемой. Большинство руководителей или менеджеров считают, что разработчик может просто присоединиться к работающему проекту, взяться за клавиатуру и… волшебство! Мы все знаем, что это неправда, и мы также знаем, сколько тредов и различных тем вызовет проект ад.
По сути, когда менеджеры начинают раздувать отряды все большим количеством разработчиков, они в основном усложняют проект, а не ускоряют работу. Это даже не хорошая сложность, а та, которая в основном заставит участников испытывать стресс и тратить все больше и больше времени на ненужные встречи, чтобы согласовать вещи, которые 1/3 из них уже знают, 1/3 думали, что они знали, а другая 1/3 не могла все равно.
Подводить итоги
Это призыв ко всем разработчикам, клиентам и менеджерам. Всякий раз, когда вы чувствуете, что проект намного сложнее, чем должен, и вам трудно осознавать его бизнес-сущность, вы не ошибаетесь. Ваша компания, вероятно, добавила к нему ненужную сложность, раздув его. Большим компаниям не нужны большие команды только для того, чтобы раздувать свое эго! Крупные компании должны быть краткими и простыми!
Отличный связанный контент
Если вы ищете гораздо более информативный контент по этой проблеме, вы можете прочитать эту статью (написанную Agile Pain Relief), в которой есть много идей и отличный контент, который подчеркивает проблему, стоящую за большими командами и их отношения. У этой статьи и у меня нет никаких отношений с владельцами упомянутой статьи, но нужно поделиться отличным содержанием!
