Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
리디의 개발 문화 적응기
Search
RIDI
May 04, 2018
Technology
3
3.7k
리디의 개발 문화 적응기
RIDI
May 04, 2018
Tweet
Share
More Decks by RIDI
See All by RIDI
원격 근무 팀 운영 경험 공유
ridi
0
2.1k
SVG Icon Design Guide
ridi
2
3.4k
빠르게 훑어보는 리디페이 백엔드 개발기
ridi
2
4.9k
Next.js는 정말 zero config였다.
ridi
0
2k
3일 걸릴 것 같던 구매목록 다운로드는 왜 3주가 걸렸을까?
ridi
0
380
원격으로 한 달 일해보니
ridi
0
1.4k
리디북스 앱에 S Pen Remote 연동하기
ridi
2
2.6k
UI 라이브러리 개발기
ridi
1
2.4k
테스트 환경 개선하기
ridi
8
3.3k
Other Decks in Technology
See All in Technology
隣接領域をBeyondするFinatextのエンジニア組織設計 / beyond-engineering-areas
stajima
1
200
第23回Ques_タイミーにおけるQAチームの在り方 / QA Team in Timee
takeyaqa
0
180
10分でわかるfreee エンジニア向け会社説明資料
freee
18
520k
これまでの計測・開発・デプロイ方法全部見せます! / Findy ISUCON 2024-11-14
tohutohu
3
190
軽量DDDはもういらない! スタイルガイド本で OOPの実装パターンを学ぼう
panda_program
29
11k
株式会社島津製作所_研究開発(集団協業と知的生産)の現場を支える、OSS知識基盤システムの導入
akahane92
1
170
「視座」の上げ方が成人発達理論にわかりやすくまとまってた / think_ perspective_hidden_dimensions
shuzon
2
16k
신뢰할 수 있는 AI 검색 엔진을 만들기 위한 Liner의 여정
huffon
0
540
製造現場のデジタル化における課題とPLC Data to Cloudによる新しいアプローチ
hamadakoji
0
190
Postmanの日本市場におけるDevRel (的) 活動 / Postman's DevRelish activities in Japan
yokawasa
1
120
Oracle Cloud Infrastructureデータベース・クラウド:各バージョンのサポート期間
oracle4engineer
PRO
28
12k
株式会社ログラス − エンジニア向け会社説明資料 / Loglass Comapany Deck for Engineer
loglass2019
3
28k
Featured
See All Featured
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
42
9.2k
Adopting Sorbet at Scale
ufuk
73
9.1k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
665
120k
Writing Fast Ruby
sferik
627
61k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
The Invisible Side of Design
smashingmag
297
50k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
15
2k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.1k
It's Worth the Effort
3n
183
27k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Transcript
리디의 개발 문화 적응기 - 커뮤니케이션 관점에서 - 오길원
리디에서 일한지 2년이 되었습니다
지난 시간을 돌이켜 보았습니다 나는 리디에서 누구인가? 나는 무엇에 에너지를
가장 많이 쏟았는가?
과일과 견과류 먹기
과일과 견과류 먹기 출근 전 운동 하기
과일과 견과류 먹기 출근 전 운동 하기 Tears Of Customers
발표하기
과일과 견과류 먹기 출근 전 운동 하기 Tears Of Customers
발표하기 동료들 더욱 알아가기
과일과 견과류 먹기 출근 전 운동 하기 Tears Of Customers
발표하기 동료들 더욱 알아가기 개발언어와 도구 적응하기
과일과 견과류 먹기 출근 전 운동 하기 Tears Of Customers
발표하기 동료들 더욱 알아가기 개발언어와 도구 적응하기 리디 개발문화 적응하기
좋은 개발문화 = 그것을 잘 가꾸어가는 사람들 = 좋은 회사
/ 좋은 서비스
좋은 개발문화의 핵심은 그것을 만들어가는 사람간의 커뮤니케이션
리디의 독특한 개발문화에 적응할 때 가장 도전적이었던 점도 커뮤니케이션
이전 회사에서는... 커뮤니케이션 문제에 대해서 크게 고민해 본적이 없었습니다
Java 개발자로서 API Management에 종사하던 저는 솔루션 개발과 커스터마이징 업무가
주력인 수직적 조직에 익숙
수직적 조직의 특징 정형화된 언어/개발 가이드/기술셋 창의성보다는 기동성 지시형 커뮤니케이션
역할의 명확한 분리
그러나 리디에서는…? 시행 착오 4단계
1. 수습 기간 때 시행착오 수평조직 적응하기
점심시간에도 느껴지는 수평적 문화 지금은 아무렇지도 않은 1/n 카드! 수직에
익숙하던 수습 때는 충격!!
수직구조의 잔재 - 나이와 경험치에 대한 부담감
수직구조의 잔재 조급함 - 나이와 경험치에 대한 부담감 - 빨리
회사에 공헌하고 싶었던 과욕
수직구조의 잔재 조급함 과시 - 나이와 경험치에 대한 부담감 -
빨리 회사에 공헌하고 싶었던 과욕 - 당장 필요하지 않은데도 잘 아는 기술들 어필
불통 - 회의시간에 혼자만 다른 이야기
불통 충고 - 회의시간에 혼자만 다른 이야기 - 동료들의 솔직한
커뮤니케이션을 받아드림
불통 충고 회복 - 회의시간에 혼자만 다른 이야기 - 동료들의
솔직한 커뮤니케이션을 받아드림 - 수습기간에 필요한 기본에 충실
불통 충고 회복 축 수 습 기 간 통 과
- 회의시간에 혼자만 다른 이야기 - 동료들의 솔직한 커뮤니케이션을 받아드림 - 수습기간에 필요한 기본에 충실
2. 업무 습득시 시행착오 코드리뷰 적응하기
코드 리뷰 = 공동 책임 엄격한 코드 리뷰로 너덜너덜~
None
None
개발환경 학습 미흡? 가이드 숙지 X 언어에 익숙 X Java언어
사용 습관 O
미니 리디 만들기! 신규 입사자 과제로 연습용 서점 사이트 만들기
개발환경을 숙지할 충분한 시간 제공 리디의 리뷰 문화를 먼저 학습할 수 있는 기회
서비스코드 개발시작시 시행착오? “이거 이렇게 하시면 안되는데...” 문서만으로는 의도 전달이
어려움
다양한 해결방법! 간단한 문제라도 해결책은 많을 수 있음 먼저 동료와
의견을 충분히 교환
찜찜함 제거! 요구사항이 완벽히 이해되지 않으면 명확해질 때까지 끈질기게 확인
롤백 발생? 충분히 공유되었다고 생각했음에도 2주간 개발했던 내용이 롤백 리뷰어도
리뷰이도 당황!
단계별 리뷰! 개발부터가 아닌 설계부터 리뷰 리뷰어와 점진적인 합의 및
공유
여러가지 이유로 망설였지만... 사전에 충분히 많은 의견을 교환하는 것이 빠르게
리뷰를 통과하는 길
3. 신입사원과 일할 때 시행착오 배려하기
배경지식의 동기화 실수 발생시 “이분이 어떤걸 몰라서 발생했을까?” 신입사원이 업무를
모르는 건 당연하다 문서화가 안되있거나, 숙지가 덜 되었거나
너무 구체적이지 않은 안내 “XX함수를 고치세요” 보다 “XX클래스를 살펴보세요”
너무 구체적이지 않은 안내 대신 코딩만 할 사람이 아닌, 함께
일하는 팀원을 만드는 방법
실은 제가 수혜자였습니다... 그러한 배려를 받아 지금에 이르렀는데 자꾸 잊어버립니다
배경지식의 동기화 너무 구체적이지 않은 안내
4. 태스크 할당 시행착오 아사나 태스크 적응하기
플랫폼팀은 프로젝트별 담당자를 두어 교차 업무를 기본 원칙으로 합니다
교차업무? 특정 업무를 한 사람만 알고 있으면 팀의 리스크 업무별
최소 2인 이상이 알고 있어야 함
교차업무의 장점 2차 책임자를 지정 하여 리스크 분산
교차업무의 단점 본인의 업무뿐 아니라 다른 업무도 파악 개인마다 역량
차이로 인해 시간이 더 필요
처음에는 업무를 나눌 때 각자가 프로젝트 내에서 원하는 태스크를 선택
(물론 중요 업무는 할당)
목표, 시급성, 중요도를 명확히!
우선순위
우선순위
우선순위 기재 태스크에 시급성과 중요도 라벨을 추가하여, 우선순위를 알려줌으로써 자발적
참여를 유도
월간 개인목표 팀 목표내에서 개인별 월간 목표를 팀 미팅을 통해
결정
그래서 현재는...
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선 - 담당
프로젝트
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선 - 담당
프로젝트 - 새로운 기술을 적용
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선 - 담당
프로젝트 - 새로운 기술을 적용 - 배우고 싶은 업무 관련
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선 - 담당
프로젝트 - 새로운 기술을 적용 - 배우고 싶은 업무 관련 - 레거시 개선
그래서 현재는... - 시급성, 난이도, 중요도가 높은것이 우선 - 담당
프로젝트 - 새로운 기술을 적용 - 배우고 싶은 업무 관련 - 레거시 개선 - 기타 등등
플랫폼팀 커뮤니케이션의 단점 (저의 경험을 바탕으로)
모든 사람의 의견에 귀 기울이고 많은 단계를 거쳐서 검증하므로 시간이
많이 걸립니다
충분히 주의하지 않으면 논리보다 특정 사람 혹은 사람과의 관계에 의해
결정 될 수 있습니다
플랫폼팀 커뮤니케이션의 장점 (저의 경험을 바탕으로)
의견을 자유롭게 낼 수 있어 미처 생각하지 못했던 개선점을 발견하거나
개발에 대한 창의적인 접근이 가능
모두 함께 책임의식과 의무를 나누어 지는 민주적인 문화
업무에 대한 다양한 성찰을 통해 개인이 성장을 할 수 있는
토대
여러 커뮤니케이션을 경험해보니, 궁극의 커뮤니케이션이란?
1. 고정적이 아니라 변동적 반드시는 없다
1. 고정적이 아니라 변동적 특정언어를 썼을 때의 고정관념
2. 의도를 충분히 생각보다 자주 발생하는 오해
2. 의도를 충분히 문제상황 공유없이 질문을 한다면?(XY 문제)
3. 주장에는 납득할 근거가 있어야 트렌드나 취향이라는 이유로 주장하는 것을
경계
3. 주장에는 납득할 근거가 있어야 “이쁜것 같습니다.” “어울리지 않나요?”
4. 목표에 명확히 집중 대부분의 의견 충돌은 숨겨져있는 진짜 목표를
잊고 있기 때문
4. 목표에 명확히 집중 “CP사이트 리뉴얼 방법”의 충돌은 “CP사이트를 통한
리디의 목적”을 정의해야 함
5. 틀릴 수 있음을 받아들임 성인이라고 해서 모두 완성되어있는 것은
아니다
5. 틀릴 수 있음을 받아들임 틀린걸 받아들이는 것이 성장을 위한
최고의 방법
6. 의견 교환은 예의있게 개발 커뮤니케이션은 사람간 커뮤니케이션의 하위 집합이다
6. 의견 교환은 예의있게 백종원 왈 : “물론 아시겠지만”
마무리
리디의 수평적 구조의 장점을 잘 운용하기 위해서는 성숙한 소통과 문화가
필수
일의 진취적인 진행과 성공적인 완성을 위해, 때에 따라서는 리더의 균형잡힌
판단과 실행력도 필요
저의 작은 경험을 나누었지만, 이것을 통해 자신의 커뮤니케이션을 돌아보고 보다
성숙한 개발문화를 만들어 나가는데 도움이 되었으면 좋겠습니다
RIDI Style Guide https://github.com/ridi/style-guide 규칙을 정하는 규칙 슬랙 사용 규칙
UI 텍스트 작성 가이드 코드리뷰 규칙
끝