자라기(학습)
2종류의 학습, 야생학습 ⇔ 학교 학습
야생학습의 특징
1.
협력적
2.
비순차적
3.
자료에 한정이 없음
4.
평가기준이 없음
5.
정답이 없음
6.
목표가 불명확하고 변경되기도 함. 불확실성이 높을수록 야생학습이 중요함. 즉 학습하는 방법을 학습해야 한다
개발자의 실력과 년차
일반적으로 개발자의 가치는 그 사람의 경력(년차)로 판단. 경력이 몇년 되지 않았을 때는 쓸만한 기준이 될 수 있음. 하지만 일정 정도 년차가 지나면 경력으로 채용할 때와 관심사로 채용할 때와 상관성은 거의 동일함(5년차와 10년차는 성과 측면에서 큰 차이가 없음). 결과적으로 경력이라는 요소는 조직에 손해를 줄 수 있는 방식. 경력과 실력은 비례하지 않는다. 단 경험의 폭이 넓고 다양하다면 변별력이 있다.
개발자 채용 방법
1.
구조화된 인터뷰
"지난 프로젝트에서 동료가 어려움을 겪을 때 어쩐 행동을 하셨는지 구체적으로 예를 들어주세요"
2.
작업 샘플 테스트
3.
실제로 같이 일해보기(Trial Sourcing)
4.
같이 일할 사람들이 같이 인터뷰에 참여하기
이미 채용한 인력을 어떻게 할 것인가
•
구성원이 요즘에 얼마나 공부하고 수련하느냐로 그직원의 성과가 결정. 조직은 개인이 전문성을 좀 더 발전시고 관리할 수 있게 최대한 지원하는것이 효과적.
•
하지만 시스템과 문화에 문제가 있다면 아무리 훌륭한 구성원도 묻혀버리기 쉽다. 반대로 훌륭한 시스테과 문화속에서 평범한 구성원이 성과를 낼 수 도 있음
•
개발자 개개인은 년수만 늘릴것이 아니라 본인의 기량을 향상시킬 수 있는 의도적 수련이 필요. 이 수련에는 짧은 피드백이 필수.
자기 계발
•
자기 계발은 복리로 돌아온다(자기 계발을 하면 할 수록 가속도가 붙는다)
1.
자신이 이미 가지고 있는 것들을 최대한 활용
2.
외부의 자극을 최대한 빨리 체화
3.
자신을 개선하는 프로세스 만들기
4.
더 일찍, 더 자주 실패하고 실패에서 배우자
5.
자신의 능력을 키워주는 도구를 점진적으로 개발
•
조직의 3가지 차원의 작업
•
A : 원래 하기로 한 일
•
B : A를 잘 하기 위한 작업
•
C : B를 잘 하기 위한 작업, 부트 스트래핑, 지수적 향상
•
조직의 형태
•
워크 그룹 : 일을 나눠서 하는 분업 조직
•
팀 : 집단의 지능을 높혀 생산성을 향상시키는 조직
학습 프레임 VS 실행 프레임
•
실행 프레임 : 성과('잘하기')가 중요함
•
학습 프레임 : 배우기('자라기')가 중요함
학습에 유리한 조건
1.
목표가 분명하고 객관적으로 정해져 있으며 변경되지 않음
2.
선택할 수 있는 행동과 종류가 유한함
3.
매 순간 자신이 목표에 얼마나 근접했는지 알 수 있음
4.
주로 닫힌 시스템 속에서 활동
5.
과거의 선택과 결과에 대한 구조화된 기록이 많음
학습에 불리한 조건(암묵지, 직관이 작동하는 회색 영역) 아래에서 필요한 능력
1.
독창성(Originality)
2.
사회적 민감성(Social Perceptiveness)
3.
협상(Negotiation)
4.
설득(Persuation)
5.
타인을 돕고 돌보기(Assisting and caring others)
•
코더와 개발자의 차이 : AI가 대체할 수 있는가? 가장 학습하기 힘든 직업이 살아남는다
달인이 될 수 있는 조건
1.
실력을 개선하려는 동기
2.
구체적인 피드백을 적절한 시기에 받을 수 있어야 함
작업의 난이도와 실력향상
가장 잘 몰입하기 위해 적절한 난이도가 필요. 어떤 난이도가 적절한지 판단하기 위해 메타인지 능력이 필요.
구성원의 실력향상을 위한 리더의 역할
구성원이 스스로 몰입 상태를 조절할 수 있는 능력을 키워줘서 자기효능감을 높혀준다.
의도적 수련의 일상적 예시
(구체적 예들이 많이 나옴...)
실수는 예방하는 것이 아니라 관리하는 것이다.
실수는 발생한다. 실수가 나쁜 결과를 내기 전에 조기에 발견하고 빠른 조취를 취하자. 이후예는 실수를 공개하고 실수에 대해 얘기하고 실수에서 배우자.
실수 예방보다 관리에 비중을 더 둘 수록 기업의 혁신 정도가 더 높다. 왜냐하면 실수가 없으면 학습하지 못하기 때문. 실수 관리를 하는 문화일 수록 학습을 더 잘한다.
"더 뛰어난 스케이터가 더 자주 엉덩방아를 찧는다"
나홀로 전문가에 대한 미신
어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본(신뢰)과 사회적 기술(소프트 스킬)이 필요. 사회적 기술을 높히기 위해 마이크로 인터렉션에 주의한다(기록, 복기, '그것이 최선이었을까' 회고해보기)
함께
소프트웨어 개발을 잘 관리하기 위한 3가지 능력
1.
복잡한 상황을 이해하는 능력 : 시스템적 사고(Systems Thinking)
2.
관찰하는 능력 : 일차적 측정(First-Order Measurement)
3.
행동하는 능력 : 일치적 행동(Congruent Action)
4.
변화를 기대하기(Anticipating Change)
프로젝트 성공요소
1.
관리 : 관리방식, 관리자
2.
시스템 : 조직체계
3.
사람
4.
도구
협력을 통한 추상화
•
다른 시각을 가진 두 사람이 협력하기(페어 프로그래밍)
•
신뢰자산이 높은 조직은 커뮤니케이션 효율과 생산성이 높음
•
신뢰(communication trust)자산을 높히는 방법
•
투명성
•
공유
•
인터렉션
•
이해(상대성을 인정하자) : 사고 과정에 대한 이해, 어떤 가치관을 가지고 있는지, 어떤 방식을 선호하는지
하향식 VS 상향식
•
문제를 분류하자
•
잘 정의된 문제(well-defined) : 디자인이 필요
•
정의되지 않은 문제(ill-defined) : 디자인 불필요
•
실제로는 하향식과 상향식 방법을 번갈아 가면서 사용한다.
조직이 문제를 해결하는 방법(협력 모델)
•
의사소통의 문제 : 바통터치에 너무 많은 비용이 발생
•
모든 사람들이 모든 단계의 전문가가 되도록 하거나 VS 바통 터치의 비용을 줄인다
•
삼투압식 의사소통, 은연중에 정보가 조직에 스며들도록 한다
•
한번에 처리되는 일의 양을 줄인다
•
전문가팀이 실패하는 이유 : 전문가들의 ego 때문에 협력을 안하려 한다
•
협력을 위해서는 신뢰가 바탕이 되어야 함
쾌속 학습팀
•
학습 환경을 만들 수 있는 리더가 필요(하지만 학습 의지가 있는 구성원이 없다면 -.-)
•
팀원들이 심리적으로 보호받고 있는가
•
새로운 것을 제안하고 시도하는데 열려있는가
•
실패에 관대한가
•
잠재적 문제를 지적하고 실수를 인정하는데 부담을 느끼는가
애자일 확률론
•
관심사의 섞임(mingling of concern)을 통해 서로서로 많은 것을 배울 수 있다.
•
팀원들을 최대한 섞이도록 한다. 한명이라도 중요한 발견을 하면 나머지 모든 구성원이 공유(copy)할 수 있도록 한다.
•
직렬적 조직 vs 병렬적 조직 : 직렬적 조직에서는 가장 약한 개체의 능력이 그 조직의 능력(AND 조건), 병렬적 조직은 각 개체 능력의 평균치가 그 조직의 능력치(OR조건)
•
애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꿉니다.
애자일 : 함께 자라기
•
불확실성이 더 높은 프로젝트에 적합
•
불확실성이 낮은 프로젝트는 비즈니스적 가치가 떨어짐
•
미래의 불확실성은 자연스러운 것
•
'학습'과 '협력'이 불확실성에 대한 대안이다
•
"고객(모든 이해 당사자)에게 매일(자주) 가치를 전하라"
애자일 성공요인
1.
고객참여
2.
리팩토링
3.
자동화 테스트
4.
코드 공유
5.
뛰어난 애자일 코치
당신의 조직에 새 방법론(애자일)이 먹히지 않는 이유
•
조직의 당신에 대한 신뢰가 부족하기 때문
•
문화적 풍토, 생성적 과정