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

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

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

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

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

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

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

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

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

Ваша перспектива, осведомленность и то, как вы работаете, должны масштабироваться вместе с командой.

Если вы попытаетесь продолжать делать то, что делаете сейчас, рано или поздно вы попадете в эти ловушки или столкнетесь с тем, чего не видите.

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

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

Один конкретный пример, который я могу придумать:

Я никогда не был в масштабируемой команде, которая не сталкивалась с проблемами, связанными с утверждением запросов на вытягивание. Когда вы малы, странно ограничивать PR до «x» количества отзывов. Я не сторонник ковбойского кодирования или продвижения прямо в основную ветку, но если у вас больше одного разработчика, вы все сотрудничаете и просматриваете пулл-реквесты. Дела волшебным образом решаются и работают в небольшой команде. В конце концов, вы становитесь больше, и, возможно, вы говорите, что все в порядке, 1 человек должен проверить, и процесс становится немного более официальным. Обычно это хорошо работает в течение некоторого времени, но затем вы становитесь больше, и заинтересованные люди могут не понимать шаблоны, и, возможно, когда-нибудь их станет два. Еще одна странная вещь — выяснить, кому нужно их просматривать. Это что-то, что вы публикуете в чате и просите? Используете ли вы свой инструмент для назначения рецензентов? Ведете ли вы список тех, кто является подходящим рецензентом? по инструменту или технологии? Как вы держите это в курсе? Что, если назначение рецензентов не информирует людей автоматически о том, что им нужно что-то сделать? Как долго слишком долго ждать бездействия по обзору?

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

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