본문 바로가기

회고/IT도서

함께 자라기

728x90
반응형

 

 

개요


 워낙 유명한 김창준 님이 쓰시기도 하셨고, 협업에 관심이 많았던 찰나에 회사에서 구매하여 읽게 되었습니다. 책이 그렇게 두껍지 않고 어려운 내용들이 있던 것은 아니라 읽는데 부담은 없었습니다. 사례 중심의 이야기가 많기도 하지만 여러 조사를 통해 근거를 가지고 설명해주는 부분들이 인상 깊었습니다. 최근에 학습 방법과 교육, 협업에 관심이 많았는데 이미 알고있던 부분도 있었지만 새롭게 알게되고 적용해보면 좋겠다고 생각한 부분들이 있었습니다. 가령 전문가에게는 방법을 묻기보다 실제로 과제나 사례를 제시하며 옆에서 어떻게 생각하는지, 해결하는지, 접근하는지 전 과정을 관찰하는 것이 훨씬 도움이 됩니다. 또한 팀이 서로 투명한 공유와 신뢰가 쌓여 있을 때, 환경 변화에 대처하기 쉬우며 같은 작업을 하더라도 훨씬 작업 능률이 올라갑니다.

 

 

신구의 조화


  •  자신이 이미 가지고 있는 것을 잘 활용하라
  •  외부 물질을 체화하라
  •  자신을 개선하는 프로세스에 대해 생각해보라
  •  피드백을 자주 받아라
  •  자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라

 

 인간은 망각의 동물입니다. 옛 것은 까먹기 쉬운데 또 새로운 것을 받아들이는 데는 저항합니다. 암기를 열심히 해도 몇 달 안지나서 까먹는데, 어렵게 새로운 것을 받아들인 내용을 내 것으로 만들지 않는다면 그 또한 흘러가는 개념입니다. 비판적으로 개념을 받아들여 내가 가진 지식과 비교 융합하고, 피드백을 통해 성장하는 것은 어느 분야든지 평생의 숙제와 과제라고 생각합니다. 단순히 새 것만 좋은 것, 옛 것은 낡고 허술한 것이라는 생각에 빠지지 않고, 내 실력에 자만하지 않고 계속 정진하며 나아갑니다.

 

 

교육의 함정, 학생의 눈높이에서 바라보기


그 기술을 성공적으로 해내기 위해 필요한 것의 30%만 가르쳐 놓고 자신은 다 가르쳤다고 생각하는 것입니다.

 

 제 자신을 많이 돌아봤습니다. 비단 IT뿐만 아니라 통신병으로 지냈던 군생활도 마찬가지입니다. 신병 때 항상 딜레마는, 이미 업무에 익숙한 상병장들이 섬세하게 자세히 알려주는 것도 아니면서 한번에 모두 외우기를 원합니다. 한두번만 알려주고서는 잘 하지 못하면 엄청 혼냅니다. 물론, 군대는 계급사회이므로 신병을 갈구기 위한 일종의 수단(?)으로 활용했을 수도 있습니다. 어쨋든, 그래서 저는 다른 사람들에게 친절하게 알려주려고 노력했습니다.

 

 여러가지 그림도 그려가고, 예시도 들어주고, 질문도 해줍니다

 

 그런데 가끔은 너무 이해하지 못하는 표정을 지을 때, 같은 내용을 여러번 질문을 했을 때는 저도 모르게 답답해 합니다. 저는 나중에 교육자 커리어 패스를 같이 가고 싶기 때문에, 이런 부분들도 잘 대처하고 알려주어야 한다고 생각하면서도 말입니다. 앞으로는 왜 이렇게 설명을 못알아듣지? 왜 알려줬는데도 계속 물어보는거지? 가 아니라 그럼 어떻게 해야 좀 더 이해를 잘 할 수 있을까? 라는 사고 습관을 가져야 겠습니다.

 

 

 절대절대 전문가에게 "비결"을 묻지 마세요......


"프로그래밍 언어를 빨리 배우는 비결이 무엇인가요?"라고 묻지 않았다는 겁니다....
이런 질문을 받아을 때 전문가들은 너무 일반적인 답(예컨대 "연습하세요")을 하거나,
실제 자신의 행동과를 다른 이론적인 답을 하는 경향이 있습니다.


그렇다면 어떻게 해야 할까요? 한가지 비결은 전문가가 구체적인 사건에 대해 말하도록 유도하는 겁니다.
전문가에게 굉장히 구체적인 기억들을 상기하도록 합니다.
익힌 과정을 시간대별로 짚어가며 어떤 행동을 했는지,
그리고 암묵적인 의사결정과 상황판단이 무엇이었는지를 추출했습니다.


즉, 전문가가 빨리 되기 위해서는 전문가에게 전문성을 효과적으로 뽑아내기에 대해 전문가가 되어야 겠지요.
그 첫걸음은 전문가를 만나는 것이고, 그 다음은 구체적 사례를 듣는 것이 되겠죠

 

 

* 페이커 선생님이 말하는 롤 잘하는 법

 

https://www.youtube.com/watch?v=mqRUoj3C53M 

 

 

 위의 페이커 인터뷰를 보고서 많은 사람들이 "저 정도는 나도 알아..." 라고 했을 것입니다. 그런데 말이죠, 저 이야기를 듣는다고해서 갑자기 사람들이 롤 실력이 올라갈까요. 그렇지 않습니다. 직접 페이커가 플레이를 하면서 어떤 상황에서는 어떻게 해야한다라고 자신의 감각과 플레이를 알려주면 훨씬 도움이 될 것입니다. 코딩도 특히나, 단순히 이론에서 끝나면 죽은 지식이고, 실제로 써먹고 실천해보아야 제 것이 될랑 말랑합니다. 

 

 앞으로 실력자와 면담자리나 업무할 일이 생기면, 원론적인 질문보다는 구체적으로 어떤 역경과 해결과정이 있었는지 좀 더 질문을 아름답게 만들어야 겠다는 생각을 했습니다.

 

 

 

전문가, 경력, 나이, 계급장? 다 떼버리고 극복해보자


"내가 이 문제를 해결할 때 어떤 과정을 거치는가?"를 생각하며 자신의 머릿속을 관찰하고,
질문을 던지고 분석하는 것이죠. 그리고 학생들이 이걸 배우면서 어떤 생각을 하는가를
직접 관찰하고 질문을 던지고 분석할 수 있을 겁니다....
이런 분석 능력이 뛰어난 선생이 잘 가르치는 사람이라는 이야기입니다.


그 선생이 가진 지식의 양만 보지 말고 선생의 메타인지를 돕기 위해 
자기가 어떻게 생각하면서 문제를 풀었는지, 그 인지적 과정을 선생에게 알려주는 것도 매우 효과적입니다
. 혹은 선생이 그 문제를 푼 인지적 과정 자체를 알려다라고 요청할 수도 있겠죠.

 

경력 횟수가 중요한 것이 아니라 학습 양이 중요한 것도 아니고 나이가 중요하지도 않습니다.

 

가장 중요한 것은 어떻게 문제를 해결하는지 그 인지적 과정을 확인하는 것입니다.

 

 

인간은 기계가 아니다


"실수는 어떻게든 할 수밖에 없다. 대신 그 실수가 나쁜 결과로 되기 전에 일찍 발견하고 빨리 고치면 된다"는 겁니다. 이태도를 실수관리라고 합니다. 이미 결과가 난 실수에 대해서는 학습을 통해 "다음 행동할 때 이렇게 하자"는 계획을 세우기도 합니다.

실수 예방 문화에서는 실수를 한 사람을 비난하고, 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다. 실수에서 배우지 못하겠지요.

 

 

 

코딩은 혼자 하는게 아니야


뛰어난 개발자들은 약 70%가 동료와의 협업을 언급하는 반면,
실력이 그저 그런 개발자들은 20%도 안 되는 사람들만이 동료와의 협업을 언급했습니다.

...
어떤 기술적 지식을 전달한다고 해도 그것을
사회적 맥락 속에서 가르치고 경험하게 하려고 노력하고 있습니다.
참고로, 제가 중요하게 다루는 사회적 기술은 도움받기, 피드백 주고받기, 영향력 미치기,
가르치고 배우기, 위임하기 등이 있습니다.

 

 

 친구들 사이에서 집단지성이라는 말을 사용합니다. 어떤 문제가 있으면 한 명이서 고민하는 것보다 여러명이서 고민 할 때 훨씬 빠른 시간내로 해결책을 발견할 수 있다는 의미입니다.

 

 

자고로 IT 조직은 이정도의 유연함은 있어야지


내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음

내가 이 일에서 실수를 하면 비난을 받는다
이 조직에서 남들에게 도움을 구하기 어렵다
내 관리자는 내가 전에 한번도 해보지 않은 걸 해내는 방법을 배우거나, 새로운 일을 맡도록 격려한다
만약 내가 이직을 준비한다면, 나는 담당자와 이야기를 나눌 것이다.
내가 매니저에게 문제를 제기하면, 그는 해결책을 찾도록 도와주는 일에 그다지 관심을 보이지 않는다.

특히 매니저에게 문제를 제기할 때 별로 관심이 없다면, 사실 그 조직에 문제가 있기도 하지만, 그냥 그 매니저와 회사 수준이 딱 그정도인 경우라고 생각합니다. 평소에도 직원들에게 관심과 투자를 아끼지 않는 사람들이었다면, 조치를 취했을 것입니다. 그런데, 어떠한 관심이 없다는 것은 원래부터 관심이 없는 환경에서 오래 있었다는 이야기입니다.

 

관리자의 입장에서 고민해봅니다. 항상 서로가 열려있는 마음으로 대화하고, 실수가 부끄러운 것이 아닌 모든 사람들이 앞으로 같이 조심해야 할 이슈로 인식하기를, 고민이 있다면 회사와 내가 지원 가능한 선에서 최대한 수용해주고 함께 해결책을 찾기 위해 노력하기를 꿈꿔봅니다.

 

 

애자일은 앞서의 고저적 방법과 달리 일을 공유합니다. 애자일에서는 되도록 사람들이 섞이도록 합니다. 애자일에서는 내가 일이 빨리 끝나면 다른 사람의 일을 도와줍니다. ... 게다가 애자일에서는 지식을 공유하기 때문에 좋은 정보는 모두가 곧 알게 됩니다. 그리고 그 좋은 정보는 각자의 일에 모두 도움이 됩니다. .... 예컨대 7명 중에서 한 명이라도 중요한 것을 발견을 하면 나머지느 모든 사람이 그걸 공유해 함께 이득을 얻는다는 뜻입니다.

 

 

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


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

 

  • 고객에게

우리의 진짜 고객은 누구인가?

 

  • 매일

어떻게 점진적으로 가치를 전할 것인가?

어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?

 

  • 가치를

무엇이 가치인가?

지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?

지금 가장 높은 가치는 무엇인가?

비슷한 수준의 가치를 더 값싸게 전달하는 방법은?

 

  • 전하라

가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?

 

 

성공도 회귀분석

- 고객 참여(0.77)

- 리팩터링(0.42)

-코딩 후 자동화 테스트 붙이기(0.38)

-코드 공유(0.37)

 

 

 

 

 

728x90
반응형

'회고 > IT도서' 카테고리의 다른 글

UML 실전에서는 이것만 쓴다  (0) 2022.09.20
The Nature of Software Development  (0) 2022.09.15
SQL 레벨업  (0) 2022.04.11
프로그래머의 뇌  (0) 2022.03.30
성공하는 프로그래밍 공부법  (0) 2020.02.27