소규모 회사에서 대기업으로 이전 [폐쇄]

창업 규모의 회사에서 대규모 조직으로 이동하는 응용 프로그램 / 데이터베이스 개발자에게 유용한 팁, 생각, 경고 또는 일반적인 지식이 있습니까?

생각에는 다음과 같은 것들이 포함됩니다.

• 관리 체인과 어떻게 다르게 상호 작용할 수 있습니까?
• 품질과 개발 속도의 트렌드가 크고 작은 차이를 보입니까?
• 팀 개발자에 대한 생각.
• 사회적 측면.
• 다른 것.

추가 : 누구나 비슷한 움직임을 공유 할 개인적인 이야기와 경험이 있습니까?

어떤 식 으로든 명확히 할 수 있으면 알려주십시오.

나는 어떤 생각을 주셔서 감사합니다!

공유 할 몇 가지 개인적인 경험 :

• 이동하기 전에 :

  • 위대한 약속을 모두 믿지 마십시오. 그들은 재능을 찾고있을 때, 당신에게 모든 좋은면을 보여주고 그 나쁜 사실을 숨길 것입니다. 그 입장이 그렇게 좋으면 왜 내 앞에 채워지지 않습니까? :-)
  • 사업은 사업이며, 유일한 목표는 이익을 얻는 것입니다. 당신을 온보드로 데려 오는 것이 목표에 가치를 더한다고 생각하십시오. 그들은 당신이 부가 가치를 가져 온다고 생각 하기 때문에 초대 되었습니다. 당신은?
  • 프로그래머라고 가정하면 대기업은 일반적으로 정치, 커뮤니케이션 기술, 규정 등과 같은 기술적 과제 이외의 복잡성을 겪게됩니다. 준비 되었습니까?

• 이동 후 :

  • 기능 그룹 (부서) 의 KPI 를 가능한 빨리 식별하십시오 . 간단히 말해서 왜이 대기업이 이런 일을하는이 그룹의 사람들에게 돈을 지불 할 의향이 있습니까?
  • 위의 답변 (발견 된 경우)의 기여 요인으로 자신을 배치하십시오. 보그와 싸우지 마십시오. 당신은 이길 수 없습니다. 준수해야합니다.
  • 좋은 일을하고 좋은 일을하는 것은 대개 가장 어려운 일이 아닙니다.

• 상황이 좋을 때 :

  • 조금씩 물건을 개선하고 앉아서 불평하지 마십시오.
  • 어려운 일 을하는 것을 두려워하지 마십시오 . 핵심 역할을 수행하면 제거 될 가능성이 줄어 듭니다.
  • 마치 지구상에서 마지막 물 한 방울 인 것처럼 자원을 사용하십시오.
  • 관리자 역할이 귀하와 미래의 경력 경로에 적합한 지 여부를 반복해서 생각하십시오. 훌륭한 관리자는 그리 많지 않습니다.

• 일이 잘못되면 :

  • 당신은 한 달에 (시간이나 돈을 ;-) 임대 당황하지 마십시오 기억하십시오.
  • 다시 말하지만, 싸우지 마십시오. 그들이 마음을 바꿀 수 있다면 그들은 이미 한 것입니다.
  • 어쨌든 sh_ts가 발생합니다. 그것은 옳고 그름에 관한 것이 아니라 성냥에 관한 것입니다.
  • 세계는 한 회사보다 큽니다. 기회는 준비가 된 사람들을위한 것입니다.

건배!

• 관리 체인과 어떻게 다르게 상호 작용할 수 있습니까?

대기업은 예전보다 관료적입니다. 위와 아래의 레이어와 상호 작용합니다. 건너 뛰기는 거의 없습니다.

• 품질과 개발 속도의 트렌드가 크고 작은 차이를 보입니까?

더 많은 레이어가 있습니다. 프로덕션 서버에 대한 관리자 액세스 권한이 없으므로 더 많은 핸드 오프가 제공됩니다. 커뮤니케이션 채널과 문서 및 프로세스는 대기업의 업무 속도를 늦출 것입니다.

• 팀 개발자 대 카우보이 코딩에 대한 생각.

관련이 없습니다. 크든 작든 둘 중 하나 일 수 있습니다.

• 사회적 측면.

더 큰 회사는 잃을 것이 더 많기 때문에 보수적 인 경향이 있습니다.

대기업은 한 가지 큰 장점이 있습니다. 급여를받는 방법을 알고 있습니다. 내가 함께 일한 작은 회사 중 일부는 실패했습니다. 소규모 회사에서는 판매 및 매출 흐름을 유지하는 것이 문제가 될 수 있습니다.

• 다른 것.

당신은 많은 사람들 가운데 하나의 목소리가 될 것입니다. 당신의 영향력은 당신이 움직이는 사람과 셰이커에 얼마나 잘 통합되는지에 달려 있습니다.

자유와 경계

내 경험에서 생각할 수있는 가장 큰 차이점은 경계와 유연성 차이입니다. 소규모 회사 :

• 더 많은 일을해야하는 개발자 로서 더 큰 역할을합니다 . 서버 설정, 소스 제어 시스템 구성, Company Product X 의 데이터베이스 관리 여부입니다 .

• 더 사회적입니다-회사 소유자 / 감독 등과 관계가있을 수 있습니다.

• 당신은 당신의 의견이 회사 주변에 더 많이 도달함에 따라 더 많은 영향력을 가지고 있다고 생각합니다.

대규모 조직으로 이동하면 경계가 더 명확하게 정의됩니다.

• 당신의 역할은 훨씬 더 구체적입니다.

• 거의 당신이 프로그래머 가 될 것 입니다.

• 작업 업데이트를 위해 프로젝트 관리자에게보고합니다.

• 인프라는 지원 / 통신 팀에서 관리합니다.

• 때로는 버그 추적 시스템에 UAT 테스트를 수행하고 버그를 처리하는 테스트 팀이 있습니다.

• 사람들이 등반을 시도하고 사람들의 바다에서 눈에 띄게 느끼는 명확한 계층 구조가 있기 때문에 경쟁이 더 심합니다.

두 환경 모두에서 일한 사람으로서 여기 내 생각이 있습니다.

• 관리 -아마도 많은 의사 소통이 "계층 구조에서 잃어버린"것입니다. 이것이 의미하는 바는 소기업에서는 거의 모든 사람이 모든 것을 알고 있다는 것입니다 (또는 적어도 "알고 있습니다"). 대기업의 경우 중간 관리자가 무엇을하고 있는지 전혀 모르는 것이 드문 일이 아닙니다 (팀장의 직무이므로 체인의 상하 정보에 대한 세분성이 손실됩니다).
• 품질과 개발 속도 -대기업에서는 더 느리게 진행됩니다. 스타트 업은보다 민첩한 경향이 있습니다 (이 중 일부는 소규모 회사의 제품이 더 작을 수 있다는 사실에서 비롯됩니다). 그러나 대기업이 반드시 프로세스와 방법론을 더 잘 확립했다는 생각의 함정에 빠지지 마십시오. 특히 회사의 주요 역량이 소프트웨어가 아닌 경우 소프트웨어 팀은 소규모 hackshop보다 더 잘 운영 될 수 없습니다. 사실, 내가 일한 최고의 장소 중 하나는 프로그래머가 시작하고 운영하는 작은 소프트웨어 상점 이었기 때문입니다. Joel 테스트에 관한 12/12
• 팀 개발 -위와 같습니다. 그것은 실제로 팀에 달려 있습니다. 대기업이 다른 분야와 달리 반드시 더 나은 운영을하지는 않습니다. 그것은 소프트웨어 팀을 담당하는 사람들이 얼마나 "소프트웨어 개발 능력"인지에 달려 있습니다. 소프트웨어를 충분히 이해하지 못하는 중 / 상위 관리자는 특히 대기업의 소프트웨어 팀을 저축하고 좌절시킬 것입니다.
• 사회적 측면 -전체적으로 소규모 기업과 신생 기업은 일반적으로보다 비공식적이고 사회적이지만 대기업도 지나치게 단단 할 필요는 없습니다. 많은 부분이 산업 영역과 팀의 평균 연령에 따라 달라질 수 있습니다. 대기업의 젊고 긴밀하게 협력하는 소프트웨어 팀은 자체 시작이 거의 없다고 느낄 수 있습니다.

다른 것 (내가 생각할 수있는 임의의 생각과 경고) :

• 팀 간 충돌에주의하십시오. 대기업에는 시스템의 여러 계층 등을 담당하는 별도의 팀이있는 경우가 많습니다. 인간 본성, 음, 인간 본성-여기에는 종종 "우리와 그들"이라는 사고 방식이 있습니다 (백 스테이 빙, 암캐, 벅스 통과, 기타). 모두가 본질적으로 같은 팀에있는 소규모 신생 기업에서는 이것을 보지 않는 경향이 있습니다.

• 소프트웨어 작동 방식을 모르는 사람들로부터 주문을받는 데 익숙해 지십시오. 물론 이것은 어느 곳에서나 문제가 될 수 있지만 "사업자"와 소프트웨어 팀 사이의 분리는 회사가 커질수록 더 강력하게 정의되는 경향이 있습니다. 소규모 스타트 업에서 그들은 종종 같은 사람들입니다. 대기업에서는 거의 존재하지 않습니다. 회사가 실제 소프트웨어 회사 (예 : Microsoft)이면 그렇게 나쁘지 않습니다.

• 당신은 클라이언트 "전선"으로부터 더 보호받을 것입니다. 고객을 다루는 헬프 데스크와 제품 관리자가있을 것이므로 거의 필요하지 않을 것입니다. 이것은 좋고 나쁠 수 있습니다. 직접적인 지원을 처리 할 필요가 없다는 점에서, 비교적 간단한 문제를 해결하기 위해 통신 문제와 지루한 처리 시간이있을 수 있다는 점에서 좋지 않습니다.

이것은 내가 지금 생각할 수있는 모든 것입니다.