'Essay'에 해당되는 글 86건

  1. 2014.06.23 조직 변경의 2가지 방법 - 역할 변경 vs. 사람 변경 - 에 대한 고찰.
  2. 2014.03.18 [Essay] HDL(High Level Design)의 형식 및 완료 시점?
  3. 2014.01.07 [Essay] (부하직원에게)"OO씨 선에서 해결해. 나까지 나서게 하지 말고." 의 문제점.
  4. 2013.11.21 [관리] 권한+책임 을 부여하면서 힘을 실어주기...
  5. 2013.10.21 지난 한 주간, 새삼스레... 새롭게 느낀 것들...
  6. 2013.08.30 [Essay] 어째서 종종 소위 '스펙'이 낮은 그룹이 '스펙'이 높은 그룹의 상사로 존재하는 많은 회사들을 볼 수 있는가?
  7. 2013.07.19 휴계공간의 접근성과 업무효율의 관계에 대한 단상.
  8. 2013.03.29 정치를 통한 세상의 변화를 체감할 수 있는 바로미터....
  9. 2013.01.21 "Programming skill"의 정의와 거기에서 파생되는 문제점...
  10. 2013.01.08 [Essay] 타국(민주주의 국가)의 훌륭한 정치인을 보면서, '정치인'을 존경하는 '이상한' 나라 대한민국...

조직 변경의 2가지 방법 - 역할 변경 vs. 사람 변경 - 에 대한 고찰.

Essay/General 2014.06.23 14:30

조직 변경의 2가지 방법 - 역할 변경 vs. 사람 변경 - 에 대한 고찰.


먼저, "역할의 단위와 조직의 단위가 정확히 일치할 때 효율은 극대화 된다는 것"을 가정할 필요가 있다 - 이후 논의는 이 가정에 기반한다.

(물론, 필자가 이에 대한 논문을 찾아 본적도 없고, 연구결과가 있는지도 모르겠으나, 직관적으로 대부분의 사람들에 의해 그렇게 받아들여지고 있는 것 같다.)

또한, 큰 조직의 변경에 대해서 논할 만큼 나 자신이 경험이 많거나 연구를 많이 한 것이 아니라서 일단 고려하지 않고, 이 글에서는 소규모 조직 - 인원 50명 이하 정도가 4-5 개의 하위 조직으로 다시 나누어진 형태 - 의 변경에 대해서만 이야기 하고자 한다.


조직의 형태는 항상, 다양한 방식으로 변경된다.

많은 경우, 10명 이내/내외 의 인원이 가장 작은 단위의 조직이 되고, 이런 조직들이 다시 적게는 4-5개 많게는 10여개가 모여 다시 차 상위 조직이 되는 구조가 반복적으로 사용되어 하나의 큰 조직이 구성된다.

(옛날, 군대 조직 역시, 10부장, 100부장 등 10 단위로 조직이 구성되는 형태를 종종 볼 수 있다.)

그리고, 이런 소조직 별로 독립적인 역할이 부여되고, 이런 조직들의 유기적인 결합에 의해 다시 차상위 조직의 역할이 결정되는 구조를 가진다.

그런데, 업무와 역할이 항상 고정적일 수는 없고 변화가 생기게 마련이다.

어떤 역할은 그 규모가 확대되기도 하고, 또 어떤 역할은 그 규모가 축소되거나 혹은 아예 사라지기도 한다.

그리고, 이런 일들이 벌어질 때마다 소위 말하는 '조직변경'이라는 것이 생긴다.


'조직변경'의 생기게 되는 이유는 결과적으로 말하면, 역할의 단위와 조직의 단위가 잘 맞지 않기 때문이다.

역할은 내/외부 환경에 의해 계속 해서 바뀌게 되는데, 이때, 요구되는 역할의 단위가 현재 조직의 단위와 맞지 않다면, 조직의 효율을 높이기 위해, 기존 조직을 역할의 단위에 맞게 수정할 필요가 있다.

이때, "어떤 식으로 기존 조직을 변경할 것인가?"라는 문제가 생기게 되는데, 필자는 크게 두 가지 방법이 있다고 생각한다.

첫째, 역할의 변경.

둘째, 사람의 변경.


용어의 모호성을 없애기 위해 '조직 변경'을 '조직역할 변경'과 '조직원 변경'으로 구분하여 사용한다.

'조직역할 변경'이란, '조직'이 수행하는 역할이 변경되는 것을 뜻한다.

'조직원 변경'이란, '조직'의 사람(구성원)이 바뀌는 것을 의미한다.


[역할의 변경]

조직원을 기준으로 역할을 조정하는 방법이다.

즉, 조직 구성원의 변경을 최소화하고, 역할을 조정한다.


[사람의 변경]

역할을 기준으로, 조직원을 변경하는 방법이다.

위의 '역할의 변경'과 반대되는 개념이다.


일반적으로 '사람의 변경'이 '역할의 변경'보다 더 자주 사용되는 경향이 있는데, 내 생각에는, '사람의 변경'에 필요한 비용이 '역할의 변경'에 필요한 비용보다 예측하기 쉽고, 대부분의 경우 비용이 더 적게 들어가기 때문인 것 같다.


예를 들어, 아래의 상황을 가정해 보자.

* A팀(7명)과, B팀(10명) 이 존재한다.

* A팀은 kernel관련 업무를, B팀은 App.관련 업무를 맡고 있다.

* Kernel 업무는 많이 늘어나고 있어서 10명 정도의 인원이 필요한 반면, App. 업무는 줄어들고 있어서 7명 정도면 가능한 상황이다.


이와 같은 경우, 각각 아래와 같이 적용된다.

* 사람의 변경 : B팀의 인원 3명을 A팀으로 옮긴다.

* 역할의 변경 : B팀이 Kernel업무를 담당하고, A팀이 App. 업무를 담당하도록 한다.


어느쪽이 더 효율적이라고 보이는가?

아마, 대부분의 사람들이 아무런 의심이 없이 '사람의 변경'쪽을 택할 것이고, 나 역시, 높은 확률로 '올바른 선택'이 될 것이라고 생각한다.

그럼, 정말 '항상' 이와 같은 선택이 올바른 선택일까?

난, 여기에 의심을 품어 본다.


그렇다면, '왜' 대부분 '사람의 변경'쪽을 택하게 된 것일까?

아마도 아래와 같은 생각 때문이였을 것이다.


'사람의 변경'의 경우, 3명만, 새로운 업무에 적응하면 된다. 반면, '역할의 변경'의 경우 10 + 7 = 17 명 모두가 새로운 업무에 적응해야하고, 새로운 기술을 습득해야 한다.


상당히 합리적이로 옳은 판단의 근거라고 생각한다.

그렇지만, 정말로, 판단의 근거가 위의 내용밖에 없을까?

3명이 빠져 나감으로 인해서 발행하는 B팀의 사기 저하는? B팀의 인원이 A팀으로 옮길 시, 기존 팀원간의 불화에 따른 조직 문제는?

즉, 사람의 문제는 위의 판단에서 완벽하게 배제되어 있다.

다시 한번 말하지만, 위의 '예'의 경우는 '사람의 변경'이 높은 확률로 옳은 선택이라고 나 역시 생각한다.

그렇지만, '항상'은 아니라고 말하고 싶다.

'사람의 문제'에 따른 비용으로, 특수한 경우는 '역할의 변경'이 오히려 더 나은 경우도 분명히 존재할 것이다.

다만, 앞서 언급한 '사람의 문제'에 따른 비용이 예측되지 않기 때문에 사용되지 않을 뿐이라고 생각한다.


이런 종류의 연구를 좀더 조사해 볼 필요가 있어 보인다...


신고
Trackback 0 : Comment 0

[Essay] HDL(High Level Design)의 형식 및 완료 시점?

Essay/Software 2014.03.18 15:49

[ 내 개인적인 생각임을 미리 밝힌다. ]


HLD이든 LLD(Low Level Design)이든 결국 block diagram의 형태 (Component 단위든, Class단위의 UML이든...)일 수 밖에 없고, 얼마나 작은 단위의 block까지 명세하느냐에 따라 구분되어 질 것이다.

그럼 이런 block diagram에서 가장 중요한 요소는 무엇인가?

결국 'Design'이라는 측면에서 본다면, 각 block의 input과 ouput을 정의하는 것이다.

그리고, input/output(IO)를 정의한다는 것은, "이 모듈의 역할을 명확히 정의"하는 것과 같다.

더 나아가, block diagram이라는 것 역시 결국,이런 block간 IO의 연결일 뿐이다.


IO를 명확히 하는 것이 왜 SW design에 중요한가?

SW design은 결국 block 간 IO 연결의 형태로 표현되게 된다. 예를 들면,

"A block은 B block의 output을 input으로 받아서 C block과 D block에서 사용할 값들을 만들어 낸다"

같은 형태가 될 것이다.

이때, 내부 구현의 문제는 해당 block하나에만 영향을 끼친다. 즉 A block의 내부 구현이 문제라고 한다면, A block 만 열심히 다시 구현/설계하면 되는 것이다.

그런데, A block의 IO로 정의된 내용이 틀리다면, 예를 들면, "이 input으로는 기대하는 output을 만드는 것이 불가능 혹은 현실적이지 않다."하다면?

그렇다면, A와 연결된 이후 모든 block의 설계다 전부 연쇄적으로 변경되어야 한다.

즉, 소위 "설계 변경"이 일어날 수 밖에 없게 된다.


일반적으로, 내부 구현 문제는 논란의 여지도 많고, 개선의 여지도 많지만, "A라는 input으로, B라는 output을 만들어 낼 수 있느냐?"의 문제는 내부 구현에 대한 고민과 관계없이 판단 가능한 경우가 많다. 혹은 '불가능'하다는 판단은 못하더라도, '가능하다'라는 판단은 명확히 할 수 있다.

따라서, HLD는 이런 block의 IO정의에 대한 잘못된 판단 요소를 조기에 찾아서, 나중에 설계전체에 영향을 주게되는 일을 미리 방지하는게 목적이 된다.


비단 HLD뿐만 아니라, LLD 및 기타 모든 SW 설계역시 마찬가지일 것이다.

얼마나 큰 단위의 block으로 IO를 설계하느냐의 문제이지 block의 IO를 명확히 하는 것이 무엇보다 중요하다.


그럼, 여기서 좋은 설계자는 어떤 차이를 만들어 내는가?

좋은 설계자는, block간 R&R을 명확히 하고, block의 내부 구현에 대한 어느 정도 '감' 을 가지고 있어서, performance및 resource 사용을 최소화 할 수 있는 형태로 block을 나눌 수 있다.

특히, 여기서, '내부 구현에 대한 감'역시 상당히 중요한데, 때로는 이론적으로 상당히 뛰어난 설계를 했음에도 불구하도, 특정 block이 설계에 정의된 IO를 만족하기 위해 너무 많은 비용 - performance, memory 등 - 이 들어가는 경우가 발생할 수도 있다. 불가능 하다는 말이 아니다, 단지 현실적이지 않다는 뜻이다.

이럴 경우, HLD에서는 IO가 타당하다고 Review되었겠지만, 실제 구현단계에서 설계변경이 필요해지는 경우가 발생하게 되는 경우이다.

이때, 경험이 많은 설계자라면, HLD시점에서, 이런 구현단계의 구체적인 문제를 알지는 못하겠지만, "이런 식의 IO로 module을 설계하면, 뭔가 문제가 발생할 여지가 많아 보이는데... 찝찝하다..."라는 소위 '감'을 가질 수도 있고, 이 '감'에 따라서, 이런 '문제 발생 가능성이 높은 설계'를 피할 수 있을 것이다.



project전체에 대한 개괄적인 schedule이 "주 단위 (혹은 2 주 단위), 아주 큰 project라면 한달 단위"로 나올 수 있다면 HLD가 끝났다고 볼 수 있을 것이다. "schedule이 나왔다."는 말은, "어떤 식으로 개발 할 것이다." 라는 것이 정했졌다는 말이고, 그 말은, "전체적인 Design(큰 그림)이 그려졌다."라는 뜻이기 때문이다.

뭐, 이런 식의 기준이 틀렸을 수도 있지만... 일단 난 이 기준으로 판단하고자 한다.




LLDR은 아마도, 2~3일 단위 정도로 schedule이 나왔을 때 끝났다고 이야기 할 수 있지 않을까?


물론, 이 모든 것은 project 의 규모에 따라, flexible할 것이다....

신고
Trackback 0 : Comment 0

[Essay] (부하직원에게)"OO씨 선에서 해결해. 나까지 나서게 하지 말고." 의 문제점.

Essay/Work 2014.01.07 21:47

회사 생활을 하다보면 제목과 같은 말을 듣는 경우가 종종 있다.

실무 선에서의 문제가 첨예한 의견대립으로 상위선까지 번지게 되는 경우가 있는데, 이런 문제가 자주 나타나게 될때, 상급자들이 하는 대표적인 말 중 하나일 것이다.


"왠만하면, 실무선에서 해결하라. 그런 문제를 해결하는 것 또한 실무 능력이다." 의 의미를 내포한다고 볼 수 있다.

분명, 이러한 의견대립을 잘 해결하는 것 엮시 실무 능력의 중요한 요소 중 하나이다.

너무 많은 의견 대립이 생기고, 상급자(관리자)가 관여해야 할 문제들이 너무 자주 발생한다면, 실무자의 업무 능력이나 태도에 대한 세밀한 관찰이 필요한 것도 사실이다.

그렇지만, 그 부작용 또한 만만치 않다.


예를 들어, A팀 실무자와 B팀 실무자가 서로 협력해서 일해야 하는 경우를 가정해보자.

R&R이 아무리 잘 나뉘어져 있더라도 모호한 부분은 항상 있게 마련이고, 이런 부분에 대한 처리 문제로 의견이 대립하는 경우가 엮시 종종 발생하게 된다. 혹은, 극단적으로는 한쪽에서 다른 쪽으로 너무 무리한 요구를 계속해서 하는 경우도 있을 수 있을 것이다.

이때, A팀 팀장은 실무자를 적극적으로 support하고 있고, B팀 팀장은 실무자에게 '제목'과 같은 이야기를 했다고 가정해보자.

자... 어찌 되겠는가?

B팀 실무자가 A팀 실무자로부터 무리한 요구를 받거나, 혹은 R&R에서 벗어난 요구를 받았을때 - 물론, A팀 실무자는 이것이 무리한 요구라고 생각하지 않을 것이다. 입장차이가 존재하므로... - B팀 실무자가 이를 거부한다면, A팀 실무자는 팀장의 도움을 요청할 것이고, A팀 팀장은 실무자를 적극적으로 support할 의사가 있으므로, B팀 팀장에게 업무 협조 요청을 할 것이다.

자, 이제 B팀 팀장은 실무자에게 상황을 보고 받고, 판단에 따라 '수락' 혹은 '거부' 의사를 전할 것이고, 실무자에게는 질책과 함께, '제목'과 같은 지시를 다시금 전할 것이다.

위와 같은 일이 몇차례 반복되면, B팀 실무자는, 의견대립으로 인해 A팀 팀장이 나서서 B팀 팀장과 연락하게 되는 것에 대한 거부감(혹은 두려움)이 생기게 마련이고, 정말 심하게 무리한 요구가 아니라면 왠만하면 '의견대립'에서 A팀의 요구를 받아 들이는 방향으로 결정하게 될 것이다. 왜냐하면, 그래야만이 관련 문제가 팀장에게까지 전달되는 것을 막을 수 있기 때문이다. 그와 함께, 이러한 "의견 대립"도 줄어 들게 된다.


자... 그럼 결과적으로 어떤 그림이 그려지는가?

관련 일에 대한 의견 대립이 줄어들었으므로, 이에 대한 상급자의 평가는 두 실무자 모두에게 같은 정도의 "이익"으로 돌아가게 된다.(혹은 그 동안의 의견 대립에 대해서 같은 정도로 "피해"가 갈 수도 있겠다.)

하지만, A팀 실무자는 R&R이 명확한 본인의 일만을 처리하면 되므로 업무의 부하가 줄어들게 되는 반면, B팀 실무자는 본인 업무 + R&R이 불명확한 기타 업무 까지 해야하게 되므로 업무 부하가 늘어나게 된다.

두 실무자의 역량이 같다고 가정하면, A팀 실무자는 같은 일을 적은 업무 부하로 해결하고 있으므로 뛰어난 성과를 보일 것이고, B팀 실무자는 반대의 상황에 놓이게 될 것이다.


여기서 필자가 하고 싶은 말은, 팀장이 잠깐 고생하면, 팀원의 업무부하를 상당량 줄여줄 수 있고, 그것은 곳 팀의 업무 성과로 연결된다는 것이다.

반면, 팀장이 어떠한 이유가 되었건 - 귀찮아서, 아니면 본인이 바빠서, 기타 등등 - 위와같은 태도를 취하게 되면, 팀원의 업무 만족도 및 성과는 떨어지게 되고, 그 피해는 결국 팀장 자신에 돌아오게 된다.

어떤 팀의 팀원들이, 협력상대가 되는 팀에 비해 전반적으로 모두 업무 부하가 심하고, 업무성과가 저조하다면, 팀장이 위와 같은 태도를 취하고 있는 것은 아닌지 한번쯤 확인해 볼 필요도 있어 보인다.


신고
Trackback 0 : Comment 0

[관리] 권한+책임 을 부여하면서 힘을 실어주기...

Essay/General 2013.11.21 17:25

지급이 높아질 수록 다른 사람에게 책임/권한을 부여해야할 일이 생기게 된다. (혼자서 모든 일을 할 수 없으므로, 누군가에게 일을 맡겨야 한다.)

이때, 조직의 공식적인 관계(결재/인사평가 에 직접적인 영향을 주지 못하는 관계 - ex. 직급에 차이가 있다 하더라도, 팀장/팀원의 관계가 아닌, 팀원/팀원의 관계)로 맺어지지 않은 사람들을 한 그룹으로 묶어야 하는 경우가 종종 생기게 된다.

예를 들어 아래와 같은 상황을 가정해 보자.

ex. 팀장(수석): A책임 B 선임 데리고 이 일좀 맡아서 해!


이때, A, B는 모두 팀장에게 평가를 받는 같은 위치의 팀원일 뿐이다. 비록 한명은 책임이고, 한명은 선임일 지라도...


아래와 같은 세 가지 경우를 생각해 보자.

경우 1. A에게만 위와 같은 이야기를 전하고, A에게 맡겨 둔다.

경우 2. A, B가 같이 있는 자리에서 두 사람에게 동시에 이 이야기를 전달한다.

경우 3. 팀 회의에서 이야기를 전달한다.


세가지 경우, 모두 특별한 문제가 생기지는 않겠으나, '1' 보다는 '2', '2' 보다는 '3'의 경우가 A에게 '힘'을 실어준다는 측면에서 더 나아 보인다.

그리고, 이 후 팀장이 B와 개인적인 대면을 통해서, A에 대한 칭찬(비록 약간 과장 되었다고 할지라도) - 'A는 충분히 B를 리드할 만 하고, 따를만한 가치가 있는 사람이다.' 라는 생각을 B에게 심어 주기 위해 - 과 함께 , A를 잘 따르라는 이야기를 전달함으로서 더욱 A에게 힘을 실어 줄 수 있다.

또한, 필요하다면, '팀장이 B에 대한 인사평가에 A의 의견을 적극 반영하겠다.'라는 이야기까지 진행함으로써 , A가 B와 함께 일함에 있어서 생길 수 있는 관계상의 문제에 마침표를 찍을 수도 있을 것이다.


어찌보면, 회사에서 '인사평가 line 혹은 report line으로 대표되는 공식적인 관계'를 만들어 두는 것 역시 위에서 언급한 '팀장' 이 A에게 힘을 실어주는 방식과 원칙적인 측면에서 다르지 않다고 볼 수 있다. 즉, 회사차원에서 힘을 실어주는 행위일 것이다.

다만, 여기서 언급하고자 하는 것은, 조직 전체라는 큰 그림에서만 이런 '힘을 실어주는 행위'가 필요한 것이 아니라, 작은 조직, 크게는 '서열'이라는 관계를 형성하는 모든 경우에, 위와 같은 '힘을 실어주는 행위'가 필요하다는 점이다.


단! 여기서 주의할 점이 하나 있다. 위의 예시의 경우에서, "A책임이 팀장의 편애"를 받고 있다고 B선임이 생각해 오고 있었다면, 위와 같은 "힘을 실어주기"는 오히려 '반발'을 불러 올 수도 있다!


신고
Trackback 0 : Comment 0

지난 한 주간, 새삼스레... 새롭게 느낀 것들...

Essay/Software 2013.10.21 14:41

* 서로 잘 모르는 관계에서 어떤 토의를 하거나, 요구사항 등을 받아들일 때, - 예를 들면, 해외 지사에서, 업무에 불편한 점이 없는지, 도와줄 일은 없는 지 등을 조사할 경우 - 는 반드시 아래의 사항들을 먼저 언급하고 시작해야, 서로간 잘못된 의사소통에 따른 비용을 최소화 할 수 있다.

- 이번 토의/회의 의 명확한 목적

ex: 제안을 받아 들여 달라, xxx를 해 달라 등등

- (제안/요구 를 듣는 입장의 경우) 나의 R&R, 할 수 있는 일과 한계 등.


* Software 업계에서 자주 나오는 이야기 중 "Software중에 '보안'을 이야기할 정도로 정말 가치있는 부분은 얼마 되지 않는다"라는 말이 있다. 수많은 좋은 Opensource software가 넘쳐나는데, 회사의 software중 보안이라는 이름으로 권한을 정밀하게 할 가치가 있는 부분은 얼마나 있을까? 너무 넓은 범위, 정밀한 permission체계는 실무자들에게 쓸데없는 Overhead 및 불편함을 만들 가능성이 굉장히 높다.


* 내가 그 사람의 일(작업)을 control할 수 있는 위치가 아니라면, 가능하면, feedback은 긍정적으로 하자.

ex)

Proposal : '이런 이런' 아이디어가 있고, 이렇게 하면 '이런 이런'게 좋아집니다. 어떤가요?

+ 내가 그 사람의 상관(관리자)라면 : 좋으면 -> OK, 나쁘면 -> NO. 만약 idea가 받아 들이기 힘들다면 NO.. etc.

왜냐하면, 그 사람이 하는 일 및 시간을 관리해야 하는 위치이기 때문에, 필요없는 일을 하는 것들 두고 보는 것은 업무에 도움이 되지 않는다.

+ 만약 내가 3자의 입장이라면 : '이런 이런' 점들이 걱정되지만(뭔가 feedback을 원하는 경우이므로, 내가 관심이 있다는 것을 알려 주기위해 feedback은 해 주어야 한다.), 그렇게만 되면 정말 좋겠군요. 꼭 성공하세요.(마지막 feedback은 항상 긍정적이여야 한다. 나는 불가능하다고 생각하지만, 그 사람은 그것을 정말로 해 낼 수 있을지도 모르기 때문이다.)

나랑 관계없는 사람/일 에 굳이 부정적인 feedback을 주어서, 미움을 살 필요는 없다.


* Project에 대한 발표(Presentation)시, Risk에 대한 언급을 포함하고 있지 않다면 그 발표는 문제가 있는 것이다!

무엇이 문제인지도 모르는(고려해 보지 않은) Project description이 제대로 된 것일리 만무하다.


* Project Schedule이 "꼭 해야만 하는 일"로 꽉 차 있다면, Risk에 대해 전혀 고려되어 있지 않다는 것이다!

Project Schedule에 "꼭 해야하지는 않으나, Risk 완화를 위해 필요한 일"을 위한 시간이 포함되어 있어야 한다.


* Project 완료 시간이 너무 촉박하다면, 그 Project는 너무 늦게 시작된 것이다.(해당 사업계획을 잘못 세웠다는 말이다.)

기획/계획 쪽에서도 책임을 져야한다.







신고
Trackback 0 : Comment 0

[Essay] 어째서 종종 소위 '스펙'이 낮은 그룹이 '스펙'이 높은 그룹의 상사로 존재하는 많은 회사들을 볼 수 있는가?

Essay/General 2013.08.30 17:16

많은 회사들이 굴곡을 겪게 된다.

완전히 망하지는 않더라고, 흥(興)했다가 쇠(衰)했다가를 반복하게 마련이다.

사세(社勢)가 안 좋을때는 "좋지 않은 회사"라는 인식때문에 소위 스펙이 좋은 사람들, 다시말하면, 일반적인 회사들이 채용하고 싶어하는 조건을 갖추어서 원하는 회사를 선택할 수 있는 정도의 사람들은 입사를 꺼려하게 된다.

그러나 그 반대의 경우, 즉 사세가 상당히 좋을 때는 "좋은 회사"라는 인식을 가지게 되고, 좋은 사람들이 많이 들어오게 된다.


물론, 회사가 얼마나 잘 되느냐는, 회사에서 어떤 사람들이 일하고 있느냐에 따라 상당부분이 결정된다.

그렇지만, 그런 문제 뿐만이 아니라, 다양한 원인 - 사람, 환경, 전략 등등 - 소위 '흐름' 이라는 것이 존재하고, 이 흐름에 따라 기업은 상승기와 하강기를 겪게 된다.

그리고, 기업은, 회사에 기여한 업적을 기준으로 보상하므로, 소위 '안 좋은 상황'에 회사에 몸담고 있던 사람들은 '상승기'가 되면, '업적'과 더불어 회사가 어려웠을때, 기여했던 공로 - 아이러니 하게도, 그 중 상당수는, 다른 곳으로 이직할 수 있는 역량이 되지 못해서, 어쩔 수 없이 남아 있던 사람들일 가능성도 무시할 수 없다. - 를 인정받아 승진하게 된다.


자~, 이제 회사는 소위 "좋은 회사"로 인정받는 기간에 접어 들었다. 그리고, 사세가 확장되었으므로 일거리가 많아지고, 사람이 많이 필요하게 되었다.

따라서 신규 사람을 채용하게 되고, 이제는 "좋은 회사"로 인정받기 때문에, 뛰어난 스펙/실력/역량 의 지원자들이 몰리게 된다.

이런 과정을 거치게 되면, 회사의 인력 구조는 제목에서 언급한 바와 같이, 실질적인 역량이 떨어지는 사람이 뛰어난 실력의 신입 입사자들을 관리하는 구조로 만들어지게 된다.


회사의 관점이 아니라, 개인의 관점에서 보면, 어떤 사람이 "나는 왜 이직하는 회사마다 망하거나, 아니면, 회사가 어려워지지?"라고 생각한다면, 그 이유는 십중팔구 그 사람이 소위 "뛰어난 사람"이기 때문일 가능성이 높다.

뛰어난 사람이므로, 이직할 당시 "최고의 회사"에 지원해서 합격할 것이다. 보통 "최고의 회사"라고 칭해지는 곳은 그 회사의 정점에 서 있을 확률이 높다. 즉, 더 좋아지기 보다는 이제 하강기에 접어들 가능성이 높다는 뜻이다.

따라서, 이런식의 이직을 몇차례 경험하게 되면, 앞서 이야기 한 바와 같은 생각을 가지게 되는 것도 무리는 아닐 것이다.


어쨌든... 만약, 내가 생각하고 있는 이런 가정들이 충분히 납득할 만하다면, 이직을 할때, 소위 "최고의 회사"에 들어가는 것 보다는 "성장 가능성"을 보고 입사하는 것이 좋아보인다. 물론... 어떤 회사가.. 흥할것이냐 망할 것이냐는 누구도 알 수 없겠지만.... -_-;


신고
Trackback 0 : Comment 0

휴계공간의 접근성과 업무효율의 관계에 대한 단상.

Essay/Software 2013.07.19 12:33

많은 기업들이, 직원들이 업무시간 중에 소위 '잡담'하는 것을 굉장히 싫어 - 일을 안하고 '논다'고 생각하는 듯 하다. - 하는 것 같다.

그래서, 직원들이 휴식할 수 있는 공간을 별로 만들지 않거나, 눈치를 보며 만들더라도 접근성이 어려운 곳에 위치한 경우가 많다.

비록 그것이 '고의적'인 조치는 아니라 할지라도, 직원들의 휴식공간이 회사의 업무공간 배치에 우선순위를 가지가 어렵기 때문에, 결국 접근성이 좋지 않은 곳으로 결정나는 경향도 있을 것이다.


그 원인이 어찌되었던 간에, 휴식공간에 대한 직원들의 접근성에 문제가 있는 경우 어떠한 문제가 발생할까?

직원들의 복지, 만족도 같은 당연하고 일차원적인 영향은, 너무나 당연한 것이므로 따로 이야기 하지 않겠다.

문제는, 직원들이 소위 '잡담'을 하고자 할때, 혹은 짧고, 간단한 업무회의를 하고자 할때 발생한다.

간단한 업무회의라, '회의실'을 따로 잡기에는 좀 무리가  - 회의실은 대부분 항상 부족하기 때문에 막상 예약하려고 해도 사용할 수 있는 곳이 없는 경우가 다반사다. -  - 있으므로, 그냥 업무하는 공간 - 큐비클 - 안에서 이야기 하는 경우가 종종 발생하게 된다.

'잡담'역시, 휴게공간에 가는 것이 귀찮으므로 - 접근성이 떨어진다 - 그냥 큐비클 안에서 이루어지는 경우가 많게 된다.

문제는, '회의'나 '잡담'을 하는 당사자가 아니라, 그 주변 사람들이다.


소프트웨어 회사의 경우를 생각해 보자.

소프트웨어는 엄청난 집중력을 요구하는 업무가 많다. 그런데, 이때 주변에서 '회의'를 하거나, '잡담'을 하는 소리때문에 집중하기 어려운 환경이 조성되게 되면, 업무에 차질을 빚게 된다.

100여명이 일하는 공간을 가정해 보면, 그 중 한 곳의 2~3명이라도  이러한 '큐비클 안 회의/잡담'을 하게 되면, 다른 97~98 명은 집중을 요구하는 일을 하기에 대단히 어려운 환경에 처하게 되는 것이다.

그렇다고 해서, '업무 큐비클에서 회의하거나 잡담하지 말라'라는 공문/지시를 하는 방법으로 해결하려고 한다면, 이 또한 흐지부지 될 가능성이 높다.

처음 며칠은 지켜질 수도 있겠지만, 약간만 시간이 지나게 되면, 또 다시 이러한 문제들이 발생하게 된다. 왜냐하면, 근본적으로 이 문제를 '처벌의 대상'으로 보기에 상당한 무리가 따르고, 객관적인 '측정기준' - 처벌을 위한 - 을 만들 수가 없으므로, 지켜지지 않을 것이다.

결국, 직원들의 휴게 공간이 부족 + 접근성의 문제는 전체적으로 보면, 직원들의 업무 효율성과도 직접적인 연관성이 있다.


소위 '직원들이 노는 꼴을 못 본다.'는 회사가, 직원들의 휴게 공간에 대한 접근성을 심하게 떨어뜨리게 되면, 역설적으로 '직원들이 일을 제대로 할 수 없는' 환경을 만들게 되는 것임을 깨달을 필요가 있다.


신고
Trackback 0 : Comment 0

정치를 통한 세상의 변화를 체감할 수 있는 바로미터....

Essay/General 2013.03.29 13:32

 자기 개발 서적에서 많이 나오는 이야기 중 하나가. "모든 것을 '자기 탓'으로 돌려라."이다. 그래야 자기 발전이 있고, 문제해결의 실마리가 보이기 때문이다. 문제의 원인을 외부의 탓으로 돌리면, "어쩔 수 없다."는 결론 이외에는 얻을 수 있는 것이 없다.


 이런 관점에서 보면, 국내 정치환경이 나아지기 까지는 앞으로도 많은 시간이 필요한 듯 하다. 


 정치에 불만을 가지는 대부분의 글이 "저 정치인은 이래서 문제고, 저래서 문제고..." 등의 글이다. 즉, 문제의 원인을 "잘못된 정치인" - 외부 - 에서 찾고 있다. 그래서, "정치인은 어쩔 수 없다." 혹은 "정치가 다 그렇지 뭐" 식의 이야기가 나오게 되는 것이다. 위에서 "자기 개발 서적"을 예로 든 내용과 거의 유사한 흐름이다.


정말 문제를 해결하고 싶다면, 원인을 "자기 탓"으로 돌려야 한다. 즉 "내가 왜 저런 정치인에게 표를 줬을까?" 혹은 "왜 저 정치인에 표를 준 많은 사람들 중 한명이라도 더 설득하지 못했던가?" 등의 방식으로...


정치에 대한 불만을 표출하는 글과 말들이, 정치인을 주어로 하지 않고, 자기 자신을 주어로 하는 식으로 변해갈 때, 비로소 우리는 "변화"를 이야기 할 수 있지 않을까?...

신고
Trackback 0 : Comment 0

"Programming skill"의 정의와 거기에서 파생되는 문제점...

Essay/Software 2013.01.21 18:10

Software업계에서 Programming skill 이라는 단어가 많이 사용되고 있는데 비해, 그 정의가 명확하지 않은 것 같다.

아니, 정의가 명확하지 않은게 아니라, 정의를 실체화 하는 방법이 명확치 않다고 해야 하나?


일단 "좋은 코드/소프트웨어"라는 말에 대한 정의는 어느 정도 합의된 실체가 있는 것 같다.

그럼에도 불구하고, 정량적인 측정 기준이 없기 때문에 여전히 관념적인 형태에 머물러 있긴 하지만...

그런데, "좋은 소프트웨어"를 만드는 것 => Programming skill 이 뛰어난 것"이 되지 못하는 이유는 현실적으로, 보통 '시간'으로 대표되는 '비용'이라는 요소가 들어가기 때문이다.

그래서 결국, Programming skill은 "적은 비용으로 좋은 소프트웨어를 만드는 기술"이라고 정의되어 질 수 밖에 없다.


문제는 앞서 이야기한 것처럼, "좋은 소프트웨어"라는 요소는 정량적인 기준이 없고, 측정방법 또한 모호하다. 그렇지만, '비용'은 객관적이고 명확한 측정 방법을 가진다. 그러다보니, 두 요소 중 '비용'이라는 요소에 더 집중하게 되고, 그것을 기준으로 Programming skill 을 말하는 경우가 많다.

그러다 보니, 극단적으로, "적인 비용으로 소프트웨어를 만드는 기술"이 Programming skill 로 왜곡되어 정의되어 버리게 된다.

(이 경우, 소프트웨어의 품질은 전혀 고려 대상이 아니다.)


실제, 계약에서도, 측정할 수 없는 "좋은 소프트웨어"라는 항목을 계약서에 기술할 수 없으므로, "비용"에 초점이 맞추어 질 수 밖에 없게되고, "적은 비용"이라는 기준을 만족시키는 쪽이 "기술력이 있는 곳"이라는 평가를 받게 되는 기이한 현상이 벌어지게 된다.

이는 계약에서 뿐만아니라, 국내 기업의 업무 형태에서도 쉽게 찾아볼 수 있다 - 물론 모든 기업이 그렇다는 이야기는 아니지만, 대부분(특히 소프트웨어가 주 제품이 아닌 곳들)의 경우 해당될 것이다.

소프트웨어를 만드는데, 연봉이 높은 우수 인력을 사용하는 것은 '과다 비용'으로 받아들이고, 경력이 짧은 미숙한 엔지니어에게 일을 맞겨 소위 "돌아가는 소프트웨어"를 만들어 내는 것을 "잘 했다"고 평가한다. 즉, 소프트웨어의 "품질"은 무시되고, "비용"부분만 고려된 "평가"인 것이다.


이와 같은 현상은 계속 반복된다.

위와 같은 방식으로 만든 소프트웨어는 필연적으로 수많은 문제점(버그)를 내포하게 된다. 이제 이 문제점들을 수정해야 하는데, 이 역시 '비용'만을 고려해서, 미숙한 엔지니어가 처리하게 되고, 수많은 fix-on-fix를 양산하는 악순환을 반복한다.

그러면서, "소프트웨어는 당연히 많은 버그를 내포할 수 밖에 없고, 약간의 수정도 많은 문제점을 동반할 수 밖에 없다."라는 이상한 결론을 내려 버린다.


위의 이야기는 좀 극단적인 측면이 있지만, 국내 현실을 상당히 잘 반영한다고 생각한다.

"소프트웨어의 비용 감소"라는 측면에서 시작된 것이 아니라, 순수하게 "소프트웨어 품질의 정량화"라는 측면에서 시작된, 소프트웨어 관련 연구가 활발하게 이루어 졌다는 이야기는 들어 본적이 없다. 물론, 내가 잘못 알고 있는 것일 수도 있지만...

각설하고... 슬프지만... Programming skill에 대한 가장 현실적인 정의는 "적은 비용으로 소프트웨어를 만들어 내는 기술"이라고 할 수 밖에....


주저리 주저리... 문맥도 안맞고... 내용도 정리가 안되어 있고.. 쩝..

신고
Trackback 0 : Comment 0

[Essay] 타국(민주주의 국가)의 훌륭한 정치인을 보면서, '정치인'을 존경하는 '이상한' 나라 대한민국...

Essay/General 2013.01.08 21:29

아침에 출근하다가 버스에서 라디오를 듣는데...  우르과이 "호세 무히카"대통령을 언급하면서, 대통령에 대한 존경을 표하는 내용의 방송이 나왔다.

그런데 문득 대한민국은 참 이상한 나라라는 생각이 들었다.

"왜 대통령을 존경하지?"

그때부터, 아래와 같은 생각들이 계속해서 머리에 맴돌았다. (그냥 떠오르는대로 마구 적어 본다...)


내가 보기에는, 대한민국의 많은 국민들이, 나라에서 일어나는 많은 일들의 공과(功過)를 이야기할때, "정치인의 공과(功過)"라는 관점으로 접근하는 것 같다.

박정희 전 대통령의 경우를 예로 들어 보면...


많은 사람들이 '박정희' 전 대통령의 업적 중 하나로, '경제성장'을 말한다.

일단 '박정희' 전 대통령에 대한 다른 평가는 전부 접어두자.

여기서 내가 이야기 하고 싶은 것은, '경제성장'의 업적을 자연스럽게 나라의 최고 통지자에게 돌리는 '이상한' 모습이다.

박 전 대통령의 역할이 전혀 없었다는 말을 하는건 아니다. 그건 누구도 알 수 없는 부분이다. 엄청난 기여를 했을 수도 있고, 전혀 기여하지 않았을 수도 있다. 혹은 오히려 방해가 되었을지도 모를 일이다.

그런데, 이상하게도 상당수의 국민들이 '경제성장'이라는 업적을 그냥 단순하게 '대통령'의 업적으로 이야기한다.


왜 그럴까? 그냥 단순한 '국민성'인건가? 아니면, 책임 회피? 모르겠다.

그렇지만, 내 생각은 이렇다.

박 전 대통령의 '경제성장'에 대한 공과(功過)는 논란의 여지가 있으나, 한가지 100% 확실한 것은 '경제성장'의 주역은 그 시대를 살았던 '대한민국 국민'이라는 것이다. 즉, 한강의 기적은 '최고 통치자의 업적'이 아니라, '대한민국 국민의 업적'으로 받아들여져야 한다.


다시 "호세 무히카" 대통령에 대한 이야기로 돌아가보면...

우리가 존경해야할 상대는 "호세 무히카" 대통령이 아니라, 그 사람을 대통령으로 선출한 "현재의 우르과이 유권자"가 되어야 하다.

대한민국에 과연 "호세 무히카"같은 사람이 없을까?

그럴리 없다. 어딘가 분명히 더 훌륭한 분이 계실 것이다.

그렇지만, 대한민국 유권자는 그런 사람을 대통령으로 선출하지 않았다.

"등록된 후보 중에 그런 사람이 없지 않냐?"라는 이야기를 한다면, "대한민국 유권자가, 그런 사람이 '등록하면 당선될 수 있다.'라는 희망을 가질 수 있는 정도의 수준인가?"라고 되묻고 싶다.


정리하면... 우리는 훌륭한 정치인을 칭찬하기 보다는, 그런 정치인을 알아보고 선택한 것을 자축해야 하며, 나쁜 정치인을 비난하기 보다는, 그런 정치인을 선택한 것을 반성해야 한다. 시대의 '공(功)'과 '과(過)'는 정치인의 몫이 아니라, 그 시대를 사는 국민들의 몫이다. 적어도, 민주주의 국가에서는...


신고
Trackback 0 : Comment 0

티스토리 툴바