Tag Archives: slack

합리적인 작업량이란?

요즘에 많이 읽고 있는 이런 저런 책들에서 공통적으로 이야기하는 것을 요약하자면 다음과 같습니다. (톰 드마르코의 책들이 특히 많습니다만..)

“지식 노동자의 경우 기존의 과학적인 관리 방법과는 다른 성향을 보인다. 예전 방식으로 뭔가 짜내려고 하지 마라”
그런데 내가 예전에 존경하던 교수님들(무려 교수님들이다..)께 듣기로는
“공학이란 예전부터 도제 시스템에 의하여 운영되었다. 장인이 제자를 키울때 처음에는 전혀 의미없어 보이는 일을 끝도 없이 시키고, 가혹하게 훈련시킨다. 그리고 난 이후에야 한사람의 장인이 탄생할 수 있다.”
그리고, “대학원생들은 ‘아야’소리도 나지 않을 정도로 짜내야 한다. 고 들었는데.. 이 접점을 찾을 수 없는 두 가지 관점에서 어떤 것을 옳은 것으로 생각해야 할까요?
제 생각에는 두 가지 관점 모두 진리라고 생각합니다.
공학이라는 분야에 있어서 말이지요.
비단 공학에만 국한된 이야기는 아니지만 많은 일이 처음에는 기술에서 출발하여 예술의 경지(state of the art)에 도달하게 되어 드디어 한 사람의 장인(artisan)이 탄생하게 됩니다.
처음의 기술을 익히는 단계에서 가장 중요한 것은 많은 실수를 겪는 것이며, 이를 위해서는 많은 시도가 필수적일 것 같습니다. 극한의 스트레스도 겪어볼 필요가 있고, 몰입의 즐거움을 느낄 필요도 있고(자의에 의해서건 타의에 의해서건) 이 기술이 자기 자신에게 어울리는 것인지 확인하는, 몸으로 체득하는 기간이 필요하다고 봅니다.
1만 시간의 법칙이 적용되는 기간이라 봅니다.
이 시간동안에 얼마나 많은 고민을 했고, 얼마나 미친듯이 달려보았는지가 나머지 엔지니어의 경험에서 큰 영향을 미치겠죠.
그 이후에는 다양한 변수에 대해서 고민할 때가 됩니다.
실질적으로 이때부터가 진정한 지식 노동자(?)의 초입에 들어가는 것이고, art까지는 아니더라도 아름다움에 대해서 고민할 때가 아닌가 싶습니다.
더 지나면 artist에 가까워지는 artisan이 되겠죠. 저는 뭐 아직 근처에도 도달하지 못했으니 아직은 모르겠지만요..
이런 측면에서 도았을때 실질적으로 눈으로 보이는 작업의 량은 초기에는 좀 많은 듯 해서 기술을 익히고, 조금 지나면 실질적인 지식 노동자되면서 생각의 질이 높아가면서 정량적인 작업량의 추정이 쉽지 않아질 수 있을 것 같습니다.
지식 노동(?)의 특징이라는 것이, 필요하다면 즉 데드라인이 결정되어 있는 경우 어떤식으로든 결과를 낼 수 있는데, 그것이 전혀 아름답지 않을 수도 있고, state of the art일수도 있지요.
slack에서 표현하고자 했던 것이 바로, 이런 측면이 아닌가 싶습니다.
“지식 노동자를 데드라인으로 압박하지 말아라.. 결과를 얻을 수는 있겠지만, 최선의 결과는 결코 아닐 것이다.”
따라서 합리적인 작업량, 합리적인 데드라인이란 지식 노동자의 수준인 엔지니어에게는 “회사에서 요구하는 작업의 질에 따라” 자기 자신이 설정해나가는 것이 가장 좋겠지요. (물론, 자기 자신에게 알맞는 데드라인을 정하는 것 자체가 별로 훈련이 되지 않은 상태일 것이므로, 적응해 나가는데 시간이 필요할 것 같습니다.)
지식 노동자에 다가가고 있는 중이라면 필요에 따라서 약간 강한 작업량을 가져가는 것이 도움이 되겠죠.

창조를 위해서 필수적으로 필요한 시간 – Slack

그동안 오랫동안 블로그에 글을 안쓰면서  비교적 독서량을 늘린 기간이었습니다.
그렇다고 뭐 전공 관련된 서적을 많이 읽은 것이 아니라 이 블로그에 소개할 만한 책은 별로 없구요.. (문학과 인문학쪽을 읽어보고 싶었다고 할까요… ^^; )

그 중에 최근에 읽은 책 한권을 소개시켜 드리려 합니다.

바로 이곳 저곳에서 화제의 책인 “Slack: 변화와 재창조를 이끄는 힘”입니다.
이 책의 존재를 알게 된 것은 자주가는 블로그인 류한석님의 블로그와 인사이트 블로그를 통해서구요..
jrouge님의 서평을 읽고 “엄훠~ 이 책은 꼭 사야해~”라는 생각을 가지고 있었습니다. 단지 queueing 되어 있던 책을 읽어나가느라 ^^;

하드웨어 엔지니어에게 있어서 slack이라는 말은 참으로 익숙합니다.

synopsys 합성툴을 돌리면 도대체 알아먹을 수 없는 단어를 처음 접하게 되는데, 바로 “slack”이라는 단어지요.
도대체 사전을 찾아봐도 딱히 와닫지 않았던 이 단어는 워낙 오랜 시간 사용하다보니 추상적으로 알게되었고, 예전에 합성 툴에서 slack이라는 개념과 TNS, WNS를 어떻게 할꺼니.. 라는 주제로 글을 쓴적도 있었더랬죠. (http://babyworm.net/tatter/90)

여하튼, 합성툴 돌리는 사람에게는 퇴근이 걸려 있는 문제라 거의 목숨과 동급으로 중요한 이 단어가, 합성툴을 사용하지도 않는 사람에게 왜 회자되게 된 것일까?

바로 효율성과 효과성이라는 문제 때문입니다.

우리는 어느덧 빨리 빨리, 좀 더 오랜시간, 좀더 tight하게.. 라는 명제에 익숙해져 있습니다.
VP가 어디선가 따온 불가능할 것 같은 일정을 받아들고, “힘들지만 할 수 있습니다.”라고 이야기 할 수 있는 사람이 능력있는 엔지니어로 생각하게 되는 것이지요.
물론, Quality는 떨어질 수 밖에 없지만, 고객에게 크게 문제가 안된다면.. 이라면서 뒤로 쌓아두게 됩니다.

이 문제는 제가 회사를 다니고, 머리가 굵어지면서(아.. 네.. 제 머리 약간 큽니다.) 항상 고민했던 문제입니다.
회사가 급하니 이런 저런 자잘한 문제(자잘하지만, 바로 먹고사는 문제와 크게 연관성이 있을 법한)에 투입되고, 그러다보니 다음 프로젝트의 시간이 줄어들고, 그럼에도 불구하고 그 프로젝트의 일정은 맞추어야 하고, 구현하려던 기능의 많은 부분을 포기하게 되고, 어느 순간 “그 기능이 없어서 못 팔아.. “라는 비난을 받게 되는 우습고도 슬픈 상황에 직면하게 되는 것이지요.

그럼 사람들이 놀았냐.. 정말 주말도 없이 일했으며, 주중에도 거의 개인 생활은 없었으며, 그럼에도 뭔가 좀 아쉽다는 거죠.

그 이유는 바로 이 책에서 명쾌하게 설명해 줍니다. (솔직히 100% 명쾌하다고 말은 못해도, 아주 많은 부분을 설명해 줍니다. 제가 하고 싶은 말을 논리적으로 누군가 잘 포장(?)해 주었다고나 할까요?)

뭐.. 변명할 필요없이 관리(?)를 하고 있던 저의 잘못이지요.
빛나던 친구들이 빛을 잃어가는 것을 보면서도, ‘뭔가 잘못되었구나’를 느끼면서도, 기껏 해줄 수 있는 것이 motivation을 주는 것 밖에 없었으니까요. 참 무력했던 거죠.
당시에 이 책을 읽었다면 좀 더 도움이 되지 않았을까.. 좀 더 적극적으로 행동하지 않았을까 하는 생각이 듭니다.

일하는 즐거움으로 빛나고 있지 않다면, 두말 없이 이 책을 권해 드립니다.