[Essay] SW영역에서 Role and Responsibility를 정의하는 두 가지 방법에 대한 비교/단상...

Essay/Software 2011.03.02 05:00

RnR(Role and Responsibility)데 대한 정의는 공동업무를 진행하는 과정에서 꼭 필요한 부분이다.
SW 실무적으로 RnR를 정의하는 방법은 크게 두가지로 나뉠 수 있을 것 같다.

첫번째, 기능별 분류이다. (a)
Multimedia Engine, Multimedia Application, GPS, Call 등등으로 구분하는 것이 대표적인 방법이다.
내가 생각하기에 현재 대부분의 SW연구소가 택하는 방법이 아닌가 한다.

두번째, 물리적인 file/directory 단위의 구분이다. (b)
Linux Kernel을 예로 들면, /mm, /kernel, /sound 등의 단위로 나누는 것이다.
이 방법은 몇몇 특수한 경우에만 사용하는 것으로 일반적이지는 않는 것으로 알고있다.

위 두가지 방법을 간단하게 비교해 보자.
먼저 (a)의 경우다.
장점: 특정 기능별로 구분되어 있으므로 해당 분야의 domain knowledge를 쌓아 전문가를 양성하기 좋다. 따라서 해당 분야에 대한 장기적인 성장에 유리하다.
단점: SW code의 물리적인 위치가 기능별로 명확히 구분되어 있지 않고, common한 부분이 많은 경우 (보통의 효율적이고 well-structured 된 code 일 수록  code 공유/재사용 이 많다.) RnR에 대한 논란의 여지가 많다. 따라서, 이로 이한 팀/개인 간의 갈등, communication overhead, 비협조적인 업무진행 등의 문제를 만날 수 있다.

(b)의 경우 (a)와 정확히 반대 된다.
같은 기능이라도 여러 팀이 관여하게 되므로, 업무 진행시 실무자간 제법 많은 양의 communication을 필요로 한다.
Camera 기능을 예로 들어보자.
Camera의 경우, Sensor Driver, HAL(Hardware Abstraction Layer), Application Framework, Application등에 그 기능이 걸쳐 있을 것이다.
따라서 Sensor에서 지원해 주는 특정 기능을 구현하기 위해서는 각 directory (아마도, driver, HAL, FW, App은 각각 다른 directory에 위치해 있을 것이다.) 별 owner들간 많은 대화가 필요할 것이다.

경우에 따라 다르겠지만, 비교/분석해 봐야할 대상은 명확해 진듯 하다.
"RnR의 불확실성에 따른 문제로 인한 업무 비용" vs. "기능별 SW업무시 발생할 수 있는 file/directory owner들 간 communication에 따른 비용"
(a)의 경우는 이미 많이 겪어 봤다. (b)는 아직 경험해 보지 못했다.
과연 어느 쪽어 더 효율적일까? (산업/업무 문야에 따라 다르겠지만...)

Trackback 0 : Comment 0

[Essay] 비효율적인 회의가 발생하는 여러가지 상황들...

Essay/Work 2011.03.02 04:33

*  leader가 담당자의 기술적인 능력을 신뢰하지 않을때.

보통, leader가 기술적으로 뛰어나거나, 실무자가 기술적으로 미숙한 경우 많이 볼 수 있다. 이 경우, leader는 담당자가 report하는 사항에 대해 기술적인 detail을 모두 다 알려고 하고, 기술적인 문제에 대한 guide를 하길 원한다.
실제로 leader의 해당 분야에 대한 기술적인 역량이, 담당자보다 뛰어난  경우, 이런 방식이 효과적일 수 있다. (예. 신입사원과 경력사원의 사수-부사수, 혹은 멘토-멘티 의 관계.)
그렇지만 (실무자의 역량이 조금 부족하다고 하더라도) 실무자 보다 leader가 해당 분야의 기술적인 역량이 뛰어난 경우는 거의 없다.
그럼에도 불구하고, leader가 해당 실무자의 기술적인 능력을 신뢰하지 못하게 되면, 실무적인 보고 사항에 대한 세세한 부분까지도 알고자 하게 된다.
따라서, 실무자는 실무의 상세한 부분을 leader에게 설명해서 이해시켜야 하게 되고, leader의 '미숙한' 기술적인 질문에 답해주어야 한다. 이는 실무자에게 상당한 overhead로 작용하게 된다.
이런 관계의 reporting line이 길어지면 길어질수록, 효율은 급격하게 떨어지게 된다.

의사결정을 해야할 경우는 leader는 reporting을 받으면서 - 담당자를 믿지 못하므로 - 좀 낫다고 생각되면 몇몇 다른 실무자들을 동반할 지도 모른다.
이 경우 문제는 좀더 심각해진다. 올바른 방향으로 의견이 잘 정리되어 모아 진다면 좋겠지만, 그렇지 않은 경우, 참석한 모든 사람들 사이에 공감대가 형성되기 전까지는 회의가 계속되는 비효율이 발생하게 된다.
특히, 중간 중간에 사람을 좀더 불러 들이는 것은 더욱 안 좋다. 회의에 참석하게되는 실무자들 역시 문제의 기술적인 detail까지 알고 싶어할 것으므로, 담당자는 이들 모두에게 또 다시 반복적으로 기술적인 설명을 해야 한다.
Leader의 요청에 의해 참석한 실무자가 기술적으로 뛰어날 수도 있겠으나, 해당 분야에 대해서 담당자 보다 더 잘 아는 경우는 거의 없다.
따라서, 담당자는 leader를 위해서 그러했듯이 다시 회의에 뒤늦게 합류한 실무자를 위해 같은 설명과정을 계속해서 반복해야 한다.
그러므로, 이런 경우는 회의하는 사람의 숫자를 될 수 있으면 줄이는 편이 좋다.
"좀더 많은 사람의 생각이 모이면 좀더 좋은 생각이 나온다."라는 말은 평등한 구조의 회의에서 성립되는 말이다.
보통의 회사에서 "평등한 구조"는 존재 하지 않는다. 노파심에서 많은 사람들을 불러 들이기는 하나, 실제로 의사결정에 관여하는 사람은 소수일 뿐이다.
실제로 회사에서 다수의 사람들을 모아 놓고 회의가 진행되는 모습을 보면 소수 (이것도 20:80 법칙을 적용 받는지는 모르겠지만...)의 사람들이 발언권을 독점하고 나머지 사람들은 꿔다놓은 보릿자루처럼 머릿수만 채우고 않아 있는 경우가 대부분이다.
왜 이런 문제가 발생하는지는 여기서 논의하지 않기로 하자. 단, 현실이 그러하다는데는 큰 이견이 없을 거라고 본다.
따라서, 차라리 의사결정에 필요한 최소한의 인원으로 회의를 진행하는게 오히려 나아 보인다.
실무자가 기술적인 내용을 일일이 설명해야할 비용도 줄어 들고, 회의 참석자들간 공감대를 만들어 내기도 더 쉽기 때문이다. 잘못될 결정을 할 가능성은? 필자가 보기에는 별 차이가 없다.

* leader가 자기 자신의 기술적인 역량이나 실무적인 역량에 자신감이 없을 때.

실무를 떠난지 오래된 leader에게서 종종 볼 수 있다. management가 주 업무가 되면서 실무에 대한 '감'을 잃어버리게 된 경우다.
이 경우, leader는 기술적인 지식이 필요한 모든 회의/논의에 실무자들을 불러 들인다.
예를 들면, 2시간의 회의에, leader한명, 실무자 10명이 들어가서, 실무자들은 말 그대로 그냥 '듣고만' 나오는 경우다.
leader는 언제 나올지 모르는 기술적인 문제를 상의하기 위해서 실무자들을 전부 이끌고 들어간다. 그렇지만, 실제 이런 문제에 답해 줄 수 있는 기회를 갖는 실무자는 한 두명 뿐이다. 나머지는 말 그대로 "시간만 때우고 머릿수만 채우는" 겪이 된다.
이런 일이 반복될 경우, 실무자는 시간을 뺏기는 것은 물론, 업무에 집중하기도 힘든 상황이 된다.

to be updated...

Trackback 0 : Comment 0

[Essay] 악플보다 무서운게 무플...

Essay/Work 2011.02.18 11:12

이라는 유명한 말이 있다...
오늘 갑자기 든 생각인데... 마찬가지 내용이 회의에도 적용되지 않을까?
회의에서, 윗사람의 주장을 반대하는 사람보다 나쁜 사람이 아무 반응이 없는 사람이 아닐까?
관심 자체가 없다는 이야기니...

내가 어떤 회의를 이끌 때는 이 점을 항상 염두해 두어야 할 것 같다....
반대하는 사람은 찬성하는 사람과 마찬가지로, 관심도 있고 잘 해 볼려는 열정도 있는 사람이란걸...

Trackback 0 : Comment 0