티스토리 뷰
2017년 OKKYCON에서 김창준님이 발표하신 것을 정리한 내용입니다.
프로그래밍을 잘하는 것과 협업을 잘하는 것은 별개이다
같은 연차(7년차)의 두 그룹, 뛰어난 성과를 내는 그룹(high performers)과 그렇지 않은 그룹(moderate performers),에게 신입이 들어왔을때 어떤 조언을 해주고 싶은지에 대해 물어봤을때 뛰어난 그룹의 70%는 사회적 요소에 대한 조언을 했던 반면 반대 그룹에서는 80%가 사회적 요소에 대한 조언을 해주지 않았다.
사회적 요소에 대한 조언이라 함은 예를 들어 '모르면 다른 사람에게 물어봐라.', '옆의 사람을 도와줘라.' 등이 있다.
성과를 잘 내는 프로그래머일수록 다른 사람과 대화하는데 더 많은 시간을 할애한다.
Sonnentag (2002)
THE RELATIONSHIP BETWEEN HIGH PERFORMANCE AND KNOWLEDGE ABOUT HOW TO MASTER COOPERATION SITUATIONS
미래에 AI로 대체될 가능성이 높은 직업군을 확인해보았을때 사회적 지능이 요구될수록 AI로 대체될 가능성이 낮은 경향을 보였다.
사회적 지능이란 상대방이 어떻게 느끼는지 빠르게 알아채는 능력, 협상하는 능력, 설득하는 능력, 타인을 돕고 돌보는 능력 등을 의미한다.
AI로 대체되기 힘든 직업일수록 임금이 높고 대체되기 쉬울수록 임금이 낮은 경향을 보였다.
프로그래머는 48% 확률로 AI로 대체될 가능성이 있는 반면, 소프트웨어 개발자는 4.2% 확률을 가졌다.
같은 개발일을 하지만 소프트웨어 개발자는 협상과 인터렉션이 많은 직군을 의미하고 프로그래머는 그렇지 않은 직군으로 나눈 것이다.
Frey and Osborne (2013)
THE FUTURE OF EMPLOYMENT: HOW SUSCEPTIBLE ARE JOBS TO COMPUTERISATION?
협업하는 능력도 프로그래밍 능력에 포함하여 생각해야 한다.
팀의 퍼포먼스는 협업이 아니라 가장 뛰어난 사람이 결정한다
심리학에 있어 IQ의 한 획을 긋는 발견인데, 이는 통념적으로 누군가가 '어떤 것을 잘하면 다른건 잘 하지 못 할거야.'라고 생각되던 것을 뒤엎고 IQ가 높으면 대부분의 것을 잘 한다는 것을 알려주기 때문이다.
이 내용을 근거로 어떤 작업을 가져다주어도 잘 하는 그룹이 있는지를 확인해보는 연구가 있었다.
해당 연구에서는 이 능력을 CQ(Collective Intelligence)라고 정의하였다.
연구 결과, 가장 IQ가 높은 사람이나 해당 팀의 평균 IQ 등이 CQ에 영향을 미치지 못 하였다.
CQ를 결정하는 중요한 요소에는 '공감하는 능력', '말을 골고루 하는 것' 등이 있었다.
공감하는 능력 테스트에는 Reading the Mind in the Eyes Test (RMET) 를 통해 해볼 수 있다. 사람의 눈 주위만을 보고 어떤 감정인지 예측해보는 테스트이다.
CQ와 RMET 점수는 높은 상관관계를 가졌으며 심지어 서로 얼굴을 보지 않고 진행하는 온라인 게임(LOL)에서도 RMET 점수는 높은 상관관계를 가졌다.
말을 골고루 하는 것은 어떤 그룹이 대화를 할때 누구 한명이 주도적으로 대화를 하는 것이 아닌 참여하는 인원이 골고루 대화에 참여할수록 CQ가 높았다.
Wooley and Chabris and Pentland (2010)
Evidence for a Collective Intelligence Factor in the Performance of Human Groups
어떤 팀의 퍼포먼스는 개개인이 얼마나 뛰어난 사람으로 채워져있는지에 대한 상관관계는 크게 높지 않았고 심리적 안정감과 압도적인 상관관계를 보였다.
심리적 안정감이란 어떤 의견을 내거나 질문을 했을때 비난받거나 조롱받지 않을 것이라는 믿음을 의미한다.
개개인이 얼마나 뛰어난 사람이 모였는지 보다 개개인이 얼마나 말을 할 수 있는 분위기가 조성되어 있는지가 중요하다.
단순한 작업을 할 때는 개개인의 역량이 중요했으나 복잡하고 어려운 문제를 해결해야 할수록 역량보다는 분위기나 CQ 등이 중요함을 알 수 있다.
복잡한 문제를 해결하고자 할수록 개개인의 역량보다는 협업적인 요소가 중요하다.
전문가들을 모아두면 협력을 잘 할 것이다
어떤 사람의 전문성에 대해 평가할때 협업하는 능력은 평가 요소에서 제외되는 경우가 많다. 그리고 협업이라는 능력은 단순히 오래 한다고 해서 느는 요소가 아니다.
전문가를 모아둔 두 그룹을 두고 한 그룹에는 어떤 식으로 협력을 할것인지 토의할 시간을 15분 정도 주고 다른 그룹에는 토의를 해도 되고 하지 않아도 되는 상황을 주었을때 후자 그룹(토의 강제성이 없던 그룹)에서는 비전문가 그룹보다 퍼포먼스가 떨어지는 결과가 나왔다.
전문가들끼리는 서로 조심하는 경향이 강해서 오히려 협력이 되지 않는 문제가 발생했다.
대부분 어떻게 일을 할까에 대한 토의를 하지 어떻게 협력할까에 대한 토의를 하지 않는다. 의식적으로 이런 과정을 거쳐 협업 능력을 길러야 한다.
Wooley and Gerbasi and Chabris (2008)
협업 능력은 저절로 성장하는 것이 아니며 의식적으로 연습해야 하고 협업이 되지 않는 전문가 그룹은 비전문가 그룹보다도 퍼포먼스가 낮았다.
협업을 잘하는 것은 서로 좋은 관계를 유지하는 것이다
협력을 함에 있어 서로 좋은 관계는 중요한 요소가 맞으나 어떻게 좋은 관계인건지에 대해 조심해서 접근할 필요가 있다.
신혼 부부 초기에 많이 싸운 부부일수록 15년 이후에 이혼했을 가능성이 낮고 싸우지 않은 부부일수록 이혼했을 가능성이 훨씬 높았다.
신혼기때 서로 싸우는 것이 당연하고 자연스러우며 서로 싸우지 않는다는 것은 어느 한 쪽이 싸움을 회피하거나 참는다는 것을 의미하며 이를 회피적인 좋은 관계라 한다. 이는 갈등을 처리하는 방식이 능숙하지 못 하다는 것을 의미한다.
일반적으로 '부정적인 얘기는 하지 않고 서로 좋게 좋게 가자.'고 하는 분위기가 좋다고 생각하지만 부정적인 얘기를 할 수 있는 분위기와 팀의 퍼포먼스를 측정하였을 때 건설적으로 부정적인 이야기를 할 수 있는 팀의 퍼포먼스가 그렇지 않은 그룹보다 더 좋았다.
Stephens and Carmeli (2016)
서로 좋은 관계를 유지하는 것은 중요하지만 회피적 좋은 관계인지에 대해 조심해야 하고 건설적으로 부정적인 얘기를 할 수 있는 팀의 퍼포먼스가 그렇지 않은 그룹보다 좋았다.
분업을 잘하는 것이 협업을 잘하는 것이다
구성원의 조직도를 Node와 Edge로 그렸을때 GROUP과 같이 매니저와만 소통하는 방식보다 TEAM처럼 구성되어있는 조직의 퍼포먼스가 훨씬 높았다.
해야할 일이 불확실할수록, 일하는 도중 조건이 바뀐다거나 서로가 얼마나 잘하는지 잘 모르는 경우 등, TEAM의 퍼포먼스가 더 높은 경향을 보였다.
TEAM이 GROUP보다 더 퍼포먼스가 높을 수 있던 이유 중 하나는 동료간에 서로 모르는 것을 도와주고 보완해주는 피어 코칭 덕분이었다.
일이 불확실할수록 동료간의 인터렉션과 커뮤니케이션이 중요해진다.
(해당 논문에 대한 정확한 자료를 찾지 못해 Hackman의 Team Effectiveness Models로 대체함)
대부분 일이 복잡하고 불확실하게 느껴질수록 분업을 세분화해서 진행한다. 분업을 세분화할수록 팀원간의 커뮤니케이션을 하는 것이 매우 줄어들게 된다.
정보가 많지 않아 분업을 하기 힘든 상황일수록 분업을 열심히 하는 경향을 보인다. 일이 끝나갈수록 전체적인 구조를 알게 되어서 분업을 어떤 식으로 하는지 알기 쉬워지는데 일이 시작하는 초반에 분업을 하려고 한다.
이는 일이 불확실하기 때문에 불확실성을 줄이는 목적으로 분업으로 해두려는 것인데 분업을 한다고 해서 불확실성이 떨어지는 것은 아니다.
퍼포먼스가 높은 팀일수록 서로 하는 업무에 무관심하는 것이 아니라 상대방의 작업을 서로 모니터링해주고 그에 대한 부정적인 의견을 말할 수 있었다.
서로 간섭하지 않을 수 있게 분업을 해서 작업을 하는 것이 아닌 최대한 서로 커뮤니케이션하고 협력할 수 있는 형태로 업무가 분담되어야 한다.
레퍼런스
https://www.youtube.com/watch?v=I4xkw_0XqAs
'etc > 협업' 카테고리의 다른 글
팀내에 심리적 안정감을 빌드하는 방법 (0) | 2022.09.28 |
---|
- Total
- Today
- Yesterday
- neovim
- 루나빔
- 레디스
- Dap
- ModelAttribute
- vim
- 도커
- IDE
- RequestParam
- 아키텍처
- lunarvim
- RequestPart
- 배포
- RequestBody
- JavaScript
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |