[내용 정리]
1. 자라기
1.1. 당신은 몇 년 차?
•
경력 연차
◦
초급인지 아닌지 구분하는 용도로 기대 가능
◦
오히려 잘못된 정보거나 판단 편의적이고 관료주의적 방식일 수 있음
•
채용 시 가장 효과적인 예측 변수
◦
연차보다 더 높은 변수들이 존재
◦
작업 샘플 테스트. 지능 테스트, 구조화된 인터뷰, 성격
•
소프트웨어 개발에서 경력과 실력 (전문가와 비/준전문가 차이)
◦
뛰어난 실력자
▪
문제를 이해하는데 시간과 노력을 적게 씀
◦
최소한도의 경험치만 넘어가면 연차는 직무 성과와 크게 상관성이 낮음
◦
개발자의 경험이 얼마나 폭넓고 다양했는지?
▪
경력의 질적인 면의 중요성
•
경력의 편향 주의
◦
대안
▪
구조화된 인터뷰 / 작업 샘플 테스트 / 실제 업무 주고 짧게 일해보기 (시험외주)
◦
구조화된 인터뷰
▪
개발자로서 협력에 대한 철학이 뭔가요? (X)
▪
지난 프로젝트에서 동료가 어려움을 겪을 때 어떤 행동을 했는지 구체적으로 알려주세요 (O)
•
이미 뽑은 사람을 어떻게 할 것인가
◦
시스템
▪
조직이 개인의 전문성을 더 발전시키고 관리할 수 있게 최대한 지원
◦
애자일 철학
▪
피드백을 짧은 주기로 얻는 것
▪
실수를 교정할 기회가 있는 것
경력은 크게 중요하지 않다. 경험의 질이 중요. 조직이 성장할 수 있도록 지원
애자일 철학 (짧은 주기의 피드백, 실수 교정)
1.2. 자기계발은 복리로 돌아온다
•
회고에 항상 되짚는 것
◦
자기계발에 얼마나 투자를 했는지?
•
자기가 습득한 지식/능력은 복리로 이자가 붙는다 = 지수적 증가
•
더빨리 자라고 싶다면 아래 2가지를 고민해야함
1.
어떻게 이율을 높일 것인가
2.
지속적인 현명한 투자를 하려면 어떻게 할 것인가?
•
우리가 더 잘하는 것을 더 잘하게 하는것이 중요
•
방법
◦
자신이 이미 갖고 있는 것들을 잘 활용하라
◦
외부 물질을 체화하라
▪
외부 자극 → 자기화
◦
자신을 개선하는 프로세스에 대해 생각해 보라
▪
회고/개선
◦
피드백을 자주 받아라
◦
자신의 능력을 높여주는 도구나 환경을 점진적으로 만들어라
1.3. 학습 프레임과 실행 프레임
•
프레임의 종류
◦
실행 프레임
▪
현재 주어진 과업을 좋은 성과를 내는 걸로 생각하는 틀
▪
잘하기에 초점
▪
목표가 학습을 통한 성장인 경우 부적절
◦
학습 프레임
▪
현재 주어진 과업을 내가 얼마나 배우느냐로 여기게 되는 틀
▪
자라기에 초점
•
환경을 바라보는 관점이 중요
◦
업무를 하면서 학습 하는것의 어려움
▪
학습 하기 어렵다 / 학습하기 좋다
◦
마인드셋의 차이
1.4. 가장 학습하기 힘든 직업이 살아남는다
•
배우기 힘든 것에 집중하라
•
일자리가 인공지능으로 대체되지 않으려면 학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 함
•
인공지능 시스템에 유리한 조건 = 인간이 학습하기 좋은 환경의 조건
•
학습하기 힘든 환경과 주제들 = 암묵지, 직관 등이 동작하는 회색영역
인공지능 시스템에 유리한 조건 | 학습하기 힘든 환경과 주제 | |
목표 | 분명하고 객관적이며 정적 | 모호하고 주관적이며 동적 |
선택가능한 행동/선택 | 매순간 선택가능한 행동/선택의 종류가 유한 | 매순간 선택가능한 행동/선택의 종류가 불확실 |
목표 도달성 | 매순간 자신의 목표에 얼마나 접근했는지 알 수 있음 (피드백 빨리 얻기 쉬움) | 매순간 자신의 목표에 얼마나 접근했는지 알 기 어려움 (피드백 빨리 얻기 어려움) |
시스템 | 닫힌 시스템 (예상 못한 외부 요소가 갑자기 들어오지 않는 경우가 흔함) | 열린 시스템 (예상 못한 외부 요소가 갑자기 들어오는 경우가 흔함) |
과거의 선택/결과 | 구조화된 기록이 많음 | 구조화된 기록이 적음 |
•
컴퓨터화에 병목이 되는 카테고리
◦
독창성
▪
주어진 상황/주제를 독창적이고 창의적인 방법들을 생각하기
◦
사회적 민감성
▪
타인의 반응을 알아차리고, 이해하려는 노력
◦
협상
▪
사람들을 화해시키고 이견을 조정하려고 노력
◦
설득
▪
사람들의 마음이나 행동을 바꾸게 설득
◦
타인을 돕고 돌보기
▪
개인적 도움 제공
•
소프트웨어 개발자 vs 컴퓨터 프로그래머
◦
소프트웨어 개발자
▪
사용자의 요구사항 분석
▪
솔루션 설계
▪
개발
◦
컴퓨터 프로그래머
▪
스펙대로 코드를 만드는 사람
•
무엇에 집중할 것인가
◦
내가 하는 일이 어떤 성격인가?
◦
남이 시킨 대로 개발하는 사람이 되지 마라
◦
암묵지와 직관을 배우고 수련하는 방법을 배울것
독창성, 사회적 민감성, 협상, 설득, 타인을 돕고 돌보기 등이 요구되는 수준이 높을수록 컴퓨터화 하기 어렵다.
암묵지와 직관을 배우고 수련하는 방법을 배워라. 남이 시킨대로 개발하는 사람이 되지 마라
1.5. 달인이 되는 비결
•
꾸준한 반복으로 달인이 되기위한 조건
◦
실력을 개선하려는 동기
◦
적절한 시기에 받은 구체적인 피드백
1.6. 수십 년 동안 전문가가 안되는 비결
•
믿을 수 있는 직관 (전문성)이 형성되기 위한 조건
◦
타당성 (validity)
▪
인과관계와 규칙성이 존재해야함 (=예측가능성)
▪
예)
•
포커: 타당성이 높음 (규칙성이 높음)
•
주가, 정치: 예측 불가능, 규칙성이 없음
◦
피드백
▪
자신이 내린 직관적 판단에 대해 빠르게 피드백 받고 학습할 기회가 주어진 환경인지?
•
타당성 높이는 방법
◦
변수 제한하며 실험
◦
규칙성과 인과관계를 찾으려는 노력
•
피드백 높이는 방법
◦
적극적인 피드백 요청
1.7. 당신이 제자리 걸음인 이유
•
실력을 높이기 위해서는?
◦
의도적 수련이 중요
◦
필수 요건: 적절한 난이도
•
업무시간에 불안함이나 지루함을 느끼는 때가 대부분이라면 실력이 도무지 늘지 않는 환경에 있다는 것
•
제자리 걸음 벗어나기 전략
1.
지루함을 느끼는 경우
•
작업의 난이도 유지, 실력 낮추기 (a1)
◦
GUI 툴 안써보기
◦
vim 사용하기
•
실력 유지, 작업의 난이도 높이기 (a2)
◦
더 높은 요구수준을 적용하기
◦
익숙한 작업을 새로운 언어로 개발하기
◦
굳이 안해도 되는 업무를 본인의 의지로 추가로 하기 (리팩토링, 테스팅)
◦
남들보다 일을 더 효율적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구/방법 (DRY)
2.
불안감을 느끼는 경우
•
실력을 높이기, 작업 난이도 유지 (b2)
◦
예) 개발 서적 읽기, 스터디
◦
실력을 높일수 있는 방법
▪
사회적 접근 - 짝 프로그래밍, 전문가 도움 받기, 튜토리얼 문서 따라하기
▪
도구적 접근 - 다른 도구 활용. 디버거, IDE, 코드분석 툴
▪
내관적 접근 - 과거 유사한 경험 떠올리기. 비유적으로 문제 해결
•
난이도 낮추기, 실력 유지 (b1)
◦
애자일 WTSTTCPW
▪
Whats The Simplest Thing That Could Possibly Work
▪
MVP
▪
쉬운것부터 만들어서 확장(고도화 하자)
•
메타 인지 전략
◦
지속적으로 나의 상태를 확인하고 적잘한 4가지 전략을 사용해야함
•
팀장
◦
팀원의 상태를 파악하고 몰입으로 가게 도와줄 것
몰입의 상태를 유지할 수 있게 자기 자신의 상태를 파악하고 꾸준히 노력하자
1.8. 프로그래밍 언어 배우기의 달인
•
인간 역엔지니어링 (인지적 작업 분석)
◦
튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다
▪
적극적 읽기
◦
공부할 때 표준 라이브러리의 소스코드를 읽는다
◦
공부 중 남들이 작성한 코드(오픈소스)에 내가 필요한 기능을 추가한다
◦
주변의 전문가로부터 전문성을 뽑아내 적용한다
▪
구체적으로 질문
1.9. 실수는 예방하는 것이 아니라 관리하는 것
•
실수 문화 종류
◦
실수 예방
▪
실수로 가는 경로를 차단
▪
실수를 저지르지 말 것
▪
현실적으로 불가능
◦
실수 관리
▪
더 나쁜 결과가 되기 전에 일찍 발견 후 조치
•
실수 문화별 개입 시점
•
예방 문화
◦
비난, 처벌, 실수 감추기, 논의 지양, 협력 감소
•
실수 관리 문화
◦
더 나쁜 결과가 나오기 전에 회복을 돕기
◦
실수 공개
◦
실수에 대한 토론
◦
높은 심리적 안전감
•
학습이론
◦
실수가 없으면 학습하지 못함
◦
실수 관리 문화인 기업은 기업의 혁신도, 수익성이 높음
실수를 예방하는 것은 불가능하다. 실수를 잘 관리하자.
1.10. 뛰어난 선생에 대한 미신
•
교육 훈련 효과: 뛰어나지 않음
•
지식이 많은 사람 ≠ 좋은 선생
•
아는 것을 온전히 가르칠 수 있는가?
◦
실제 지식의 70%는 가르치지 않음
◦
30%만 가르치고 모든 것을 가르쳤다고 생각
◦
반복적으로 숙달되어 자동화 → 인식하지 못함
•
인지적 작업 분석 (메타인지 상승 노력)
◦
선생: 내가 이 문제를 해결할 때 어떤 과정을 거치는가
◦
학생: 자신의 인지적 과정을 선생에게 알려주기
1.11. 나홀로 전문가에 대한 대한 미신
•
새로운 기술이나 개념을 도입하려하는데 잘 안되는 경우…
◦
시간이 없음, 구성원들이 공감하지 못함, 외부 조직에서 공감 X 등등 → 사회적 측면에 관한 것
•
아무리 좋은 기술적 실천법이더라도, 그 기술은 사회적 맥락 속에서 실천되어야 하며, 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요
•
현실 - 사회적 맥락이 나쁜상황에서 기술적 측면만 매몰
•
어떤 기술적 실천법이더라도 현실에 적용하기 위해서는 사회적 자본과 기술이 필요하다.
◦
주변을 설득하고 공감하는 과정
•
사회적 자본
◦
연결, 신뢰, 유대
•
뛰어난 개발자
◦
사회적 자본과 사회적 기술이 뛰어남
◦
동료의 협력 중시
•
사회적 기술 훈련 방법
◦
마이크로 인터렉션 신경 쓰기
◦
인사 주고 받기, 지나가는 대화, 물어보기 등
•
어떤 기술적 지식을 전달한다고 해도 그것을 사회적 맥락 속에서 가르치고 경험하게 하려고 노력할 것
◦
사회적 기술
▪
도움받기, 피드백 주고 받기, 영향력 미치기, 가르치고 배우기, 위임하기
2. 함께
2.1. 소프트웨어 관리자의 개선 우선순위
조엘 스폴스키의 개발팀 평가 테스트
•
맥락을 이해하지 못한채 단순히 12가지 질문에 “예”를 대답하는것을 목표로 노력하는것은 위험하다.
◦
모든 항목에 “예”라고 답하는 것이 무조건 더 나은것은 아니다
▪
경우에 따라 다르게 해석할 수도 있다.
•
예) 조용한 작업환경 vs 시끄러운 공간
◦
12가지 질문의 개발팀 평가에 정말 중요한 요소인가?
•
제럴드 와인버그의 [품질 소프트웨어 관리, QSM]
◦
소프트웨어 개발 비용 종류
▪
도구: IDE, 개발 기법, 컴퓨터
▪
사람: 능력, 경험
▪
시스템: 복잡도, DB 크기 등
▪
관리: 매니징
◦
실제로는 관리의 개발 비용이 제일 크지만 관리자들은 도구부터 개선하려고 함
•
나 자신을 돌아보고 관리 방식을 개선하는 것이 중요
2.2. 협력을 통한 추상화
•
실력이 뛰어난 개발자
◦
커뮤니케이션, 협력 능력이 뛰어남
•
협력을 통한 작업 → 다른 시각 → 소통을 위한 추상화 진행 → 업무에 큰 도움
•
소프트웨어 공학의 여정 → 추상화 고도화
◦
다른 시각을 가진 두사람의 협력 → 추상화를 높일 수 있는 방법
•
대화하는 프로그래밍
◦
익스트림 프로그래머: 작업하면서 프로그래밍 각 단계에 대해 함께 얘기
•
코드의 추상성을 높이고 싶다면?
◦
다른사람들과 협동, 대화
◦
함께 소스코드 편집
2.3. 신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
•
신뢰를 쌓을 수 있는 방법: 투명성, 공유, 인터렉션
◦
작업물 투명하게 공유
◦
피드백 교환, 인터렉션
◦
소통 신뢰
•
각자 하나를 공유하거나 최고의 작업물을 공유하는 것보다 여러 작업물을 모두 공유하는 것이 신뢰 향상에 도움이 많이 됨
•
복수 공유의 장점
◦
불안감이 상대적으로 덜함
◦
성과도 더 좋음
2.4. 객관성의 주관성
•
팀장 자리에 있다고 새로운 아이디어 전파가 쉬운것은 아니다.
•
새로운 개념 전파에 중요한 질문
◦
상대방에 대해 얼마나 이해하고 있나?
◦
얼마나 대화를 해봤나?
•
품질이란 누군가에게 가치가 되는 것이다 (Quality is value to some person, 제럴드 와인버그)
◦
인간에 대한 이해가 필수적으로 선행 → 고품질 가능
◦
설득을 위해서는 객관성이 필요. 객관성의 개념은 매우 주관적
•
결국 결정하는 것은 사람
◦
마음에 안들면 객관적 자료로도 설득 불가
•
의사결정을 하는 과정에서 감정적이고 직관적인 부분이 큰 역할을 함. 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없음
•
남을 설득하려면?
◦
상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야함
◦
그 사람을 이해하는 것에서 출발해야함
2.5. 이것도 모르세요?
•
공감하면서 들어주려고 할 것
•
상대가 어떤 멘탈 모델을 갖고 있는지 파악하려 할 것
◦
멘탈 모델: 세상이 어떤 식으로 돌아가는지에 대해 개인이 갖고 있는 믿음과 생각
•
훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해해야함
•
행동을 유도하는 대화
•
서로 코칭을 해주며 함께 동기와 의지를 북돋워주고 같이고민해주는 분위기
2.6. 하향식 접근의 함정
•
탑다운 방식 협력 모델
◦
층위별 전문팀 존재 (기획팀, 구현팀, QA 팀)
◦
바톤 터치 모델
◦
잦은 바톤 터치 → 오버헤드
•
삼투압식 의사소통
◦
배어드는 소통방식
◦
은연중에 서로간의 정보가 스며드는 것
▪
물리적으로 가까운 거리여야 유리함
2.7. 전문가팀이 실패하는 이유
•
전문가를 추가하는 것이 오히려 성과를 깎아먹는 경향
◦
전문가들의 전문성이 서로 유사할때 도드라짐
◦
원인: 전문가들의 에고
•
해결책
◦
협력 계획 필요
•
정리
◦
전문가들을 모아서 팀만든다고 잘하는 것은 아님
◦
오히려 성과가 떨어질 수 있음
◦
정보 공유 및 협력을 잘 하기 위한 명시적 도움 필요
◦
소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 됨
2.8. 구글이 밝힌 탁월한 팀의 비밀
•
구글 아리스토텔레스 프로젝트 연구 결과
◦
팀에 누가 있는지 보다, 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요
◦
성공적인 팀의 특징
▪
높은 심리적 안전감
▪
팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감 향상 가능
•
심리적 안전감
◦
내 생각이나 의견, 질문, 걱정, 실수 등이 드러났을 때 처벌 받거나 놀림 받지 않을 거라는 믿음
•
리더, 관리자
◦
새로운 프로그램 도입 전에 마이크로 인터렉션에 다른 행동 양태를 보여줘야 함
◦
일상에서의 변화 → 신뢰 → 특별히 고안된 활동 시도 가능
2.9. 쾌속 학습팀
•
개발자들의 고민거리
◦
끊임 없는 학습. 특히 빠른 학습
•
학습이 빠른 팀
◦
도전 자체를 팀의 학습 능력에 대한 도전으로 받아 드림
◦
개개인이 새로운 기술을 획득해야하는 것이 아니라 함께 일하는 새로운 방법을 만들어야 한다고 생각
◦
심리적 안정감을 느낌
•
학습이 느린 팀
◦
학습을 개인 과제로 치부
◦
학습보다 단기 퍼포먼스 중시
◦
리더
▪
낙오의 위험성 강조, 팀원 실력 불평 불만
•
현실에서 실천하기 (팀원으로써)
◦
학습 환경을 만들 것
◦
학습과 일을 분리하지 않고 동체로 만듦
◦
학습 공동체 구축
2.10. 프로젝트 확률론
•
확률의 종류
◦
그리고 확률: 모든 조건을 만족해야하는 AND 조건
◦
또는 확률: 하나만 만족하면 되는 OR 조건
•
개발자의 일정 체크
◦
7명의 개발자가 90% 확률로 가능하다고 한다는것?
◦
이건 AND 조건임. 0.9 * 7 = 54%로 봐야할 것
◦
게다가 일반적으로 사람들을 일의 소요시간을 낙관적으로 추정하는 편향 연구 결과가 많음
•
애자일 확률론
◦
12가지 일 & 12명의 작업자에게 작업 할당 방식?
◦
관심사의 섞임
▪
3가지의 일만 주고 협동해서 일을 할 것을 요청
▪
서로에 대해 엄청나게 많은 것을 빨리 배울 수 있음
◦
애자일 방법론은 일을 공유하고 함께 일을 함
▪
좋은 정보들이 도움이 되어 또는 확률로 적용됨
▪
나쁜 일에 대한 정보 공유는 그리고 확률로 적용됨
•
애자일 문화
◦
좋은일: 그리고 확률 → 또는 확률로 바꿈
▪
공유해서 또는 확률로 바꿀것
◦
나쁜일: 또는 확률 → 그리고 확률로 바꿈
▪
여러사람이 중복 검토(짝 프로그래밍, 코드 공유, 코드리뷰 등)해서 모두가 실수해야지만 구멍이나게 그리고 확률로 바꿀 것
3. 애자일
•
좁은 의미의 애자일
◦
애자일 소프트웨어 개발 방법론
◦
불확실성이 높은 일을 계획하는 것이 불가능하다.
◦
불확실성이 크기 때문에 미리 분석하고 설계하는데 한계가 있음
◦
불확실성을 다루는 방식을 좀 더 짧은 주기로 더 일찍부터 피드백 받고, 더 다양한 사람들로부터 더 자주 더 일찍 피드백을 받는 것
•
넓은 의미의 애자일
◦
단순히 개발 방법론이 아니라 삶을 사는 방식으로 확장
◦
학습과 협력 → 애자일이 불확실성을 다루는 핵심적인 구동원리
◦
학습
▪
지속적인 학습 & 학습 능력을 키워 불확실성 대응
◦
협력
▪
서로 업무를 공유하고 상호 검토하는 협력
▪
불행한 일을 그리고 조건으로 변경 가능
▪
통찰을 얻은 좋은 일은 확장하여 또는 조건으로 변경
•
애자일의 핵심 구동원리: 함께 (협력) & 자라기 (학습)
3.1. 애자일의 씨앗
•
애자일의 씨앗 한줄 요약: 고객에게 매일 가치를 전하라
◦
매일 → 학습 빈도
◦
고객에게 → 협력 대상
◦
가치를 전하라 → 협력 진행
3.2. 애자일 도입 성공 요인 분석
•
애자일을 도입해서 성공하는 조직들이 국내에 존재
•
애자일 실천법을 잘 실행하면 성공률도 높아질 수 있음
•
성과에 도움되는 애자일 실천법
◦
고객 참여
◦
리팩터링
◦
코딩 후 자동화 테스트
◦
코드 공유
•
애자일 성숙도가 낮은 조직 → 고객 참여가 없이 프로젝트 성공이 어려움
•
무섭고 두렵지만 중요한 일이라면 미루지 말 것
•
뛰어난 애자일 코치는 함께 자란다
3.3. 당신의 조직에 새 방법론이 먹히지 않는 이유
•
치료자 효과
◦
치료자가 누구냐에 따라 상담 효과가 다름
•
어떤 방법론을 쓰느냐보다는 누가 참여하는가가 훨씬 압도적으로 중요한 문제
•
애자일 방법론 도입을 원한다면?
◦
나는 어떤 팀장인가?
◦
어떤 팀장인지가 안바뀌면 새 방법론을 도입하더라도 의미 없음
3.4. 애자일을 애자일스럽게 도입하기
•
도요타의 실천법
◦
도요타 방식을 도입하여 성공한 기업은 도요타 뿐임
◦
도요타의 방법론이 중요한 것이 아니라, 도요타의 구조와 문화가 중요
•
애자일 방법론
◦
방법론 도입은 태생적으로 불확실성이 높음
◦
현명한 전략은?
▪
정해진 수순을 따르지 말것
▪
곁에 있는 사람들과 함께 탐색하고 조금 나아가고 확인하고를 반복
▪
우리의 현 맥락에 맞는 좋은 전략을 만들어가는 것
4. 주요 내용 정리
4.1. 자라기 (성장)
•
경력과 성장
◦
경력은 크게 중요하지 않다. 경험의 질이 중요. 조직이 성장할 수 있도록 지원
◦
애자일 철학 (짧은 주기의 피드백, 실수 교정)
•
더빨리 성장하려면?
◦
우리가 더 잘하는 것을 더 잘하게 하는것이 중요
•
배우기 힘든것에 집중하라
◦
독창성, 사회적 민감성, 협상, 설득, 타인을 돕고 돌보기
◦
암묵지와 직관을 배우고 수련하는 방법을 배워라. 남이 시킨대로 개발하는 사람이 되지 마라
•
업무환경이 제자리걸음인 것을 피하자
◦
몰입의 상태를 유지할 수 있게 자기 자신의 상태(메타 인지)를 파악하고 꾸준히 노력하자
◦
실력 / 난이도 조정
•
실수 관리
◦
더 나쁜 결과가 나오기 전에 회복을 돕고, 실수를 공개하고 토론하라
◦
실수가 없으면 학습하지 못한다
•
전문가의 사회성
◦
사회적 자본과 기술의 중요성
▪
연결, 신뢰, 유대
◦
아무리 좋은 기술이더라도 사회적 맥락속에서 실천되어야하며, 성공을 위해서는 사회적 자본과 기술 필요
4.2. 함께 (협력)
•
협력을 통한 추상화
◦
다른사람들과의 협동, 대화
◦
함께 소스코드 편집
•
신뢰를 쌓는 방법
◦
투명성, 공유, 인터렉션
•
객관성의 주관성
◦
의사결정에서 가장 중요한 것은 감정적이고 직관적인 부분
◦
남을 설득하려면? 그사람을 이해하는 것부터 시작해야 함
▪
자주 만나서 신뢰를 쌓고, 무엇을 중요시여기는지, 어떤 설명 방식을 선호하는 이해
•
삼투압식 의사소통
◦
은연중에 서로간의 정보가 스며들 수 있게 하는 것이 중요
◦
잦은 바톤 터치 → 오버헤드 높음
•
협력
◦
정보 공유 및 협력을 잘하기 위한 도움 필요
◦
소셜 스킬이 중요
◦
공감하면서 들어줄 것. 상대가 어떤 멘탈 모델을 갖고 있는지 파악해볼 것
◦
서로 코칭해주며 함께 동기와 의지를 북돋워주고 같이 고민해주는 분위기
•
성공적이고 학습이 빠른 팀의 특징
◦
높은 심리적 안전감
◦
마이크로 인터렉션
◦
팀 단위의 도전으로 바라봄
◦
함께 일하는 새로운 방법 만들기 위해 시도
•
애자일 문화
◦
좋은일은 또는 확률로 바꿈
◦
나쁜일은 그리고 확률로 바꿈
4.3. 애자일
•
넓은 의미의 애자일
◦
삶을 사는 방식
◦
학습(자라기)과 협력(함께)을 통해 애자일의 불확실성을 다룸 → 핵심 구동원리
•
애자일 방법론
◦
새로운 방법론 도입은 불확실성이 높을 수 밖에 없음
◦
정해진 수순에 따르지 말고, 함께 일하는 사람들과 협력하며 함께 고민하고 개선해 나갈 것
◦
이를 통해 우리에게 맞는 좋은 전략을 만들어갈 것
[감상평]
1. 개인적으로 느낀 점
[결국엔 사람이다. 사람을 이해하자]
주변에서 워낙에 추천을 많이 해줬던 책이라 조만간 읽어야지라고 생각했었는데, 이번에 마침 좋은 기회로 책을 읽을 수 있어서 내심 쾌재를 불렀다. 사회적 자본/기술, 객관성의 주관성, 실수 관리 문화, 애자일 문화 등 정말 많이 공감이 되는 주제가 많았는데 그중 특히 사회적 자본/기술, 객관성의 주관성이 기억에 남았다. 개발자로 일을 하다보면 새로운 기술을 도입하려고 시도하고 다양한 모습들을 봐왔다. 그중 일부는 좋은 기술이나 개념이었음에도 불구하고 적용이 잘 되지 않았던 적도 있었다. 그때 당시에는 설득할 논리나 객관적인 근거가 부족했기 때문에 도입이 잘 안되었다고 생각했었는데, 책을 읽고 나서 곰곰이 생각해보니 사회적 기술/자본이 부족했거나, 또는 서로에 대한 이해가 부족했던 게 더 큰 원인었겠구나 싶었다. “결국 결정하는 것은 사람이다. 마음에 들지 않는다면 객관적인 자료로도 설득이 부족하다. 따라서 그사람을 이해하는 것에서 출발해야한다” 라는 구절을 다시한번 속으로 곱씹게 된다.
[실력을 의도적으로 낮추기]
책에서는 제자리 걸음 벗어나기 전략으로 4가지 방법을 설명한다. 그 중, “작업 난이도는 유지하며 실력을 낮추는 방법”을 과연 내가 잘 활용하고 있는지 돌이켜보게 되었다. 기존에 익숙한 방법과 툴만 사용하지 않고, 나에게 변화를 줄 수 있는 새로운 환경에 끊임없이 노출시키는 방법으로 성장을 더 이끌어나가봐야겠다고 생각했다. (CLI로 Git을 쓴다던지, Vim을 활용해본다던지 여러 아이디어가 떠오른다.)
[함께 자라기]
책을 관통하는 주제는, 책 제목 그대로 “함께 자라기” 이다. “함께(협력)” 그리고 “자라기(학습)” 이라는 2가지 핵심적인 구동원리를 가지고 우리는 불확실성을 단순히 소프트웨어 개발에만 국한하지 않고 삶의 모든 부분에 적용시킬 수 있다. 1인 기업으로 혼자서 서비스를 운영하고 있는게 아니라면, 우리는 많은 사람들과 협업하며 서비스를만들어나간다. 정말로 뛰어난 역량을 가진 한명의 구성원이 멱살잡고 캐리하는 곳도 있을 수 있다. 그러나 이러한 조직의 한계는 분명하다고 생각한다. 혼자서 모든것을 할 순 없다. 구성원들이 심리적 안전감을 느끼고 함께 고민하며 개선해나가고 성장할 수 있는 문화와 환경을 꾸준히 만들어나간다면 그 결과는 생각하는 것 이상으로 큰 복리로 돌아올 것이라고 생각한다.
2. 현재 우리 조직 돌아보기
[잘하고 있는 점]
•
마이크로 인터렉션을 권장하는 분위기
◦
구성원들 사이의 자유로운 커피챗 / 스몰토크
◦
랜밥메(랜덤 밥 메이트)를 통해 같은 본부 내 타 팀원분들과의 유대감을 더 형성할 수 있는 문화
◦
온보딩 식사 등으로 새로운 입사자가 소프트 랜딩할 수 있게 도와줌
◦
데일리 미팅 체크인으로 소통하기
•
성장 지향
◦
회사의 성장과 개인의 성장을 함께 이끌 수 있게 독려
◦
업무 시간 내 업무에 지장이 가지 않는 선에서 원하는 스터디를 진행할 수 있는 문화
◦
스프린트 회고 / 과제 회고 등을 통해 업무 내용을 되돌아보고 더 발전할 수 있도록 논의
[발전해나가면 좋을 점]
•
인터렉션
◦
기능조직의 형태 + 10명 가량의 팀의 형태다보니 팀안에서 함께 협력하고 소통할 기회가 적어지는 느낌임. 더 자주 소통하고 협력할 수 있도록 팀 자체를 쪼개거나, 팀 안에서 자주 인터렉션 할 수 있는 자리가 더 많이 마련되면 좋을 것 같음
•
성장
◦
스프린트 / 과제 회고에서 나오는 구성원들의 의견들 중, Action Item을 뽑아서 실제로 적용하고 추적해나가면 좋지 않을까 싶음
•
동기부여
◦
스프린트를 통한 단기적인 목표는 있으나 팀/본부 단위의 분기/반기/년 단위의 목표(OKR, KPI)나 로드맵이 있다면 좀 더 주도적으로 일할 수 있을 것 같음
◦
R&D 본부에서 지향하는 조직문화/개발문화에 대한 핵심가치를 함께 논의해서 선정하여 내재화된 핵심가치 기반으로 일하는 문화를 만들면 어떨까 싶음
•
기타
◦
애자일 문화를 적용하기에는 현재 스프린트 주기가 상당히 긴 편인것 같아 아쉬움. 조금 더 짧은 호흡을 가져가면 좋을 것 같음