2021 03 / OKKYCON 2021

 

 

1. 커뮤니케이션

나도 나를 모르고 나는 스스로를 모를 상대도 모르고 내가 무슨 생각을 어떻게 하는지도 모르겠고 글로 말로 표현하기도 어렵고 그런데 어떻게 커뮤니케이션을 하면서 일을 하느냐?

사실과 짐작을 분리한다.

내가 도달한 생각을, 생각하기까지의 경로를 함께 전달한다.

컨텐츠는 항상 한군데로 모은다. (<-> 메세지/컨텐츠의 파편화)

왜 계획은 작은 단위로 짜는 것이 좋은가? 계획 수정에 용이

 

 

 

2. 협력의 조건

왜 협력하나? 혼자 해결할 수 없는 큰 문제를 해결하기 위해

협력? 공동의 목표 수행

일할때 체계가 있는데 어느 단계(context)에서 협력하는게 유리한가? 

1. 일이 어려운complicated것이(어떻게 할지 알지만) 아닌, 일이 복잡할complex 때 (모호하고 변동성이 높은)
2. 전문적(기술적 부분이 숙련, 숙달되는)인 해법을 필요로 할 때 보다 산발적(연습게임대로 게임이 항상 흘러가지 않음)인 해법이 필요할 때
3. 직업 절차와 공정을 명확히 나누기 어려울 때 (공장vs전투)

항상 협력이 정답은 아니며 문제가 발생했을 때 잘 파악하여 알맞은 방법으로 처리해야함

협력이 잘 이루어지는 조건

1. *심리적 안정: 조직 내에서 위험을 감수하거나 취약점을 드러내도 안전하다고 느낄 때

ex. (회의하다가) 이런얘기 해도 괜찮나? 해도 될까? 

방법

- 비폭력대화: 연민의 본성으로 나를 먼저 이해하고 타인과 유대

- 퍼실리테이션

2. 일의 의미 이해

- Output, Outcome, Impact: 산출물. 이러한 결과를 통한 영향력

3. 피드백

- 내가 한 행위에 따른 결과가 의도에 부합하는지 확인

- 더 중요한 정보를 더 빨리, 자주 받아야함

4. 투명성: 정보 공유 / 커뮤니케이션

- Jira, Daily Sync Up, Team competency matrix

이 조건대로 잘 해도 사람이 빠지는 순간 붕괴되는 경우가 있음. 따라서 사람에 의존하지 말고 시스템을 이렇게 만들어서, 관리하고 훈련해서 모두가 참여할 수 있도록 해야 유지된다.

내가 가진 문제가 협력으로 해결되는 게 유리한가? -> 사람들이 협력을 선택하도록 만들려면 어떻게? -> 해당 프로세스 설계할 때 무엇을 고려하고 어떻게 유지?

 

 

 

3. 함께 성장하고 협업하는 문화

개발 문화

리더가 되면? 문화를 이러이러하게 만들고 싶다! 툴은 이걸 사용하고 이런 프로세스로 개발하고 배포하고.. => 아웃사이드 인 접근 방식 == 필패의 지름길

리더는 만들고 싶은 개발 문화의 방향성만 정하고 구체적인 개발 프로세스는 최대한 뒤로 미룬다

문화(변화를 만들기 전에)

1. 인간의 성향은 변화를 거부한다.
2. 팀은 변화를 거부하는 성향이 강하다.
3. 대부분의 사람들은 변화에 실패한 경험을 갖는다

구글 내부에서 성공한 팀의 특성 중 첫 번째로 소개된 것은 Psychological Safety (책: 두려움 없는 조직)

구성원이 업무와 관련해 어떤 의견을 제시해도 벌을 받거나 보복당하지 않을 거라고 믿는 조직 환경

심리적 안정감을 높이는 가장 좋은 방식: 인사이드 아웃 접근 방식 (어렵고 시간이 많이 걸려서 잘 안하지만 장기적으로 좋다)

1. 지속적인 1:1 면담 등으로 신뢰 개선 - 팀원이 문제점을 이야기할 때 해답을 제시하려하지 말고 '어떻게 할까?', '너라면?' 반문하라
2. 면담내용 중 가장 효과가 있을것 같은 것을 먼저 수행하되, 이 Practice가 개인/팀 모두에게 익숙해질 때까지 한가지에 집중한다. (즉 이건 팀장이 제시한 것이 아닌 팀원들이 제시한 것)
3. 이러한 변화를 완료함으로써 팀이 함께 Small success를 맛본다. 1번으로 되돌아가 회고하고 사이클을 반복한다.

문화, 변화를 만들기 위해서는 리더의 인내심과 용기 (초기 학습 비용으로 인한 생산성 저하, 안정화에 최소 1년 이상의 시간 투자)가 필요하다.

현재보다 나아지고 있다는 방향성이 중요하며, 이는 리더만의 책임이 아니다.

실패해도 괜찮으며 실패해도 도전을 즐기는 사람을 원한다. 이에 대한 책임을 묻는다면 그만둔다.

가장 필요한 것은 가보지 않은 길에 꾸준히 도전할 수 있는 용기

 

 

 

4. 협업의 대상

Fast Idea(이해 당사자 편의성, 즉각적 효과, 경제적 인센티브, 기술적 복잡성) > Slow Idea(타인 편의성, 장기적 효과, 사회적 인센티브, 절차의 귀찮음)

협업의 치트키 1. 기본 원칙 (Policy, Guideline, Convention, 형식에 맞는 이메일, 미팅에 늦지 않고 회의에 집중..) 지키기

협업의 치트키 2. 소외된 고객 (장애 등으로 인한)에게 포용적 사고, 행동

협업의 치트키 3. 자율적으로 사고하는 기계(미래 고객)와의 대화 방법

 

 

 

5. 자동화, 생산성

큰 관점: 전체 프로세스를 관찰하며 개선

작은 관점: 질문, 반복, 실수를 줄인다.

이슈 트래커(Jira, ASANA..)를 강조. 여러 레포를 하나의 프로젝트로 관리, status를 손으로 바꾸지 말자, 이슈트래커를 덜 열어볼수록 잘 쓰는 것

JetBrains Task & Context, IDE와 status의 연계: 주로 미래의 커밋메세지를 생각하며 이슈를 먼저 작성

이슈를 많이 만들고 많이 닫자 => 처리가 곧 속도감

Progressive YearWeek Versioning: 1-2103-1234(Major-YearWeek-minor)

질문 발견 -> 질문을 없애겠다 -> 프로세스 관찰 -> 프로세스 개선 -> 문서화(김영재 님의 wiki작성 팁 참고) 반복

축적하여 팀원의 몰입 최대화

단점: 청소 담당, 멘탈관리(공허함, 보람없음) => 팀 문화로 확장, 패턴/규칙화할 두명 더 포섭, 영향력 넓힌다

과하게 하지말자

 

 

 

6. OKR

조직이 커지면서 협업, 소통이 더욱 필요 => 오버헤드 증가

일성과 상태의 공유, 공동 편집가능한 문서 작업, JIRA

OKR: 달성하고자 하는 목표에 대한 정성적인 기술, 달성됐음을 확인할 수 있는 정량적인 결과

CELL

 

 

 

7. 개발

좋은 개발 그룹

 

 

 

8. 성장에 따른 협업의 변화

3명으로 시작(기획, 서버 겸 iOS, 서버) 디자인, 안드로이드 외주 -> 6명(+외주 디자이너, 안드로이드, 서버)

이때까지는 CS 돌아가면서 하고, 마케팅 다같이함. 협업 관리할 필요가 없었음. 배포는 커밋 될때마다 했음

6명 -> 10명에 2년 걸림, 그 이후 협업에 대한 고민 시작

회사, 문화를 만드는것은 결국 사람