[링크 : http://bbs3.agora.media.daum.net/gaia/do/story/read?bbsId=K161&articleId=100567]
일단 위에 링크를 살포시 누질러 주세요
개발자에게 프로의식이 없다라..
어쩌면 내가 정말 개띠에 개발로 개발을 하기 때문에 울컥하는건지는 모르겠지만..
개발자에게 프로의식이 없다면 대한민국이 이렇게 돌아 갈까? 라는 생각이 든다.
(여기서 개발자는 프로그래머 외에 모든 어떠한 것들을 만드는 사람을 의미함)
물론 반박의 여지는 있지만 과연.. 이쪽에서 일하는 사람이 아니라면 알아주거나 알수나 있을까..
기술영업은 개발자에서 영업으로 전환하는 사람들이 많이 한다고 하는데, 이런걸 떠나서
포장하는것도 기술이라고 하지만, 이러한 걸로 이빨까서 돈버는 사람들이 직접 노가다 해서 만드는 사람보다
돈을 더 버는건 참.. 웃기기 까지 하다.
어쩌면 21세기의 이름만 바뀌어진 노예제도가 아닐까..
모든 회사가 그런건 아니겠지만, 대부분의 회사는
기능 추가나 변경, 버그 수정에 별도의 개발 시간이 존재하지 않는다.
상당히 주먹구구식으로 진행되는 기획과
문서화되지 않고 그냥 말로만 넘어 오는 개발 지령들
좋게 잘하면 빠르게 적용이 되는 중소기업의 장점일수도 있지만,
결국에 뒷통수 맞는건 개발자가 된다는 문제가 있다.
개발자 : 아니 전에 이렇게 수정하라고 하셨는데요?
상 관 : 아니 내가 언제 그랬어? 그럼 다시 원래 대로 해놔
개발자 : ... (아놔 ㅆㅂ) 네
물론 CVS/SVN 등의 버전 관리 시스템과
최대한 모듈화 하면, 이전 버전으로 돌리거나 기능 변경에 따른 버그, 충돌이 없지만
문제는 앞에서 말했듯, 기능 요구명세가 없는관계로 개발자가 알아서 모듈화 하고 설계하고
그런 뒷통수를 예방하기 위해 각종 장치들을 동원해야 한다.
(물론 이러한 시스템을 도입하기도 쉽지만은 않다. 높은 자리에서는 익숙해진것에서 벗어나려 하지 않기 때문에..
게다가 최악의 경우 제안자가 직접 시스템을 구축하고 제대로 안될경우 모든 욕을 다 들어 먹어야 한다.
잘되면 다행 안되면 욕 바가지로 먹는 위험을 감수해야만 한다.)
하.지.만 가장 치명적인 것은 바로
이러한 수정에 필요한 시간은 고려되지 않는 다는 점이다.
단지 수정이 아니라, 새로운 업무로 작업 스케쥴에 추가될 뿐이다.
결국 이런 이유로 남에꺼에는 이런 기능이 있고 동일 칩셋인데 우리꺼는 안돼? 라고 하면
안되요~ 라고 하면서 디펜스를 할 수 밖에 없다.
왜냐고?
상 관 : oo씨 전부터 만들고 있던 oo기능은 아직도 안됐어? 몇일 남았네(혹은 몇일 초과됐네)
개발자 : (어우 미네랄 니가 고치라고 한 기능 최우선으로 하라면서 ㄱ-) 이거빨리 하고 그거 마무리 지을께요
상 관 : 어우 제 시간에 하지도 못하면서 무슨 개발자라고 ㅉㅉㅉ
개발자 : ... (어우 저 십센치 머리에다가 cpu하나 박어 버릴까?)
그리고 어떠한 아이디어를 말했을때 조금은 고려해보고 말을 해주었음 좋겠다
개발자 : 이런이런 기능은 사용이 불편해서 이렇게 변경하면 좋을꺼 같은데요?
상 관 : 개발이나 하지 그런거 신경쓰지 말고 하던거나 해. 너가 이쪽 트렌드를 몰라서 그래
개발자 : 네...
(시간이 흘러)
상 관 : oo 기능 이렇게 개선해줘
개발자 : 이거 전에 말씀드렸던건데요?
상 관 : 하라면 하지 언제 그런 말을 했었다고 그래?
개발자 : ... 네 (아놔 ㅆㅂ 개선하라는게 전에 했던 거랑 똑같구만)
그리고 버그가 우려되는 것에 대해서는 조금은 더 신경써주면 좋겠다.
개발자 : 이건 아직 테스트가 제대로 되지 않아 출시할 품목에 넣기는 불안합니다.
상 관 : 일단 내놓고 수정하면돼. 그냥 넣어
개발자 : 네
(시간이 흘러)
상 관 : 아니 이거 왜 오작동해? 제대로 만들란 말이야, 신기능 넣는다고 버그 만들지 말구
개발자 : 전에 테스트 못해서 버그 우려 있다고 반대했었는데요..
상 관 : 언제 그랬어! oo까지 고쳐놔!
영업/사장 님들 제발 부탁합니다.
기능추가? 좋습니다. 단지 다른 업무 보다 우선시 한다면 다른 작업이 밀린다는 것을 명심하십시오.
기능수정? 좋습니다. 물론 기능추가와 마찬가지로 단지 다른 업무 보다 우선시 한다면
다른 작업이 밀린다는 것을 명심하십시오.
하지만 수정이 이루어 지지 않도록 초기에 이기능은 이러한 이유로 이렇게 하는게 좋았을 것이라고 초기 기획시에
말씀 드렸다는 사실은 잊지 말아 주시기 바랍니다. 그때는 경력 안된다는 이유로 너가 몰라서 그런 말을 하는거고~
라고 하면서 제말 듣지도 않으셨죠?
야근/추가근무? 좋습니다. 하지만 월급은 제대로 좀 챙겨주세요. 기본야근, 기본 추가근무 싫습니다.
그리고 제발 높으신분들 집에서 애보기 싫어서 회사에서 노시면서 아랫것들은 빠져서 일찍 퇴근한다
라는 말로 구박하지 마십시오. 그런 이유로 회사에 계신거라면 손에 잡히지도 않는 일로 모니터만 보다가
늦게 퇴근하게 되면서 생기는 홧병이 더 치명적입니다.
PC수리? 좋습니다. 하지만 이것 역시 시간이 드는 것이고, 개발자라면 개발시간에 제외하는 것으로 생각좀 해주십시오.
그게 싫다면, 제발 PC AS기사를 따로 두던가, 유료로 받으시던가 하십시오. 개발자라고 모두 PC를 신급으로
다룰 줄 알고, 남들 1시간 걸릴꺼 10초 만에 포맷하는 기술의 소유자가 아닙니다. 그렇다고 해서 월급을 더 주는 것도
아니지 않습니까? 고쳐주고 나서 그게 끝이 아닌것도 알기에 안해주려는 것입니다. 손봐주고 나서는 네버엔딩으로
oo씨 ~가 안돼, ~좀 고쳐줘. 시간 얼마나 걸린다고 언넝와서 고쳐주고 가서 일해.
이런 말은 하지 말아주시기 바랍니다. 아니 하실려면 AS 비용을 따로 챙겨 주십시오.
-------------
리플이 달렸길래 봤더니
"개발자들이 무시당하고 야근하는건 능력탓입니다. 이 사회구조의 모순을 개발자만 비켜나가고 싶다? 말이 안되는 논리죠. 개발자들 대접받고 싶으면 권리와 요구를 말로 표현하는 기술도 늘려야되고, 프로그램실력은 기본으로 뛰어나야됩니다. 하지만 둘다 안되면서 개나소나 프리랜서라고 ㅋㅋ 돈 마니주면 하던거 내팽게치고 책임감없이 옮기는 개발자가 한둘이냐고. 쓰다보니 짱나네 경력속이고, 학력속이고 들어왓는데 실력은 못속이겟으니 대충 시간때우다가 수당받아처먹고 다른데 가는 한심한 it직군"
라고 해주셨다.
본문에서는 개발자에게 영업마인드가 있으면 좋겠다라..
개발자들에게 영업마인드가 있고 영업잘하면 영업따위 필요없이 개발자가 영업 직접 다 하면 된다.
영업팀이란거 자체가 존재할 필요가 없어진다.
그런데, 개발자가 개발 안하고 영업을 뛰면 또 좋은 소리가 들려올까?
영업팀에서 자기네 할일이 줄어서 좋겠네~ 가 아니라
개발도 해야 하고 영업도 해야하고, 개발자는 무슨 슈퍼맨이 아니다.
그러면 물론 영업에서 한소리 하겠지
"술먹는거 밤새 비위맞춰주는거 얼마나 힘든데!"
너네 술먹고 밤새 이빨까면서 남 비위맞춰주는거 쉽지 않은거 안다.
그러니까 아무소리 안하고 니네 개소리 하는거 다 맞춰주면서 우리 야근하면서 개발하잖냐
근데 능력탓과 회화기술에 프로그램은 기본이라..
그렇게 프로그램이 기본이라고 생각이 되면, 영업니네가 이빨만 까지 말고 직접 프로그램으로 뛰어들지
아니 알바만도 못한 개발자라고 하면서 영업이 직접 개발할 생각은 왜 안하는거냐?
그리고 말하고 포장하는것도 능력이라지만, 개발자에게는 그것외에 프로그래밍 능력까지 요구하잖아
요구사항들만 왜케 많은건데?
그리고 개발자에게는 개발 마인드가 있어야지 영업마인드 있는 개발자?
이빨만 조낸 까고, 윗사람 비위맞춰주고 이것저것 저질러는 놓고 다른 개발자에게 떠밀고 안되면
도망치듯 사라지는 그런 마인드의 개발자라면 오노~ 그런 사람과는 같이 일하기도 싫고 그 사람아래는 더더욱 싫고
다시는 보고 싶지 않을 뿐이다.
개발자에게 있어서 영업마인드는
술퍼마시고,
강한사람에게 꼬리를 내리고 배를 드러내고 복종을 하고,
알지도 못하면서 어디서 주워들은것만 잔뜩이라 실제로 가능한지도 모르면서 가능하다고 우기면서 이빨까고,
돈 많이 쓰고 접대하면서 개발팀에서 원하는 장비는 비싸다고 딴지만 거는
실질적인 일은 하나도 하지 않고 그럴싸하게 한것처럼 포장하는 것으로 밖에 보이지 않는다.
욱해서 쓰게 되었지만, 개발자(다르게 말하면 기술자)들은 자신의 일에대한 자존심이 세고
자기가 항상 최고다라는 생각에 가득차있다. 하지만 그렇다고 해서 영업이 항상 자존심을 꺽고(혹은 버리고)
살아야 한다고 생각하지 않는다. 개발자에게 있어 이러한 영업의 푸념은, 밖에서 조낸 기고 왔으니까 안에서라도 좀
왕처럼 살고 싶다는 모습으로 보이고, 힘든거 아니까 안에서는 좀 쉬게 놔두고 싶다.
그리고 영업과 개발은 엄연히 업무가 다르고, 답답하다고 해서 서로 그럼 니가 하던가! 라고
'다름'을 무시하고 할 수 있는 직군도 아니다.
단지 개발이 바라는건 영업이 바이어의 요구를 듣고 와서는, 바이어의 전령으로 자기가 마치 왕이 된것 처럼
행세를 하지 않기를 바랄 뿐이고, 개발쪽의 요구사항도 들어 달라는 것이다.
모든 일에는 기회비용이 있고 하나를 선택하기에는 다른 하나를 포기해야 하는 상황이 생긴다.
A를 원한다면 B를 포기해야 하는 상황이 생기는 것이고
개발 역시 하나를 위해서는 다른 하나를 포기 해야하는 상황이 생기게 된다.
그게 아니라면?
결국에 개발자의 야근으로 '시간을 선택'하고, '개인의 시간은 사라지고 초과수당도 없이 혹사'를 당하는 것 뿐이다.
(결국 개발자에게 득이 되는 것은 하나도 없다)
영업에서는 이렇게 말하고 싶겠지
"우리는 항상근무야. 퇴근해서도 만나서 술마셔야 하고 얼마나 힘든데"
개발자 눈에는 이렇게 밖에 안보인다.
"맨날 술만 퍼마시고 놀고 회사돈으로 술도 마시는데 머가 힘들어. 그러면서 우리 사용할 장비 사는건 왜 돈이 아깝대?
우리는 니네 그렇게 마시는 술값이 더 아까워!"
어쩌면 가장 이상적인것은, 서로 한발 물러서서 절충을 하면서 서로 윈-윈 해야 하는 것인데
어째.. 출산과 군대로 대표되는 소모전의 양상을 띄는것 같다.
가장 근본적인 해결책은,
서로의 다름을 인정하고 자기 분야에서 최선을 다하면 되고
다른 직종도 잘 알지는 못하더라도 최대한 이해를 하려고 노력하고,
서로의 말에 귀를 기울이는 것이 되지 않을까 싶지만..
화타가 말했듯이, 아프기 전에 고치려 하면 흘려 듣고 대수술을 해야지 위대하다고 생각하기에
결국에는 근원으로 돌아가지 못하고 끝까지 싸울수 밖에 없는 화두가 아닐까..
일단 위에 링크를 살포시 누질러 주세요
개발자에게 프로의식이 없다라..
어쩌면 내가 정말 개띠에 개발로 개발을 하기 때문에 울컥하는건지는 모르겠지만..
개발자에게 프로의식이 없다면 대한민국이 이렇게 돌아 갈까? 라는 생각이 든다.
(여기서 개발자는 프로그래머 외에 모든 어떠한 것들을 만드는 사람을 의미함)
물론 반박의 여지는 있지만 과연.. 이쪽에서 일하는 사람이 아니라면 알아주거나 알수나 있을까..
기술영업은 개발자에서 영업으로 전환하는 사람들이 많이 한다고 하는데, 이런걸 떠나서
포장하는것도 기술이라고 하지만, 이러한 걸로 이빨까서 돈버는 사람들이 직접 노가다 해서 만드는 사람보다
돈을 더 버는건 참.. 웃기기 까지 하다.
어쩌면 21세기의 이름만 바뀌어진 노예제도가 아닐까..
모든 회사가 그런건 아니겠지만, 대부분의 회사는
기능 추가나 변경, 버그 수정에 별도의 개발 시간이 존재하지 않는다.
상당히 주먹구구식으로 진행되는 기획과
문서화되지 않고 그냥 말로만 넘어 오는 개발 지령들
좋게 잘하면 빠르게 적용이 되는 중소기업의 장점일수도 있지만,
결국에 뒷통수 맞는건 개발자가 된다는 문제가 있다.
개발자 : 아니 전에 이렇게 수정하라고 하셨는데요?
상 관 : 아니 내가 언제 그랬어? 그럼 다시 원래 대로 해놔
개발자 : ... (아놔 ㅆㅂ) 네
물론 CVS/SVN 등의 버전 관리 시스템과
최대한 모듈화 하면, 이전 버전으로 돌리거나 기능 변경에 따른 버그, 충돌이 없지만
문제는 앞에서 말했듯, 기능 요구명세가 없는관계로 개발자가 알아서 모듈화 하고 설계하고
그런 뒷통수를 예방하기 위해 각종 장치들을 동원해야 한다.
(물론 이러한 시스템을 도입하기도 쉽지만은 않다. 높은 자리에서는 익숙해진것에서 벗어나려 하지 않기 때문에..
게다가 최악의 경우 제안자가 직접 시스템을 구축하고 제대로 안될경우 모든 욕을 다 들어 먹어야 한다.
잘되면 다행 안되면 욕 바가지로 먹는 위험을 감수해야만 한다.)
하.지.만 가장 치명적인 것은 바로
이러한 수정에 필요한 시간은 고려되지 않는 다는 점이다.
단지 수정이 아니라, 새로운 업무로 작업 스케쥴에 추가될 뿐이다.
결국 이런 이유로 남에꺼에는 이런 기능이 있고 동일 칩셋인데 우리꺼는 안돼? 라고 하면
안되요~ 라고 하면서 디펜스를 할 수 밖에 없다.
왜냐고?
상 관 : oo씨 전부터 만들고 있던 oo기능은 아직도 안됐어? 몇일 남았네(혹은 몇일 초과됐네)
개발자 : (어우 미네랄 니가 고치라고 한 기능 최우선으로 하라면서 ㄱ-) 이거빨리 하고 그거 마무리 지을께요
상 관 : 어우 제 시간에 하지도 못하면서 무슨 개발자라고 ㅉㅉㅉ
개발자 : ... (어우 저 십센치 머리에다가 cpu하나 박어 버릴까?)
그리고 어떠한 아이디어를 말했을때 조금은 고려해보고 말을 해주었음 좋겠다
개발자 : 이런이런 기능은 사용이 불편해서 이렇게 변경하면 좋을꺼 같은데요?
상 관 : 개발이나 하지 그런거 신경쓰지 말고 하던거나 해. 너가 이쪽 트렌드를 몰라서 그래
개발자 : 네...
(시간이 흘러)
상 관 : oo 기능 이렇게 개선해줘
개발자 : 이거 전에 말씀드렸던건데요?
상 관 : 하라면 하지 언제 그런 말을 했었다고 그래?
개발자 : ... 네 (아놔 ㅆㅂ 개선하라는게 전에 했던 거랑 똑같구만)
그리고 버그가 우려되는 것에 대해서는 조금은 더 신경써주면 좋겠다.
개발자 : 이건 아직 테스트가 제대로 되지 않아 출시할 품목에 넣기는 불안합니다.
상 관 : 일단 내놓고 수정하면돼. 그냥 넣어
개발자 : 네
(시간이 흘러)
상 관 : 아니 이거 왜 오작동해? 제대로 만들란 말이야, 신기능 넣는다고 버그 만들지 말구
개발자 : 전에 테스트 못해서 버그 우려 있다고 반대했었는데요..
상 관 : 언제 그랬어! oo까지 고쳐놔!
영업/사장 님들 제발 부탁합니다.
기능추가? 좋습니다. 단지 다른 업무 보다 우선시 한다면 다른 작업이 밀린다는 것을 명심하십시오.
기능수정? 좋습니다. 물론 기능추가와 마찬가지로 단지 다른 업무 보다 우선시 한다면
다른 작업이 밀린다는 것을 명심하십시오.
하지만 수정이 이루어 지지 않도록 초기에 이기능은 이러한 이유로 이렇게 하는게 좋았을 것이라고 초기 기획시에
말씀 드렸다는 사실은 잊지 말아 주시기 바랍니다. 그때는 경력 안된다는 이유로 너가 몰라서 그런 말을 하는거고~
라고 하면서 제말 듣지도 않으셨죠?
야근/추가근무? 좋습니다. 하지만 월급은 제대로 좀 챙겨주세요. 기본야근, 기본 추가근무 싫습니다.
그리고 제발 높으신분들 집에서 애보기 싫어서 회사에서 노시면서 아랫것들은 빠져서 일찍 퇴근한다
라는 말로 구박하지 마십시오. 그런 이유로 회사에 계신거라면 손에 잡히지도 않는 일로 모니터만 보다가
늦게 퇴근하게 되면서 생기는 홧병이 더 치명적입니다.
PC수리? 좋습니다. 하지만 이것 역시 시간이 드는 것이고, 개발자라면 개발시간에 제외하는 것으로 생각좀 해주십시오.
그게 싫다면, 제발 PC AS기사를 따로 두던가, 유료로 받으시던가 하십시오. 개발자라고 모두 PC를 신급으로
다룰 줄 알고, 남들 1시간 걸릴꺼 10초 만에 포맷하는 기술의 소유자가 아닙니다. 그렇다고 해서 월급을 더 주는 것도
아니지 않습니까? 고쳐주고 나서 그게 끝이 아닌것도 알기에 안해주려는 것입니다. 손봐주고 나서는 네버엔딩으로
oo씨 ~가 안돼, ~좀 고쳐줘. 시간 얼마나 걸린다고 언넝와서 고쳐주고 가서 일해.
이런 말은 하지 말아주시기 바랍니다. 아니 하실려면 AS 비용을 따로 챙겨 주십시오.
-------------
리플이 달렸길래 봤더니
"개발자들이 무시당하고 야근하는건 능력탓입니다. 이 사회구조의 모순을 개발자만 비켜나가고 싶다? 말이 안되는 논리죠. 개발자들 대접받고 싶으면 권리와 요구를 말로 표현하는 기술도 늘려야되고, 프로그램실력은 기본으로 뛰어나야됩니다. 하지만 둘다 안되면서 개나소나 프리랜서라고 ㅋㅋ 돈 마니주면 하던거 내팽게치고 책임감없이 옮기는 개발자가 한둘이냐고. 쓰다보니 짱나네 경력속이고, 학력속이고 들어왓는데 실력은 못속이겟으니 대충 시간때우다가 수당받아처먹고 다른데 가는 한심한 it직군"
라고 해주셨다.
본문에서는 개발자에게 영업마인드가 있으면 좋겠다라..
개발자들에게 영업마인드가 있고 영업잘하면 영업따위 필요없이 개발자가 영업 직접 다 하면 된다.
영업팀이란거 자체가 존재할 필요가 없어진다.
그런데, 개발자가 개발 안하고 영업을 뛰면 또 좋은 소리가 들려올까?
영업팀에서 자기네 할일이 줄어서 좋겠네~ 가 아니라
개발도 해야 하고 영업도 해야하고, 개발자는 무슨 슈퍼맨이 아니다.
그러면 물론 영업에서 한소리 하겠지
"술먹는거 밤새 비위맞춰주는거 얼마나 힘든데!"
너네 술먹고 밤새 이빨까면서 남 비위맞춰주는거 쉽지 않은거 안다.
그러니까 아무소리 안하고 니네 개소리 하는거 다 맞춰주면서 우리 야근하면서 개발하잖냐
근데 능력탓과 회화기술에 프로그램은 기본이라..
그렇게 프로그램이 기본이라고 생각이 되면, 영업니네가 이빨만 까지 말고 직접 프로그램으로 뛰어들지
아니 알바만도 못한 개발자라고 하면서 영업이 직접 개발할 생각은 왜 안하는거냐?
그리고 말하고 포장하는것도 능력이라지만, 개발자에게는 그것외에 프로그래밍 능력까지 요구하잖아
요구사항들만 왜케 많은건데?
그리고 개발자에게는 개발 마인드가 있어야지 영업마인드 있는 개발자?
이빨만 조낸 까고, 윗사람 비위맞춰주고 이것저것 저질러는 놓고 다른 개발자에게 떠밀고 안되면
도망치듯 사라지는 그런 마인드의 개발자라면 오노~ 그런 사람과는 같이 일하기도 싫고 그 사람아래는 더더욱 싫고
다시는 보고 싶지 않을 뿐이다.
개발자에게 있어서 영업마인드는
술퍼마시고,
강한사람에게 꼬리를 내리고 배를 드러내고 복종을 하고,
알지도 못하면서 어디서 주워들은것만 잔뜩이라 실제로 가능한지도 모르면서 가능하다고 우기면서 이빨까고,
돈 많이 쓰고 접대하면서 개발팀에서 원하는 장비는 비싸다고 딴지만 거는
실질적인 일은 하나도 하지 않고 그럴싸하게 한것처럼 포장하는 것으로 밖에 보이지 않는다.
욱해서 쓰게 되었지만, 개발자(다르게 말하면 기술자)들은 자신의 일에대한 자존심이 세고
자기가 항상 최고다라는 생각에 가득차있다. 하지만 그렇다고 해서 영업이 항상 자존심을 꺽고(혹은 버리고)
살아야 한다고 생각하지 않는다. 개발자에게 있어 이러한 영업의 푸념은, 밖에서 조낸 기고 왔으니까 안에서라도 좀
왕처럼 살고 싶다는 모습으로 보이고, 힘든거 아니까 안에서는 좀 쉬게 놔두고 싶다.
그리고 영업과 개발은 엄연히 업무가 다르고, 답답하다고 해서 서로 그럼 니가 하던가! 라고
'다름'을 무시하고 할 수 있는 직군도 아니다.
단지 개발이 바라는건 영업이 바이어의 요구를 듣고 와서는, 바이어의 전령으로 자기가 마치 왕이 된것 처럼
행세를 하지 않기를 바랄 뿐이고, 개발쪽의 요구사항도 들어 달라는 것이다.
모든 일에는 기회비용이 있고 하나를 선택하기에는 다른 하나를 포기해야 하는 상황이 생긴다.
A를 원한다면 B를 포기해야 하는 상황이 생기는 것이고
개발 역시 하나를 위해서는 다른 하나를 포기 해야하는 상황이 생기게 된다.
그게 아니라면?
결국에 개발자의 야근으로 '시간을 선택'하고, '개인의 시간은 사라지고 초과수당도 없이 혹사'를 당하는 것 뿐이다.
(결국 개발자에게 득이 되는 것은 하나도 없다)
영업에서는 이렇게 말하고 싶겠지
"우리는 항상근무야. 퇴근해서도 만나서 술마셔야 하고 얼마나 힘든데"
개발자 눈에는 이렇게 밖에 안보인다.
"맨날 술만 퍼마시고 놀고 회사돈으로 술도 마시는데 머가 힘들어. 그러면서 우리 사용할 장비 사는건 왜 돈이 아깝대?
우리는 니네 그렇게 마시는 술값이 더 아까워!"
어쩌면 가장 이상적인것은, 서로 한발 물러서서 절충을 하면서 서로 윈-윈 해야 하는 것인데
어째.. 출산과 군대로 대표되는 소모전의 양상을 띄는것 같다.
가장 근본적인 해결책은,
서로의 다름을 인정하고 자기 분야에서 최선을 다하면 되고
다른 직종도 잘 알지는 못하더라도 최대한 이해를 하려고 노력하고,
서로의 말에 귀를 기울이는 것이 되지 않을까 싶지만..
화타가 말했듯이, 아프기 전에 고치려 하면 흘려 듣고 대수술을 해야지 위대하다고 생각하기에
결국에는 근원으로 돌아가지 못하고 끝까지 싸울수 밖에 없는 화두가 아닐까..
'개소리 왈왈 > 직딩의 비애' 카테고리의 다른 글
내가 왜 일하지? (4) | 2009.04.22 |
---|---|
문득 주차장의 흡연자와 눈이 마주쳤습니다 (2) | 2009.04.21 |
관리자 비번을 알려달라니! (4) | 2009.04.10 |
눈이 이상해진게야... OTL (2) | 2009.04.09 |
KT 인증 수 제한조치 관련 상담전화 (2) | 2009.03.30 |