엔터프라이즈에서 조직을 구조화하기 위한 모범 사례

엔터프라이즈 내 조직에 대한 모범 사례 정보

엔터프라이즈 내에서 조직을 구조화하기 위한 여러 옵션이 있습니다. 각 접근 방식에는 장단점이 있으며 엔터프라이즈에 가장 적합한 구조는 크기 및 보안 제약 조건을 포함하여 비즈니스의 특성과 요구 사항에 따라 달라집니다.

그러나 현재 가지고 있는 문화권이 아니라 만들려는 문화권에 전략을 맞추는 것이 좋습니다. 협업 및 내부 소싱 측면에서 발전하려면 그에 따라 도구를 구성합니다. 그런 다음 도구는 방해자 역할을 하는 대신 문화적 변화를 지원할 수 있습니다.

일반적으로 GitHub은 만드는 조직의 수를 최소화하는 것이 좋습니다. 조직이 적으면 협업과 내부 소싱이 강화되어 효율성이 높아질 수 있습니다. 실제로 많은 기업은 다음과 같은 이유로 단일 조직에서 가장 잘 서비스를 제공합니다.

검색할 위치가 하나뿐이므로 단일 조직 내에서 리소스를 더 쉽게 찾을 수 있습니다.
동일한 조직의 구성원 간에만 작동하므로 @-mentions 단일 조직 내에서 보다 쉽게 통신할 수 있습니다.
누구나 액세스할 수 있는 단일 대규모 조직의 일원이 됨은 협업과 충성도를 높이는 반면, 소규모 조직으로 분리하면 팀을 더욱 고립시킬 수 있습니다.

조직 소유자는 항상 조직이 소유한 모든 리포지토리에 액세스할 수 있습니다. 회사가 단일 소유자가 모든 리포지토리에 액세스할 수 없을 만큼 충분히 큰 경우 여러 조직을 만드는 것이 좋습니다.

여러 조직을 만들 때의 주요 이점은 각각에 대해 별도의 정책, 설정 및 요구 사항을 구성할 수 있다는 것입니다. 예를 들어 각 조직에는 다른 SAML 구성이 있을 수 있습니다.

조직과 개별 팀 또는 사업부와 같은 회사의 구조 엔터티 간에 일대일 관계를 만들지 마세요. 대신 정책, 설정 및 요구 사항을 단일 조직으로 공유할 수 있는 구조적 엔터티를 그룹화합니다. 이 방법은 규정 요구 사항을 충족하는 동안 협업을 최대화합니다.

조직을 제거하는 것보다 조직을 추가하는 것이 항상 더 쉽기 때문에 앞으로 더 많은 유연성을 제공하는 소수의 조직으로 시작하는 것이 좋습니다. 비즈니스에 적합한 것에 대한 더 많은 경험을 개발한 후에는 필요한 경우 추가 조직을 만들 수 있습니다.

조직을 제거하는 것은 훨씬 더 어렵고, 종종 마이그레이션이 필요하고 팀이 익숙해진 유연성이 감소합니다. 많은 고객이 수를 줄이는 도전적이고 시간이 많이 걸리는 프로세스를 경험한 후 많은 조직을 만드는 것을 후회하게되었습니다.

엔터프라이즈에서 새 조직을 만들기 위한 고정적이고 투명한 규칙을 만들고 적용하는 것이 좋습니다. 이렇게 하면 모든 사용자가 각 조직의 목적과 어디에 있는 자산을 더 쉽게 이해할 수 있습니다.

조직 구조에는 5가지 주요 원형이 있습니다. 아키타입은 다음 두 가지 결정으로 정의됩니다.

팀에 대한 자세한 내용은 "팀 정보.

가장 간단한 조직 구조는 구성원에게 조직 멤버 자격을 통해 직접 모든 리포지토리에 대한 액세스 권한을 부여하는 단일 조직입니다. Teams는 조정 및 커뮤니케이션에 사용할 수 있지만 리포지토리 액세스 관리에는 사용할 수 없습니다.

이 구조는 모든 사람이 모든 것을 공동 작업하는 신생 기업과 같은 중소기업에 가장 적합합니다. 신뢰가 높은 경우 중견 기업에서도 작동할 수 있습니다.

이 원형을 사용하려면 조직의 기본 권한을 "쓰기" 또는 "읽기"로 설정합니다. 자세한 내용은 "조직에 대한 기본 권한 설정"을 참조하세요.

회사에서 리포지토리 액세스를 보다 세부적으로 제어해야 하는 경우 조직의 기본 권한을 "없음"으로 설정한 다음 각 팀에게 특정 리포지토리에 대한 액세스 권한만 부여할 수 있습니다.

이 구조는 중견 기업이나 신뢰도가 낮은 중소기업에 가장 적합합니다. 모든 사람이 모든 것을 공동 작업하는 높은 신뢰를 가진 소규모 기업의 경우 팀을 관리하는 것은 시간 투자 가치가 없을 수 있습니다.

대기업의 경우 단일 조직 내에서 리포지토리 액세스를 관리하는 것은 팀에서도 다루기 어려울 수 있습니다. 이 원형은 여러 조직을 활용하여 리포지토리 액세스를 대신 관리합니다. 각 조직의 구성원은 해당 조직의 모든 리포지토리에 액세스할 수 있습니다.

이 구조는 함께 작업할 필요가 없는 다른 그룹을 가질 수 있을 만큼 큰 회사에 가장 적합합니다. 사업부 간 협업이 중요한 경우에는 이 구조가 유용하지 않습니다.

이 원형을 사용하려면 위에서 설명한 대로 정책, 설정 및 요구 사항을 공유할 수 있는 각 그룹에 대해 하나의 조직을 만든 다음 각 조직의 기본 권한을 "쓰기" 또는 "읽기"로 설정합니다.

대규모 기업은 여러 조직 내에서도 리포지토리 액세스를 보다 세부적으로 제어해야 할 수 있습니다. 이 경우 팀을 사용하여 각 그룹에 특정 리포지토리에 대한 액세스 권한만 부여할 수 있습니다.

이 원형을 사용하려면 위에서 설명한 대로 정책, 설정 및 요구 사항을 공유할 수 있는 각 그룹에 대해 하나의 조직을 만들고 각 조직에 대한 기본 권한을 "없음"으로 설정한 다음 각 팀에게 특정 리포지토리에 대한 액세스 권한만 부여합니다.

직접 리포지토리 액세스 권한이 있는 단일 조직의 공동 작업 이점을 원하지만 전역 액세스에 너무 민감한 리포지토리가 적은 경우 액세스 방법이 혼합된 여러 조직을 사용하는 것이 좋습니다.

이 원형을 사용하려면 모든 직원과 대부분의 리포지토리에 대해 하나의 조직을 만듭니다. 조직의 기본 권한을 "쓰기" 또는 "읽기"로 설정하여 모든 구성원에게 이 조직의 모든 리포지토리에 대한 액세스 권한을 부여합니다.

그런 다음, 더 중요한 리포지토리를 위해 특별히 두 번째 조직을 만듭니다. 이 조직에서 기본 권한을 "없음"으로 설정하고, 중요한 리포지토리에 액세스해야 하는 사용자만 추가하고, 팀 멤버 자격을 통해 리포지토리에 대한 액세스를 관리합니다.