요즘에 많이 읽고 있는 이런 저런 책들에서 공통적으로 이야기하는 것을 요약하자면 다음과 같습니다. (톰 드마르코의 책들이 특히 많습니다만..)
Tag Archives: slack
창조를 위해서 필수적으로 필요한 시간 – Slack
그동안 오랫동안 블로그에 글을 안쓰면서 비교적 독서량을 늘린 기간이었습니다.
그렇다고 뭐 전공 관련된 서적을 많이 읽은 것이 아니라 이 블로그에 소개할 만한 책은 별로 없구요.. (문학과 인문학쪽을 읽어보고 싶었다고 할까요… ^^; )
그 중에 최근에 읽은 책 한권을 소개시켜 드리려 합니다.
바로 이곳 저곳에서 화제의 책인 “Slack: 변화와 재창조를 이끄는 힘”입니다.
이 책의 존재를 알게 된 것은 자주가는 블로그인 류한석님의 블로그와 인사이트 블로그를 통해서구요..
jrouge님의 서평을 읽고 “엄훠~ 이 책은 꼭 사야해~”라는 생각을 가지고 있었습니다. 단지 queueing 되어 있던 책을 읽어나가느라 ^^;
하드웨어 엔지니어에게 있어서 slack이라는 말은 참으로 익숙합니다.
synopsys 합성툴을 돌리면 도대체 알아먹을 수 없는 단어를 처음 접하게 되는데, 바로 “slack”이라는 단어지요.
도대체 사전을 찾아봐도 딱히 와닫지 않았던 이 단어는 워낙 오랜 시간 사용하다보니 추상적으로 알게되었고, 예전에 합성 툴에서 slack이라는 개념과 TNS, WNS를 어떻게 할꺼니.. 라는 주제로 글을 쓴적도 있었더랬죠. (http://babyworm.net/tatter/90)
여하튼, 합성툴 돌리는 사람에게는 퇴근이 걸려 있는 문제라 거의 목숨과 동급으로 중요한 이 단어가, 합성툴을 사용하지도 않는 사람에게 왜 회자되게 된 것일까?
바로 효율성과 효과성이라는 문제 때문입니다.
우리는 어느덧 빨리 빨리, 좀 더 오랜시간, 좀더 tight하게.. 라는 명제에 익숙해져 있습니다.
VP가 어디선가 따온 불가능할 것 같은 일정을 받아들고, “힘들지만 할 수 있습니다.”라고 이야기 할 수 있는 사람이 능력있는 엔지니어로 생각하게 되는 것이지요.
물론, Quality는 떨어질 수 밖에 없지만, 고객에게 크게 문제가 안된다면.. 이라면서 뒤로 쌓아두게 됩니다.
이 문제는 제가 회사를 다니고, 머리가 굵어지면서(아.. 네.. 제 머리 약간 큽니다.) 항상 고민했던 문제입니다.
회사가 급하니 이런 저런 자잘한 문제(자잘하지만, 바로 먹고사는 문제와 크게 연관성이 있을 법한)에 투입되고, 그러다보니 다음 프로젝트의 시간이 줄어들고, 그럼에도 불구하고 그 프로젝트의 일정은 맞추어야 하고, 구현하려던 기능의 많은 부분을 포기하게 되고, 어느 순간 “그 기능이 없어서 못 팔아.. “라는 비난을 받게 되는 우습고도 슬픈 상황에 직면하게 되는 것이지요.
그럼 사람들이 놀았냐.. 정말 주말도 없이 일했으며, 주중에도 거의 개인 생활은 없었으며, 그럼에도 뭔가 좀 아쉽다는 거죠.
그 이유는 바로 이 책에서 명쾌하게 설명해 줍니다. (솔직히 100% 명쾌하다고 말은 못해도, 아주 많은 부분을 설명해 줍니다. 제가 하고 싶은 말을 논리적으로 누군가 잘 포장(?)해 주었다고나 할까요?)
뭐.. 변명할 필요없이 관리(?)를 하고 있던 저의 잘못이지요.
빛나던 친구들이 빛을 잃어가는 것을 보면서도, ‘뭔가 잘못되었구나’를 느끼면서도, 기껏 해줄 수 있는 것이 motivation을 주는 것 밖에 없었으니까요. 참 무력했던 거죠.
당시에 이 책을 읽었다면 좀 더 도움이 되지 않았을까.. 좀 더 적극적으로 행동하지 않았을까 하는 생각이 듭니다.
일하는 즐거움으로 빛나고 있지 않다면, 두말 없이 이 책을 권해 드립니다.