Search

함께 자라기 - 애자일로 가는 길

조직의 성장이란?

함께 자라는 것.
함께 자란다는 것은 뭘까?
D:Light Onboard
단순히 그냥 작업을 더 한것. 비슷한 결과물을 하나 더 만든 셈
“성장”. 더 나은 결과물이 나오는 것.
결과물을 생산해내는 방식을 개선하는 것.
제품을 만드는 방식을 개선하는 방식을 개선하는 것. = 함께 자라기 = 성장하는 조직
단순히 업무시간을 늘리는 것, 추가 근무를 하는 것은 단순 더하기이고 프로세스에 대한 고민을 다같이 해나가는 것이야말로 곱셈, 제곱의 시너지를 만드는 방법입니다.

어떻게 해야, 곱하고 제곱할 수 있는가?

자신이 이미 갖고 있는 것들을 잘 활용하자.

새로운 것을 유입시키는 데에만 집중하다 보면 이미 있는 것들을 덮는다.
이미 읽은 책을 얼마나 활용하고 있는지 반성하자
자신을 개선해나가는 프로세스를 만들어라.

학습 프레임과 실행 프레임

학습 프레임 : 현재 주어진 과업이 내가 얼마나 배우느냐로 여기는 틀
실행 프레임 : 현재 주어진 과업이 뭔가 좋은 성과를 내는 걸로 생각하는 틀
실행 프레임은 당신의 목표가 학습을 통한 성장이라면 불리한 선택이다.
“당장 해야할 업무가 있는데, 학습을 중요하게 여기기가 쉽지 않은 거 같다”
→ 동일한 자극/조건이 주어졌을 때 어떤 사람은 더 많은 학습과 성장의 기회를 찾고 오히려 그 조건을 자신에게 유리한 조건으로 생각한다.

학습하기 힘든 환경에서 학습하기 힘든 주제들을 골라야 인공지능으로 대체되지 않는다.

목표가 모호하고 주관적일 수 있으며 동적이다.
매 순간 선택할 수 있는 선택의 종류가 불확실하다.
매 순간 내가 목표에 얼마나 근접했는지를 알기 어렵다. ( 피드백을 빨리 얻기 어렵다 )
주로 열린 시스템( 예상치 못한 외부 요소가 개입하는 환경 ) 속에서 일한다.
과거의 선택과 결과에 대한 구조화된 기록이 별로 없다.
컴퓨터화할 수 있는 확률이 높을수록 해당 임금이 낮았다.
독창성
사회적 민감성
협상
설득
타인을 돕고 돌보기
와 같은 능력의 요구 수준이 높을수록 그 직업은 컴퓨터화하기 힘들다 = 임금이 높다. ( 단순히 오래한다고 실력이 느는게 아니기 때문)

컴퓨터 프로그래머 vs 개발자

프로그래머 : 주어진 스펙대로 개발하는 것 → 컴퓨터화 가능 확률 0.48
개발자 : 뭘 만들지를 고민하고 설계하는 것 → 컴퓨터화 가능 확률 0.042
혼자서 딱 정해진 일만 할 수 있는 환경은 축복이 아니라 저주다.
암묵지와 직관은 그럼 어떻게 배우고 수련할 수 있을까?
자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 쌓일 것입니다.
1.
실력을 개선하려는 동기
2.
구체적인 피드백을 적절한 시기에
단순히 반복만 한다고 해서 달인이 될 수 없다.
타당성 : 직관이 적용되는 영역에 어느정도 인과관계와 규칙성이 존재해야한다.
피드백 : 오늘 실수한 것을 몇달 뒤에 알게되면 그것을 고칠 수 없다.
이 두가지를 높이기 위해 팀은 어떤 노력을 하고 있는가?
즉, 내 성장을 측정할 수 있는 지표. 가 명확해야하고
내 결과물에 대한 피드백을 바로바로 받을 수 있는 환경을 조성해야 한다는 것.

의도적 수련

아무 생각 없는 반복은 전문성 향상에 어떠한 도움도 되지 않습니다.
자신의 수준에서 딱 한단계 높은 수준을 학습하고자 할 때, 퍼포먼스와 학습능력이 최대치가 돼요
지루함 또는 불안함에 빠지지 않고 몰입할 수 있는 환경을 구성하는 것이 중요합니다.
그렇다면 어떻게 몰입할 환경을 만들까요?

지루함을 느끼는 경우

A1 : 실력 낮추기

모래주머니 달기 전략
기존에 사용하던 툴이나, 라이브러리를 사용하지 않고 개발 해보기

A2 : 난이도 높이기

자신만의 제약을 추가하기
코드에서 예외상황을 빈틈없이 찾아보기
하루동안 해야할 일을 2시간의 시간제한을 두고 작업해보기
공식적으로는 안 해도 되는 업무를 자신의 의지로 추가하기
리팩터링하기
중복되는 코드를 찾아보기
남들보다 일을 좀 더 효율적/효과적으로 하기 위해 내가 직접 만들어 쓰는 나만의 도구,방법 만들기

불안함을 느끼는 경우

B1 : 난이도 낮추기

자신이 맡은 일을 세분화 해서 가장 간단하면서 핵심적인 결과물을 첫번째 목표로 삼기

B2 : 실력 높이기

사회적 접근 : 나보다 전문가의 도움 받기
도구적 접근 : 다른 툴의 도움을 받기
내관적 접근 : 비슷한 일을 했던 경험을 떠올리기
자신의 실력이나 작업의 난이도는 요동치고 있음에 주의해야합니다.
현재 자신의 업무 처리 속도가 외부에 영향을 미치지 않는 선에서 적절하게 난이도와, 실력을 조절해 나가야 하죠.
자신의 감정상태를 지속적으로 살펴야 한다는 거에요
지루한지, 불안한지 말이죠
이렇게 감정상태를 살피고 이에 조치를 취하는 사이클을 계속 돌아보는 것이 좋습니다.
지속적인 회고만이 성장의 지름길이다. = 메타인지 전략
역엔지니어링 방법 : 작업을 잘하고 있는 전문가가 있다면, 보통 그들은 자신이 왜 잘하고 있는지 모른다.
그들의 작업방식을 그들 스스로 자세히 세분화하고 들여다보고 분석하게 만드는 방법을 역엔지니어링 방법이라하고, 이를 통해 비전문가들도 학습시킬 뿐만 아니라, 전문가도 그 방법을 다른 곳에도 적용할 수 있게 된다.

나홀로 전문가 상황

흔히 고독한 천재 라고 불리는 이러한 사회적 상황은 생각보다, 사회에서 흔히 볼 수 있는 상황입니다.

개인의 영역

1.
TDD를 제대로 이해하고 조직에 돌아간다
2.
나 스스로 TDD를 제대로 실천해서 객관적 성과를 낸다

사회적 영역

3.
TDD가 좋다고 사람들을 설득한다
4.
TDD 를 가르쳐 준다.
5.
모두가 TDD 를 열심히 한다.
6.
모두가 좋은 성과를 낸다.
일반적인 교육에서는 1,2 번에만 집중합니다.
하지만 통상적으로 실무에서 발생하는 문제는 3,4,5,6 번입니다.
어떤 기술적 실전법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요합니다.
신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다.
신뢰 사회적 자본의 일종이라고 합니다.

이러한 사회적 기술도 훈련이 가능하다는 점.

어떻게 훈련해요?
마이크로 커뮤니케이션(하루하루 대화 내용들)을 기록하고, 복기하고, 어떻게 했으면 좋았을까? 를 생각해보는 식으로 훈련이 가능합니다.

협력에 대한 잘못된 이해.

사람들은 보통 협업을 한다고 하면서, 일을 세분화하고 , 일을 나누어가져가서, 모두 해온 뒤, 합쳐봅니다.
이러한 방법은 협업이 아닌, 분업에 가깝습니다.
우리는 협업하는 방식에 대해서 배워본 적이 없지요.
협업하는 방식을 어떻게 배울 수 있는가?
협업을 위한 도구 <<< 넘사벽 <<< 관리
도구를 개선하는 데 집중하는 것 보다, 관리 자체의 프로세스가 잘못되지는 않았는 지 점검하는 것이 협력의 출발점

하드 스킬을 개발하는 데 초점을 맞추다 보니 소프트 스킬을 과소 평가하게 되었다.

협력을 위한 TIP
두사람 이상의 개발자가 시각화 없이 소통할 때 보다, 시각화와 함께 소통할 때 효율이 더 좋다.
추상화의 중요성, 혼자일 때 보다, 둘이상일 때 추상화의 가능성이 5배 증대되었다.
이는 서로의 생각과정에 관심을 가지게 되고
거기서 반복되는 패턴을 발견하게될 가능성이 커지기 때문이다.
설령 그게 본인의 생각과정과 일치할지라도 말이다.
신뢰자산이 높은 조직은 커뮤니케이션 효율이나, 생산성이 높다.
신뢰를 쌓는 방법?
1.
투명성과 공유, 인터랙션
자신이 한 작업물을 투명하게 공유하고, 그에 대해 피드백을 주고 받으며 인터랙션을 하는 것
그럼 공유만 하면 신뢰가 증가할까?
아니다.
하나공유, 최고공유 의 상황에서는 오히려 신뢰가 떨어졌다.
→ ‘작업물 = 나’ 인 상황이 벌어지기 때문이다.
복수공유의 상황에서 신뢰도가 증가하는 경향을 보였다 ( 작업물과 내가 분리되기 때문이다.)
더불어 성과도 좋았다.
2.
객관성의 주관성
a.
상대방에 대해 얼마나 이해하고 있는지 → 설득에 필요한 코스트 결정
품질은 상대적이다.
품질이란 단지 성능, 안정성을 의미하는 게 아니다.
품질이란 누군가에게 가치가 되는 것이다.
코드 → 팀원들이 읽기 쉬운 코드, 유지보수하기 쉬운 코드, 사용자가 만족도를 올려주는 예외처리, 버그의 원인을 찾기 쉬운 예외처리 방식.
디자인 → 사용자가 만족하는 디자인,
감정과 이성은 깔끔하게 분리할 수 없다. 감정과 이성의 혼합상태를 인정하지 않으려는 태도, 인간 이성의 위대함에 먹칠하는 것 같은 기분이 들 수 있겠지만, 명백한 사실이다.
따라서 남을 설득하려면 논리성과 객관성에 대한 환상을 버려야한다.
설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명방식을 선호하는지 이해해야 합니다.

전문가의 함정 Top Down?

전문가가 Top Down 으로 문제를 해결하기 때문에, 조직도 Top Down 으로 문제를 해결해야 한다고 생각하기 쉽다.
연구가 활발하게 이루어지는 영역은 “문제가 잘 정의된 영역” 이다.
조직이 비즈니스를 만들어가는 데 더 자주 마주하게 되는 건, “문제가 잘 정의되지 않은 영역” 이다.
전문가는 오히려,추상화와 구체화를 번갈아 가면서 작업한다.
어떤 결과물이 필요할 지 불확실성이 큰 영역에서, 처음부터 완벽하게 계획해서 무언가를 만들어 내자, 라는 건 초보자 처럼 일해보자라는 말과 동의어이다.
바통터치에 따른 오버헤드를 줄이는 방법.
한 사람이 다기능을 하게끔
협력이 쉽게 되게끔
전자는 , 바통터치가 덜 필요하게 만드는 방법
후자는 , 바통터치에 드는 비용을 줄이는 방법

빠르고 빈번한 바통터치가 일어나게 만드는 조직

삼투압적 의사소통
은연중에 서로간의 정보가 스미는 것
그렇게하려면 사람들이 물리적으로 가까운 거리에 있어야 한다.
한번에 처리되는 업무량을 작게 즉 batch size 를 작게 만들어야 한다.
공유가 빠르게 되게끔.
전략
범위
구조
뼈대
표면/비주얼
더 높은 품질을 얻고 싶다면 이 사다리를 오르락 내리락 반복해야 한다.

구글이 밝힌 탁월한 팀의 비밀

1.
팀에 누가 있는지 보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 더 중요하다
2.
심리적 안전감이 가장 높은 상관관계를 보인다
3.
팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.
실수율 → 조직의 실수 보고 문화와 관련이 깊다.
오히려 실수율이 높을 수록 심리적 안전감이 높았다.
처벌 받거나 놀림 받지 않을 거라는 믿음”
학습 속도가 빠른 팀의 리더는
학습을 기술적 도전이 아닌 조직적인 도전이라고 여겼다.
학습과 실행이 동시에 이루어지도록
실수를 탓하지 않는 분위기
통상적으로 기간내에 마무리할 수 있을 것 같은 기간의 2~3배를 산정해야한다.
90% 의 확률로 완수할 수 있다고 말한 개발자가 7 명있다면,
팀원 전부가 90% 내에 완수 가능하려면
90% 를 7 번 곱해 48% 의 확률로 예상하면 된다.
이는 동전을 던져서 나오는 면을 맞추는 확률보다 낮다.