여러분의 관리자는 이러지 않나요..?
누구든지 다른사람에게 어떤 일인가를 부탁해 본 경험들이 있을 겁니다.
여기서 두 부류로 나뉘게 되죠..
1. 과정을 일일이 지켜 보며
'아니야~ 아니야~ 그렇게 해선 안된다구! 이렇게 하는게 더 효율적이란 말이야!! 왜 그렇게 느려?!' 라고 옆에서 지적을 서슴치 않는 분류와,
2. 때때로 일이 잘 진행되고 있는지 확인을 하는 경우죠.
네, 제가 하고 싶은 이야기는 1번 스타일의 '관리자' 이야기 입니다.
하나의 애플리케이션이 만들어 지기까지 선두 지휘하는 그 '관리자'요.
하지만 모든 관리자에 대한 얘기가 아닌..
프로그래머의 스케쥴을 완전히 장악해 숨통을 죄는 관리자에 대한 얘기를 해보려고 합니다.
제가 아는 회사의 관리자는 매일 스케쥴을 시간 단위로 정검 합니다.
프로그래머들은 스트레스 받아 곧 죽어도 이상하지 않을 지경이더군요.
무슨 핑계꺼리로든 '몇시~ 몇시 DB에서 xx값을 읽어오는 모듈 작성' 식의 업무판이 작성되어 있어야하죠.
다른 프로그래머 보다 시각이 작거나 건수가 작으면 그 자리에서 비교대상이 됩니다.
ㅎㅎㅎ
이렇게 프로그래머를 꽉 잡아 비틀고 있어야 회사가 제대로 돌아간다고 생각 하시나요..?!
그건 절때 아니라고 생각하는데요..?
프로그램을 예술이라고 부르는 사람도 있습니다.
네, 저도 프로그램을 창조적인 일이라고 생각하는 사람 중에 하나 입니다.
머리가 너무 산만해도 열심히 버튼을 누르거나 끈을 묶어주면 오늘치의 과업을 마무리 되는 일이 아니라, 오늘 너무 머리가 산만해서 뭐라고 열심히 타이핑을 하긴 했는데 정작 진도는 하나도 빼지 못하는 날이 있는 직업이죠.
오늘 너무 머리가 산만해서 진도를 하나도 못나가는 날이 일주일, 한 달이 계속되면 분명 문제가 있는 겁니다.
제가 말하고 싶은 건 바로 이때! 관리자가 개입해 채찍을 후려대며 당근을 적당히 뿌려줘야 된다는 겁니다..!!
하루, 시간 단위로 무턱대도 개입해서 '왜 생산성이 이것 밖에 안돼죠? 인사고과에서 누락 되고 싶으신가요?!'라며 옆에 사람과 비교를 해가며 과음을 버럭 버럭 질러대는 관리자 밑에서 그 어떤 프로그래머가 버텨 줄까요?!
신기하게도 많은 사람들이..
어떤 공개적인 글을 읽을 때 자신과는 거리가 먼 얘기라고 생각하는 경우가 많더군요.
거기 이 글을 읽고 계시는 관리자님..
프로젝트 때마다 새로운 회사원과 작업을 하고 계신다면,
자신을 한 번 천천히 돌아보세요.
이 글이 바로 바로 당신 부하직원의 글일지도 모르잖아요?! ㅎㅎㅎ
하하...보기만해도
왠지 숨통이 막혀오는군요...
뭐 (아직) 회사원은 아니지만
저런 관리자밑이라면 (창조적인 작업뿐만아니라) 어떤일이든지
제대로 할 수 있을지 의문이군요....:?
그리고 프로그래밍이 창조력을 필요로한다는데는
절대 동감입니다.
붓은 CURSOR, 캔버스는 WHITESPACE라고
해석되어야 하는겁니다......
Want 2 be A good Programmer
Want 2 be A good Programmer
저도 프로그래밍을
저도 프로그래밍을 예술이라 칭하는 사람 중 하나입니다.
그리고 "개인적으로" 프로그래밍은 머리속이나 종이, 화이트 보드에 설계하는 부분까지라고 여기고 있습니다. 그 다음부터는 슈도 코드를 따라서 머리속에 있는걸 타이핑 하는 것 뿐이라고 생각하고 있습니다. 이건 코딩이죠. 생각을 키보드로 하지말자 주의입니다;
원글과 같은 형태의 일정 조율이 "프로그래밍" 단계에서는 적절하지 않다고 생각합니다. 하지만 코딩이 이루어 지는 시기에는 일정 조율은 꼭 필요하다고 생각합니다. 물론 방법은 여러가지 겠지만요. 원글의 방법도 이런 시기(공학의 시기라고나 할까요;;)에는 괜찮은 방법이라고 생각합니다. 일전에 15분 단위로까지 그룹웨어를 통해 일정 조율을 하던 때도 있었으니까요. 당시에는 평균 30분 정도로 조절했었습니다. 15~30분 단위로 타임라인 체크가 이루어질 때 전체 업무 집중도가 엄청났던걸로 기억합니다. 개발방법도 XP를 따르고 있었는데 결과물 나오는 속도는 엄청났었습니다;
조율 간격이나 체크 방식은 조직이나 시스템에 따라 적절히 조정하면 된다고 생각합니다.
하지만 그걸 토대로 사람의 능력을 공개적으로 또는 암묵적인 비교가 이루어진다면 그건 좀 아니네요;; 일을 잼나게 하게 해줘야 하는데 사람 기를 꺾는 관리 방식이라면 관리자에게 문제가 있다고 생각합니다..
피플 웨어를
피플 웨어를 읽어보셔야 할 팀장님 같군요. 물론 그 글을 읽으시고 잘 받아들이실지는 의문이지만요.
Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/
Orion Project : http://orionids.org
삽질
밑에 링크들이 말씀하신 피플웨어의 링크인줄 알고 한참 들여다 봤습니다.
ㅎㅎㅎ
ㅡ_ㅡ);;;;;;;;;;;;;;;;;
--------------------------------------------
:: 누구보다 빠르게 남들과는 다르게
Quote: 밑에 링크들이
-_-;;; 피플웨어는 서점에 있습니다.
절취선을 두었습니다...
--------------- >8
Coral Library Project : http://coral.kldp.net
Orion Project : http://home.megapass.net/~heesc22/
Orion Project : http://orionids.org
믿음이 필요합니다..
제목이 무슨 종교 얘기처럼 돼버렸는데요.. ^^;
한시간동안 일을 하느냐 마느냐도 못믿는데
어찌 일을 맡겼을까요..
저와 가까운 경험상으로 개발자들이 제일 당혹해
하는 것이 일일보고였는데요.. 한시간은 넘 심해요..
그나저나 그 관리자분 참 부지런하십니다..
저같음 도저히 안될 것 같습니다.. ^^;
http://blog.dreamwiz.com/shjii
^^
관리자는 자신의 팀중에 이러한 팀원을 찾아서,
사표를 쓰게 만드는 것이 그들의 임무입니다. ^^
There is no spoon. Neo from the Matrix 1999.
There is no spoon. Neo from the Matrix 1999.
얼마전에 본
얼마전에 본 블로그의 그림이 하나 떠오르는군요.
말은 쉽지만...
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
시간단위
시간단위 스케쥴이라..
공장에서 단순 생산직을 관리하던 방식을 그래도 적용하고 있군요.
저는 프로그래밍을 예술이라고 생각 하지는 않습니다만,
창조적인 일이라고 생각 합니다.
흠...
초짜 관리자이거나 계념이 없다고 봐야겠지요.
그나저나 저라면 피말려서 같이 일 못하겠네요.
리더십/매니지십
마이크로매니지의 병폐는 이미 널리 알려져 있지요.
관련 있는 글을 전에 쓴 것이 있어 링크 겁니다.
http://agile.egloos.com/1530311
공감이 갑니다
저도 공감이 갑니다
프로그래밍은 예술?
백남준이 예술은 사기라고 말했다는 군요.
백선생님이 옳다면 프로그래밍도 사기입니다.
그래서, 우리는 사기를 치고 있는거죠. 버그 있는 프로그램을 잘 팔아먹잖아요
백선생님은 예술을 mental game이라고 하셨다는 군요
programming도 mental game인가요?
programming은 혼자 하는 것이 아니라 함께 하는 것입니다.
programmer는 너무 이기적이지 않을까 반성해야 합니다.
우리는 자기 반성 없이 비판만 합니다.
믿음을 먼저 주면 관리자도 그렇게까지 할까요?
일단 give하고 그 다음 take합시다.
믿음을 먼저 주면
믿음을 먼저 주면 관리자가 그렇게까지 할까라는 것에 대해...
네! 아무리 일 잘하는 사람에게도 하나하나 간섭하지 않으면 못 견디는 관리자가 있.습.니.다.
반면에 그렇게 간섭하지 않으면 제대로 일 안 하는 프로그래머도 상당히 있겠죠. 그때그때 상황과 상대에 따라 적절히 대응하는 관리자가 최적이겠지만...
약간 핀트가 다른 듯....
말씀하시려는 주제는 알겠습니다만,
비유가 적절치 못한 것이 아닌가...합니다.
백남준씨가 말씀하신 [예술은 사기]라는 의미는 ,
[예술은, 기호를 왜곡하여 해석하기 어렵게 하는 놀이일 뿐] 이라는 의미로 이해됩니다.
즉, [예술 = 기호학적 왜곡] 이란 의미에서 [사기]라는 거죠. 원래의 기호를 왜곡하게 되니까요.
하지만, [프로그래밍도 예술이다] 일때의 예술이란 의미는...
[프로그래밍도, 창조적 작업이 필요하다]라는 의미에서 예술이다는 의미로 알고 있습니다.
프로그램은 창조적 작업이 필요하지만, 그렇다고 기호를 왜곡하지는 않지 않습니까.
고로... 비유하신 예는 이 경우에는 안 맞는 것이 아닌가 합니다.
물론, 이것은 [버그 있는 프로그램을 팔아먹는다.] 에 대한 반론도 아니며,
[일단 give하고 다음 take하자]의 반론도 아닙니다.
단지, 의도가 다르게 쓰이는 것이 눈에 거슬려, 몆 자 적어봅니다.
행복은 희생없이는 얻을 수 없는 것인가?
시대는 불행없이는 넘을 수 없는 것인가?
저런.........
저희 팀장님은 2번( 가끔 살피시는)에 속하시는 분이신데,
1번과 같다면 정말 회사 다니기 싫을 것 같습니다.
병특이라 3년은 있어야 하지만.....ㅡ.ㅡ;;
신뢰의 문제가 아닐까요?
이 글과 비슷한 경우를 본 적이 있는데요.
그 팀장은 처음 2번의 경우처럼 가끔 일의 진척도만 체크를 하면서 프로젝트를 진행했습니다. 그런데, 이것이 문제가 되는 것이 열심히 하는 사람은 문제가 되지 않는데, 이 핑계~ 저핑계 되면서, 농땡이만 피우는 사람도 있었답니다. 그렇게 시간이 흐르자~ 서로에 대한 신뢰감을 떨어지고~~ 팀장은 1번의 경우처럼 매 시간마다 숨통을 죄면서 프로젝트를 진행했답니다.
그렇게해서 프로젝트는 문제없이 끝냈지만, 그 후 서로에 대한 신뢰감을 상당히 떨어졌다고 합니다.
팀장이 습관처럼 매 시간마다 체크하고 숨통을 죈다면 문제가 있겠지만, 혹시 그전에 서로의 신뢰를 잃지는 않았나요? 그래서 팀장이 팀원을 못 믿어서 그렇게 숨통을 죄지는 않는지~~^^;