2장 함께 #183
Comments
This was referenced Nov 24, 2023
This was referenced Dec 2, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
2장 함께
린 스타트업을 조사한 대학생들의 사례로 그들은 초기에 대상에 대한 지식이 거의 없어서 일을 제대로 나눌 수가 없었지만 초기에 일을 빨리 나눠버려 불상사가 발생했던 것
사실 일을 가장 잘 나눌 수 있는 때는 프로젝트가 완료된 시점이다.
사람들은 협력이 중요하다고 말 하지만 사례와 같이 초반에 일을 세밀하게 나누고 선을 긋는다. (그리고는 안녕)
가장 많이 형태를 띄는 각자 진행하고 나중에 만나서 서로 합쳐본다.
그 속을 들여다보면 협력은 거의 없다.
소프트웨어 관리자의 개선 우선순위
조엘 스폴스키라는 사람이 만든
개발팀 평가 테스트라는 것이 있다.이 테스트는 당시에 인기를 많이 얻기도 하고, 비판도 많이 받았다.
만약 이 테스트에 모두 '예'라도 대답한다면 완벽하다고 조엘스키는 말한다.
책의 저자는 전혀 동의하지 않으며 좋은 점이라곤 간단하다는 것이다.
여기서 발생하는 문제점은 관리자나 경영진이 각 질문의 맥락을 이해하지 못하고 단순히 12가지 질문에 예라고 답하는 것을 목표로 노력하는 경우를 말하는 것이다.
이런 경우를 문제로 보는 데 크게 두 가지의 이유가 있다.
모든 항목에 "예"라고 답하는 것이 무조건 더 낫다고 동의하기 어렵다
쓰면서 의문이였던 8번.. 프로그래머는 조용한 환경에서 일해야 한다고 주장한다.
하지만 다른 예시를 보면 팀원들이 상시 대면 의사소통할 수 있는 공간이 생산성 향상에 많은 도움이 된다고 역설한 바가 있다.
오히려 개발자에게 팀 전체가 공유할 수 있는 시끄러운 공간을 주는 것이 생산성 향상에 더 좋을 수 있다.
조용한 작업환경을 강조하다 보면 자칫 면대면 의사소통을 나쁜 것으로 생각하게 될 수 있다.
9번의 경우도 빠른 컴퓨터, 듀얼 모니터, 좋은 용량 등등 이런 것에 돈을 팍팍 쓰라는 말인데, 소프트웨어 툴의 경우 고를 때 단순히 비싼것을 생각하고 고르지 않는다.
단순 비싼 것을 고르는 것은 경영자 마인드에 가깝다.
정말 뛰어난 팀은 툴을 고를 때 여러 조건을 고려한다. (직접 수정이 가능한가?)
따라서 단순하게 '예'라고 말해서 평가가 좋을 순 없다.
12가지 질문이 개발팀 평가에서 정말 중요한 요소인가?
많은 회사의 CTO나 관리자가 이 테스트를 기반으로 소프트웨어 개발 팀을 관리, 개선하려고 한다.
과연 이 12가지가 개발팀에 얼마나 중요한 것일까?
제럴드 와인 버그는 소프트웨어 개발을 잘 관리 하려면 3가지 근본적인 능력이 필요하다고 했다.
이 분이 쓴 책 '품질 소프트웨어 관리'라는 책은 총 4권으로 각 제목은 다음과 같다.
책 제목과 와인 버그가 주장한 근본적인 능력은 일치한다.
마지막 책은 계획하지 않았던 책으로 3가지 능력을 활용해 실제 조직과 개인을 어떻게 바꿔나갈 것인가 하는 이야기이다.
실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유의 첫 번째가 관리라는 변수 때문이었다.
하지만 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선은 도구에서 일어났다.
실제 통계를 내어보니 관리의 개선은 64배의 비용이 절감되고 도구는 약 3배의 절감이 발생한다고 한다.
다시 조엘 테스트로 돌아가 가장 만만하고 쉬운 것부터 시작하는 관리자의 성향과 충돌하지 않는다.
이것이 조엘 테스트가 위험할 수 있다고 생각하는 두 번째 이유다.
자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 한다.
협력을 통한 추상화
커뮤니케이션과 협력
이제까지 전문 프로그래머 연구에서 가장 관심 받지 못했던 분야는
소프트 스킬이다.이는 커뮤니케이션이나 협력능력 같은 것을 말한다.
실제로 컨퍼런스나 강연을 들어도 실력있는, 오래 일한 프로그래머 일수록 커뮤니케이션을 강조한다.
일반적으로, 실력이 뛰어난 프로그래머는 보통 정도의 실력을 가진 프로그래머에 비해 커뮤니케이션, 협력 능력이 더 뛰어나다. (반면 코딩, 테스팅에 들이는 시간은 별 차이가 없다.)
백지장도 맞들면 찢어진다?
협력하면 밑천도 못 건진다고 생각하는 사람도 많다.
과거 '부분의 합보다 큰 전체'라는 이야기가 나왔던 것 처럼, 실력이 뛰어난 사람은 혼자 일하게 둬야 한다고 주장하는 사람도 있었다.
하지만 최근의 연구 결과는 반대의 이야기가 늘어나고 있다.
그냥 협력이라고 좋은 것이 아닌 몇 가지 전제 조건이 필요하다는 것이다.
예컨대 두 사람이 시각화 없이 헙력하는 것(전화, 텍스트)보다 중간 매개(화이트 보드, 종이)를 두고 협력하는 것이 훨씬 낫다등의 연구 결과가 있다.
톱니바퀴 실험
스탠퍼드 대학교의 심리학자인 대니얼 슈와르츠는 같은 문제를 혼자 푸는 경우와 두 사람이 함께 푸는 경우의 차이에 대한 연구를 시행했다.
이런 문제를 일곱 개를 낸다.
문제에서 톱니바퀴의 수는 각기 3, 4, 5, 6, 7, 8, 9로 증가(뒤섞인다.)하며 마지막 문제의 경우 131개라는 바퀴수를 낸다.
처음에는 다들 허공에 손을 돌리며 풀다가 일종의 법칙(패리티 법칙으로, 톱니바퀴 개수의 홀짝 여부에 따라 좌우측 바퀴의 회전이 결정됨)을 발견하고 그 때부터는 허공에 손을 내젓지 않고 답을 한다.
일곱 번째 문제까지 추상화된 규칙을 찾아내는지 그렇지 못한지를 살펴보았더니, 혼자서 작업한 경우는 14%만이 추상화 규칙을 찾아냈다.
반면 둘이서 작업한 경우 58%나 이 규칙을 찾아내었다. (4배가 넘는다.)
이런 차이가 생긴 이유는 두 사람이 서로 같은 문제를 이해하거나 혼동을 해결하기 위해서 추상적 개념을 도입한다는 것이다.
둘이서 협력하면서 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해 줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다.
되게 흥미로운 내용으로 코드로 따지면 서로가 이해할 수 있는 하나의 인터페이스를 설계한 것과 같은 것 같다.
추상화의 중요성
객체지향 프로그래밍에서 코드의 중복을 줄이다보면 흥미로운 객체들이 발견되는데, 함수형에서는 함수와 함수의 함수를 발견한다.
이는 모르던 것을 배우게 하기도 하고, 프로그래머의 영역을 넘어서 고객들의 대화가 바뀌기도 한다.
이런 객체들을 발견하지 못했다면 너무 고리타분한 코딩은 아닐까 생각한다.
여기서 '흥미로운 무엇'이 바로 추상화다.
특히 예상하지 못했던 추상화로, 말하자면 창발적 추상화라고 할 수 있다.
읽으면서 생각이 들지만 추상화란, 지금 우리가 믿고 있는 개념, 이데올로기에도 포함되어 있다고 생각한다. 신을 믿거나 자본주의, 화폐의 개념또한 추상화에 가깝다.
추상화는 이토록 중요한데, 그렇다면 추상화를 높이는 방법은 뭐가 있을까?
이번 소제목은 협력을 통한 추상화로, 톱니바퀴 실험을 통해 알 수 있듯이 협력을 통해 추상화 수준을 높일 수 있다.
대화하는 프로그래밍
짝 프로그래밍에 관한 이야기로, 두 사람이라는 구성은 대화를 통해 추상화를 높이게 한다.
짝 프로그래밍의 조금 낮은 버전이 코드리뷰의 형태라고 생각한다. 엄연히 다르지만..
신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가
최근
신뢰 자산이 높은 조직은 커뮤니케이션 효율이나 생산성이 높다는 등의 연구가 많이 있다.그렇다면 어떻게 신뢰를 쌓을 수 있을까?
신뢰를 쌓는 데에 많이 쓰이는 방법은
투명성과 공유, 인터랙션이다.자신이 한 작업물을 투명하게 서로 공유하고 그에 따라 피드백을 주고 받으며 인터랙션하는 것이다.
조직에서의 신뢰를 연구하는 사람들은 이런 것을 소통 신뢰라고 한다.
그런데 과연 그렇게 공유하고 소통하면 신뢰가 쌓일까요?
공유 조건별 신뢰도 변화 실험
두명의 디자이너가 각자 고인 단체를 위한 광고를 디자인 한다.
주어진 시간 동안 개별적인 디자인이 끝나면 두 사람은 한 방에 모여서 서로 디자인을 공유하고 피드백을 나누며 인터랙션을 한다.
그러고 각자 돌아가서 자신의 최종 버전이 될 광고를 다시 새롭게 만든다.
이 최종 버전은 전문가 평가나 클릭률 등을 통해 실제 성과를 측정하게 된다.
첫 광고 디자인을 시작하기 전에 상호 간의 신뢰 정도를 측정했다.
그리고 한 방에서 공유하고 다시 상호 간 신뢰를 측정했다.
5개의 질문에 답하는 것이였는데, 대부분 SVI라고 하는 측정 도구의 관계 항목을 사용하였다.
결과부터 말하면 신뢰감이 떨어졌다.
공유를 해서 신뢰감이 떨어진 상황이 발생한 것
다른 조건으로 실험을 진행했는데 신뢰감이 유의미하게 증가했다.
디자이너들이 각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우였다.
신뢰면에선 최악인 안 하느니만 못한 좋은 결과물의 공유보다 상대방에게 불안감을 가지는 "이걸 보고 흉을 보면 어쩌지"와 같은 상황이 더 신뢰감을 주는 이유는 뭘까?
복수 공유의 장점
복수 공유는 작업자가 부정적으로 피드백을 수용하려는 마음도 많아진다.
여러개를 준비했으니 그중 하나를 두고 뭐라고 해도 나에 대한 공격은 아닌 것이다.
또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고, 듣는 사람도 좋다는 이야기랑 안 좋다는 이야기를 같이 들으니 마음이 좀 더 편하다.
또한 복수 경우의 실제 결과에서도 피드백 수용률이나 개선정도도 더 크다는 것이다.
가장 중요한 부분은 복수 경우는 성과도 더 좋아졌다는 사실이다.
과연 나는 신뢰를 깎아 먹는 공유를 하고 있었을까? 아니면 신뢰를 쌓아가는 공유를 하고 있었을까?
복수 공유의 특징 즉, 투명한 공개와 시행착오의 공유는 회고의 또 다른 형태로 보인다.
객관성의 주관성
애자일 같은 새로운 개념을 주변에 설득하기 위해 노력하는 사람들이 있다.
어떤 측정 자료를 근거로 해여할지, 효과적인 사례는 뭐가 있는지 등등..
사실은 이런 자료에 근거한 것 보단 상대방에 대한 이해가 먼저 선행되어야 한다.
책에선 함수 포인터에 대한 설명으로 강사와 학생의 입장으로 보여준다. (실패하는 이유)
품질은 상대적이다
실제로 사용되는 품질의 정의와는 조금 다른 느낌인데, 실생활에서 사용되는 품질의 경우
성능이 얼마나 좋은가?,요구사항과 얼마나 일치하는가?등으로 품질을 이야기 하곤 한다.하지만 이런 정의는 상당히 플라톤적이며, 고상하고 완벽한 품질이라는 것이 존재한다고 생각한다.
반해, 와인버그의 주장은 상대적이며 동시에 실용적이다.
사실 품질은 사람을 빼놓고 이야기할 수 없다. (사람이 없으면 품질이라는 개념 자체가 없다.)
결함또한 상대적으로 정의된다.
이런 이유로 품질 관련 일을 하는 사람들, 고품질을 얻으려고 노력하는 사람들은 '인간'에 대한 이해가 필수적이라고 한다.
설득도 마찬가지로 사람들을 설득하기 위해선 객관성이 필요하다고 생각한다.
그런데 이 개념 자체가 매우 주관적이라는 것이다. (인지적 편향의 발생)
결국 결정하는 것은 사람이다.
객관성을 확보하기 위해 데이터를 수집하고 분석하는 것은 좋은 방법이지만, 이것만으로는 부족하다.
마음에 들지 않으면 객관적 자료를 갖다 줘도 설득할 수 없다.
감정을 배제할 수 없다
하지만 논리적이라는 것도 상대적이고, 논리랑 감정적 판단을 분리할 수가 없다.
다양한 연구 사례에도 불구하고 사람들은 이성과 감정은 분리할 수 있다고 생각한다. (나아가 그렇게 해야한다고 생각한다.)
따라서 설득에는 상대방에 대한 대화와 이해가 필요하다.
성향과 기질에 따른 애자일 설명법
KAI라고 하는 사람의 인지 성향에 대한 이론을 빌려서 애자일을 설명해본다.
MBTI도 마찬가지로 큰 그림을 그리는 NT, 사람들관의 관계에 관심이 많은 NF, 구체적이며 체계적인 SJ, 모험을 좋아하고 닥친 문제를 푸는 것을 즐기는 SP 이렇게 4가지로 구분하여 설명한다.
결론은 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대방의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말이다.
그러므로 설득을 하기 위해 객관적 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 합니다!
이것도 모르세요?
대부분의 사람들은 질문을 쉽게 하지 않는다.
그리고 데드라인 다 되어서 "못했습니다."라고 이야기를 한다. (or 어느정도 노력한 흔적, 연기, 그럴듯한 결과물을 가져온다.)
홍춘이와 술퍼맨의 대화에서 명백하게 홍춘이의 잘못이다.
(질문 방식에 대한 조언을 하려면 먼저 답변을 해주고 더 좋은 접근 방법을 소개시켜 준다.)
공감하고 이해하려는 대화
이번 대화에서 중요한 점은 답변자가 질문자의 어떤 멘탈 모델(개인이 갖고 있는 믿음과 생각)을 파악하려고 했다는 점이다.
이런 과정을 통해 답변자는 질문자의 사고방식을 어느정도 엿볼 수 있고, 답변자는 질문자의 사고방식을 파악할 수 있다.
그렇게 되면 이 상황에서 왜 이런 접근을 했는지, 할 수밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 답변을 할 수 있다.
이 방법은 누가 물어볼 때뿐만 아니라 실수나 잘못을 했을 때도 효과적으로 도움을 줄 수 있다.
능력없는 팀장일수록
비난만 한다.나중에 비슷한 일이 생기게 되고 악순환이 반복되게 된다.
하지만 훌륭한 팀장이라면 먼저 그 사람의 사고 과정과 전략을 이해하려고 한다.
행동을 유도하는 대화
여기서 좀 더 나아가서 다음 행동을 유도하는 코칭까지 나갈 수 있으면 더욱 좋다.
행동으로 옮길 수 있도록 공감을 통해 상대방의 멘탈 모델을 참고하여 적절한 질문을 하고, 해당 답변을 통해 스스로 행동할 수 있도록 유도한다.
이 과정은 10분이면 충분하고, 흥미로운 점은 코치 자신이 해당영역에 전문지식이 없어도 코칭을 할 수 있다는 점이다. (공감의 효과)
하향식 접근의 함정
우리는 일정의 미신을 갖고 있다. "전문가는 언제나 탑다운으로 깔끔하게 생각할 것이다."
탑다운은 문제 해결 과정을 시간의 흐름에서 볼 때 추상적인 숲에서 출발해서 점점 더 구체적인 나무로 내려오는 접근법을 말한다.
그 반대라 할 수 있는 바텀업은 나무에서 출발해서 숲으로 올라오는 과정이다.
탑다운은 더 깔끔해 보이는데, 바텀업 탐색적인 성격이 많다.
여기저기 찔러보거나 방향을 바꾸기도 한다.
기업이나 실제 전문가들은 탑다운의 모습을 띄기도 한다. (특히 기업에서 많이 보인다.)
인공지능 연구에선 이 세상의 문제를 두 종류로 나눈다.
잘 정의된 문제와 잘 정의되지 않은 문제.
잘 정의되지 않은 문제는 출발 상태와 목표 상태가 명확히 알려져 있고 그 상태 간 이동의 규칙이 주어진 문제를 일컫는다.
오목이나 체스 같이 승패와 말의 이동 규칙이 명확한 게임
하지만 "벽을 장식할 아름다운 그림을 그리시오" 같은 문제는 잘 정의되지 않은 문제다.
무엇이 목표 상태인지 불분명하다.
심지어 최초의 출발 상태에 대한 정보도 온전히 주어지지 않고, 무엇이 적법한 행동이고 부적법한 것인지 규칙의 경계도 불투명하다.
잘 정의된 문제는 연구하기가 쉽기 때문에 많은 연구가 이루어졌다.
하지만 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제이다.
사실상 뭔가 만들어야 하는 문제, 디자인이 개입더ㅣ는 것은 거의 다 제대로 정의될 수 없는 문제다.
실제 전문가들은 자신이 자주 접하지 않았던 문제를 만나면 접근법을 바꾼다.
탑다운과 바텀업을 섞어 사용하는데, 뛰어난 전문가일수록 더욱 그러하다.
이런 현실에도 우리는 이 믿음을 협력 방식에도 도입하여 사용한다.
오히려 전문가일수록 불확실한 일에서는 초보자의 마인드로 돌아가고 비전문가일수록 탑다운으로 접근한다.
비전문가는 계획을 수정하지 않고, 전문가는 계획을 많이 수정한다.
빠르고 빈번한 바통 터치가 가능한 전문가 조직
오버헤드를 낮추려면 협력 모델이 바통 터치 모형에 기반하지 않고 삼투압 모형에 기반해야 한다.
뛰어난 팀들의 몇 가지 특징으로 대부분 삼투압적 의사소통이라는 특징을 보인다.
삼투압적 모형은 화살과 같은 모형이 아닌 은연중에 스며드는 것이다.
전문가팀이 실패하는 이유
사업을 하는 사람들이 흔히 버스에 사람 태우기라는 메타포를 이야기하곤 한다.
이 메타포를 사용하는 사람은 상당수는 '뛰어난 사람'을 뽑는 것이 얼마나 중요한가를 말하기 위해 이 비유를 든다.
그들에게 있어서 뛰어난 사람은 해당 전문 분야의 역량이 뛰어난 사람을 의미한다.
소프트웨어로 따진다면 남들보다 뛰어난 개발 실력을 가진 사람으로 어려운 기술을 잘 쓰면서 남들보다 짧은 시간에 코드를 만들어 내는 능력이 될 것이다.
하지만 뛰어난 사람을 뽑아두면 어떻게든 잘할 거라는 사고가 지나치게 낙관적인 기대라고 생각한다.
실제 연구 결과에서도 가장 뛰어난 팀을 골라서 만든 올스타팀 (롤 올스타전과 같이)의 결과는 스타들이 한 명씩 추가될 때마다 한계효용(점차 줄어든다.)을 보이며 어느 수준을 지나면 음의 방향으로 작용한다고 한다.
결국 결과가 더 안좋아지고 이 실상 이팀의 비용도 생각하지 못한 것으로 비용까지 따지게 되면 더욱 안좋아진다.
비전문가와 전문가를 데리고 실험을 했는데 단순 전문가를 모아둔다고 해서 높은 성과가 나오지 않은 것이다.
정리하자면 전문가들 모아서 팀을 만든다고 잘하는 것이 아니고, 오히려 성과가 떨어질 수 있고, 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며, 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.
구글이 밝힌 탁월한 팀의 비밀
구글은 뛰어난 팀의 특징을 찾기 위해 옥시전 프로젝트 이후에 아리스토텔레스 프로젝트를 진행했다.
여기서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌 받거나 놀림받지 않을 거라는 믿음을 말한다.
그렇다면 심리적 안전감을 높이려면 어떻게 해야 할까?
앞에서 언급한
팀 토론 등 특별히 고안된 활동을 통해 토론 주제를 안전한 환경에서 이야기하게 해주는 것 자체가 심리적 안전감을 높일 것이다.단순히 우리팀의 현상황에 대해 연린 대화를 시작하는 것만으로 변화가 시작될 수 있다고 생각한다.
"팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터랙션을 보여주고 있나요?"
쾌속 학습팀
패러다임 전환, 죽느냐 사느냐
기술적 변화는 언제 어디서든 찾아올 수 있다.
이를 패러다임의 전환이라고 하며, IT업계에서는 전환 주기가 짧아서 더욱 빠르게 변화가 일어난다.
개발자에게 있어 학습이라는 것, 더 나아가 빠른 학습이라는 것은 늘 고민거리이다.
최소 침습 심장 수술
그렇다면 팀의 학습속도를 높이기 위한 방법이 뭐가 있을까?
실제 수술팀의 경우 팀 학습의 가장 대표격으로 이야기가 되는데, IT업계의 개발팀도 마찬가지의 형태이다.(각 분야로 나눠진 전문가들)
실제 수술팀에 어느정도 러닝커브가 있는 시술법(새로운 기술)을 학습하게 하고 이를 실험해봤는데, 각 팀마다 천차만별의 결과를 도출했다.
학습 속도와 상관없는 것
학습 속도와 상관 없는 것에는 교육 배경, 수술 경험 등 은 학습 곡선의 기울기에 영향을 주지 못했다.
참고로 의사의 실력, 예컨대 수술 성공률과 경력 연차가 통계적으로 상관성이 없다는 널리 알려진 사실이다.
따라서 무조건 젊은 의사라고 신뢰하는 것은 좋지 못하다.
리더가 팀 학습 속도에 미치는 영향
논문 결과에서도 기술적 탁월함을 갖춘 사람 보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것이다.
학습 환경의 차이
학습이 빠른 팀은 팀원을 뽑을 때부터 달랐다.
선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라, 선발 기준도 달랐다.
단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았다.
또한, 속도가 빠른 팀은 새로운 수술 도입을 기술적 도전이라기보다 조직적 도전으로 받아들였다.
개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.
마지막으로 속도가 빠른 팀은 심리적으로 보호가 되고 있었다.(새로운 것을 제안하고 시도하는 데 두려움이 없음)
기술 전환에 성공한 개발팀
개발도 마찬가지로 PHP에서 자바로 이동에서 자바를 능속하게 하는 사람이 있는지가 중요한 것이 아닌, 리더와 팀원들의 학습에 대한 태도가 근본적인 차이였다.
리더가 기회와 가능성, 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했다.
반면 느린 팀은 그것을 개인 과제정도로 생각하고 실력이 부족하다고 불평을 자주 했다.
현실에서 실천하기
우선 자신의 학습 환경을 만드는 것이 중요하다.
개별 기술 이상으로 일하는 방식에 대해 실험을 해보고, 실패에 좌절하지 말자(사실 실험에는 실패는 없다. 학습만 있을 뿐)
학습과 일을 굳이 분리하지 말고 동체로 만들 것, 학습과 실행은 하나이다.
이 말의 힘을 느끼려면 정반대를 생각해볼 것
프로젝트 확률론
어디에 돈을 걸 것인가
생략
직관의 허점
위 사례에서 보여주는 직관의 허점을 말해준다.
(사실 나는 첫 번째 문제에 2번 두 번째 문제에 2번을 선택했다..)
이번 프로젝트는 제때에 끝낼 수 있을 것 같았는데
이제 프로젝트로 바꿔서 생각해보자.
우리는 흔히 통상 시간을 추정할 때 대푯값으로 최반값을 선택하는 경향이 있다.
개발자는 약속이 아닌 대부분의 추정을 한다.
그 추정은 대부분 어긋나기에 더욱 더 중요하다.
애자일 확률론
애자일 프로젝트라면 어떨까?
관심사의 섞임을 통해 일의 병렬처리가 아닌 협동을 중시한다.
고전적인 방법과 달리 일을 공유하고, 각자 일을 얼마나 진행했는지 매일 공유할 뿐 아니라 내 일, 네 일의 구분선이 뚜렷하지 않다.
애자일에선 일이 빨리 끝나면 다른 사람의 일도 자신의 일이기에 자연스럽게 협동하게 된다.
개개인이 같은 일을 따로 처리하는 것이 아닌 팀으로써 일을 처리하는 것이다.
마무리
2장은 함께라는 주제에 맞게 팀이 어떻게 협력하고, 어떻게 협력을 통해 성과를 내는지에 대한 이야기를 했다.
팀이라는 것은 한 덩어리이며 같이 굴러가야 한다는 점과 지금 내가 진행하고 있는 프로젝트에 적용하고 싶은? 필요한 내용이 많아서 좋았다.
The text was updated successfully, but these errors were encountered: