Page History
...
| Code Block | ||
|---|---|---|
| ||
## 📌 소프트웨어 개발자가 비즈니스 관계자와 효과적으로 소통하기 위해 필요한 것은 무엇인가? 대화의 목적을 명확히 이해하고(프레이밍), 대화의 목적에 맞는 언어와 형식을 사용하며, 의사결정을 위한 모델을 제공하는 것입니다 ## 💡 비즈니스 관계자를 설득하기 위한 효과적인 방법은? - 상대방의 핵심 동기나 가치를 이해하고, 그 방향에 맞는 단 하나의 강력한 논거를 제시해야 합니다 - 상대방의 사고방식과 언어에 맞춰 메시지를 전달해야 합니다 - 복잡한 분석보다는 스토리텔링이나 간단한 시각 자료를 활용하는 것이 효과적입니다 이 영상은 도메인 주도 설계(DDD) 실무자가 겪는 어려움과 해결책을 제시합니다. 워크숍을 통해 도메인 지식을 습득하고, **공통 언어**를 구축하여 소프트웨어 모델링을 진행하지만, 비즈니스와 기술 용어의 불일치, 문서화의 목적 불분명, 의사소통방식의 문제 등 새로운 난관에 직면합니다. 이러한 문제들을 해결하기 위해, 문서화도구의 목적을 명확히 하고, **위임**** 수준**을 정의하여 의사 결정과정을 개선하며, 설득보다는 **자신의 ****전문성****을 바탕으로 결정**하는 것이 중요하다고 강조합니다. 궁극적으로, 기술 전문가가 자신의 전문성을 발휘하여 비즈니스와 효과적으로 소통하고, 올바른 결정을 내릴 수 있도록 돕는 방법을 제시합니다. ## 1. 🚀 좋은 소프트웨어 개발의 출발점과 현실적인 장애물 -  - - **좋은 소프트웨어**를 만들어 누군가의 삶을 개선하기 위해서는 단순히 문제를 해결하는 것 이상의 과정이 필요하다 . - 좋은 소프트웨어는 **잘 설계된 솔루션**에서 출발하며, 이는 문제의 복잡성을 이해하고 모델링하는 것이 핵심이다 . - 개발자는 대개 문제가 발생하는 도메인의 **전문가가 아니며**, 주도적인 호기심을 바탕으로 새로운 도메인 지식을 탐험한다 . - 조직 내에는 **지식 사일로**, **지역적 ****전문성**, **개별적인 용어**들이 존재해 정보의 유통과 소통을 어렵게 만든다 . - **레거시 소프트웨어** 등 복잡한 기존 시스템을 이해하고 해독해야 하며, 비즈니스와 기술 구현 사이에서 균형을 이루는 것이 도전 과제임을 인정해야 한다 . ## 2. 💡 대규모 워크숍과 공통 언어 구축을 통한 초기 모델링 단계의 실제 -  - - 대규모 워크숍을 통해 20~30명의 다양한 이해관계자들과 함께 비즈니스 흐름 전체를 **모델링**하여 도메인별 상충되는 지식과 비일관성을 시각화한다 . - 워크숍에서는 각 결정 지점과 그에 필요한 **정보**를 분석하며, 이를 통해 이해관계자들이 참고하는 데이터 출처와 관점을 비교하여 숨겨진 불일치와 문제를 발견한다 . - **Corner case(예외적 상황)**에 대해서 실제로 액션을 실험해 보면, 남아 있는 불확실성이 드러나며, 경우에 따라서는 자동화 대신 사람이 결정을 내릴 수 있도록 시스템을 설계한다 . - 워크숍이후에는 **컨텍스트 맵**을 만들고, 조직 내 독립적인 모델 및 그 관계를 시각화하여 추가 논의에 참고 자료로 활용한다 . - 도메인 지식을 단순 용어집을 넘어서 **유비쿼터스 언어**와 서사로 정제하여, 프로토타이핑과 개선을 반복하면서 견고하고 실제로 도움이 되는 소프트웨어를 출시한다 . - 모델링을 통해 개발자는 비즈니스 도메인을 고도의 정밀도로 이해하게 되나, 여전히 비즈니스와 기술 간 **언어적 불일치** 문제는 지속적으로 발생함을 인지해야 한다 . ## 3. 🛠️ 다양한 모델링 도구와 문서화, 그리고 효과적 커뮤니케이션의 과제 -  - - **문서화****(documentation), 검증(validation), 비즈니스 규칙**과 같은 용어는 매우 모호하게 쓰이며, 모두가 같은 의미로 이해한다고 착각하기 쉽다 . - **문서화**** 도구**나 시각화 도구는, 사용자(누가)와 프로젝트의 성숙도 수준(언제)에 따라 쓰임새와 가치가 달라지므로 그 목적과 맥락을 분명히 해야 한다 . - **Event Storming**같은 협업 모델링 툴은 워크숍내에서는 강력하지만, 실제로 거기 있지 않은 사람에게는 단순한 포스트잇으로 인식되어 정보 가치가 크게 떨어진다 . - **아키텍처 결정**** 기록(Architectural Decision Records)**과 **컨텍스트 맵****(context map)**은 프로젝트 전반에 걸쳐 장기간 참고할 가치가 높은 산출물이다 . - 대화의 목적(정보 제공, 허가 요청, 조언 구하기 등)이나, **문서의 타겟 독자**가 명확하지 않으면 의사소통방식이나 도구 선정이 엉켜 오해를 낳을 수 있다 . - 같은 도구(다이어그램 등)를 다양한 배경의 사람들에게 반복 사용하면 서로 다르게 해석하는 혼란이 발생하며, **의사소통****의 환상**만 남는 결과가 초래된다 . ## 4. 🎲 의사결정과 설득, 그리고 효과적인 커뮤니케이션 전략 -  - - 도메인 설계 관련 논의는 다의적이고 불명확하며, 애초에 잘못된 방향에서 시작되는 경우가 많다 . - 기술적 의사결정 책임이 있음에도 상사의 승인을 필요로 하는 경우가 있으며, 기술자가 **자율적으로 결정**할 수 있는 자유가 더 요구된다 . - Delegation Poker는 **위임**** 수준**을 7단계로 정리하여, 책임과 결정 권한의 스펙트럼을 명확하게 프레임화하는 데 효과적이다 . - 모든 의사결정에 동일한 위임수준이 적용될 수 없으므로, 상황에 따라 **미세 조정**이 필요하다 . - 타인을 설득할 때 많은 근거나 이유를 제시할수록 설득력이 오히려 떨어지며, 상대의 **핵심 동기와 가치**를 파악해 하나의 강력한 논거만 제시하는 것이 효과적이다 . - 설득메시지는 UML이나 EventStorming 같은 도구가 아니라, 상대의 사고와 언어 방식에 맞는 스토리, 그림 등 맞춤적 형식으로 전달해야 한다 . - 의사소통목표가 바뀌면, 전달 방식과 미디어도 바뀌어야 하며, 결국 "재사용"보다 맥락에 맞는 **맞춤형 커뮤니케이션**이 중요하다 . - 실제 현실은 단순한 **3가지 bullet point**가 아니라, 복잡한 인과관계와 피드백 루프가 있는 구조임을 인식해야 한다 . ### 4.1. ️ 모호함과 책임 소재의 명확성에 대한 갈망 - 현재 많은 **대화가 모호**하고 제대로 정의되지 않아 처음부터 잘못된 논의가 이루어지는 경우가 많다 [126] - 신뢰 부족이나 상대방의 **확신 부재**로 인해 대화 자체가 불필요하거나 비생산적일 수 있다 [127] - 기술적인 결정이 내 책임이라도 상사의 **승인을 기다리게 되는 경향**이 있으며, 더 자유롭고 독립적으로 결정하고 싶다는 바람이 있다 [128] - **흑백이 명확히 갈리고 책임 경계가 분명한** 환경을 원하며, 결정에 대한 주체성과 명확한 기준이 필요하다 [129] - 대부분의 사람들이 이런 이상적인 책임 구조 속에 있지 않으며, 그런 환경에 있는 사람은 소수에 불과하다 [137] ### 4.2. Delegation Poker를 통한 책임과 위임 수준 정의 - **Delegation Poker**는 Management 3.0에서 나온 도구로, 책임과 위임의 회색지대를 구체적으로 다루는 데 도움을 준다. [138] - 이 도구는 총 **7단계의 ****위임**** 수준**을 정의하며, 두 영역 간의 구체적 상황에서 실질적인 책임이나 위임수준을 설정할 수 있다. [140] - 최저 단계는 "내가 시키는 대로 한다", 중간 단계는 "의견을 묻고 내가 결정"과 "의논하여 함께 합의", 최고 단계는 "모든 결정 위임"과 같이 **다양한 ****위임**** 방식**을 구분한다. [143] - 각 의사결정 상황마다 이 스펙트럼이 똑같이 적용되는 것은 아니며, 실제로는 **세밀한 조정과 맥락에 맞는 적용**이 필요하다. [151] - 자신의 위치와 상황에 따라 적정 위임수준을 정하고, 그에 따라 필요한 **조정점**을 찾는 것이 중요하다. [152] ### 4.3. 기술적 의사결정 설득 과정의 함정과 책임 - **의사결정의 ****위임**** 수준**을 조정하면 모델링 프로세스에서 정책을 미세하게 조율할 수 있다. [153] - 실제 상황에서는 모든 기술적 결정을 스스로 내릴 수 없고, 때로는 상사나 파트너를 설득해야 하는 일이 생긴다. [155] - 기술적 선택에 대해 설득모드로 들어가는 순간, **책임을 상사에게 전가하는 함정**에 빠질 수 있다. [156] - 전문가로서 타당성을 검토한 결정은 스스로 실행해야 하며, 상사의 명백한 허락을 구하는 것은 불필요한 책임 전가로 이어질 수 있다. [157] - 설득이 실패하면 “검토해보겠다”는 답변 등으로 사실상 **실행이 무산되는 결과**를 맞게 되므로, 이러한 대화를 **함정**으로 인식하고 피해야 한다. [158] ### 4.4. 효과적인 설득과 사고 오류 방지 전략 - 아키텍처적 결정 논의에서는 **비판적 사고**가 누락되어 여러 사고의 오류와 잘못된 주장들이 자주 발생한다. [159] - 예산이 이미 소진되었다는 논리, 권위에 기대는 주장, 근거 없는 속도 저하 우려 등 다양한 **논리적 오류(궤변)**가 반복적으로 등장한다. [160] - 설득을 위해 많은 주장을 쏟아내면 상대의 설득가능성이 오히려 낮아진다; 이는 심리학적으로 근거가 있는 사실이다. [168] - 상대방은 열 가지 근거 중 가장 약한 하나를 집고 반론하는 경향이 강하므로, 근거가 많을수록 오히려 **논리적 약점**이 드러나 설득력이 떨어진다. [170] - Adam Grant의 " Think Again"에서는 이러한 **설득**** 과정에서의 사고 오류**와 그 해결 전략이 실질적으로 도움이 될 수 있음을 강조한다. [165] ### 4.5. 상대의 동기와 맥락에 맞춘 효과적인 소통 전략 - 상대방의 **핵심 동기**와 가치를 들어보고 이해하는 것이 설득의 출발점이다 [175] - 한 가지 맞춤형 논거만을 선택해 상대의 동기를 자극하면, 다른 모든 설명은 불필요하다 [178] - 효과적인 설득을 위해 상대의 **사고방식**과 소통 방식에 맞는 메시지 전달 방식(이야기, 이미지, 그림 등)을 채택해야 한다 [179] - 소통의 목적이 바뀌면 **매체, 스타일, 접근법**도 함께 바꿔야 하며, 일률적인 도구(UML 등)는 적합하지 않다 [183] - 실제 현실은 복잡한 **인과관계와 피드백 루프**로 구성되어 있지만, 상황에 따라서는 단순한 요약(예: 세 개의 핵심 포인트)이 요구될 수 있다 [187] ## 5. 🚩 효과적인 의사결정과 변화 촉진을 위한 실질적 전략 -  - - **복잡한 분석이나 시각적 자료**보다 명확하고 간결한 메시지가 효과적이며, 핵심 메시지 전달에 자신감을 가져야 한다 . - **스토리텔링**은 메시지 전달에 가장 강력한 전략이며, 적절한 예시나 상황, 사용자 여정 등을 통해 공감과 반향을 이끌 수 있다 . - **수신자에 맞는 형태(위장)**로 메시지를 포장해야 할 때도 있으며, 비즈니스 관행에 맞는 자료(예: PowerPoint)로 메시지를 전달하면 더 잘 수용될 수 있다 . - 데이터와 대시보드 해석의 불일치, 해석 지연, 해석 계층이 많아질 경우 명확한 결론에 도달하기 어렵고, 신속한 의사결정을 방해한다 . - **도메인 주도 설계를 통한 본질적 복잡성 반영**은 해석의 여지를 줄이고, 더 신뢰할 수 있는 **객관적 데이터**로 신속한 의사결정을 가능하게 한다 . - Toyota의 OAA 등 물리적 의사결정 공간 개념은, 여러 정보를 한 공간에 모아 전략과 실행을 연결하는 중요한 도구로 활용될 수 있다 . - 설득대신 행동으로 실체를 보여주는 것이 변화의 핵심이며, **'이미 실현된 현실처럼 행동하는 것'**이 변화를 촉진할 수 있다 . - 컨텍스트 맵, 프로세스 모델링, 이벤트 스토밍 등 DDD 도구가 **빅 픽처를 시각화**하고 전략적 의사결정의 기반이 될 수 있다 . - 데이터의 신뢰성에 대한 **'디스클레이머'**는 대화의 시작점을 만들고, 적극적인 피드백을 유도하여 점진적 진화를 이끈다 . - KPI 및 성과관리를 위한 공간(게시판이나 온라인 협업도구)의 시각화는 협업 성공의 핵심이며, **'가시성'**이 높을수록 참여와 정보 정리가 용이하다 . - 변화와 습관화는 긴 시간이 걸리며, 인내심과 반복이 필요하고, 도구의 존재만으로는 즉각적인 변화가 어렵다 . - 비즈니스 문서화, 정보 수집 및 공유에는 공개적 채널(예: Slack 등)이 이메일보다 훨씬 효과적이며, 꾸준한 정보 누적이 중요한 참고 자료가 된다 . ### 5.1. 효과적인 메시지 전달을 위한 전략 - 복잡한 분석 결과나 이미지가 아닌, 전달하려는 **핵심 메시지**에 집중해야 효과적으로 전달할 수 있다 [189] - **스토리텔링**이나 사용자 경험, 구체적 사례를 통해 메시지의 공감과 주목도를 높일 수 있다 [193] - 완벽한 예시를 찾기는 어렵지만, 이야기를 활용하는 것이 청중의 **공감과 반응**을 얻는 최선의 방법이다 [194] - 비즈니스 상대가 익숙한 형식(예: **PowerPoint** 등)에 메시지를 담아내는 **위장 전략**도 소통을 원활하게 한다 [196] - 메시지 형식을 청중에게 맞추더라도, 전달해야 할 **불가협상(양보할 수 없는) 본질**은 반드시 지켜야 한다 [199] ### 5.2. 데이터 기반 의사결정의 혼란과 DDD의 의의 - 각기 다른 대시보드를 사용해 **동일한 데이터를 다르게 해석**하면 조직 내 혼란과 **성과 측정의 왜곡**이 발생한다 [202] - 주요 문제는 **동일한 출처의 데이터를 여러 방식으로 바라보는 해석의 차이**와, 각자 관리하는 대시보드의 남용이다 [204] - **공통 데이터와 명확한 설명, 통합 대시보드**를 제공하면 해석 차이를 줄이고 의사결정의 일관성을 높일 수 있다 [208] - DDD는 대시보드상의 **라벨에 더 의미있는 이름**을 부여하고, **공통 언어(ubiquitous language)**로 용어를 명확히 하여 데이터 해석의 신뢰성을 높인다 [209] - DDD 접근법을 경험해보니, **대안이 가진 부정확성과 불일치가 생각 이상으로 심각함**을 깨닫게 되었다 [211] ### 5.3. 풍부한 이벤트 기반 도메인 모델이 비즈니스 의사결정에 미치는 영향 - **빈약한 도메인 모델**을 사용할 경우, 비즈니스 측은 BI 도구나 담당자에게 시스템 현황과 매출 등 복잡한 정보를 개별적으로 요청해야 하며, 이는 데이터 해석의 오류와 지연을 초래한다. [213] - 비즈니스가 원하는 정보는 CRUD(생성, 조회, 갱신, 삭제) 데이터 구조 내부에 존재하지 않고, 예를 들어 특정 예약이 몇 번 전송됐는지, 계약이 몇 번 수정됐는지 등 더 의미 있는 정보를 요구한다. [215] - 해석이 필요한 데이터는 해석의 신뢰도가 낮아지고, 다양한 해석·집계 과정에서 시간 지연이 발생할 수 있으며, 이런 구조는 비즈니스 의사결정 지연으로 이어진다. [217] - 하지만 **풍부한 이벤트 기반 도메인 모델**을 적용하면 해석이 필요 없는 명확한 데이터(=비즈니스의 본질에 가까운 정보)를 바로 활용할 수 있어, 의사결정이 신속하고 정확해진다. [218] - 개발자 입장에서는 이런 모델의 효과가 바로 눈에 띄지 않을 수 있으나, 실제로는 비즈니스의 효율성에 **지대한** 영향을 미치며, 의사결정 구조와 속도를 크게 변화시킨다. [220] ### 5.4. OAA(Obeya)와 리미널 씽킹을 통한 의사결정 혁신 - 조직 내에서 **정보의 오해·권력다툼·왜곡된 데이터 해석** 등으로 인해 동일한 결론에 도달하기 어렵다 [224] - 이러한 문제를 개선하기 위해서는, 토요타의 OAA(Obeya)처럼 전략과 실행 관련 모든 **중요 정보를 한 곳에 모아두는 공간**이 효과적이다 [227] - 시각적인 자료와 **데이터 기반 의사결정**, 그리고 물리적 혹은 디지털 메모(스티키 노트) 활용이 도움이 될 수 있다 [229] - 하지만 대부분의 조직에서는 제조업 환경이 아니라는 이유 등으로 이러한 접근에 **저항감을 보이거나 불가능하다고 여기는 경우가 많다** [230] - 리미널 씽킹은 ‘존재하는 것’과 ‘가능한 것’ 사이, 그리고 **복잡과 복잡하지 않은 영역의 경계**에서 변화를 주도하는 사고법이며, 현실을 바꾸는 첫걸음은 '이미 원하는 현실이 실현된 것처럼 행동'하는 것에서 시작된다 [233] ### 5.5. ️ 실질적인 변화 주도를 위한 구체적 접근 및 도구 활용 - **가시적인 예시**를 만들어 변화를 시도할 때, 꿈을 보여주기보다는 실질적으로 동작하는 예시를 제시하는 것이 더 효과적이다. [236] - DDD에서 얻은 주요 도구들은 **컨텍스트 맵**, **프로세스 모델링**, **이벤트 스토밍** 등이 있으며, 이는 중요한 의사결정 공간을 구축하는 훌륭한 출발점이 될 수 있다. [239] - 컨텍스트 맵과 프로세스 모델링을 결합하면 **OBA**와 같은 도구가 탄생하지만, 이는 단지 시작점일 뿐 더 많은 요소가 필요하다. [241] - 모든 사람이 분산되어 있는 경우, **Miro** 같은 협업 툴을 활용하는 것이 효과적인 방법이 될 수 있다. [243] - 실천의 첫 번째 **핵심 재료**는 **disclaimer(면책 조항)**이며, 자신의 이해가 맞지 않을 수 있음을 명확하게 밝혀 타인의 교정과 협업을 유도하는 것이 중요하다. [244] - 이러한 접근법을 사용하면 많은 동료를 얻거나, 상대방이 당신을 바로잡아 주는 반응을 경험하게 된다. [246] ### 5.6. ️ 데이터 가시화 도구와 변화 촉진의 실제 적용 및 인내의 중요성 - 완벽한 시작을 기대하지 말고, 먼저 **가시화**를 시도하면 피드백이 생기고 점차 정보를 정제해나갈 수 있다. [248] - 협업을 위해서는 KPI나 OKR 등 **성과 관리**의 범위와 동일한 범위를 갖는 가시화 공간이 필요하며, 이를 통해 사람들과 협업이 효율적으로 이루어진다. [256] - 전략적 의사결정이나 복잡한 도메인 탐색에도 같은 형식의 모델링·도구가 활용될 수 있으며, 중요한 것은 **대화가 가능한 공간**을 마련하는 것이다. [260] - 대화와 정보 공유를 시작할 때는 완벽함을 요구하지 말고, **가시성을 우선**하며 시간이 지남에 따라 점진적으로 참여자가 늘어난다. [263] - 변화는 한 번에 일어나지 않고, **인내심을 가지고 꾸준히** 자신의 모델을 활용하고 노출시키며, 피드백과 점진적 정착을 기대해야 한다. [271] - 물리적 공간에서는 눈에 띄게, 디지털 환경에서는 Slack 등 **시각적 노출과 채널 활용**을 통해 문서나 모델이 무시받지 않도록 해야 한다. [311] - 이메일은 **가시성이 낮아** 효과가 떨어지며, 보다 공개적이고 접근성이 높은 채널을 우선적으로 활용하는 것이 좋다. [307] - **주도적으로 툴을 사용**하고 회의 중 화면을 공유하는 등의 방식으로, 반복적으로 노출시켜 영향력이 서서히 확장되도록 해야 한다. [270] |
| Code Block | ||
|---|---|---|
| ||
## 1. DDD 실무자가 마주하는 현실적인 어려움 ,
| **문제점** | **설명** | **영향** |
| --- | --- | --- |
| 언어적 불일치 | 워크숍 후에도 비즈니스와 기술 담당자 간의 전문 용어 차이 발생 | 오해 발생 |
| 문서화 문제 | 문서의 내용, 목적, 대상이 불명확함 | 효과적인 소통 어려움 |
- 도메인 주도 설계(DDD) 실무자는 워크숍을 성공적으로 마친 후에도 여러 **어려움**에 부딪히게 돼요.
- 특히, 비즈니스 담당자와 기술 담당자 사이에 여전히 **언어적인 불일치**가 생기곤 합니다.
- 워크숍에서 **공통 언어**를 만들었음에도 불구하고, 비즈니스만의 전문 용어나 기술만의 전문 용어가 따로 쓰여서 오해가 생길 수 있어요.
- 어떤 내용을, 왜, 그리고 누가 볼 것인지가 명확하지 않은 **문서화**** 문제**도 큰 걸림돌이 될 수 있습니다.
- 결국 이런 문제들 때문에 비즈니스와 기술 전문가 간의 **효과적인 소통**이 어려워집니다.
## 2. 효과적인 문서화 및 도구 활용 전략
- 문서화를 할 때는 **무엇을 위한 문서인지** 목적을 분명히 해야 해요.
- 프로젝트가 얼마나 진행되었는지, 즉 **프로젝트의 성숙도**에 따라 적절한 도구를 선택하는 것이 중요합니다.
- 예를 들어, 프로젝트 초반에는 **Event Storming** 같은 도구가 다양한 관계자의 참여와 탐색에 유용하지만, 유지보수 단계에서는 큰 도움이 되지 않을 수 있습니다.
- Event Storming처럼 협업 모델링 도구는 **워크숍**** 참여자에게는 매우 유용**하지만, 참여하지 않은 사람에게는 단순한 포스트잇처럼 보일 수 있어요.
- 반면에 **Architecture Decision Records(ADR)** 같은 문서는 프로젝트 전반에 걸쳐 유용하게 사용될 수 있는 **긴 수명**을 가집니다.
- **Ubiquitous Language**는 프로젝트 초기부터 만들어나가기 시작해서 **지속적으로 관리**하고 대화에 활용하려는 노력이 필요합니다.
## 3. 비즈니스와 기술 간의 소통 방식 개선 ,
- 비즈니스와 기술 분야 전문가 사이의 **대화 목적을 명확히** 하는 것이 소통의 첫걸음이에요.
- 상대방에게 정보를 제공하는 것인지, 허락을 구하는 것인지, 아니면 단순히 조언을 얻으려는 것인지 등 **대화의 목적**에 따라 **소통 방식**을 달리해야 합니다.
- 기술 전문가가 비즈니스 용어를 이해하기 어려운 것처럼, 비즈니스 담당자도 기술 용어를 이해하기 어려워 **언어 불일치 문제**는 계속 발생할 수 있어요.
- 따라서 **다양한 소통 방식**을 준비하고 상황에 맞게 사용하는 것이 중요합니다.
- 똑같은 다이어그램이나 문서를 모든 상황에 재사용하려는 생각은 **오해를 불러일으킬 수 있어요.**
## 4. 의사결정 과정에서의 위임 수준 정의 및 활용 ,
- 기술적인 결정에 대한 **책임 범위**가 모호할 때가 많아요.
- 이럴 때 Management 3.0의 **Delegation Poker**라는 도구가 유용할 수 있습니다.
- 이 도구는 **의사결정의 ****위임**** 수준을 7단계**로 나누어 보여줍니다.
- 가장 낮은 단계는 "내가 시키는 대로 해(Tell)"이고, 가장 높은 단계는 "너에게 전적으로 맡길게(Delegate)"입니다.
- 이 단계를 통해 누가 어떤 결정에 대해 **얼마나 책임**을 지고 **얼마나 권한**을 가질지 명확히 할 수 있습니다.
- 모든 결정에 똑같은 위임수준을 적용할 수는 없지만, 각 상황에 맞는 **적절한 수준을 조절**하는 데 도움을 줍니다.
## 5. 설득보다는 전문성에 기반한 결정의 중요성 ,
- 기술 전문가는 자신의 **전문적인 지식**을 바탕으로 **기술적인 결정**을 내려야 합니다.
- 이는 마치 "내가 아는 내 일이니까, 내가 결정하겠다"고 말할 수 있는 **자신감과 책임감**을 갖는 것과 같아요.
- 상사나 다른 사람을 **설득****하려 하는 것**은 때로 **비효율적인 함정**이 될 수 있습니다.
- 기술에 대해 잘 모르는 사람에게 어려운 내용을 설명하고 설득하는 과정에서 **오히려 신뢰를 잃거나 시간만 낭비**할 수 있기 때문이에요.
- 진정한 전문가는 자신의 판단에 확신을 가지고 **불필요한 ****설득**** 과정을 피하며** 올바른 결정을 내릴 수 있어야 합니다.
## 6. 효과적인 소통을 위한 메시지 전달 전략 ,
- 누군가를 설득할 때 **너무 많은 이유를 나열하는 것**은 오히려 역효과를 낼 수 있습니다.
- 사람들은 가장 약한 주장에 집중하는 경향이 있어, 많은 이유를 댈수록 **메시지가 약해 보일 수** 있어요.
- 핵심은 상대방이 **무엇을 중요하게 생각하는지** 그들의 **동기**를 먼저 **이해**하는 것입니다.
- 그리고 상대방의 동기에 맞는 **단 하나의 강력한 주장을 선택**하여 전달하는 것이 효과적입니다.
- 메시지를 전달할 때는 **상대방에게 익숙한 방식**을 사용하는 것이 좋습니다.
- 어려운 전문 다이어그램보다는 **스토리텔링, 그림, 간단한 비유** 등을 활용하는 것이 더 잘 전달될 수 있어요.
## 7. 데이터 기반 의사결정의 중요성과 DDD의 역할
- 데이터를 해석하는 데 문제가 있거나 의사결정이 느려지는 것은 **소프트웨어 모델의 문제**에서 비롯될 수 있습니다.
- 단순히 데이터를 저장하고 보여주는 **Anemic Domain Model**로는 복잡한 비즈니스 상황을 제대로 이해하기 어렵습니다.
- 이런 모델에서는 비즈니스 담당자가 원하는 의미 있는 정보(예: 예약이 몇 번 변경되었는지)를 얻기 위해 **복잡한 데이터 해석 과정**을 거쳐야 합니다.
- 결과적으로 **데이터 해석에 대한 논쟁**이 벌어지고, **의사결정이 몇 달씩 지연**되는 상황이 발생할 수 있어요.
- 반면, **Rich Event-Driven Domain Model**은 비즈니스의 복잡한 과정을 **모델 자체에 담아냅니다.**
- 이를 통해 **데이터를 해석하는 과정**이 줄어들고, **의심의 여지가 없는 데이터**를 **빠르게** 얻을 수 있어 **훨씬 나은 의사결정**이 가능해집니다.
## 8. 가시적인 정보 공유 공간 구축의 필요성
- 의사결정에 필요한 모든 정보를 **한곳에 모아 눈으로 볼 수 있게** 하는 공간이 중요해요.
- 토요타의 **OBA(Obeya)**처럼, 회의실에 관련 정보를 모두 붙여놓고 함께 보면서 논의하는 방식입니다.
- 하지만 원격 근무 환경이나 문화적인 이유로 이런 물리적인 공간을 만들기 어려울 수 있어요.
- DDD 실무에서 사용하는 **컨텍스트 맵****이나 ****프로세스 모델링** 같은 도구를 활용하여 **디지털 OBA**를 구축하는 것을 시도해 볼 수 있습니다.
- 가시화된 정보 공간은 **"내 이해가 맞는지 봐주세요, 틀렸다면 고쳐주세요"**라고 말하는 것과 같아서, 다른 사람들의 **피드백과 기여**를 이끌어낼 수 있습니다.
## 9. 변화를 이끌어내는 실천적인 자세 ,
| **주제** | **핵심 아이디어** | **실천 전략** | **필요한 자세** |
| --- | --- | --- | --- |
| 변화를 이끌어내는 실천적인 자세 | 완벽함보다 시작이 중요하며, 허락보다 시도가 효과적이다. | • 작게 시도하고 결과 보여주기 • 회의에서 정보 시각화 자료 공유 및 참조 | • 인내심 • 포기하지 않는 자세 |
- 완벽하게 준비될 때까지 기다리기보다는 **일단 시작하는 것**이 중요합니다.
- 특히 허락을 받기 어렵다면, **먼저 작게 시도**하고 **결과를 눈으로 보여주는 것**이 효과적입니다. ,
- 예를 들어, 회의에서 필요할 때 **자신이 만든 정보 시각화 자료**를 공유하고 **참조**하는 식으로 시작할 수 있어요.
- 처음에는 아무도 신경 쓰지 않을 수 있지만, **꾸준히 시도**하고 **가시화**를 멈추지 않으면 **변화가 시작될 수** 있습니다. ,
- 이 과정에는 **인내심**이 필요하며, 바로 눈에 보이는 결과가 없더라도 **포기하지 않는 자세**가 중요합니다.
|