Какие методы управления / разработки вы меняете, когда команда из 1-3 разработчиков достигает 10+?

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

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

Какие изменения в управлении / разработке наиболее полезны, когда команда превращается из небольшой команды размером с гараж в 10+ разработчиков?

Я бы сказал, что есть примерно две основные дороги:

• Разделите команду на две или три группы, каждая из которых отвечает за определенное поле / аспект. это дает преимущество в том, что вы все еще можете работать так, как привыкли, в небольших группах.
• «Хирургическая бригада», о которой вы можете прочитать на « Мифическом человеко-месяце» . также эта ссылка имеет прекрасный рисунок об этом.

Удачи!

Мы выросли с 10 до почти 200 за последние 7 лет. Первое, что нужно изменить, это то, что вам потребуется лучшая документация и более стандартные процессы. Требования могут быть более формальными.

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

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

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

Координация между людьми является ключевым. Две команды, вносящие взаимоисключающие изменения в продукт, - это плохо.

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

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

Если проект достаточно велик для 10+ разработчиков, его будет легко разбить на более мелкие области. Разделите команду на более мелкие команды по 3-5 человек и предоставьте им автономию в своем районе. API должны быть разработаны между командами. Я рекомендую каждой команде выяснить свои требования и пригласить одного или двух человек из каждой вовлеченной команды для обсуждения API. Проще вести дискуссию и принимать решения, когда в нее вовлечено меньше людей.