[OKKYCON 2021 Live] 협업의 기술
1. 키노트 : 한빛미디어 의장 박태웅
커뮤니케이션이란?
상대방의 의식을 정확하게 꿰뚫수 없다. ("당신은 나의 지옥이다.")
"지붕에 올라갔으면 사다리를 버려라"
딜레마 : "형편없는 말"밖에 내 의견을 전달하는 방법이 없다.
그럼에도 불구하고 같이 일을 하기 위해서 우리가 할 수 있는 것들
나의 행동은 의도, 남의 행도는 보이는 대로 판단하지 말고 공평하게 판단하자.
짐작과 사실
레이블링을 하지 말아야 한다. 실제 사실과 레이블링을 구별할 줄 알아야 한다.
"뺀찌 주세요"
뺀찌 -> 망치 -> 드릴
텍스트를 주지 말고 context를 주자. (왜 이걸 하려고 하는지 전달)
모든 컨텐츠를 위키로 모으는 이유
보고와 사고
일정을 주 단위보다 시간 단위로 짜도록 하자.
정리
커뮤니케이션은 사람이 할 수 있는 일이 아니다.
하지만 최선을 다해야 한다.
2. 네오위즈 애자일 코치 홍영기
협력이란?
특정한 목적을 달성하기 위해 서로 힘을 합하여 도움
협력과 협업의 구분
shared 하냐 shared 안 하냐
협력을 잘하려면?
언제 협력을 선택하는 것이 좋을지 고민해야 한다.
협력은 언제 유리할까?
1. 일이 어려울때(complicate) 보다는 복잡할때(complex)
어렵다 : 공부하고 배워서 익히면 할 수 있다
복잡하다 : 주어진 상황이 이해하기 모호하고, 예측하기 어려운 불확실성이 높은 상황
2. 전문적...(못적음)
전문적 : 기술적인 문제를 숙련, 숙달
3. 작업 절차/공정을 명확하게 나누기 어려울 때
불확실성이 높고 예측 불가능한 사항이 많을 때
비즈니스 도메인 입장에서 협력을 선택하는 것이 유리하다
협력이 잘 이루어지기 위한 조건과 실천법
1) 피드백 2) 투명성 3) 일의 의미 4) 심리적 안전
정리
- 지금 우리가 푸는 문제는 협력을 선택하면 유리할지 생각
- 사람들이 협력을 선택하도록 만들려면 어떻게 해야 할까?
- 설계를 할 때 무엇을 고려해야 할까? (앞서 말씀한 4가지)
3. 우아한형제들 교육이사 박재성
주제: 함께 성장하고 협업하는 문화 어떻게 만들 것인가?
어떤 문화를 만들고 싶은가?
팀의 문화를 만들려면 어디서부터 만들면 좋을까?
예) 온라인 코드 리뷰, TDD를 팀의 문화로 정착시키고 싶다.
문화(변화)를 만들기 전에 생각해 볼 점
- 사람은 기본적으로 변화를 거부하는 성향
- 팀은 변화를 거부하는 성향이 강함
- 대부분의 사람들은 변화에 실패한 경험을 가지고 있음
팀의 변화를 만드는 일을 성공하기 위해 가장 중요한 것
팀원들에게 심리적 안정감을 주는 것
마치며
새로운 문화를 정착하기 위해 가장 중요한 것은 리더의 인내심과 용기
- 새로운 문화를 만들면서 초기 학습 비용 등으로 인해 생산성 저하
- 안정화하는데 최소 1년 이상의 시간을 투자해야 한다는 마음을 믿고 기다려주어야 함
4. SAP PM UX 김영욱
주제 : 당신에게 협업의 대상은 무엇입니까? (누구인지 말고)
1) 협업의 첫 번째 대상 : 생각(idea)
아이디어의 가치는 무엇이 결정하는가?
협업의 첫 번째 치트키 : 기본 원칙
2) 협업의 두 번째 대상 : 소외된 고객
협업의 두 번째 치트키 : 소외된 고객이 없도록 적극적으로 협업하기
3) 협업의 세 번째 대상 : 자율 머신
협업의 세 번째 치트키 : 미래 고객과 대화를 준비
마무리
생각 : 기본 업무 원칙을 지켜요
소외된 고객 : 포용적 사고, 행동을 해요
자율 머신 : 미래의 고객과 대화 방법을 익혀요
5. 라인플러스 Fellow 김영재
큰 관점 : 전체 프로세스를 관찰하며 개선
작은 관점 : 질문을 줄인다. 반복을 줄인다. 실수를 줄인다.
이슈트래커 (Jira, ASANA, YouTrack, Pivotal Tracker...)
선택 기준 : 깃허브 이슈는 한계가 있다고 생각, 전사적으로 사용 가능해야 함
개발자가 이슈트래커를 잘 쓴다는 기준
절대 상태(status)를 손으로 바꾸지 말자
이슈트래커 웹에서 적게 열어볼수록 잘 쓰는 것
이슈를 많이 만들고, 많이 닫자
API 영혼까지 끌어모아서 자동화
- 조직이 커질수록 자동화에 제약이 생긴다
- 하지만 포기하지 말자. API를 째려보면 자동화가 보인다.
- 자동화 스크립트 팁
과적합 주의
- 자동화도 과한 자동화가 있다
- 개발 흐름 또는 체계를 바꾸려고 할 때 일이 커질 수 있음
- 타성에 젖을 수 있음
결론
- 전체 프로세스를 보자
- 정확하고 자동화된 버저닝 시스템을 확립
- 이슈트래커를 정보와 코드의 창구로
- 일단 혼자 해보고 자신 있게 권하자
6. 번개장터 CTO 이동주
주제 : OKR 기반으로 스케일업 가능한 협업체계 만들기
협업 효율을 개선하기 위해
- 정보 공유와 공동작업을 쉽게
- 소통을 수월하게
- 업무 가시성을 높게
- 서로 사용하는 도구의 차이를 줄여서
- 별도의 학습 없이 직관적으로 소통할 수 있도록
- 프로세스나 도구의 단순함을 유지
목표 기반의 업무체계 도입
- OKR (Objective Key Result) : 달성하고자 하는 목표에 대한 정성적인 기술, 목표가 달성됐음을 확인할 수 있는 정량적인 결과
- CELL : 목표를 공유하는 서로 다른 직무가 모인 목적 중심 조직, 많은 회사에서 도입하여 운영하고 Squad, Silo라 불리기도 함
7. 쏘카 데이터 그룹 그룹장 김상우
주제: 7년간 방치되었던 쏘카의 가격 시스템, 직접 개발해버린 이야기
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
...(못적음)
AS IS : 높은 자유도, but 한땀한땀 만들어야 함
TO BE : 논리적인 요소들의 조합으로 가격 결정
Essential Ingredients
- 좋은 개발팀과의 좋은 관계
- 우리가 할 일을 저쪽에서 왜?(X)
- 공동의 목표, 같이 달성하는 것(O)
- 업무 분산을 위한 기술적 도태
- MSA
- 표준화되고 다루기 쉬운 배포 환경 및 인프라
- 운영 경험
- QA, 자동화된 테스트
- 책임감 있는 팔로업 및 모니터링
New-type
- 어려움들을 이겨내고 현재는 여러 기능을 데이터 엔지니어, 분석가들이 직접 개발 중
- 개발팀의 부족한 시간과 리소스를 보완
- 도메인 지식과 데이터를 기획/개발, 오퍼레이션에 불어넣는 역할
Closing
Agile : 개인 간의 상호작용을 더 중요시해라
There's no silver bullet : 마법의 무기는 없다. (어떠한 기술을 도입해도 결국 장단점이 있다.)
8. 당근마켓 이사(CTO) 정창훈
하루에 배포 몇 번?
직원 3명(개발자 2명)
"비전을 맞춰가는 과정"
직원 6명(개발자 4명)
"다 같이 회의" / "다 같이 운영" - 돌아가면서 CS 대응
-> "협업에 대한 고민 X"
직원 10명(개발자 7명)
"서초 이사"
직원 25명
"강남 이사" "다른 사람들은 뭐하나"
직원 140명
"서로에 대해 알 기회가 줄어들고 있다."
"협업에 대한 고민의 시작"
개발 문화는 어떤가요?
- 저는 잘 모르겠다고 이야기합니다.
- 회사 업무에서 하고 싶은 것들을 할 수 있는 환경을 만들어주는 것에 집중
- 회사에서 강제하는 것이 없는 것이 문화일 수도 있겠다는 생각
- TDD를 하라고 강제하지 않고 하지 말라고 강제하지 않습니다.
- 다른 모든 것들에 대해서 비슷한거 같아요, Circle CI를 강제하지 않고 Github Action을 강제하지 않습니다.
- 혹시나 강제하는게 있을수 있지만 안하려고 노력하려 합니다.