잘하기 vs 자라기 - '함께 OOO' 책을 읽어봤습니다

thinkySide·2024년 7월 14일
5
post-thumbnail

🧐 책을 읽게 된 이유

요즘 책 읽기가 부쩍 재밌어졌다! 개발 공부를 위해 공식 문서, 블로그를 떠돌아다니는 것도 재밌지만 책 읽기만의 매력을 느꼈달까?,,, 핵심 주제에 대해 심도 있게 파고들며 많은 생각을 할 수 있게 해준 다는 점이 가장 크다고 느낀다.

가끔은 반복되는 말을 하는 것 같은 느낌도 들지만, 그래서 더 소중하다! 함께 자라기에서도 언급했듯이, 무슨 책을, 얼마나 많은 책을 읽었다고 자랑하는 것이 아닌 여기서 얻은 지식을 얼마나 어떻게 활용했는지를 돌아보려면 그 맥락에 대한 깊은 이해가 필요하기 때문이다.

역시 나는 책을 많이 읽는 것보다, 책을 잘 읽는 것에 더 관심이 간다.

아카데미에서도 꽤나 유명한 '함께 자라기'를 지나가듯 들었던 기억은 있었지만 읽을 생각은 하지 않고 있었다. 가장 큰 이유는 자기 계발서에 나오는 내용들보다 개발 지식이 지금 내게 더 가치 있다고 느꼈기 때문이었다.

그리고 여느 때처럼 보노와 열띤 이야기 중에(개발 얘기만 나오면 시간 가는 줄 모름) 하드 스킬적인 내용은 아니지만, 개발자의 관점에서 배울 점이 분명하다는 말과 함께 이번 책을 추천받게 되었다.

보노라면 좋은 책을 추천해 줄 것이라는 믿음을 가지고 있었기 때문인지 "어, 한번 읽어봐야겠는데?"라고 마음이 바뀌었고, 게다가 때마침(?) 룸메이트가 가지고 있어 "어디 한번 읽어보자!"라는 마음으로 책을 펼치게 되었다.(에이스야 고마워)

🌳 느낀점 적어보기

나는 성장하고 싶다. 어제보다 나은 내가 되기 위해 하루하루 열심히 노력하고 있다. 그만큼 성장에 대한 고민도 많이 했다. 아니, 많이 했다 생각했고 그렇기에 나름의 방법도 있었다. 내가 바라보고 있는 '성장'이 무엇인지 잘 안다고 확신했었다.

하지만 이 책을 읽으며 내가 정의하고 있는 '성장'이 무엇이었을까? 되돌아보게 됐다. 성장을 위해 학습 방법을 학습해야 한다는 것의 필요성을 느끼게 됐다.

저자는 성장과 관련된 여러 가지 키워드를 제시한다. 애자일, 사회적 자본, 삼투압적 의사소통, 협력, 피드백, 추상화, 공유, 설득, 실수에 대한 인정, 심리적 안전감, 학습 환경을 만드는 리더 등이다.

그리고 모든 키워드는 하나의 본질적인 것으로 귀결된다. 바로 '사람'이다. 역설적이게 들릴 수도 있겠지만, 내가 성장하고 싶다면 다른 사람과 함께 성장해야 한다. 이것이 내가 느낀 이 책의 핵심 문장이다.

언뜻 보기에 효율적이지 못하다고 생각할 수 있다. 내가 해야 할 일도 많은데 언제 다른 러너에게 피드백을 주고 있겠는가? 동료의 실수로 문제가 생겼다면 그 책임은 당연히 그가 짊어져야 할 것이다. 기획 이후 디자인 팀과 개발팀의 대화는 적어지는 게 누가 봐도 합리적일 것이다.

우리는 수도 없이 이런 상황들을 마주쳐왔다. 성장의 포커스가 '나'에 맞춰져 있기 때문이다. 당장은 빠를 수 있다. 기능을 하나 더 완성할 수도 있고, 책임에 대한 스트레스를 받을 일도 없을 것이고, 오로지 '내 일'에만 집중할 수 있다 생각할 것이다.

하지만 그뿐이다. 만약 성장했다고 해도 더 큰 기회를 잃은 것이라 확신할 수 있다.

동료와의 피드백에 시간을 쓰지 않겠다는 것은, 관계적으로든 역량적으로든 피드백을 받는 것도 어렵게 만든다. 이는 내 성장의 관점에서 발전도 어려울뿐더러 문제가 있더라도 전혀 인지하지 못할 것이다.

실수에 대한 책임을 동료에게 돌린다는 것은, 결국 나의 실수도 인정되기 어렵다는 뜻이다. 이는 창의성과 자율성을 해치고 오히려 더 큰 실수를 불러올 수 있다. 실수를 통해 배움을 기대하는 것이 아닌 불안함만 남게 되는 것이다.

팀 간의 커뮤니케이션이 적어진다는 것은, 반대로 '내 일'에 더 집중하지 못하게 만들 것이다. 커뮤니케이션이 적어지니 요구사항에 대한 이해도가 떨어져 개인적으로 자주 연락해야 할 것이며, 작업을 여러 번 다시 하는 상황이 발생하다 보니 일정이 지연되고 결국엔 팀 간 갈등으로 번질 수도 있다.

하지만 늘 그렇듯, '다른 사람과 함께 성장하기' 같은 눈에 보이지 않는 것을 좇는 일은 어렵다. 그래서 우리는 상황을 '언뜻' 보지 말고 '세심하게' 봐야 한다. 당연하지만 당연하지 않은 것을 위해, 내 성장과 동료들의 성장을 위해 다시 한번 마음에 새기자.

동료의 말과 피드백에 귀 기울이자.
동료의 실수에 대해 같이 책임지고, 회복할 수 있게 돕자.
팀 간의 커뮤니케이션과 공유를 위해 노력하자.
성장의 포커스를 나에서 '우리'로 재조정하자.

마지막으로 누군가에겐 걱정이 가득한, 새로운 기회를 찾고 있는, 꿈꾸는 것을 만들기 위해 고민 중일 모든 러너 분들께 내가 얻은 소중한 질문을 드리고 싶다.

"함께 성장할 수 있나요?"

이 질문은 앞으로도 내게 이정표와 같은 역할로서 성장의 길을 이끌어 줄 것이다!

📝 메모 내용 정리


머리말

지금 잘하냐?가 아니라 지금 자라냐.

우리가 정말 매일매일 함께 자랄 수 있을까?


1장: 자라기

학교 학습 <-> 야생 학습

야생 학습?

  • 대부분 협력적이다.(학교는 대부분 개별적이다.)
  • 대부분 비순차적이다.(학교는 대부분 순서가 정해져있다.)
  • 대부분 자료에 한정이 없다.(학교는 대부분 교과서, 교재, 시험범위가 있다.)
  • 대부분 명확한 평가가 없다.(학교는 대부분 시험이 있다.)
  • 대부분 정답이 없다.(학교는 대부분 정답이 명확하다.)
  • 대부분 목표가 불분명하고 바뀌기도 한다.(학교는 합격, 자격증과 같은 목표가 있다.)

학습 방법을 학습해야 한다!


1-1. 당신은 몇년차?

경력 연차로 채용 여부나 임금 수준을 결정한다는 것은
판단 편의적이고, 관료주의적이며, 결과적으로 조직에 손해를 줄 수 있는 방식.

직무 성과와 상관성이 낮은 것들

  • 학력 : 0.10
  • 경력 : 0.18
  • 관심사 : 0.10
  • 필체 : 0.02
  • 나이 : -0.01

직무 성과와 상관성이 높은 것들

  • 작업 샘플 테스트 : 0.54
  • 아이큐(지능테스트) : 0.51
  • 구조화된 인터뷰 : 0.51
  • 성실성 : 0.41

결론?
경력과 실력을 동등하게 보는 함정에 빠지면 잘못된 전문가상을 갖게 될 수 있다!

조직은 개인이 자신의 전문성을 좀 더 발전시키고 관리할 수 있도록 최대한 지원해야 한다.
그것이 윈윈하는 길!

애자일 프로젝트는 지금 내가 한 행동의 피드백
10분 후, 1시간 후, 하루 후, 일주일 후 등 여러 주기를 통해 지속적으로 얻을 수 있다.

학습은 피드백이 중요하다.

피드백 시점도 중요하다 → 너무 오래걸리면 효과가 떨어진다.

자기계발은 복리로 돌아온다.

더 빨리 자라고 싶다면?

  1. 어떻게 이율을 높일 것인가?
  2. 지속적으로 현명한 투자를 어떻게 할 것인가?

매일 더 나은 내가 된다.

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

  • 새로운 것을 유입시키는 데에만 집중하다 보면 새로 들어온 것들이 이미 있는 것들을 덮어버릴 수 있다.
  • 자신이 올해 몇 권을 읽었다고 자랑하지 말고 내가 그 지식을 얼마나 어떻게 활용하는지 반성하라.
  • 이미 갖고 있는 것들을 하이퍼링크로 서로 촘촘히 연결하라.
  • 새로운 것이 들어오면 이미 갖고 있는 것들과 충돌을 시도하라.
  • 현재 내가 하는 일이 차후에 밑거름이 될 수 있도록 하라.

2. 외부 물질을 체화하라.

  • 계속 내부 순환만 하다가는 일정 수준에 수렴할 위험이 있다. 주기적인 외부 자극을 받으면 좋다. 단, 외부 자극을 받으면 그걸 재빨리 자기화해야 한다.
  • 외부 물집 유입 이후 생긴 내부의 갈등을 해결하려는 데에 노력을 기울여야 한다.

3. 자신을 개선하는 프로세스에 대해 생각해보라.

  • 나의 작업을 되돌아보는 회고/반성 활동을 주기적으로 하는 프로세스를 만들어라.
  • 나를 개선하는 과정을 어떻게 하면 개선할 수 있을지 고민하라.

4. 피드백을 자주 받아라.

  • 사이클 타임을 줄여라. 새로운 정보를 얻었다면 1년 후에 크고 완벽한 실험을 하려고 준비하기보다는 1달, 혹은 1주 후에 작게라도 실험해 보는 것이 좋다.
  • 순환율을 높여라.
  • 일찍, 그리고 자주 실패하라. 실패에서 학습하라.

5. 자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라.

  • 완벽한 도구와 환경을 갖추는데에 집착해서는 안된다. 그런 식으로는 무엇도 영원히 얻을 수 없다.
  • "방이 조용해지고 배도 안 고프고 온도도 적절해지기만 하면 공부 시작해야지"라고 생각하는 사람들 중에 1등은 없다.
  • 또한 실제로 그런 환경이 되어도 몸에 배어든 습관 때문에 결국은 공부하지 못할 것이다.

1-2. 학습 프레임과 실행 프레임

실험 프레임은 여러분의 목표가 학습을 통한 성장이라면 불리한 선택이다.


1-3. 가장 학습하기 힘든 직업이 살아남는다.

알파고 같은 인공지능 시대에 대비하려면 배우기 힘든 것에 집중하라.

피드백이 주어지고 작업이 반복되며 객관적 분석이 가능한 경우에 해당 직업에서 전문성이 잘 드러난다.
-> 학습이 잘 일어나는 조건

컴퓨터화에 병목이 되는 3가지 카테고리

  1. 지각과 조작
  2. 창의적 지능
  3. 사회적 지능

3가지 카테고리에 속하는 변수

  1. 독창성
  2. 사회적 민감성
  3. 협상
  4. 설득
  5. 타인을 돕고 돌보기

어떤 직업을 컴퓨터화 할 수 있는 확률이 높을수록, 해당 임금이 낮았음.

소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며,
그 과정에서 타인과 상호작용하는 업무가 많다.
→ 개발자는 더 높은 수준의 협상 능력이 필요하다!

자신이 주로 하는 일이 남이 시킨 대로 혼자 프로그램을 만드는 것이라면 그런 스킬과 경력만 계속 쌓일 것이다.

지금이라도 암묵지와 직관을 배우고 수련하는 방법을 배우면 된다.


1-4. 달인이 되는 비결

꾸준한 반복으로 달인이 되려면?

  1. 실력을 개선하려는 동기
  2. 구체적인 피드백을 적절한 시기에 받기

특정 영역에서 개인이 성취할 수 있는 최고 수준의 퍼포먼스/경험을 오래한다고 해서 자동으로 얻을 수 있는 것은 아니다.


1-5. 수십년 동안 전문가가 안되는 비결

믿을 수 있는 직관이 형성되려면 특정 조건이 필요하다.

  • 전문성 향상을 위해선 타당성과 피드백을 높이는 환경을 만들자!

  • 타당성을 높이려면 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려는 노력!

  • 피드백을 높이려면 동료, 상사, 고객에게서 혹은 내가 개발하는 프로그램에서 직접 피드백을 적극적으로 구하기!


1-6. 당신이 제자리 걸음인 이유

실력을 높이기 위해서는 의도적 수련이 중요하다.

의도적 수련을 효과적으로 하기 위해서는?

  • 동기와 피드백이 중요하다.
  • 나의 실력과 작업의 난이도가 비슷해야 한다.

의도적 수련의 필수 요건 중 하나가 '적절한 난이도'

자신이 업무 시간 중에 불안함이나 지루함을 느끼는 때가 대부분이라면, 실력이 도무지 늘지 않는 환경에 있는 것.

하지만 우리에겐 매번 몰입하는 일만 주어지진 않는다...

a1 : 작업의 난이도는 그대로 두고 실력을 낮추는 전략

  • 키보드만 써보기
  • 디버거 안쓰기
  • 컴파일 30초 -> 5분마다하기

a2 : 실력은 그대로 두고 난이도를 높이는 전략

  • 하루만에 해야하는 일을 1시간 만에 할 수 있는 방법 고민하기
  • 100RPS 시스템이면 되지만 1000RPS 까지 만들기
    - Requests Per Second? -> 웹 서버나 API의 성능을 측정하는 지표로, 특정 시간 동안 얼마나 많은 요청을 처리할 수 있는지를 나타냄
  • 평소 코드를 검토할 때 버그를 시간당 1개 찾기 -> 2개 찾기
  • 익숙한 작업을 새로운 언어로 해보기
  • 공식적으로 안해도 되는 업무를 자신의 의지로 추가하기
  • 리팩토링
  • 자동화 테스트
  • 자신만의 방법 개발(도구 만들기)

b2 : 실력 높이기

  1. 사회적 접근
    • 나보다 뛰어난 전문가의 도움 받기
    • 인터넷 채팅
    • 페어 프로그래밍
    • 튜토리얼
  2. 도구적 접근
    • 내 능력을 확장해 줄 수 있는 도구 찾기
    • 디버거
    • 자동 통합 도구
    • 코드 분석 툴
    • 오픈 소스 라이브러리
  3. 내관적 접근
    • 비슷한 일을 했던 경험을 머릿속으로 되살려 보기
    • 비유적 문제 해결
    • 자기 효용감 증대

b1 : 난이도 낮추기

  • 자신이 맡은 일의 가장 간단하면서도 핵심적인 결과물, 즉 아기 버전을 첫번째 목표로 잡는 것.

현재 자신의 업무 처리 속도가 외부적으로 문제가 되지 않는 범위 내에서 적절하게 난이도와 실력을 조정해야 한다.

메타인지는 모든 분야의 전문성에 있어서도 핵심적인 요소다!


1-8. 프로그래밍 언어 배우기의 달인

새로운 언어를 효과적으로 익히는 달인의 방법

  1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.
    • 튜토리얼을 읽다가도 이 정도면 그 프로그램을 작성할 수 있겠다는 생각이 들면, 그 자리에서 읽기를 멈추고 코딩을 시작한다.
    • 그리고 완성하면 다시 돌아와 계속 읽는다.
    • 적극적 읽기를 실천하는 것.
    • 첫번째 목표는 단어 개수 세기 프로그램을 짜는 것.
  2. 공부할 때 표준 라이브러리 소스코드를 읽는다.
    • 해당 언어의 문화와 스타일을 익힌다.
  3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.
    • 실질적인 사용 예를 통해 실제 코드의 감을 익히기.

전문가들의 전문성을 뽑아내고 적용하는 것이 자신의 전문성을 빨리 높일 수 있는 방법.

전문성을 뽑아낼 수 있는 질문?

  • 프로그래밍 언어를 빨리 배우는 비결이 뭔가요? ❌
  • 구체적인 사건에 대해 말하도록 유도하기 ✅

무엇인가 잘하고 싶다면 이미 잘하는 사람을 관찰하고, 인터뷰하는 것부터 시작하는 것이 큰 도움!

  1. 전문가를 만나고
  2. 구체적 사례 듣기

1-9. 실수는 예방하는 것이 아니라 관리하는 것이다

실수 관리 문화는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생긴다.

실수가 없으면 학습하지 못한다.

불확실한 상황 하에 실수는 피할 수 없다.


1-10. 뛰어난 선생에 대한 미신

지식이 많은 사람을 뛰어난 선생으로 보는 시각은 앞에서 말한,
교육의 효과를 결과가 아니라 투입으로 측정하는 것과 비슷한 오류가 있다.

선생 입장에서는 자신에 대한 메타인지를 높이는 노력하기

  • 내가 이 문제를 해결할 때 어떤 과정을 거치는가?
  • 자신의 머릿속을 관찰하고, 질문을 던지고 분석하기

1-11. 나홀로 전문가에 대한 미신

아무리 기술적인 실천법이라고 해도 그 기술은 사회적 맥락 속에서 실천되어야 하며, 그 기술의 성공을 위해서는 사회적 자본과 사회적 기술이 함께 필요하다.

신뢰가 깨져있는 상태에서는 어떤 행동을 해도 악의적으로 보인다.

신뢰 == 사회적 자본의 일종

뛰어난 소프트웨어 개발자일수록 타인과 인터랙션에 더 많은 시간을 쓴다. → 동료와의 협업

사회적 기술 훈련 → 마이크로 인터랙션 → 인사 주고 받기, 지나가는 대화 물어보기 등

저자가 중요하게 다루는 사회적 기술

  • 도움 받기
  • 피드백 주고 받기
  • 영향력 미치기
  • 가르치고 위임하기

"저는 OOO을 도입하려고 장점에 대한 발표도 하고 교육도 몇 번에 걸쳐 해줬는데 결국 사람들이 쓰게 하는데에 실패했습니다. 사람들이 너무 수동적이고 보수적이에요." -> "그 조직원들이 선생님을 좋아하나요?"


2장: 함께

2-1. 소프트웨어 관리자의 개선 우선순위

제럴드 와인버그가 이야기하는 소프트웨어 개발을 잘 관리하려면 3가지 근본적 능력.

  1. 복잡한 상황을 이해하는 능력
  2. 관찰하는 능력
  3. 행동하는 능력

실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는? -> 관리
그에 반해 보통하는 개선 시도는? -> 도구

소프트웨어 개발 관리자는 자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 될 것.

2-2. 협력을 통한 추상화

실력이 뛰어난 프로그래머는 커뮤니케이션과 협력에 더 오랜 시간을 들인다.

집단의 성과가 부분의 합을 넘는다.

둘이서 협력하며 작업하면 서로 시각이 다르기 때문에 두 사람의 다른 시각을 연결해줄 다리가 필요하고, 그 다리에는 필연적으로 추상화의 요소가 있게 된다. 서로 다른 것들을 하나로 묶어야 하기 때문.

소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특정지을 수 있다.

추상화를 높일 수 있는 방법 -> 다른 시각을 가진 두 사람이 협력하기

자신이 작성하는 코드의 추상성을 높이고 싶다면 혼자서 고민하지 말고 다른 사람들과 협동하고, 대화할 것.


2-3. 신뢰를 깎는 고융인가, 신뢰를 쌓는 공유인가

3가지 공유 방법

  1. 하나 공유 : 하나만 공유하는 것.
  2. 최고 공유 : 여러 개 중 최고만 공유하는 것.
  3. 복수 공유 : 여러 개를 공유하는 것.

복수 공유!

  • 부정적 피드백의 수용성 증가
  • 피드백 하는 사람도 더 편함
  • 공유 후에 개선 정도 커짐
  • 같은 시간을 투자했을 때 신뢰도 높아지고 성과도 더 좋다!

2-4. 객관성의 주관성

객관의 개념 자체가 매우 주관적이다.

가만히보면 우리는 그동안 우리의 객관만 신경을 쓰는 실수를 저질러 왔다.

의사결정을 하는 과정에 감정적이고 직관적인 부분이 배제된다면 의사결정을 제대로 할 수 없다.

감정과 이성을 분리할 수 없다.

남을 설득하려면 논리성과 객관성에 대한 환상을 버려야 한다. 그래야 현실적으로 설득이 가능하다.

내가 설득하고 싶은 상대를 자주 만나서 신뢰를 쌓고, 그 사람이 무엇을 중요하게 여기는지, 어떤 설명 방식을 선호하는지 이해해야한다.

출발은 결국 내가 설득하려는 사람에게서 하는 것이다. 자료에서 출발하는 것이 아니다.

객관성이라고 하는 것은 상대적이며, 내가 생각한 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다.

설득을 하기 위해 객관적 자료를 모으는 부분 이상으로 상대를 이해하는데 많은 시간을 투자해야 한다.


2-5. 이것도 모르세요?

전문가는 상황 파악을 먼저 하지만, 초보자는 뭘 할지부터 정하려고 한다는 차이를 발견했다.

공감해주고, 잘 들어주고, 그 사람의 멘탈 모델을 이해하는 코칭이 필요하다.


2-6. 하향식 접근의 함정

삼투압적 의사소통 -> 은연 중에 서로 간에 정보가 스며든다!

개발 5단계 (분석-설계-구현-테스트-전개)를 프로젝트 기간에 얼마씩 배치할지 고민하지 말고,
첫 주부터 이 사이를 모두 왔다갔다 할 수 있을까를 고민해야 한다

탑다운이 아닌 삼투압적으로!


2-7. 전문가 팀이 실패하는 이유

그로이스버그 등의 연구에 따르면 스타들이 한명씩 추가될 때마다 팀의 추가적 성과 향상은 한계 효용을 보이며, 어느 수준을 지나면 음의 방향으로 작용한다.

그 원인 중 하나는, 전문가의 Ego

팀에 작업 관련 전문가가 포함되는 것과 동시에 각 멤버의 작업을 조율하고 통합하는 전략을 팀이 드러내놓고 탐색하는 경우에 팀의 분석 작업이 가장 높은 수준의 효과성을 보인다.

  1. 전문가들 모아서 팀 만든다고 잘하는 것도 아니고
  2. 오히려 성과가 떨어질 수도 있고
  3. 정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
  4. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

2-8. 구글이 밝힌 탁월한 팀의 비밀

  1. 팀에 누가 있는지(전문가, 내향/외향, 지능)보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요했다.

  2. 5가지 성공적인 팀의 특징을 찾았는데, 그 중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감이었다.

  3. 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.

심리적 안전감?
-> 내 생각이나 의견, 질문, 격정, 혹은 실수가 드러났을 때 처벌 받거나 놀림 받지 않을거라는 믿음.

팀원이 불편한 문제를 제기하거나, 어리석어보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니 없는 실수를 저지를 때 우리는 어떤 마이크로 인터랙션을 보이고 있는가?


2-9. 쾌속 학습 팀

리더가 팀 학습 속도에 미치는 영향
→ 단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다!

학습이 빠른 팀은 팀원을 뽑을 때 부터 달랐다.

  • 선발 자체가 매우 협동적으로 이루어졌을 뿐 아니라(ex: 디자이너를 뽑는데 개발자가 관여 등) 선발기준도 달랐다.
  • 단순한 업무 수행 능력 뿐 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았다.

학습이 빠른 팀의 특징

  • 속도가 빠른 팀은 새로운 기술 도입을 기술적 도전이라기보다, 조직적 도전으로 받아들임. 개개인이 새로운 기술을 획득해야 한다고 보지 않고, 함께 일하는 새로운 방법을 만들어야 한다고 생각했다.

  • 속도가 빠른 팀은 심리적으로 보호가 되고 있었다. 뭔가 새로운 것을 제안하고 시도하는 데에 열려 있었고 실패에 대해 관대했으며 잠재적 문제를 지적하고 실수를 인정하는 데에 부담을 느끼지 않았다.

  • 속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했다.

자신의 학습환경 만들기 -> 학습과 일을 굳이 분리하지 말고 동체로 만들어라

작지만 유용한 프로그램을 매일 작성할 것을 추천한다!


2-10. 프로젝트 확률론

소프트웨어 공학 쪽의 연구를 따르면 사람들이 통상적으로 추정하는 소요 시간에 적어도 2~3배를 해야 80% 확률로 마칠 수 있는 시간이 나온다고 한다.

애자일의 특징

  • 애자일이라면 관리자가 12명에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청할 것이다.

  • 애자일은 고전적 방법과 달리 일을 공유한다. 각자 일을 얼마나 진행했는지 매일 공유하고,
    내 일, 네 일의 구분선이 뚜렷하지 않다.

  • 애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 된다.

  • 애자일은 되도록 일 진행에 단계를 두지 않으려고 한다.

  • 애자일은 마치 프랙털 구조처럼 부분 속에 전체가 들어가게 한다.

  • 애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고,
    나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다.


3: 애자일

학습과 협력이 애자일의 불확실성을 다루는 핵심적이 구동 원리.

애자일은 서로의 업무를 공유하고 상호 검토하는 협력을 통해
불행한 일을 '또는' 조건에서 '그리고' 조건으로 바꾸게 한다.


3-1. 애자일의 씨앗

"고객에게 매일 가치를 전달하라!"

고객은 넓은 의미로 이해관계자

3-2. 애자일 도입 성공 요인 분석

  • 고객 참여
  • 리팩토링
  • 자동화 단위 테스트
  • 코드 공유

중요한 것은 어렵고 두렵지만 중요한 것을 '얼마나' 뒤로 미루느냐, 두려워도 중요하면 시도해봐야 하지 않겠는가?

진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하는 것.

애자일 도입의 핵심적 성공 요인?
→ 성공하는 조직들에는 항상 뛰어난 애자일 코치가 있었다.

뛰어난 애자일 코치는 함께 자라기를 하는 사람이다.

  1. 애자일을 도입해서 성공하는 조직들이 국내에 있다.
  2. 애자일 실천법을 잘 실행하면 성공률도 높아질 수 있다. (애자일을 한 지 얼마 되지 않더라도.)
  3. 실천법 중에서 비교적 성공과 직결되는 것들이 존재한다.
    그것은 고객 챔여, 리팩토링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 등이다.
  4. 애자일 성숙도가 낮은 조직일수록 고객 참여를 하지 않으면 프로젝트 성공이 어렵다.
  5. 무섭고 두렵지만 중요한 일이라면 미루지 말라.
  6. 뛰어난 애자일 코치가 있는 것이 애자일 도입 성공에 핵심적이다.
  7. 뛰어난 애자일 코치는 함께 자란다.

우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제가 아닐까?

profile
UX 한스푼 넣은 iOS 디발자 한톨 / Apple Developer Academy @POSTECH 3기 / 티스토리 이사중,, https://thinkyside.tistory.com/

0개의 댓글

관련 채용 정보