Business is Business

바가지의 정석?

Service Business 라는 개념을 ‘대한민국’에 거주하고 계시는 많은 분들은 망각(?)하고 있는 듯 합니다.

친한 (컴퓨터 잘하는)친구들에게 밥한끼에 컴퓨터 좀 고쳐줘 하는 것과 ‘서비스 업체’를 불러서 ‘서비스’를 받는 것은 ‘전혀 다른 가치척도’에서 생각해야 할 문제 아닌가 합니다.

학교 전산실 아무도 사용하지 않는 컴퓨터에 담당자의 허락을 받고 가지고 놀 요량으로 Linux 설치하여 여기저기 계정주고 이것저것 프로그램 깔고 노는 것과 Data Center나 전산실에서 실 서비스에 사용될 목적으로 Linux를 설치하는 것을 동일시 여기는 것과 같습니다.

행위는 똑같습니다. 그냥 CD넣고 아는 지식의 범위내에서 OS 설치하고 프로그램 설치하고 네트워크 연결하고 하면 되는 것이지요. 어느정도 경지에 이르신 분들에겐 XP 다시 설치하는 것 처럼 큰 일 아닐겁니다.(아니 요즘은 더 쉽겠군요..)

Privacy is Privacy, Business is Business 입니다.

좀 더 다른 이야기로, 과외 활동으로 이력서나 지소서등 처음 사회 활동을 시작하시는 분들에게 컨설팅(이라 쓰고 잔소리라 읽습니다.)을 해드리고 있습니다. 그냥 남들 다 아는것 이력서에만 목메어서 잘 안보일 때 옆에서 한 두마디 해주는 수준입니다만, 그저 옆에서 훈수두는 수준이고 최종적인 책임은 스스로에게 귀속된다는 것을 ‘명시’해두고 컨설팅(이라 쓰고 잔소리라 읽는..)을 시작합니다. 물론 ‘아직까지는 무상’으로 서비스 되고 있습니다.

주변에 유학을 준비하시는 분들, 그리고 유학가신 분들 덕분에 몇개 알게된 ‘영어 교육 서비스’가 있습니다. ‘첨삭 서비스’라고 하는 것인데요. ‘특정 레벨에 맞게’ 영어로 에세이를 올리면 ‘영어에 능숙한(주로 원어민) 첨삭사’들이 에세이를 흩어보고 ‘이런 부분은 이렇게 하는 것이 좋다’는 형태의 첨삭을 해주는 서비스입니다. 영어+유학 시장의 규모로 인하여 꽤 큰 ‘시장’을 형성하고 있더군요.

과연 그 ‘첨삭 서비스’와 제가 해주는 ‘이력서 컨설팅’에는 어떤 차이가 있을까요? 만약 제가 ‘이력서 컨설팅’을 유료로 한다면 여러분은 서비스 받아 보시겠습니까?

혹, 우리는 서비스에 대한 비용 지불에 너무 인색한 건 아닌지요?(저부터도 반성해야 하겠지만..)

Posted in computer, think at September 14th, 2009. 1 Comment.

내가 사용하는 Freeware Desktop Application

작은아이님의 글을 보고 비켜 이 떡밥은 내꺼야~ 라는 심정으로 트랙백을 달아 봅니다.

사실 평소에 쓰던 Freeware들에 대한 링크 정리 겸 작성해 봅니다.

1. OpenOffice

MS Office 많이들 쓰시죠?.. 얼마나 제대로 쓰고 계신가요? 제가 아직 복잡한 구조의 Excel File이나 Powerpoint File을 접해보지 못해서인지 충분한 듯 합니다. 특히나 PDF Export 기능은..그냥 예술이죠. 외부에 보내야 하는 문서의 상당수를 OpenOffice로 보내고 있습니다. MS형태로 Export해서 보내는 것도 현재까진 문제없었습니다…(차라리 MS쪽의 2003/2007 버젼 사이의 Gap이 더 커보입니다.) 문제 생길때 까지 계속 사용할 예정입니다.

2. PicPick

저는 그림판/캡쳐 대용으로 사용하는 픽픽~ 입니다. 개발업무 도중이나 분석작업 도중 화면을 그대로 캡쳐해서 간단하게 몇가지 표시만 해서 보내줘야 할 경우가 “매우 빈번하게” 있습니다. 그런 용도에 딱! 인 바로 그 프로그램! 입니다.

3. Filezilla

두 말 하 면 입 아 프 죠. 이 프로그램의 치명적인 단점은 업데이트가 지나치게 자주된다?

4. foobar2000

예전에는 저 사양의 pc에서도 잘 돌아간다는 이유로 사용했고, ogg가 유행일때 가장 먼저(경량급 player중에) 지원해주기도 했고 관련된 me2day plugin도 쓰기도 하고..열심히 사용하는 Player!

5. 7-zip

이거야 말로 Freeware 계의 압축툴의 거성… 설명이 필요없죠~

6. putty

저는 ssh로 하는 Shell 작업이 제가 하는 작업의 절반 가까이를 차지합니다. 그리고 그 대부분의 작업을 putty와 함께..합니다. 뭐..그냥 당연한 생활?..

7. gVim

vi의 확장(?)판 vim의 Win32용 gVim 입니다.(사실 그냥 GUI가 붙어 gVim) vi계열 중 가장 많이 쓰이기도 하고..(거의 대명사화 되었다고 생각합니다.) 저는 Emacs보다 vi를 더 익숙하게 쓰기도 하고 하여..어찌저찌 계속 쓰고 있습니다. Win32 운영체제에서도 예상외로 여러가지로 배려(?)되어 있어서..(대형 파일을 Open한다던지, 인코딩 문제라던지) 잘 사용하고 있습니다.

자 우리 모두 우간다의 아이들을 도와주세요!

8. Launchy

vi를 사랑하는 제 취향상 키보드 프렌들리한 프로그램들을 매우 사랑하는데요..(픽픽, vim 등..) 런쳐로써 가춰야 할 것들은 다 갖춘 프로그램입니다. 키보드 프렌들리한 프로그램들을 쓰는 사람들은 대게..가 몸에 익은 프로그램이 있으면 거기에서 헤어나오지 못하는 습성이 있는 것 같습니다.(저만 그런가요..) 아 그러니까 결론은.. 일단 한번 써보시라니깐요..;;

Freemind를 Launchy로 실행~

Freemind를 Launchy로 실행~

9. FreeMind

MindMap Tool 입니다. 뭐 정말 저도 제대로 Mind Map을 사용하는건 아니고 업무 우선순위, 여러 업무들에 대해서 이런 저런 것들을 좀 정리하거나 할 때 사용합니다. 머리속에 있는 아아아아아악~ 복잡해~ 꼬였어~ 하는 것들을 생각보다 쉽게 풀어내 줍니다.

그런식으로 정리하다보면 별것 아닌 일도 정리하고 보니 엄청 큰 일이 되기도 하고, 엄두도 내지 못하던 일에 대해 대략 윤곽을 잡을 수 있기도 합니다.(아 이건 FreeMind 광고가 아니라 Mind Map 활용법..인가요?)

여튼 좋은 경험(이건 프로그램에 대한 경험이 아닌가..)을 하고 즐겁게 사용하고 있습니다.

사업 분야 고민 중

사업 분야 고민 중

10. Dia

단순한 드로잉 도구였는데.. 실제로 여러가지 Concept Diagram 을 그리거나 ERD를 그려야 할 때(사실 Dia로 ERD 그리는건 절대 추천하지 않습니다..) 구조적인 것들을 누군가에게 설명하고자 할 때 많은 도움을 받았습니다.

11. Comodo

백신 + 방화벽 이지만 백신기능은 거의 사용하지 않고 방화벽 기능을 Main으로 사용하고 있습니다. 참 귀찮지만..(특히 인터넷 뱅킹이나 ActiveX 녀석들..) 한번 교육시키면…참 잘 관리해줍니다.(아참 엄청 무겁기도 합니다..) 업데이트가 꾸준해서 귀찮은 단점(?)이 있네요.

12. HydraIRC

mIRC 많이들 사용하시는데 전 그냥 귀찮아서(?) HydraIRC 사용합니다. IRC 프로그램이라 딱히 더 대단하거나 한건 없고 UI나 이런게 전체적인 상황을 모니터링(????)하는데 mIRC보다 편합니다. 특히 채팅중에 뿌려지는 많은 링크들에 대해 별도로 창을 보여줘서 무척이나 좋아하고 있습니다.

13. Infra Recoder

가급적이면 오픈소스, 단순한 UI, 그리고 가벼워 보이는 프로그램을 좋아합니다…(그 프로그램들이 실제로 가벼운지는..) 제가 Hard하거나 Heavy하게 CD나 DVD를 구워본 적이 없어서..(이미지 Sample CD나 Debian Boot CD나 좀 구웠지..) Hardcore한 평가는 힘들겠네요.

14. Firefox

음..다 아시죠?(구글과 함께 생활의 중심?..)

자자..여러 분들도 좋은 프로그램 정보 같이 공유해 보아요~

Posted in computer at July 10th, 2009. 3 Comments.

중국집 비유

짜장면과 개발자 란 글의 트랙백입니다.

마침 어제 점심(잠들기 전이니..)이 중국집이여서.. 생각나더군요.

사용자 입장에서 한번 풀어보겠습니다.

일단 오늘 점심은 중국집!! 으로 결정. 점심 시간이 되어 근처에 잘한다는 중국집에 룰루랄라 가서 자리를 잡습니다.

중국요리가 어떤건지는 알고 있습니다. 국민 요리 자장면도 있고 사천 요리는 맵고, 삼선이란 단어가 들어 있으면 해물이 많이 들어 있겠죠. 그러다가 요즘 개발 되었다는 짬짜면, 탕볶밥.. 너무도 다양한 메뉴에 눈이 휘둥글해집니다.

결국 이런 저런 메뉴를 고르다가 번뇌에 빠집니다. 번뇌에 빠지는 순간… ‘중국 요리는 느끼하던데..’ , ‘몇인분 이상 시키면 군만두도 서비스로 준다던데…’ 등의 생각에 다다르게 되고 처음에 ‘룰루랄라’하는 마음은 온데간데 없습니다.

그러다가 결국 아무 요리나 시킵니다. 그리고 먹으면서.. ‘나 이런거 원한게 아니였는데…’ 라며 후회합니다.

IT도 마찬가집니다. 사용자는 홈페이지가 필요하다, ERP가 필요하다, CRM이 뭐다.. 무슨 솔루션인가가 필요하다더라 라는 것을 잘 알고 기꺼운 마음으로 업체에 컨택하고 프로젝트를 진행하게 됩니다. 프로젝트를 진행하다 보면.. ‘이게 아닌데..’하는 생각들로 가득차게 되고 먼가 물어 보면 알기 쉽게 대답이 나오지도 않습니다.(사용자 입장에선 다형성이나, 라조육과 라조기의 차이나 머리에 안들어오긴 마찬가집니다..)

요리는 상도의(?)상 뒤집지 못하지만, 이물질(아~~주 심각한 버그?)이 나오거나 하면 강하게 클레임을 걸 수 있습니다. IT의 경우 그 이물질의 기준이 사용자에게 있기 때문에..(OTL) 원활한 진행이 더 어려워 지기도 합니다.

결국 어떻게든 만들어지지만 갑(사용자,고객)이나 을(회사,개발자)이나 모두 만족스럽지 못합니다. 차라리 홍x반점 04xx 처럼 ‘짬뽕’만을 전문으로 하던지(우린 이거만 해요~), 노다메 칸타빌레의 중국집 ‘우라켄’ 처럼 ‘클럽 하우스 샌드위치와 에스프레소’라도 주문하면 만들어 줄 정도의 준비(…)가 되어 있어야 서로 만족스러운(?) 결과를 낼 수 있습니다.

물론 현재는 IT산업 자체는 세계적으로 안정화 되어 가고 있습니다만.. 국내에서의 이 산업 자체가 더 성숙하기 위해선 이런 일들에 대해서 커뮤니케이션하는 프로토콜들이 정해질 필요가 있습니다.(사회/문화적 합의를 통하는게 제일 무난하겠죠) ‘을’의 입장에서는 갑측에서 깔끔하게 ‘클럽 하우스 샌드위치와 에스프레소’라고 주문해주고, 우린 그게 힘들겠다. 다른 곳을 찾아보시지요~ 라고 하는 편이 속 편할 수도 있고, ‘갑’의 입장에서는 홍x반점 처럼 ‘우린 이 분야에선 확실해요.’라고 하는 곳을 쉽게 찾을 수 있도록 ‘뭘 먹고 싶은지 제대로 정하는 일’이 선행되어야 하지 않을까?

이러나 저러나 아직 우리의 인식수준은… 포병이나 상근이나 해병대나 특전사나 모두 같은 군인이듯이.. 당신이 서버 관리자건 HTML 코더건 C 프로그래머건 웹 프로그래머건… ‘IT회사에서 근무하는 컴퓨터 잘 하는 사람’(좀 심하게는 오덕후?)일 뿐 입니다. IT 산업 전반이 성숙해져서.. 프로그래밍 언어나 연차로 구분 되지 말고 의사들 처럼 전문분야로 구분되어질 때 즈음 되면 자연스레 줄어들 것만 같습니다~

횡설수설 했습니다. 긴 글 읽어주셔서 감사합니다.

2줄 요약.

1. 중국집 자주 가지 말자(응?..)

2. 대세는 클럽 샌드위치와  에스프레소(응??….)

Posted in computer, think at June 25th, 2009. No Comments.

수박 겉핥기식 학습을 살리자…

Hani님의 일과 학습 에서 트랙백 합니다.

1. 수박 겉핥기 식 학습 마인드를 가진 스스로에 대한 반성

수박 겉핥기 식 학습마인드는 말하자면 “단기적인 성과와 장기적인 발전의 Trade Off” 입니다. 급하게 수정해야 할 부분을 고치고나니 알수 없는 문제가 터졌다. 그렇게되면 정말 그로기 상태. 어떻게 해야 할지 모르는 것입니다. 그런 요구사항을 맞추는데 급급했을 뿐이고 눈에 보이는 진도에만 메달렸지 실제 뒷단(설계적인 부분이나 경험적인 부분이 적용되어야 하는 부분에 있어)에 문제점들에 대해서는 생각하지 않습니다.(당장 눈에 돌아가는 것 처럼만 보이면 되니까요..)

그렇게 운영되다가 몇 개월 혹은 몇 달뒤에 문제가 뻥~ 터지면 악의 축이신 해결사(^^)분들을 모셔서 비싼 댓가(돈의 문제뿐 아니라 시간 및 여러가지..)를 치르고 문제를 해결합니다.

물론 한국 사회의 구조적 병폐(?)로 인하여 깊이 있는 학습(혹은 자기계발) 자체가 힘든 경우도 많고 이를 토로하시는 분들을 주변에 많이 계십니다. 학교로 돌아가서 공부에도 매진해보시고 여러 교육과정을 찾아듣기는 하지만 어느 것 하나  충족시켜 딱 이것이다 하고 맘에 드는 것은 없다고들 하십니다. 그렇게 몇년을 시름시름 앓고(?) 계시다가  이런저런 나쁜 일로 일에 대한 열정을 잃고 다른 일로 떠나시는 분들의 이야기도 들어보았습니다.

그렇다고 그런 학습법이 무조건 나쁘다고만은 할 수 없습니다.

2. 수박 겉핥기 식의 학습을 긍정적으로 이용해보자.

서론이 길었습니다. 오늘의 진정한 주제가 되겠습니다. 이런 문제가 많은 수박 겉핥기 식의 학습을 어떻게 긍정적으로 이용해 볼 수 있을까요? Hani님의 글을 인용해 봅니다.

수박 겉핥기 식 학습 마인드로 수행했던 프로젝트 몇 건에서 제가 얻은 건 무엇일까요? 하나는 ‘일 잘한다는 칭찬’과 ‘속이 빈 중국호떡을 먹은 뒤 생기는 공복감 비슷한 지적인 배고픔’이었습니다.

수박 겉핥기 식 학습으로 생긴 저 ‘공복감’이야 말로 우리가 잊지말아야 할 부분 아닌가 합니다. 수박 겉핥기 식 학습으로 새로운 분야를 Start up 했고 경험도 쌓았습니다. 그 분야에 대해서 체계적으로 제대로 공부할 기회(!!)를 얻은 건 아닐까요?

요즘 회사의 Was를 Resin 최신버젼(회사의 기존것이 너무 구버젼 이였습니다.)으로 교체중이였습니다. 예전에 한번 만져본 경험(만 있습니다..)이 있는 녀석이라 최신버젼에 테스트로 당장 눈에 보이게끔 회사 서비스를 올리는 것에는 아무 문제가 없었습니다. 하지만 실제 서비스 가능한 녀석은 아니라 내부적인 구조와 자세한 세팅(SSL부터 Session등등..)은 또 몇일 끙끙거리며 작업을 해야 했습니다. 아마 다음번에 다른 서비스에 Resin을 이용하라고 하면 자신있게 할 수 있을 겁니다.

처음에는 그냥 설정만 조금 만져본 Resin에 대한 경험(수박 겉핥기식 학습)을 지속적인 학습으로 승화(??)되면 Resin이라는 WAS의 전문가가 아니더라도 회사 서비스의 WAS 변경 정도는 할 수 있게 되었습니다.(이건 그냥 하나의 예를 든 것입니다…)

3. 결론적으로…

수박 겉핥기 학습하는 것은 배움의 기회를 만들어 내는 것이고 여기서 만들어진 기회를 노력하여 스스로 학습하도록 이어지면 우리가 해온 수 많은 수박 겉핥기 학습들(어쩐지 찔립니다만..)이 그리 헛 것많은 되지 않을 것 같습니다. 물론 이를 위한 적지 않은 노력이 필요하겠지만 말이죠.

한 줄 요약 : 열심히 공부하자. 예습이 안되면 복습이라도 잘하자.

Posted in computer, think at May 18th, 2009. 1 Comment.

개발팀만 매일 회의하는 회사.

겸손한 개발자가 만든 거만한 소프트웨어

겸손한 개발자가 만든 거만한 소프트웨어

‘개발업무’이외에도 업무와 관련된 커뮤니케이션 자체 대한 절실함이 느껴지는 하루 하루 입니다. 마침 좋은 기회(?)를 맞이하여 현재 칼퇴근의 신화(?)를 창조한 현 개발팀 이야기를 잠깐 해 볼까 합니다.

1. 조직과 조직간의 의사소통

- 회사내에 Feedback을 주는 사람(or 부서)이 거의 없습니다. 일정확인도 거의 없습니다.

- 업무 연락 및 관리 업무를 담당한 분들은 다들 자기 일에 바빠서 개발업무에 신경을 거의 쓰지 않으십니다.

이런 경우 겪어보셨는지요?(저..저도 처음입니다만) 사실 기획 업무를 맡으신 분과의 원활한 의사 소통이 프로젝트 성공의 상당히 중요한 요소라고 생각하는데 무척 안타까운 점이였습니다.

이런 회사 분위기를 바꿔보기 위해서 개발팀이 나서서 메일을 보내고 일을 진행하고 외부와 연락하는 모든 메일에 참조로 붙이고, 외주업체와의 협업시에는 반드시 기획팀을 통하여 연락을 하도록 건의하여 프로세스를 변경하였습니다. 기획팀은 귀찮아(???) 할 수도 있는 문제지만 예전에 0건이던 FeedBack이나 일정에 대해 물어보는 횟수가 1-2회씩이라도 늘어나고 서로 이야기 할 시간이 조금씩 이라도 늘어나고 있다는 것은 고무적인 일입니다.

아직은 서로가 부족하지만 시간이 지나면 서로간의 업무에 대한 범위, 장기적으로 프로세스에서 진행 방법등을 더 이야기 해 볼 수 있을 것 같습니다.( 다른 곳에서는 기획팀이나 영업/마케팅 하시는 분이 너무 괴롭혀서 힘들어 하시는 분들이 많으시던데… ^^ ) 서로간의 기본적인 상식선에서 이 문제는 해결을 본 것 같습니다.

2. 개발팀 내부의 의사소통 문제

- 버젼 관리/보안/구조화 같은 것은 찾아 볼 수 없는 JSP+Model1 Code 들로 된 사이트가 있습니다.

- 거기에 JSP 코드를 PHP 수준으로 사용하고 있습니다.(으악!)

사실 위에 나열한 기술적인 문제는 팀 내부의 소통의 문제는 아닙니다. 기존 개발팀들이 서서히 해체되고 현재의 팀이 꾸려지는 기나긴(자세한 내용은 생략해도 누구나 알수 있을 법한?) 과정중에 발생한 기술적인 화두들일 뿐입니다. 하지만 팀원(PM까지 전부 합쳐야 단 둘. ^^) 들이 저런 문제에 대하여 서로 다른 생각을 가지고 있다거나, 한사람만 인지하고 다른 사람이 인지하지 못하고 있다면 함께 일 해내가긴 참 힘들 것 같습니다.

다행히 개발자분은 기술적인 지식은 약간 부족하지만 문제 해결 능력이나 실제 업무 처리에 있어서(시간이 좀 걸리는 점 빼고는) 문제 될 점은 없습니다. 하지만 이 상태(1번에 내용을 포함하여..)로만 계속 간다면 회사 전체적인 관점에서 큰 문제다라는 인식을 서로 공유하게 되었습니다. 하여 어찌할까 고민하다. 입사 초에 개발자분과 이런저런 대화 나누던 중 ‘저는 질질 끄는 회의 말고 짧고 깔끔하게 하는 회의가 너무 좋아요. 뭔가 일하는 것 처럼 보이자나요? 여기선 아무도 그런걸 안하려고 해요.’ 라는 말이 기억이 나서. 그래. 그럼 우리 매일 회의하자!

기술적인 지식도 좀 쌓고, 원활한 의사소통을 위하여 매일 10-30분 정도 회의를 가집니다. 추후 일정, 오늘의 남은 업무,현재 작업의 진행사항이나 문제점, 개발과 관련된 전반적인 지식이나 새로운 기술들에 대한 것들로 회의를 가집니다. 회사 회의실의 화이트보드는 사실상 개발팀이 독점해서 사용할 만큼 빈번히 회의를 합니다. 많게는 6-7번씩 가질 때도 있고 적을 때는 1-2번으로 끝나는 날도 있습니다.

회의에서 주로 거론되는 내용이라고 해봐야 ‘오늘 뭐했나?’, ‘지금 어디까지 진행되었나?’, ‘이제 해야 할 것은 무엇인가?’, ‘이런이런식으로 문제를 해결하려는데 어떠냐?’, ‘이런이런거 있는데 한번 해볼까?’, ‘오늘 야근 할껀가?’, ‘점심(or 저녁)은 뭘 먹을 것인가?’, ‘아 우리회사 누구누구~’, ‘아 어제 어디 갔었는데 정말 좋더라’, ‘다음에 뽑을 개발자는 꼭 여직원으로!!’ 같은 것들뿐이지만 이 회의에는 독서와 경험에서 나온 몇가지 나름의 원칙이 있습니다.

- 형식을 갖춘 브리핑/보고서 같은건 일절 하지 않고 가볍고 편안한 분위기로 칠판에 쓱쓱~ 쉽게 그리고 간단하게만 메모하고 특별한 이슈가 발생하면 그때그때 보고하고 처리합니다.(귀찮으면 핸드폰 카메라로 찍어서 대충 메모 할 때도 있습니다..)

- 아무리 뛰어난 개발자라도 놓치는 부분이 있을 수 있습니다. 한 사람보다는 두 사람의 생각이 (대체로) 더 뛰어나다는 확신을 가져야 합니다.

- 아무리 바보같은 생각이나 이야기라도 서로 이야기 할 수 있어야 합니다. 그렇지 않으면 서로 배워나가기 힘듭니다.

- 회의시간은 절대 30분을 넘지 않아야 합니다.(넘을 것 같으면 잠시 쉬었다가 다른 일을 하다 다시 모입니다.)

사실 위의 몇가지 원칙은 코끼리를 춤추게 하라, 맥킨지는 일하는 방식이 다르다. 등의 책을 참고하여 나름 정한 원칙입니다. 지금까지는 아주 효과적이고 또 효율적으로 진행되고 있습니다.(서로 충분히 만족할 만한 성과를 보이고 있다는 의미입니다.) 일정보고도 꼬박꼬박 메일을 통해 공유되고 일이 터지면 스스로 야근(?)하는 개발팀인지라 타 부서에서의 압박이 거의 없긴 합니다.(사실 아무도 관심이 없는 걸지도 모릅니다.)

이제 회의 하는 문화(?)는 확실히 자리 잡았습니다. 여기에 버젼관리와 Wiki/BBS류의 도구를 도입하여 문서화만 적절하게 하면 개발팀 안에서의 의사소통(+정보 공유)에는 큰 문제가 없을 것 같습니다.(이건 순전히 제 생각일뿐..)

이제  1번의 문제가 점진적으로 해결되면 칼퇴근의 신화도 옛 말이 될 수도 있습니다. 새로운 개발팀원이 합류하면(부디 회사가 커져서 내년에는 여자 개발자분을 당당(?)하게 뽑을 수 있기를!!) 또 다른 방법의 의사소통을 고민해야 될 수도 있습니다. 그러나 입사초기에 급작스럽게 떨어진 사이트 런칭, 사이트 및 업무 파악, 새로운 체계 정립 등 짧은 시간에 많은 일들을 ‘함께’ 처리하고 개발팀이 자리잡는데 있어서 가장 큰 원동력개발팀 내부의 원할한 의사소통 이 아니였을까요?

ps. 두서없이 긴 글 읽어주셔서 감사합니다.

ps2. 사실상 의사소통이 없어서 정체되어 있던 곳에 와서 이렇게 우리는 의사소통 하자 라고 정한 것이기 때문에 주제에 맞는지는 모르겠지만 의사소통과 관련된 이야기는 한번 해보고 싶어서 이렇게 트랙백을 남깁니다.

Posted in computer, think at April 23rd, 2009. 5 Comments.