Перехід від невеликої до великої компанії [закрито]

Хтось має поради, думки, застереження чи загальну розумність для розробника програми / бази даних, який спеціально переходить від стартової компанії до великої організації?

Приклади думок включають такі речі, як:

• Як я можу по-різному взаємодіяти з ланцюгом управління?
• Ви бачите тенденції в якості чи швидкості розвитку, які відрізняються між великими та малими?
• Думки про розробника команди.
• Соціальні аспекти.
• Ще щось.

Доповнення: Чи є у когось якісь особисті історії та досвід поділитися подібним кроком?

Будь ласка, дайте мені знати, чи можу я уточнити будь-яким способом.

Я ціную будь-які думки!

Кілька особистого досвіду, з яким ви можете поділитися:

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

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

• Після переїзду:

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

• Коли справи йдуть добре:

  • Поліпшуйте речі потроху, не сидите і не скаржтеся.
  • Не бійтеся приймати важкі завдання. Ви будете рідше усунені, якщо будете в ключовій ролі.
  • Використовуйте ресурс так, ніби це остання крапля води на землі.
  • Подумайте знову і знову, чи корисна роль менеджменту для вас і вашої майбутньої кар’єрної дороги. Не надто багато інженерів - хороші менеджери.

• Коли все піде не так:

  • Пам'ятайте, що у вас є оренда на місяць (часу чи грошей ;-) не панікуйте.
  • Знову ж таки, не воюйте. Якщо вони можуть змінити свою думку, вони вже зробили це.
  • Незважаючи ні на що, трапляються sh_ts. Справа не в тому, що це правильно чи неправильно, це про відповідність чи ні.
  • Світ більший, ніж одна компанія. Можливості є для тих, хто готовий взяти участь.

Ура!

• Як я можу по-різному взаємодіяти з ланцюгом управління?

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

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

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

• Думки про кодування розробника та ковбойське кодування.

Невідповідне; і великі, і малі можуть бути будь-якими.

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

Більші фірми, як правило, більш консервативні, оскільки втратити більше.

Більші фірми мають одну велику перевагу: вони знають, як зробити заробітну плату. Деякі з менших фірм, з якими я працював, зазнали невдач. Продажі та утримання потоку доходу може бути проблемою для меншої фірми.

• Ще щось.

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

Свобода та межі

Найбільша відмінність, яку я можу придумати в своєму досвіді, - це межі та гнучкість. У менших компаніях:

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

• Це більш соціально - у вас можуть бути стосунки з власником / директорами компанії тощо.

• Ви відчуваєте, що маєте більший вплив, оскільки ваші думки дістаються далі навколо компанії.

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

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

• Це майже те, що ти просто стаєш програмістом .

• Ви повідомляєте менеджеру проекту про оновлення завдань.

• Вашою інфраструктурою керує команда підтримки / comms.

• Іноді є тестова команда, яка проводить тестування UAT та надсилає помилки в системі відстеження помилок.

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

Як хтось, хто працював в обох середовищах, ось мої думки:

• Управління - Ви, мабуть, виявите, що багато спілкування втрачається в ієрархії. Я маю на увазі під цим те, що в невеликих компаніях майже всі всі знають (або принаймні "знають про це"). У великих компаніях ваш непростий керівник не має уявлення, над чим ви навіть працюєте (це робота керівника команди - тому втрачається деталізація інформації вгору та вниз по ланцюжку).
• Якість та швидкість розвитку - Це, як правило, більш велике у великих компаніях. Стартапи, як правило, більш спритні (частина цього пов'язана з тим, що товар у невеликої компанії, ймовірно, буде меншим). Однак не потрапляйте в пастку думки про те, що велика компанія обов'язково має більш усталені процеси та методології. Особливо, якщо основна компетенція компанії полягає не в програмному забезпеченні - команди програмного забезпечення можуть бути запущені не краще, ніж у будь-якому невеликому магазині. Насправді, одне з найкращих місць, у яких я коли-небудь працював, - це невеликий хакерський магазин, наскільки це стосується - головним чином, тому, що це був справжній маленький магазин програмного забезпечення - розпочатий та керований програмістами. Суцільний 12/12 на тесті Joel Test.
• Розвиток команди - Як вище. Це дійсно залежить від команди. Великі компанії не обов'язково працюють краще (на відміну від деяких інших дисциплін). В основному це залежить від того, наскільки "компетентними розробники програмного забезпечення" є люди, які відповідають за команди програмного забезпечення. Менеджери з середнього та верхнього рівня, які недостатньо добре розуміють програмне забезпечення, особливо недофінансують та розчарують програмні колективи у великих компаніях.
• Соціальні аспекти - В цілому малі компанії та стартапи, як правило, більш неформальні та соціальні, але великі компанії також не повинні бути занадто жорсткими. Багато що може залежати від галузі галузі, а також від середнього віку колективу. Молода команда програмного забезпечення, що тісно співпрацює у великій компанії, може відчувати себе трохи за допомогою власного запуску.

Все інше (лише кілька випадкових думок та попереджень, про які я можу придумати):

• Слідкуйте за міжкомандним конфліктом. У великих компаніях часто існують окремі команди, відповідальні за різні шари системи і т. Д. Людська істота, ерм, природа людини - означає, що тут часто є менталітет "ми і вони" (тупінг, сука, передача долара, тощо). Ви не схильні бачити це в невеликих стартапах, де всі по суті в одній команді.

• Звикайте приймати замовлення від людей, які не мають уявлення про те, як працює програмне забезпечення. Звичайно, це може бути проблемою де завгодно, але розмежування між "діловими людьми" та командою програмного забезпечення, як правило, більш чітко визначено, чим більше компанія отримує. У невеликому стартапі вони часто одні і ті ж люди. У величезних корпораціях вони майже ніколи не є. Це буде не так вже й погано, якщо компанія є фактичною компанією програмного забезпечення (наприклад, Microsoft).

• Ви, ймовірно, будете більш захищені від клієнтської "лінії фронту". Напевно, буде служба підтримки та менеджери продуктів, які мають справу з клієнтами, і вам, мабуть, майже ніколи цього не доведеться. Це може бути як добрим, так і поганим. Добре в тому сенсі, що вам не доведеться мати справу з прямою підтримкою, погано в тому сенсі, що для вирішення відносно простих проблем можуть виникнути проблеми з комунікацією і нудні повороти.

Це про все, про що я зараз можу придумати.