2장 사회 활동으로 보는 프로그래밍 #207
Comments
5 tasks
This was referenced Jan 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2부 사회 활동으로 보는 프로그래밍
프로그래머는 혼자 일하지 않는다.
1인 프로그래머와 2인 프로그래머의 차이는 단순 능률의 2배의 문제가 아니다. (3배 이상으로 늘어난다고 생각)
프로그래밍 팀이란 더 나은 제품을 만들기 위해 함께 일하는 프로그래머의 모임이다.
4장 프로그래밍 그룹
프로그래머들을 공식적인 팀 또는 프로젝트 조직화한다 해도, 그 내부에서는 비공식적인 관계들이 비구조적인 그룹에 있는 만큼이나 많이 생겨난다.
사실, 우리가 사회 심리학에서 가장 먼저 배워야 할 것은 공식 그룹과 비공식 그룹의 차이점이다.
공식 조직과 비공식 조직
프로그래머 간의 상호관계가 조직도를 있는 그대로 따라 그 좁고 단선적인 통로를 통해서만 형성된다면 프로그래밍 작업에 진척이 있을 리 없다.
트리형태가 아닌 그래프형태로 이뤄져야 한다.
공식적인 구조만이 어떤 조직 내의 유일한 구조라는 생각은 위험하다.
프로젝트에서 비공식 구조는 대부분 작업의 구조에 영향을 받아 결정된다.
그 프로젝트가 얼마나 잘 조직화되었느에 따라 조직도에 가까운 모습이 될 수도 있다.
그러나 비공식 구조는 항상 기존 공식 구조의 기능을 정정하고 보완하는 방향으로 자라난다.
현명한 상급자라면 비공식 구조를 공식화하기도 한다.
위 두가지 사례의 요점은 비공식적인 조직은 항상 존재하며 그것을 깊이 이해하지 않은 상태에서 바꿔 버리면 위험하다는 것이다.
그렇게 하면 원할하게 돌아가던 전체 시스템을 교란시키는 꼴이 되기 때문이다.
또한 깊이 이해하지 못했으므로 그 비공식적인 조직을 비슷한 비용의 공식적인 조직으로 대체할 수도 없을 것이다.
그런 교란 가운데 많은 경우가 물리적인 배치를 변경하여 발생한다.
물리적 환경과 사회적 조직
우리는 물리적 환경이 프로그래밍 작업의 양과 질에 영향을 끼침을 모두가 알고 있다.
소음이나 빛, 온도 등과 같은 요소가 아닌 작업 공간의 배치를 말한다.
프로그래머를 한군데 모아 놓으면 분명 중요한 이점이 생긴다.
그러나 관심을 가져야할 부분은 작업 공간의 배치가 사회적인 상호작용에 미치는 영향이다.
그 상호작용이 다시 작업 결과에 영향을 주기 때문이다. (재귀적)
단말기 시스템의 원격에서 작업할 수 있는 측면은 어쩌면 축복이 아닌 저주일 수 있다.
1장에서 나온 내용처럼 생각하거나 정보를 나눌 기회가 줄어들고 있다.
프로그램의 오류와 프로그래머의 자아
프로그래밍은 개인의 행위인 동시에 사회적 상호작용을 많이 요구한다.
프로그래머는 대부분 고립된 장소에서 혼자 일하는 편을 더 선호하는 경우가 많다. (대다수)
물론 프로그래밍 업무에서 상당 부분이 홀로 그리고 창조적으로 해야 하는 것이므로 그런 프로그래머를 선택하는 것이 좋다.
그러나 종종 이런 고립성이 너무 지나쳐 사람들에게서 고립되고 자신의 프로그램에 애착을 두는 경우가 있다.
자신이 작성한 프로그램을 자신의 것으로 여기는 데 무슨 문제가 있을까?
실제 작가, 건축가, 프로그래머는 사람에게 존쟁을 받고 실력이 떨어지는 사람들은 그 작품을 모방하여 발전하곤 한다.
하지만 사람들은 프로그램을 읽지 않기 때문에 어떤 프로그래머를 흠모한다고 해서 그 프로그래머의 작품을 모방하게 되지 않는다.
단지 매너리즘을 부추길 뿐이다.
모두 어떤 화가처럼 보이는 방법은 알고 있지만, 그 화가처럼 그리는 방법을 아는 사람은 거의 없다.
누구의 것이냐를 중시하는 프로그래밍에서 나타나는 실질적인 문제점에는 또 다른 원인이 있다.
어떤 그림이나 소설, 건물이 열등하다는 생각은 취향의 문제다.
그러나 어떤 프로그램이 열등하다는 생각은 적어도 잠재적으로 객관적인 증명 또는 반증이 가능하다.(좋은 프로그램을 정의하기가 어렵다는 사실은 자치하고)
최소한 우리는 프로그램을 컴퓨터에서 실행해 나오는 결과를 볼 수 있다.
화가의 경우에 따라 비판을 수용하지 않을 수도 있다. 그러나 프로그래머가 컴퓨터의 판단을 무시할 수 있을까?
표면상 컴퓨터의 판단은 의심할 여지가 없다.
그렇다면 자기 프로그램에 대한 프로그래머의 애착은 자화상에 심각한 손상을 남길 수 있다.
컴퓨터가 자신의 프로그램에 오류가 있다는 결과를 내면, 프로그래머는 이렇게 생각할 것이다.
"이 프로그램에는 결함이 있어. 그런데 이 프로그램은 내 일부야. 나의 외연이란 말이지. 심지어 내 이름도 물려받았어. 그러니까 결함은 나에게 있어."
자신의 프로그램이 자아의 외연이라고 진심으로 믿는 프로그래머는 프로그램에 있는 모든 오류를 찾아내려 하지는 않을 것이다.
오히려 그 프로그램의 정확성을 증명하려 노력할 것이다.
좋은 프로그램을 만들기 위해서는 확실한 반증이 있음에도 자신의 프로그램은 부정확하다고 믿으려는 완전히 정상적인 사람의 성향에 대해 뭔가 조치를 취해야 한다.
비자아적 프로그래밍
직접적인 공격이 이 문제에 대한 해결책이 될 수는 없다.
공격은 언제나 방어를 부르고, 그런 방어 자세는 우리가 없애려 노력해야 할 대상이기 때문이다.
자아 문제는 사회적 환경과 더불어 프로그래머들의 가치 체계를 재구성함으로 극복해야 한다.
자신의 코드를 읽어야 하는 모든 사람을 위해 프로그램을 명확하고 이해하기 쉽게 만들려고 항상 노력했던 것이다.
비자아적 프로그래밍 방식으로 개발된 프로그램이 그렇지 않은 프로그램보다 효율성에서 뒤쳐질 이유가 없음은 확실하다.
프로그램의 전체 효율성은 원작자가 고안한 구조에 주된 영향을 받겠지만, 다른 사람의 검토를 거치면 적어도 너무 뚜렷하게 비효율적인 부분은 미리 없어지기 때문이다.
또한 다른 사람이 작성한 프로그램을 읽는 사람에게도 좋은 영향을 미친다.
프로그램 읽기에 내포된 가치를 제대로 평가했다면, 비자아적 프로그래밍 방식으로 작성된 프로그램을 읽는 사람은 더 나은 프로그래머가 되지 않을 수 없다.
프로그래밍 환경의 조성과 유지
조성된 환경을 그냥 유지하는 것은 비교적 쉽지만, 기존 그룹을 새로운 환경으로 이끌려면 사회적 구조의 정착 또는 고착화 현상이라는 난관에 부딪힌다.
고착화는 어떤 상황이 자신을 유지하기에 더 적합한 환경을 만들어 내는 것을 말한다.
한 회사에서 프로그래밍 언어를 한 가지만 사용하는 것은 프로그래밍 환경에 관련된 사회적 고착화 현상의 전형적인 예다.
사회적 환경은 비자아적 프로그래밍을 장려하거나 또는 억제하는 방향으로 조성될 수 있다.
ex) 조언에 대해서 냉소적인 반응, 서로 협력하는 관계
우리가 취하는 행동에서 상당 부분은 환경적인 영향을 많이 받기 때문에 프로그래밍 그룹에 새로 합류한 사람은 그 그룹의 철학에 맞춰 사회화된다.
고위 관리자들이 비 자아적 프로그래밍 철학을 위협하는 경우도 종조 있다. (상업적 생각이 우선)
요약
프로그래머의 작업 환경은 복잡다단하며 인간관계와 그 변화 그리고 오해를 불러일으킬 만한 상황들로 가득 차있다.
그 환경을 이해하라면, 공식적 구조와 비공식적 구조의 차이를 이해하고 물리적 환경에서 개인의 자아까지 환경에 영향을 미치는 다양한 요소들도 이해해야 한다.
그리고 프로그래밍 환경에는 외부로부터 발생한 변화에 저항하는 자기보존성이 있다.
특히, 그 변화가 공식적인 것과 비공식적인 것의 차이를 이해하지 못한 상태에서 이루어질 경우에는 더더욱 그렇다.
이런 자기보존성은 모든 차원의 사회에 존재하는 현상이고, 본질적으로 좋지도 나쁘지도 않다.
그저 프로그래밍의 현실일 뿐이다.
추가 (보태는 글)
과거와 다르게 메일을 사용(지금은 메신저)한다.
장점으로는 비가시성이 존재한다.
3장의 생각 MBTI로 개발자들을 테스트내용
논의사항
5장 프로그래 팀
개발하려는 시스템의 크기가 클수록 프로그래밍 경험 부족이 더 여실하게 드러나기 마련이다.
이상적으로는 프로그래머들이 사소한 문제라도 결코 혼자 작업하지 않는다고 보았지만, 작은 프로그램과 큰 프로그램은 사회적 측면에서 서로 차이가 있다.
어떤 한 명이 그룹 전체의 작업을 목표와 일반 체계부터 아주 작은 코드의 세부 사항까지 숙지할 수 있다면 프로그래밍 작업을 통합할 필요는 없다. (인간 문서)
프로그램을 서로 모두 이해하고 있는 상태에서 함께 개발하는 두 프로그래머의 상호 작용과 한 사람이 맡기엔 너무 커서 프로그램을 둘로 나눠 작업하는 두 프로그래머의 상호 작용은 전혀 다르다.
특히 요구사항의 충돌이 해소되는 방식이 다르다.
전자의 경우에는 한 사람의 사고 과정 즉, 가끔 다른 이의 도움을 받기도 하지만 늘 스스로가 통제하는 사고 과정을 통해 충돌이 해소된다.
반면 후자는 기술적인 요구사항이 충돌이 대인 관계의 갈등으로 번질 가능성이 있으며, 이 문제를 해결하기 위해서는 사회적인 장치를 갖추어야 한다.
팀을 어떻게 조직할 것인가
한 사람이 감당할 수 없는 업무 요구사항을 만족시키려면 프로그래밍 팀을 조직해야 한다.
그 필요성은 단순히 해야 할 작업의 요구 명세뿐만 아니라 그 일에 필요한 사람들의 능력과 할당될 시간과도 관련되어 있다.
그 2가지 요소 즉, 팀 구성원의 능력과 가용 시간에는 작업을 수행하는 데 요구되는 최소치가 있다.
예를 들어 어떤 프로그래밍 작업은 팀 크기가 아무리 크다 해도 초보자들만으로는 불가능하기 때문에, 경제에서 말하는 인력을 두 배로 늘려도 전혀 소용이 없을 것이다.
개념상, 목적한 시스템을 개발하는 데 필요한 최소의 전문 기술과 최소의 시간이 있다.
그러나 이 수치들은 정확하게 정의하기 어려울 뿐 아니라 프로그래밍에서 추정은 항상 불확실성이 개입되기 때문에, 관리자는 상식적으로 봤을 때 계획된 시간 내에 주어진 업무를 절대 수행할 수 없는 팀을 구성하곤 한다.
십중팔구, 이런 팀은 마감 시한이 닥쳐 현실을 직시해야만 하는 상황이 되어서야 일정 연기를 요청한다.
현실을 좀 더 일찍 깨달았더라면, 일정이 길어짐을 고려해 그에 맞춰 작업을 다르게 계획할 수 있었을 테고, 결국 일을 더 빨리 마칠 수 있었을 텐데 말이다.
너무나 흔히 목격되는 이런 상황으로부터 능력과 일정 간의 상호 보완 관계를 알 수 있다.
최단 일정은 오로지 최고의 팀을 프로젝트에 투입할 때에만 달성 가능하며, 팀의 인원을 최소로 투입하려면 프로젝트 일정이 늦어짐을 각오해야 한다.
다시 말해서 프로그래밍 기술이 다소 부족하다 해도 일정을 연장해 줄 여유가 있고 능력이 최저 수준 이하만 아니라면, 어떤 프로그램이든 만들어 낼 수 있다.
또 일정과 작업 진척 간의 중요한 관계도 알 수 있다. (파킨스의 법칙)
파킨스의 법칙이란 주어진 시간을 다 채울 때까지 작업을 지연시킨다.
파킨스의 법칙도 경계해야 할 대상이긴 하지만, 너무 빠듯한 일정을 핑계로 위험한 지름길을 택하는 것도 피해야 한다.
지름길을 통해도 시스템을 제 시간 내에 성공적으로 가동시킬 수 있을지도 모른다.
반면에, 일정에 착오가 생길 가능성에 대비하려 한다면 팀에 정원 외 인력을 충원해야 한다.
그러나 작업을 더 많은 사람이 분담할수록 전체 작업의 통합이 더 어려워진다는 점을 고려해야 한다.
어림잡아, 프로그래머 3명으로 구성된 팀은 작업을 통합하는 데 소요되는 시간 때문에 동등한 능력을 지닌 프로그래머 한 명이 할 일의 2배 밖에 하지 못한다.
더 나아가, 각각 프로그래머 3명으로 이뤄진 팀 3개는 마찬가지 이유로 팀 하나가 할 일의 2배, 또는 프로그래머 한 명이 할 일의 4배밖에 할 수 없다.
따라서 프로그래머 한 명이 8달 안에 마칠 수 있는 프로젝트에 3명을 투입하면 4달만에, 9명을 투입하면 2달만에 끝낼 수 있다.
더 뛰어난 프로그래머도 있지만, PM의 역할도 중요하다고 생각된다.
최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머를 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다.
이것이 프로그래밍 팀의 크기와 구성에 대해 언제나 통용되는 기본 원칙이다.
일을 더 빨리 해야 하거나 덜 숙련된 사람들과 일해야 한다면 비용과 불확실성이 더 증가하게 된다.
최악의 방식은 초보자들만 고용한 뒤 스트레스만 주고 감독은 하지 않으면서 일을 시키는 것이다.
경험이 없는 프로그래머는 반드시 훈련이 필요하고, 미숙하더라도 팀에 포함시켜 업무 구조 자체를 생산과 훈련으로 변경해야 한다.
프로그래밍 팀을 조직하는 방식을 결정하는 데는 목표 시스템의 구조와 팀의 구성이라는 두 가지 요소가 강력한 영향을 미친다.
시스템의 구조에 접근하는 방식은 다양할 수 있는 데 반해 그 일에 투입할 수 있는 프로그래머들은 한정된 경우가 많기 때문에, 팀 구성원 개개인이 지닌 강점과 약점을 잘 살릴 수 있는 조직 구조로 선택하는 경우가 많다.
콘웨이의 법칙
이상적인 방향은 프로그램 구조를 먼저 계획하고 그 작업을 가장 잘 수행할 수 있는 사람들을 모으는 것이 옳은 순서다.
그러나 재능 있는 프로그래머가 부족하기 때문에 현실적으로 그렇게 하기 힘들다.
가장 중요한 요인 중 하나가 바로 누가 누구의 작업을 비판하는가이다.
따라서 비자아적 프로그래밍을 실천한다면 팀원이 모두 언젠가는 모든 동료의 업무를 자세히 검토할 수 있는 기회를 갖게 되므로 조직의 계층성이 강해지는 것을 막을 수 있다.
프로그래밍에서 팀원의 지위는 대체로 다른 사람들이 그의 능력을 어떻게 평가하는가에 큰 영향을 받는다.
서로 작업을 검토하면서 팀원에 대한 평가가 전체적으로 공유되면, 실력자가 윗자리로 올라가는 속도가 빨라진다.
다른 한편으로, 어떤 업무를 맡느냐에 따라 지위를 얻을 수도 혹은 잃을 수도 있다.
목표의 수립과 합의
어떤 팀원이 사소한 업무를 할당 받아서 감정이 상한다면 팀 전체에 매우 나쁜 영향을 줄 수 있다.
반면에 비자아적 프로그래밍을 실천하면, 프로그래머 각자가 전체 시스템에 대해 자기 나름의 몫을 하고 있다고 느끼게 되므로 그런 감정이 한층 완화된다.
그렇다 해도, 팀이 프로젝트의 구조와 업무 분배에 대한 완전한 합의를 이끌어내기 전에 너무 성급하게 일을 시작한다면 어떤 형태로든 문제가 발생할 것이다.
사회 심리학자들은 맥락은 좀 다르지만, 한 명 이상의 구성원이 그룹의 목표를 공유하지 못하면 그룹 전체의 업무 효율에 악영향을 미친다는 사실을 증명했다.
목표를 공유하지 못하면 단지 그 구성원 한 사람의 문제로 끝나지 않고, 다른 구성원들이 그룹 내의 분열이나 일부 동료의 무관심한 태도를 피부로 느낄 수밖에 없기 때문에 업무 능률이 떨어지게 된다는 것이다.
프로그래밍 작업을 편견 없이 평가하는 데 꼭 필요한 건전한 논쟁을 억누르는 그릇된 합의와 팀의 생산적 활동을 원활하게 하는 팀의 목표에 관한 합의는 전혀 다르다는 것이다.
그룹의 목표에 대한 진정한 합의를 얻기 위해서는 그 그룹이 목표를 직접 설정하도록 하는 것이 가장 좋은 방법이다.
그러나 무엇보다도 참여 자체가 다른 요소들과는 완전히 독립적으로, 어떤 개인이 진정으로 팀의 실제 목표를 인정하여 그만큼의 생산성 향상을 보일지 여부를 결정하는 중요한 요인인 것으로 보인다.
팀원들이 협력을 통해 세부사항을 결정해야 하지만, 고위 관리자가 정의하려 한다면 팀원들은 단순 코더로 느껴질 수 밖에 없다.
프로그래머는 단순히 무엇을만이 아니라 왜인지도 알고 싶어한다.
프로그래밍 팀이 특정 시스템을 제작하는 일이 아니고 다른 프로그래밍 그룹에게 어떤 서비스 또는 지원 함수를 제공하는 일을 하는 경우, 분명하지 않은 목표의 문제는 한층 더 심각해진다.
그러나 주 업무가 지원인 그룹은 끊임없이 자신이 맡은 바를 되새기지 않으면 더 구체적이지만 덜 생산적인 방향으로 흘러버릴 위험이 크다.
사소한 논쟁이라도 쉽게 무시해서는 안된다.
팀 리더십과 팀 리더
프로그래머의 리더는 강압적이거나 원칙적이면 안된다.
사회학자들이 업무 집단의 만족도에 영향을 끼치는 요인들을 다음과 같이 크게 4가지로 분류했다.
과거와 다르게 이직율이 높은 지금은 성장을 좀 더 높게볼 것 같다.
프로그래머는 창조적인 사고와 전문 느력을 중요시하는 사람으로, 자신의 분야인 프로그래밍에 뛰어나다고 판단되는 사람을 신뢰하고 높이 평가하는 경향이 있다.
리더가 할 수 있는 최악의 행동은 다른 팀원들과 프로그래밍 지식을 겨루려고 하는 것이다.
민주적인 집단에서 리더십은 한 사람에게 국한되지 않고 당시의 요구에 들어맞는 능력이나 생각을 소유한 구성원에게 계속 옮겨 다닌다.
그러나 사람이 모두 평등하게 태어날지 몰라도 똑같지는 않는다.
따라서 민주적인 팀의 리더십도 절대 균등하고 나눠지지 않으며, 어떤 팀원은 상대적으로 많은 리더십을 행사한다.
외부의 영향을 받지 않고 내부의 현실 상황에 맞춰 리더십이 정해지는 것이다. (계속 바뀌는 리더)
하지만 적절한 리더를 찾을 수 있는가라는 측면에서 보면 어떤 프로그래밍 팀도 완벽하게 민주적일 수는 없다.
우선, 팀 내에 적합한 인물이 없을 수도 있다.
두번째로, 인성의 문제가 당면한 상황에 적절한 리더를 선택하는 데에 걸림돌이 될 수도 있다.
마지막으로, 외부로부터 리더가 임명되어 들어오면 반드시 그 집단은 민주주의에서 멀어지게 된다.
팀 리더가 반드시 명심해야 할 사항은 다음과 같다.
외부에서 온 리더라도 위 사항을 잘 지킨다면 지배력을 지도력으로 대체할 수 있다.
리더로서 자신감이 있다면, 언제든 물러날 준비가 되어 있는 리더만이 진정한 성공의 열쇠를 쥐고 있다.
팀의 위기
팀의 생명 주기는 팀원 고용을 시작으로, 목표를 설정하고 업무에 맞춰 내부를 조직하는 과정을 거쳐, 결국 업무가 완료되거나 새로운 목표를 받아들일 때 해산됨으로써 끝을 맺는다.
편의상 팀 활동은 두 가지 범주 즉, 팀 목표를 성취하려고 수행하는 일과 위기가 닥쳤을 때 팀을 효율적으로 유지하고 관리하고자 행하는 일로 나누어 생각할 수 있다.
사회 심리학에서는 이런 활동들을 각각 업무 지향적 그리고 관리 지향적이라고 부른다.
민주적으로 조직된 팀은 승진, 사직, 병, 죽음, 임신, 출가 등 어떤 이유로든 구성원을 잃을 때 받는 충격을 잘 견디는 경향이 있다.
팀원끼리 공유와 의사소통이 활발하기 때문에 업무에 대한 이해도가 높을 수 밖에 없다.
하지만 새로운 구성원에 대해서는 받아들이기 힘든 것으로 알려져 있다.
이미 팀원끼리 강한 결합도를 가지고 있었기 때문에 (인간 문서와 같이) 이런 관계를 다시 맺는 것이 어려울 것이다.
반대로 권위적인 팀의 구성원들은 새로 온 사람에게 아주 친절하고 호의적인 반면, 민주적으로 조직된 팀은 다소 냉정하고 비우호적인 모습으로 비춰지곤 한다.
모든 일을 오로지 단 한 사람의 리더가 조직하고 관리할 정도로 권위적인 성향이 강한 팀에서는, 구성원 중 하나가 이탈하여 생긴 구멍이 그대로 방치된다.
오직 리더만이 남은 구성원들에게 일을 다시 분배하는 데 필요한 정보를 쥐고 있다.
민주적인 집단에서는 철저하게 무능력한 구성원보다 유능하지만 다른 사람들과 잘 어울리지 못하는 구성원이 훨씬 더 심각한 문제가 될 수 있다.
권위적인 집단이라면 구조적으로 무능력한 구성원이 업무에 관해 다른 사람들과 접촉할 기회가 많지 않을 것이다.
따라서 리더와 원만하게 지내는 한 특별히 문제가 되지 않는다.
수동적인 직원일수록 강력한 중앙 집권적 리더 아래에서 일하기를 선호하고, 능동적인 직원일수록 민주적인 리더에서 일하길 선호하는 것 같다.
팀의 위기가 반드시 특정 개인과 연관되는 것이 아닌 발전 단계나 외부 환경의 변화에 의해서도 발생할 수 있다.
일반적으로 팀의 조직 형성은 냉동실에서 얼음을 얼릴 때와 같이 아래쪽에서 위쪽으로 그리고 위쪽에서 아래쪽으로 동시에 진행된다.
한 팀에 강력한 리더의 소질을 지닌 사람이 두 명 있다면, 위쪽으로부터 팀이 형성되는 과정이 오랫동안 진행되지 못하고 질질 끄는 경우가 있다. (비생산적이지만, 분리하면 해결)
어떤 사람이 리더의 자질이 강한 사람인지는 팀에 주어진 작업 요구에 따라 다르다.
앞서 말한 기본적인 룰을 지킨 상태에서 리더는 계속 변경될 수 있어야 함.
집단 행동에 관한 보편적인 사회심리학 연구 결과 중에서 특히 다음 두가지는 위기로 점철된 프로그래밍 팀을 정확히 설명한다.
이러한 이유 때문에 민주적인, 기술주의적인 조직이 왜 프로그래밍 팀에 그토록 딱 맞는 조직 형태인지 알 수 있을 것이다.
따라서 프로그래머를 뽑을 때 끊임없이 변하는 구조에 적합한 사람 즉, 너무 지배적이지도 너무 수동적이지도 않은 사람을 찾아야 한다.
또, 프로그래머를 훈련시킬 때에는 유능한 리더를 어떻게 따라야 하는지 그리고 스스로 집단 내에서 리더로 가장 적입자일 때 어떻게 그 기회를 잡아야 하는지를 가르쳐야 한다.
외부세력은 이러한 민주적인 활동에 간섭하지 않아야 한다.
현명한 관리자라면 팀이 발족되어 활동을 시작하고 난 후에는 팀의 내부 구조와 그 변화에 관해 일종의 무간섭 정책을 펼칠 것이다.
요약
대부분의 상황에서 프로그래밍의 가장 중요한 작업 단위는 팀이지 개인이 아니다.
보태는 글
현대에는 업무 요구사항이란 용어를 좀 더 넓게 해석하여 팀과 팀원의 능력 개발을 포함하는 개념이라고 생각한다.
논의사항
과거와 다르게 이직률이 높아진 지금 여러 요인이 생기도, 우선순위가 달라지도 한 것 같습니다.
우선순위와 추가할 만한 요인에 대해서 논의해보고 싶습니다.
6장 프로그래밍 프로젝트
어떤 프로그래밍 목표를 이루기 위해 두 팀이 함께 일해야 하는 상황에서는 두 프로그래머가 함께 일하게 될 때와 마찬가지로 중간에서 조율 기능이 타나난다.
또 개인이 모여 팀을 이룰 때와 마찬가지로 새로운 형태의 사회관계도 형성된다.
변화를 통한 안정
대규모 조직이 지닌 특성 중 가장 흥미로운 것은 구성원 개개인의 수명보다 더 오래 존속한다는 점이다.
프로그래밍 팀도 최초 구성원들은 다 떠났지만 팀은 유지되는 경우를 볼 수 있다.
이러한 특성은 조직의 큰 강점이며, 상호 작용을 통해 팀의 목표와 성취가 새로운 구성원에게 전달되고 또 기존 구성원이 떠난 후에도 그대로 유지되기 때문이다.
가끔 프로젝트의 핵심인력에 대한 잘못된 태도로 비참한 결과를 맞기도 한다.
프로젝트가 진행되면서, 사람들은 현재 하고 있는 제한된 업무에 비해 더 흥미로워 보이는 새로운 것들을 배우기 마련이다.
또는 자신의 능력에 비해 너무 쉽게 느껴지는 업무가 지겨울 수도 있다.
모든 프로그래머가 어려운 업무에 도전하는 것을 즐기지는 않지만, 대부분은 자신의 지식을 적용해 볼 기회가 없다면 불만족스러워 한다.
따라서 프로젝트가 일종의 프로그래머 생산 공장으로 기능하도록 만들어야 한다.
또한 프로젝트는 카드로 지은 집이 아니다.
핵심 인력이 한명 없다고 붕괴되지 않는다. (그러지 말아야 한다.)
성과의 측정
프로젝트의 규모가 클수록 성과를 측정하기가 더 어렵다.
규모가 너무 크면 한 사람이 전체를 판단하기 불가능하다.
또, 개별 프로그램의 친척도에 대한 판단은 주관적인 문제이므로 다른 요인이 없는 상태에서도 각양각색일 것이다.
그러나 어떤 프로그램 하나에 대한 여러 사람의 의견을 들어 볼 기회는 없다.
대신, 프로젝트라는 큰 그림 내에서 여러 프로젝트에 대한 여러 사람의 의견을 비교하고 종합해야 한다.
그렇게 의견을 종합하는 과정에는 심리적인 문제가 발생할 다양한 가능성이 존재한다.
학습 효과를 극대화하려면 학습 주체가 자신에 대한 평가를 피드백으로 받아야 한다는 심리학적 원칙은 잘 알려져 있다.
사례의 보고 체계는 일련의 필터들로 생각할 수 있는데, 각 필터는 시간 진여과 정보 손실을 어느 정도 수반한다.
이런 의미에서 정보는 놀라운 소식일 경우에만 보고서를 통해 전달된다.
심리학 실험에서 피실험자들에게 선형적인 잣대로 뭔가를 평가하게 하면, 극단적인 값을 택하는 사람은 거의 없다.
실제로 5단계의 등급 구별이 필요하다면 7~9단위의 값이 사용되고 양쪽 극단의 값은 옆의 값과 함께 뭉뚱그려진다.
이련 효과가 각 단계를 지나면서 보고서가 여과되는 현상과 관련이 있다.
이전의 검토자가 손대지 않은 극단적인 값을 각 단계의 검토자가 없앤 것이다.
따라서 보고서의 수치들은 위로 올라가면서 점점 더 중간값을 향하게 된다.
그럼으로써 실질적으로 전달되어야 할 정보를 여과한다.
이런 문제를 막기 위해서는 먼저 극단적인 값을 평범한 값으로 조작하는 경향이 지닌 심리적 원인을 찾아야 한다.
침묵의 나선이론
내 편이 한 명이라도 존재하면 사물을 있는 그대로 볼 용기가 생기는 것이다. (동조)
프로젝트의 구조
프로그래밍 프로젝트에서 진척도 평가에 관련된 심리적 함정을 극복하려면, 실무와 그에 대한 평가를 어떤 식으로든 분리하는 것이 필수다.
그런데 계층 조직의 가장 심각한 약점이 바로 이 분리가 불가능하다는 것이다.
실무에 대한 통제 경로가 그대로 진행 보고 경로의 역순이기 때문이다.
앞서 다룬 보고 경로를 따라 전달되는 정보에 왜곡이 생기기 마련이다.
이런 왜곡을 방지하고자 단순히 계층적인 형태에서 탈피한 구조가 나타나기 시작한다.
QA팀을 두거나 인력을 버퍼로 설정하여 필요할 때 조직한다.
조직을 개편하려 하면 생각보다 많은 문제가 발생할 수도 있다.
다른 그룹으로 옮기거나 어떤 사람과 함께 일하는 것 또는 특정 업무를 맡는 것을 거부하는 사람들이 생긴다.
어떤 사람과 계속 함께 일을 하거나 현재 업무를 계속 해야겠다고 우기는 경우도 있다.
본질적으로 이런 문제들은 모두 차별에서 비롯된다.
이는 한 개인이 정해진 팀에 속해 일할 때에 발생하는 문제와 유사하다.
팀 구성원 각자는 팀 목표를 일정 부분 자기 것으로 받아들인다.
그러나 특화된 팀을 경우에는 팀 목표가 프로젝트 전체의 목표 또는 다른 팀의 목표와 일치하지 않을 수도 있다.
예를 들어, 특정 업무가 다른 일보다 시시한 것으로 치부될 수 있다.
ex) 문서화 그룹에 대한 프로그래밍팀의 무시
프로젝트 내의 자연스런 반목은 경영진과 프로그래머라는 수직 계층 사이에서도 발생한다.
이 반목은 목표의 수립 때부터 나타나는데, 프로젝트의 목표가 각 팀의 목표의 단순함은 아니기 때문이다.
보통, 목표는 하향적으로 수립되며 주요 사항은 팀 조직이 갖춰지기 전에 이미 결정된다.
그런 상황에서는 팀 목표의 수립도 민주적으로 이뤄지길 바랄 수 없다.
결국, 프로그래머들이 프로젝트는 물론이고 자신의 팀에도 충성심을 갖기 어려워진다.
대규모 프로젝트에서 공통적으로 발생하는 사회 문제
대규모 프로젝트에서 발생하는 사회적 문제에서 대부분의 원인은 프로젝트 리더십과 실무자 사이의 먼 거리에 있다.
프로그래밍 팀 내에는 딱 두가지 역할만 있으면 된다. (프로그래머와 그 리더)
그러나 프로젝트 전체를 놓고 보면 리더의 리더 즉, n차 관리자가 있다.
n차 관리자는 하위 관리자들을 통해 간접적으로만 볼 뿐이다.
관리자가 스스로 이해하지 못하는 일을 감독할 때에는 언제나 실무자를 평가하는 기준이 일 자체가 아니라 일하는 모습이 된다.
프로그래밍 분야, 관리자의 지위의 상징에 관한 이야기는 너무 과거의 이야기라 생략
논의사항
The text was updated successfully, but these errors were encountered: