3 вещи, которые малые компании не должны копировать у крупных технологических компаний

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

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

1. Собеседование

Традиционное собеседование в крупной технологической компании – это стандартное сочетание сеансов кодирования, системного проектирования и поведенческих сессий. Об этом рассказывает знаменитая книга Cracking the Coding Interview. Кроме того, это и есть суть leetcode. В результате многие инженеры пытаются научиться решать загадки алгоритмов и структур данных, а потом никогда не вращают деревья и не находят кратчайший путь между двумя узлами на работе.

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

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

2. Создание собственных инструментов и инфраструктуры

Я видел, как некоторые небольшие компании пытались развернуть свои собственные репозитории git или hg или настроить полностью настраиваемые конвейеры непрерывной интеграции. Крупные компании часто создают инструменты с нуля по следующим причинам:

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

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

• Нужно ли вам хранить свой код в версионной системе? Вероятно, лучше всего использовать Github или Bitbucket.
• Вам нужна система непрерывной интеграции? Тогда, возможно, используйте Gitlab или Функции Github CI.
• Возможно, вам нужен мобильный конвейер CI/CD? Используйте Bitrise или другие специализированные платформы.

Использование существующего проверенного сервиса обычно экономит кучу денег и позволяет людям сосредоточиться на реальной работе.

3. Тяжелый процесс

Большие компании вводят сложные процессы (например, обязательный дизайн системы или обзоры продуктов) по следующим причинам:

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

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

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

Заключение

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

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

:::информация Также опубликовано здесь.

:::