원문 기사는 여기

대부분의 회사에서는 결정을 내리기 위해 회의를 합니다. Alan에서는 온라인 포럼에서 “issue"라고 하는 서면 대화를 엽니다. 이러한 대화는 투명성, 비동기성 및 글쓰기 문화의 초석입니다. 이 포럼의 대화 메커니즘을 마스터하는 것은 모든 Alaner에게 핵심입니다. 그들이 어떻게 하는지 알아보세요.

소개

#

모두가 회의를 싫어합니다

#

아무도 준비하지 않고, 늦게 시작하며, 목소리가 큰 사람이 옳든 그르든 항상 마지막 말을 합니다. 한 시간 후, 당신의 마음은 회의실에 들어가기 전보다 더 혼란스럽고 파라세타몰이 남아 있는지 궁금해합니다. 하지만 당신은 익숙합니다. 결국 회의병은 자존심 있는 회사의 상표이지 않습니까?

그들이 다르게 할 수 있다고 말한다면 어떨까요? Alan에서는 회의의 한계와 위험을 매우 일찍 감지했습니다. 회의는 짧게 (15분 이내), 잘 조직되고 (명확한 안건) 따라서 결정을 생성하도록 설계되었습니다. 문제는 그들이 자주 벗어났다는 것입니다 - 토론을 제어하기가 어렵습니다. 결과적으로, 그들은 종종 실망했고, 무엇이 말해졌는지 기억하는 데 어려움을 겪었으며, 부재하거나 먼 거리에 있는 사람들과는 복잡했습니다.

그래서 그들은 전통적으로 구두로 했던 것을… 서면으로 옮기기로 결정했습니다!

결과: 더 나은 결정을 내립니다. 왜냐하면 쓰기는 우리에게 성찰할 시간을 주기 때문입니다. 토론은 더 미묘하고, 더 잘 문서화되고, 논증됩니다. 요컨대, 더 이상 웅변 대회가 아닙니다. 그리고 케이크 위의 아이싱은 회의를 서면 내부 포럼으로 대체하면 모든 사람의 자율성이 증가한다는 것입니다: 정보를 공개함으로써 토론에 기여할 가능성이 증가하고 협업이 더 쉬워졌습니다.

방법을 알고 싶으십니까? 모두 설명합니다.

1. 플랫폼을 온라인 포럼으로 전환하기

#

이제 문제를 해결하기 위해, 주제를 깊이 있게 다루기 위해, 솔루션을 검증하기 위해 팀의 지능이 필요할 때, 회의를 예약하는 대신 온라인 포럼에서 대화(또는 “issue”)를 엽니다. 이 포럼은 “Github"이라는 플랫폼에서 호스팅됩니다.

Github이란 무엇입니까?

#

처음에는 웹 개발자를 위해 설계된 협업 플랫폼입니다. 아이디어는 그들이 만드는 코드에 대한 피드백을 공유하고 중앙 집중화하는 것입니다.

그들은 소셜 플랫폼과 구조화된 피드백 관리 사이의 절충안이 흥미롭다고 생각했고, Alan의 모든 의사 결정 대화를 호스팅하기 위해 그 사용을 전환하기로 결정했습니다.

구체적으로 어떻게 이루어졌습니까?

1. Github에 계정을 만들었습니다.
2. 가짜 “코드” 디렉토리를 만들고 “비공개"로 만들었습니다 (Alan에서는 “Topics"라고 명명했습니다😇)
3. 각 대화 주제를 더 쉽게 구별하기 위한 라벨링 시스템을 만들었습니다.
4. 디렉토리의 “Issues” 탭으로 이동하여 모든 현재 “열린” 토론과 결정된 “닫힌” 것들을 찾습니다.

💡이제 17,000개의 issue 마크를 넘었습니다. 즉, 빛을 보지 못한 많은 회의와 절약된 많은 시간입니다! 이 지식의 역사는 귀중합니다: 각 결정의 세부 사항을 이해하기 위해 Github에서 조금만 검색하면 됩니다. 그리고 그것에 의문을 제기하고 싶다면, 과거에 어떤 논쟁이 이겼는지 이미 알고 있습니다.

2. 규칙 정의: 언제 “issue"를 여나요?

#

“토론을 열거나 열지 않거나, 그것이 문제입니다.” 효율성을 위해, 모든 결정이 체계적으로 issue를 여는 것을 정당화하는 것은 아니라는 것을 알고 있습니다. 일부는 며칠 안에 해결될 수 있지만 다른 것은 일주일 이상 걸릴 수 있습니다… 따라서 더 나은 결정을 더 빨리 내리기 위해 그들은 시스템을 개발했습니다.

올바른 질문을 하기

#

• 결정에 의해 누가 영향을 받습니까?
• 결정은 얼마나 가역적입니까?
• 이것은 긴급하게 결정해야 하는 것입니까?
• 결정하기 위해 더 많은 컨텍스트가 필요합니까?

영향 정도 결정

#

일반적으로 결정의 영향 정도와 가역성 정도가 중요하다고 간주될 때 issue가 열립니다. 간단히 말해서, Slack보다 포럼에서 토론을 선호하는 경우는 다음과 같습니다:

주요 연락처

#

그들은 LOCI(Lead, Owner, Consulted, Informed) 모델을 사용하여 각 토론에서 책임과 대화자의 분배를 균형 있게 명확히 합니다.

Lead

#

설명

#

Lead는 결정의 성공에 책임이 있습니다. 그/그녀는 각 결정 뒤의 컨텍스트가 팀 내에서 올바르게 이해되고 배포되도록 보장합니다.

특징

#

토론 초반에, Owner가 중재할 수 있도록 모든 카드를 손에 쥐기 위해 얼마나 결정에 관여하고 싶은지 명시합니다.

임무

#

Lead가 최종 의사 결정자(Owner)가 아닌 경우, 그/그녀는 다음을 해야 합니다:

➡️ 고려 중인 결정에 동의하는지 확인합니다. ➡️ “Owner"를 신뢰하고 팀이 생산한 것에 대한 책임을 받아들입니다. ➡️ 강한 불일치가 있을 때 의견을 표현합니다.

배분

#

토론당 한 명의 “Lead"만 있어야 합니다.

Owner

#

설명

#

Owner는 최종 결정에 책임이 있으며 설정된 목표를 달성하기 위해 프로젝트를 주도합니다.

특징

#

그/그녀가 해결할 수 없는 문제를 만나면 Lead에게 참조해야 합니다.

임무

#

지휘자로서, 그/그녀는 다음을 해야 합니다:

➡️ 각 기여자가 토론에 대해 알림을 받았는지 확인합니다(그리고 적시에 기여합니다) ➡️ 문제를 조사하고, 답변을 수집하고, 프로젝트를 후속 조치합니다. ➡️ 토론을 열고 닫습니다. 최종 결정을 내리고 공유합니다.

배분

#

각 결정에 한 명만 책임이 있는 것이 좋습니다.

Consulted

#

설명

#

“consulted” Alaner는 의사 결정 과정에서 의견이 중요한 사람들입니다. 그들의 의견은 가능한 최선의 절충안을 만드는 데 필수적이라고 간주됩니다.

특징

#

그들은 의사 결정자(Owner)에게 통제권을 넘깁니다. 강한 불일치의 경우, 그들은 경보를 울려야 하며, 최악의 경우 Lead에게 정보를 에스컬레이션해야 합니다.

임무

#

토론에 적극적으로 기여하는 사람으로서, 토론에 추가할 것이 없음을 확인하는 것뿐이더라도 적시에 기여할 의무가 있습니다.

배분

#

토론당 6명 이상의 Alaner “consulted"를 알리는 것을 피하는 것이 좋습니다. 그들의 의견은 중요하지만, 이로 인해 일정이 지연될 수 있습니다.

Informed

#

설명

#

이들은 종종 결정이 내려진 후 진행 상황에 대해 알림을 받는 Alaner입니다.

특징

#

이러한 Alaner와의 커뮤니케이션은 일방향입니다.

임무

#

“informed” Alaner로서, 그들로부터의 기여는 기대되지 않습니다.

배분

#

의사 결정자는 결정의 잠재적 영향을 고려하고 영향을 받는 Alaner에게 그에 따라 알려야 합니다.

유용한 정의

#

좋아요, 그러나 그들은 이 중요성의 임계값을 어떻게 평가합니까? Alan은 두 가지 유형의 결정을 구별합니다:

• 일방향 결정(역전이 어려움)
  • 이것은 역전하기 위해 너무 많은 노력이나 상당한 비용이 필요한 결정입니다.
  • 예: 상향 조정된 요금 업데이트(이미 하향 조정했지만)
• 양방향 결정(쉽게 가역적)
  • 이것은 언뜻 보기에 너무 많은 위험을 수반하지 않는 결정입니다. 예상치 못한 사건은 에너지 손실을 초래할 수 있지만 이는 허용됩니다.

“문제 해결” 접근 방식 채택

#

프로젝트나 토론을 프레임화하는 것은 더 나은 결정을 내리는 데 도움이 됩니다.

프레임워크는 작업 도구이며 사고를 금지하지 않습니다. 오히려 그것들은 우리가 관점을 구조화하고 명확히 하도록 합니다.

문제나 결정에 대한 생각을 가능한 한 효과적으로 전달하는 데 도움이 되도록 각 issue는 동일한 템플릿을 제공합니다. 이 구조는 주니어 사람들에게 문제를 분해하는 방법을 가르치면서 한 단계 더 나아갈 수 있게 합니다.

issue의 전형적인 아키텍처

#

• “Scope” - 범위를 정의하고 토론의 “이유"를 명확히 합니다
  • “이 결과의 목적은…”
  • “이 issue는…에 관한 것이 아닙니다”
• “Context & materials” - 컨텍스트와 유용한 리소스를 제공합니다
  • 컨텍스트를 제공하는 토론이나 문서에 대한 링크를 추가합니다.
• “LOCI” - 책임과 연락처 배분을 명확히 합니다
  • Lead
  • Owner
  • Consulted
  • Informed
• 마감일 설정
  • 여기서 기대치를 공유합니다: 기여 마감일, issue를 닫는 날짜, 솔루션을 찾아야 하는 날짜.
• 솔루션 제안 공유
  • 여기서 문제에 대한 잠재적 솔루션을 설명하거나 선택할 수 있는 몇 가지 솔루션을 제안합니다.
• 질문 다루기
  • 충분한 정보에 입각한 결정을 내리는 데 도움이 될 의견과 참여를 가진 모든 사람이 참여하도록 초대됩니다. 토론을 올바른 방향으로 유지하기 위해 토론 리더는 주요 기여자에게 특정 질문을 하여 가정을 확인하거나 반박합니다 - 그리고 바다에 병을 던지는 것을 피합니다.

    

서면으로 자기주장하기

#

결정을 둘러싼 논쟁이 질질 끌리는 것을 방지하기 위해, 그들은 토론을 본질에 집중시키기 위해 몇 가지 규칙을 채택합니다.

더 효과적으로 쓰기

#

• 간결하고 명확하게
  • 그들은 유용한 글쓰기를 믿습니다: “잘 생각된 것은 명확하게 진술된다"고 Boileau가 말했습니다. 간단한 방법으로 무언가를 적을 수 없다면, 그것은 진술의 정확성을 확신하지 못한다는 것을 의미합니다.
• “So what?” 테스트를 적용합니다.
  • 무언가를 쓸 때마다, 그들은 그것을 다시 읽고 자신에게 “So what?“이라고 묻습니다. 이것은 메시지의 의미나 논쟁을 더 잘 이해하는 데 도움이 됩니다. 답이 명백하다면, 잠재적인 질문에 더 명확하게 답하는 데 도움이 됩니다.

후속 조치

#

• “Million Dollar Question"에 집중
  • 많은 다른 의견을 수집하는 것은 혼란스러울 수 있으며, 가장 중요한 문제나 고착점에 집중하는 것은 우선순위에 집중하고 세부 사항의 바다에서 길을 잃지 않고 동료의 기여를 재집중하는 데 도움이 됩니다.
• 정기적으로 합의 사항 요약
  • 집단적으로 합의된 것과 여전히 논의해야 할 것을 명확히 하는 것은 Github 대화의 owner에게 일반적인 관행입니다. 그것은 동료에게 기여 라인을 더 잘 보이게 하는 방법이며, 또한 우선순위가 낮은 문제에 대한 집중된 왕복을 피하는 방법입니다 - 대화의 목표는 항상 따라야 할 북극성이어야 합니다.
• 최후의 수단으로 Slack에서 재시작
  • 그들은 Slack에서 리마인더 수를 제한합니다. 두 가지 예외: 기여가 늦어질 때 또는 긴급성이 빠른 조치를 요구할 때. 일정이 존중되도록 하기 위해, owner가 충분한 정보에 입각한 결정을 내리기 위해 관점을 비교해야 할 때 Slack에서 리마인더를 사용할 수 있습니다.

    

관련 없는 댓글 숨기기

#

• 일부 스레드에는 많은 댓글이 있을 수 있습니다. owner로서, 대화를 진전시키는 기여만 유지하는 것이 도움이 될 수 있습니다.

형식 마스터하기

#

• 서면으로 관점을 전달하는 것에 관해서는, 내용이 형식만큼 중요합니다. Github 포럼을 최대한 활용하는 방법은 다음과 같습니다.
  • 키보드 단축키
    • 시간을 절약하기 위해 Github 키보드 단축키의 전체 목록은 다음과 같습니다.
  • 페이지 레이아웃
    • 제목(H1, H2, H3), 각주 또는 테이블을 추가하여 아이디어에 본문을 제공하는 것이 Github에서 가능합니다. 지침의 전체 목록은 다음과 같습니다.

함정 피하기: 비동기적으로 결정하기

#

issue 시스템을 사용하면 누구나 모든 토론에 참여할 수 있습니다. 속삭임, 비밀, 정치가 없습니다: 모두가 같은 정보를 가지고 있습니다 - 그러나 실망을 피하기 위해 염두에 두어야 할 특정 전제 조건이 있습니다.

합의 의사 결정 피하기

#

Alan에서는 포럼에서 논의되는 모든 결정에는 “계몽된 전제군주"로 결정할 책임이 있는 단일 지정된 “owner"가 있습니다.

그녀의 역할은 합의를 추구하지 않고 정치 없이 회사를 위해 가능한 최선의 결정을 내리는 것입니다. 이를 위해, 그녀는 혁신적인 아이디어를 조사하고, 위험을 측정하고, 데이터를 분석하고, 동료에게 질문해야 하지만, 말한 모든 것을 구현할 필요는 없습니다.

회사에서 의사 결정은 합의적이지 않으며, 그들은 “민주주의"가 아닙니다. 모두가 주주이므로 Alan의 소유자입니다. 각 Alaner는 팀이나 개인의 이익보다 회사의 이익을 우선시합니다. 그러나 그들은 고립되고, 성급하거나, 정보에 입각하지 않은 의사 결정도 원하지 않습니다.

결정의 owner가 올바른 베팅을 하는 것에 합리적으로 확신할 때, 그는 결정하고 그들은 시도합니다. 나중에 영향이 더 명확해지기 시작하면, 그들은 그들이 내린 결정을 되돌아보고 미래에 더 잘할 수 있는 방법을 봅니다.

기여자 수 제한

#

효과적인 결정은 주요 기여자의 견해로 제한되는 것입니다. Jeff Bezos의 “두 개의 피자 또는 아무것도 없음” 규칙을 아십니까? 그의 아이디어는 잘 알려진 사실에 기반합니다: 회의에 사람이 너무 많으면 비효율적입니다. 비동기 의사 결정은 이 규칙의 예외가 아닙니다: 일반적으로 사람이 많을수록 그들의 기여는 적습니다. 멀리서, 일반적인 참여를 억제하는 이 “방관자 효과"는 issue에 대한 기여자 수가 통제되지 않을 때(6명을 초과하면 복잡해집니다) 참여의 질을 변경하는 경향이 있습니다.

점진적 알림 접근 방식 채택

#

노이즈를 생성함으로써 알림은 중요한 것과 사소한 것을 식별하기 어렵게 만듭니다. 그래서 그들은 Alan에서 점진적 알림 규칙을 적용합니다: 그들은 서로를 신뢰합니다. 그들은 모든 Alaner가 알림을 받기 위해 Github 계정을 올바르게 설정했다고 가정합니다. 따라서 그들은 각 issue의 “Questions” 섹션에서 사람들의 태그 수를 제한합니다.

알림을 받기 위해 계정 설정

#

• “Settings” 페이지로 이동
• “Participating” 및 “Watching” 섹션에서 “Web and and Mobile” 상자를 확인

마지막 말

#

최선의 의지가 있더라도, 거기에 없었던 사람에게 회의에서 일어난 모든 것을 설명하기는 어렵습니다. 그러나 팀의 모든 사람이 결정과 관련될 수 있습니다.

분명히, 포럼을 통한 의사 결정 시스템은 이 문제를 해결하기 위한 최선이나 유일한 가능한 솔루션이 아닙니다: 그것은 단순히 다음 이유로 우리와 가장 닮은 것입니다:

• 그들은 중단을 제한합니다: 부적절한 회의와 관련 알림의 홍수에 작별을 고합니다.
• 그들은 방관자 효과를 줄입니다: 억제된 참여와 출석주의에 작별을 고합니다.
• 그들은 결정의 질을 향상시킵니다: 한 걸음 물러서서 사실적이 되는 것을 환영합니다.

제안 템플릿

#

Scope

#

• 이 issue의 목표는…
• 이 issue는…에 관한 것이 아닙니다

왜 나는 이 issue를 여는가

#

타임라인

#

컨텍스트 및 자료

#

제안

#

질문?

#