특정 기능이 제공되지 않는 이유를 이해하는 것은 종종 어려울 수 있습니다. 경영진은 기술팀을 비난할 수도 있고, 기술팀은 경영진을 비난할 수도 있습니다. 그 사이 사업부는 상황을 아랑곳하지 않고 결과를 추구하면서 근본 원인을 규명하려다 중간에 끼어든다. 이 시나리오는 일반적으로 회사가 크게 성장한 후 또는 이전에는 쉽게 해결할 수 있었던 초기 문제가 시간이 지남에 따라 무시되었을 때 발생합니다. 기술 회사의 모든 문제가 순전히 기술적인 문제라는 것은 일반적인 오해입니다. 이것은 사실과 거리가 멀다. 이 기사에서는 기능 제공을 크게 방해할 수 있는 회사 조직 내의 영역을 간략하게 설명합니다. 또한 근본 원인을 파악하기 위한 조사 지침을 제안해 드릴 것이며, 귀하의 권한 수준 내에서 문제를 확대하거나 해결할 수 있습니다. 변경이나 개선을 구현하기 전에 작업 환경을 이해하는 것이 중요합니다. 이 주제에 관해 많은 통찰력 있는 책이 저술되었지만 모든 접근 방식이 모든 회사에 적합한 것은 아닙니다. 이는 잘못된 일을 반영하는 것이 아니라 각 회사의 고유한 특성을 인정하는 것입니다. 중요한 점은 여기에서 공유된 통찰력은 주로 소프트웨어 개발과 관련되어 있으며 직원이 50명 이상인 회사나 부서에 가장 적합하다는 것입니다. 조직 구조 가장 먼저 회사의 규모와 구조를 이해하세요. 다양한 부서를 식별하고 각 부서에서 기대하는 바를 명확히 하세요. 이러한 부서가 모두 필요한지 평가하십시오. 각 부서와 해당 역할을 자세히 설명하는 조직 구조 다이어그램을 작성하여 해당 부서가 수행하는 작업과 존재 이유를 확실히 이해하세요. 각 부서는 여러 팀으로 구성되는 경우가 많습니다. 이러한 팀도 다이어그램에 포함하되 지금은 설명하지 말고 팀 이름만 남겨두세요. 기업이 성장함에 따라 조직 구조가 복잡해져서 진행 상황을 추적하기 어려울 수 있습니다. 이러한 복잡성으로 인해 특정 부서나 팀을 만든 원래의 근거를 놓칠 수 있습니다. 더 이상 관련이 없는 문제를 해결하기 위해 일부 팀이 구성되었을 수도 있습니다. 여기, 높은 수준에서 어떻게 보일 수 있는지 살펴보겠습니다. 조직 구조에 대한 명확한 다이어그램을 갖고 나면 다음 단계는 무엇입니까? 직원 계층 구조 다음으로, 직원의 계층 구조를 계획하는 것이 중요합니다. 누가 누구에게 보고하는지, 왜 보고하는지 이해하는 것이 중요합니다. 라인 관리자는 대규모 사업 단위를 관리하든 소규모 팀을 관리하든 상관없이 부하 직원과 효과적으로 커뮤니케이션해야 합니다. 기술 언어나 비즈니스 언어 모두를 처리하는 것이 어려울 수 있으므로 의사소통은 명확해야 합니다. 대기업에는 명확한 책임 영역을 가진 직접적이고 기능적인 관리자가 있을 수 있으며, 이는 계층 구조 다이어그램에 명확하게 표시되어야 합니다. 직원 계층 구조는 보고 라인을 명확하게 할 뿐만 아니라 조직 내 업종을 식별하는 데도 도움이 됩니다. 업종은 디자이너, HR, DevOps, 개발자 등 여러 부서에서 공유 리소스 역할을 하는 계층 구조입니다. 업종은 매우 유익할 수 있지만 때로는 병목 현상이 발생할 수 있습니다. 특히 개발자가 다양한 프로젝트를 진행하고 비즈니스 목표나 기술적 과제에 익숙하지 않은 관리자에게 보고할 때 더욱 그렇습니다. 결과적으로 개발자는 적절한 피드백을 받지 못하고 관리자는 적절한 컨텍스트를 갖지 못합니다. 따라서 계층 구조를 이해하는 것은 작업의 잠재적인 문제나 우선 순위를 식별하고 분석하는 데 필수적입니다. 그러면 결국에는 다음과 같은 것을 갖게 될 것입니다. 주석 CEO — 최고 경영자 CPO — 최고 제품 책임자 CTO — 최고 기술 책임자 COO — 최고 운영 책임자 HD — 디자인 책임자 PO - 제품 소유자 HE — 엔지니어링 책임자 HS — 영업 책임자 HM — 마케팅 책임자 D — 개발자 PM — 제품 관리자 TL — 기술 책임자 EM — 엔지니어링 관리자 S — 영업 관리자 M - 마케팅 담당자 조직 구조를 보고 라인과 비교하여 다양한 활동에 각 직원의 참여에 대한 통찰력을 얻으십시오. 또한 조직 구조를 직원 계층 구조에 맞춰 조정하면 개인이 동일한 부서 및 팀 내에서 공통 목표를 향해 일하고 있는지 확인하는 데 도움이 될 수 있습니다. 매핑 템플릿은 전적으로 귀하에게 달려 있지만 이렇게 할 수도 있습니다. 팀의 책임 각 팀이 활동하는 영역을 명확하게 정의하는 것이 중요합니다. 팀이 코드를 사용하는 경우 사용하는 서비스와 소유하는 서비스를 지정하세요. 놀랍게도 이들은 종종 다를 수 있습니다. 팀이 한 부서 내에서만 운영되는지, 아니면 다른 팀이 활용하는 핵심 기능을 직접 변경하지 않고 작업하는 플랫폼 팀인지 확인하세요. 팀 이름, 부서, 소유한 서비스 목록, 팀이 수정할 수 있지만 소유하지 않은 일반 서비스 목록(이상적으로는 그러한 서비스가 있어서는 안 됨) 및 간략한 설명 열이 포함된 테이블을 생성하면 매우 유용할 수 있습니다. . 이 표는 여러 팀이 동일한 코드 베이스에서 작업하여 충돌이 발생하는지 또는 책임 영역에 대한 명확성이 부족한지 조사하는 데 도움이 됩니다. 또한 팀이 주로 버그를 수정하는지 아니면 명확한 초점 없이 다양한 작업에 손을 대고 있는지도 알 수 있습니다. 이러한 세부 수준은 팀 책임의 중복, 충돌 및 격차를 식별하여 보다 원활한 협업과 보다 효율적인 프로젝트 실행을 보장하는 데 중요합니다. 직원의 책임 팀을 설명하는 것 외에도 일반 직원의 위치를 이해하고 책임에 대한 자세한 설명을 준비하는 것이 중요합니다. 경영진이 상상하는 것과 직원이 실제로 하고 있는 것이 크게 다를 수 있는 경우가 많습니다. 소프트웨어 개발 업계는 다양한 입장을 갖고 있으며 기대치는 회사마다 크게 다를 수 있습니다. 예를 들어 엔지니어링 관리자의 역할은 제공 관리자, 데이터 과학자, 설계자, 기술 리드 등과 같은 역할은 물론이고 매우 다양할 수 있습니다. 일부 회사에서는 한 사람이 여러 역할을 수행해야 할 수도 있습니다. 각 직위에 대한 명확한 기대치를 설정하는 것이 필수적입니다. 이러한 명확성은 활동을 적절하게 추적하는 데 도움이 될 뿐만 아니라 직원이 자신에게 기대되는 것과 범위를 벗어나는 것이 무엇인지 이해하도록 보장합니다. 이는 조직 내 모든 직위에 적용됩니다. 명확한 역할 정의는 중복을 방지하고, 혼란을 줄이며, 모든 사람이 효율적이고 조직적인 방식으로 공통 목표를 향해 노력하도록 보장합니다. 기능 제공 프로세스 이제 회사 구조, 직원 계층 및 책임을 명확하게 이해해야 합니다. 상황이 혼란스러워 보일 수도 있지만 목표는 변경하기 전에 먼저 현재 상태를 이해하는 것입니다. 이제 기능 제공 프로세스, 즉 비즈니스 기능이 초기 아이디어에서 생산까지 어떻게 이동하는지 설명할 차례입니다. 여기서는 CI/CD와 같은 기술적 측면에 초점을 맞추지 말고 개발자가 코드를 작성하여 프로덕션에 직접 배포한다고 가정하고 비즈니스에서 개발자로의 흐름에 집중하세요. 목표는 비즈니스부터 팀까지 프로세스에서 문제를 식별하고 직원이 이에 얼마나 잘 부합하는지 확인하는 것입니다. 다음 측면을 고려하십시오. 얼마나 자주 새로운 기능을 계획하고 각 부서 및 팀에 작업을 할당합니까? 핵심 성과 지표를 어떻게 설정하고 측정합니까? 마일스톤을 사용하시나요? 초기 준비에는 누가 참여합니까? 팀에서는 어떻게 계획을 세우나요? 계획 및 실행 프로세스를 조정하는 사람은 누구입니까? 당신은 정말 민첩한 회사인가요? SAFe, Prince2, PMP와 같은 프레임워크를 사용하시나요? 아니면 자신에게 맞는 맞춤화된 프레임워크가 있나요? 팀 간 복잡한 작업을 어떻게 처리하고 진행 상황을 제어합니까? 구조화된 접근 방식을 갖고 있습니까, 아니면 문제가 어떻게든 해결될 것이라고 믿고 있습니까? 관리 및 보고의 각 수준은 방향에 관계없이 복잡성과 불확실성을 추가한다는 점을 기억하십시오. 궁극적으로 프로세스 다이어그램은 "어떻게?"라는 간단한 질문에 대답해야 합니다. 템플릿을 가지고 놀면서 필요에 맞게 조정할 수 있습니다. 다음은 배송을 규제하는 주요 플레이어는 없지만 기간은 있는 매우 높은 수준의 배송 프로세스 예입니다. 이 다이어그램을 만드는 방법을 잘 모르는 경우 BPMN(비즈니스 프로세스 모델 및 표기법)을 사용하거나 직사각형 및 선과 같은 간단한 형식을 사용하여 모든 이해관계자의 명확성과 이해를 보장하는 것이 좋습니다. 핵심은 프로세스를 명확하고 이해하기 쉽게 만드는 것입니다. 피드백 수집 회사 구조, 직원 계층 구조, 팀 및 직위 책임, 전달 프로세스를 계획한 후 모든 결과를 조직과 공유하고 익명으로 설문조사를 수행하는 것이 좋습니다. 이 기준선은 회사의 운영 방식을 강조합니다. 이 개요를 직접 준비했거나 일부 작업을 위임했을 수도 있지만 개발자, 디자이너 및 분석가는 직접 참여하지 않았을 가능성이 높습니다. 그들의 피드백은 조사 결과의 정확성을 평가하는 데 매우 중요합니다. 직원들에게 문서의 품질을 평가해 달라고 요청하세요. 배송 과정에 대해 어떻게 생각하나요? 그것이 실제로 일이 어떻게 이루어지는지를 반영하는가? 그들은 어디에서 장애물을 발견합니까? 회사 운영의 현실에 더 잘 부합하도록 조사 결과를 개선하는 데 도움이 되는 다양한 불만 사항과 피드백을 기대하세요. 여러 수준의 계층 구조를 통해 컨텍스트가 손실되는 경우가 많기 때문에 이러한 피드백은 매우 중요하며 모든 수준에서 입력을 수집하면 조직에 대한 보다 명확하고 정확한 그림을 제공할 수 있습니다. 추정 결과 이제 회사 또는 부서의 운영 방식에 대한 포괄적인 설명을 얻었으므로 잠재적인 문제를 분석하고 찾을 수 있습니다. 이 기준선은 문제를 이해하고 해결하기 위한 명확한 출발점을 제공합니다. 다음은 집중해야 할 몇 가지 영역입니다. 귀하의 부서는 체계적으로 구성되어 있나요? 보고 라인이 명확합니까? 라인 관리자가 자신의 책임 영역에 대해 실제로 피드백을 제공할 수 있습니까? 비즈니스 요구 사항을 기술 작업으로 전환하는 데 혼란이나 불확실성이 있습니까? 개발 중에 지연을 일으키는 다른 팀에 대한 종속성이 있습니까? 직원이 자신의 주요 책임 영역을 벗어나는 활동에 참여하여 주요 업무를 방해합니까? 직원 계층 구조가 팀 구조와 얼마나 잘 일치합니까? 보고 계층 구조가 효과적입니까, 아니면 의사소통과 맥락에 격차가 있습니까? 서로 다른 팀이 동일한 서비스를 작업하여 갈등을 일으키고 작업 소유권을 결정하는 데 시간이 낭비됩니까? 명확하게 정의된 책임이 없거나 핵심 인력이 누락된 팀이나 부서가 있습니까? 일부 팀은 어떤 부서에도 통합되지 않습니까? 그런 다음에는 회사가 겪고 있는 실제 문제 목록을 준비할 수 있으며, 이를 해결하기 위해 노력할 것입니다. 즉각적인 상호 작용이 필요한 중요한 것부터 "있으면 좋은" 개선 사항을 우선시합니다. 변경 방법 "이 모든 것이 훌륭해 보이지만 실제로 어떻게 개선할 수 있을까요?"라고 궁금해하실 수도 있습니다. 좋은 질문입니다. 솔직한 답변은 파악한 특정 문제와 비즈니스 요구 사항에 따라 달라집니다. 그러나 한 가지 중요한 조언은 모든 것을 한꺼번에 바꾸려고 하지 말라는 것입니다. 대신 작은 변화를 점진적으로 구현하고 결과를 평가하고 반복하십시오. 애자일 접근 방식은 소프트웨어 개발뿐만 아니라 모든 유형의 조직 변화에도 적용될 수 있다는 점을 기억하십시오. 개선 프로세스를 안내하는 몇 가지 단계는 다음과 같습니다. 직원들이 자신의 역할에 수반되는 것과 책임 범위를 벗어나는 것이 무엇인지 정확히 알도록 하십시오. 잘 정의된 부서나 도메인을 만들고 각 도메인에 특정 팀을 할당합니다. 명확한 책임 영역을 정의하고 부서와 팀의 중복을 최소화하세요. 소프트웨어 개발의 다양한 측면을 다루기 위해 플랫폼, 스트림 정렬, 활성화 및 복잡한 하위 시스템 팀을 소개하는 팀 토폴로지 접근 방식을 숙지하는 것이 좋습니다. 새로 설정된 도메인 및 팀에 맞게 직원 계층 구조를 검토하고 조정하세요. 보고 구조가 명확하고 진행 상황 추적이 간단한지 확인하세요. 기능 제공 및 결과 추적에 사용할 방법론이나 프레임워크를 선택하세요. 중요하지 않은 부서에서 변경 사항을 테스트하고 영향을 평가하고 피드백과 결과를 바탕으로 접근 방식을 개선하세요. 선택한 사고방식을 조직 변화에 적용하여 지속적으로 개선합니다. 이러한 단계를 수행하면 조직의 효율성과 효율성을 점진적으로 향상시키는 정보에 입각한 점진적인 변화를 만들 수 있습니다. 요약 어느 회사나 부서에서나 발생할 수 있는 공통적인 문제를 강조하고 싶었습니다. 각 회사마다 고유한 목표와 구조가 있고 자신에게 가장 적합한 것이 무엇인지 결정하는 것이 중요하기 때문에 특정 프레임워크나 접근 방식을 권장하는 것을 의도적으로 피했습니다. 다시 말하지만, 개발자를 비난하기는 쉽지만, 개발자가 비즈니스 우선순위를 인식하지 못하거나 불분명한 전달 프로세스로 인해 차단될 수 있다는 점을 기억하십시오. 때로는 사업 자체가 무의식적으로 방해 요소를 만들어 내는 경우도 있습니다. 이 기사가 개선을 향한 첫 걸음을 내딛는 데 도움이 되기를 바랍니다.
