Переход от маленькой к большой компании [закрыто]

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

Примеры мыслей могут включать такие вещи, как:

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

Дополнение: Есть ли у кого-нибудь личные истории и опыт, которыми можно поделиться с подобным ходом?

Пожалуйста, дайте мне знать, если я могу уточнить в любом случае.

Я ценю любые мысли!

Несколько личного опыта, чтобы поделиться с:

• Перед переездом:

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

• После переезда:

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

• Когда дела идут хорошо

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

• Когда дела идут плохо:

  • Помните, у вас есть месяц аренды (времени или денег ;-) не паникуйте.
  • Опять не борись. Если они могут изменить свое мнение, они уже сделали.
  • Независимо от того, что случается Дело не в правильном или неправильном, а в совпадении или нет.
  • Мир больше, чем одна компания. Возможности для тех, кто готов принять.

Ура!

• Как я могу по-другому взаимодействовать с цепочкой управления?

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

• Видите ли вы тенденции в качестве или скорости развития, которые различаются между большими и маленькими?

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

• Мысли о разработке команды против ковбойского кодирования.

Ненужные; и большое и маленькое может быть одним.

• Социальные аспекты.

Крупные фирмы имеют тенденцию быть более консервативными, потому что есть что терять.

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

• Что-нибудь еще.

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

Свобода и границы

Самое большое различие, которое я могу вспомнить в своем опыте, - это различия в границах и гибкости. В небольших компаниях:

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

• Это более социально - у вас могут быть отношения с владельцем / директорами компании и т. Д.

• Вы чувствуете, что имеете больше влияния, так как ваши мнения распространяются по всей компании.

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

• Ваша роль гораздо более конкретна.

• Это почти, что вы просто стали программистом .

• Вы сообщаете менеджеру проекта об обновлениях задач.

• Ваша инфраструктура управляется командой поддержки / связи.

• Иногда есть команда тестировщиков, которая проводит UAT-тестирование и борется с ошибками в системе отслеживания ошибок.

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

Как человек, который работал в обеих средах, вот мои мысли:

• Управление - Вы, вероятно, обнаружите, что большая часть общения «теряется в иерархии». Под этим я подразумеваю, что в небольших компаниях почти все знают все (или, по крайней мере, "знают об этом"). В больших компаниях ваш менеджер среднего звена нередко понятия не имеет, над чем вы вообще работаете (это работа руководителя команды - так что теряется детализация информации вверх и вниз по цепочке).
• Качество и скорость разработки. В крупных компаниях эта тенденция более медленная. Стартапы имеют тенденцию быть более гибкими (отчасти это связано с тем, что продукт в небольшой компании, вероятно, будет меньше). Тем не менее, не попадитесь в ловушку, думая, что крупная компания обязательно имеет лучше налаженные процессы и методологии. Особенно, если основная компетенция компании не связана с программным обеспечением - команды разработчиков могут работать не лучше, чем в любом небольшом хакшопе. Фактически, одним из лучших мест, где я когда-либо работал, был небольшой хакшоп, насколько это возможно - главным образом потому, что это был настоящий маленький магазин программного обеспечения - запускаемый и управляемый программистами. Твердые 12/12 на материале Джоэл Тест.
• Развитие команды - как указано выше. Это действительно зависит от команды. Крупные компании не обязательно работают лучше (в отличие от некоторых других дисциплин). Это в основном зависит от того, насколько «компетентны в разработке программного обеспечения» люди, отвечающие за команды разработчиков программного обеспечения. Руководители среднего / высшего звена, которые недостаточно хорошо понимают программное обеспечение, будут недофинансировать и разочаровывать команды разработчиков программного обеспечения в крупных компаниях, особенно.
• Социальные аспекты. В целом, небольшие компании и стартапы, как правило, более неформальные и социальные, но крупные компании тоже не должны быть слишком жесткими. Многое может зависеть от предметной области, а также от среднего возраста команды. Молодая, тесно сотрудничающая команда разработчиков программного обеспечения в большой компании может чувствовать себя немного стартапом самостоятельно.

Что-нибудь еще (только некоторые случайные мысли и предупреждения, которые я могу придумать):

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

• Привыкайте принимать заказы от людей, которые понятия не имеют, как работает программное обеспечение. Конечно, это может быть проблемой где угодно, но разделение между «деловыми людьми» и командой разработчиков программного обеспечения имеет тенденцию быть более четко определенными, чем больше становится компания. В маленьком стартапе они часто одни и те же люди. В огромных корпорациях они почти никогда не бывают. Это не будет так плохо, если компания является реальной компанией-разработчиком программного обеспечения (например, Microsoft).

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

Это обо всем, что я могу думать сейчас.