천객만래 [千客萬來] (It has an interminable succession of visitors)
[아이디어 낚시질] 가르치며 배운다  
저자: 정용석 |  날짜: 2005년 02월 24일  

무엇을 익힐 때 그 효과를 배가시키면서 빨리 배우기 위해서는 목적의식이 중요합니다. 그 중에서 가장 강력한 것이 가르침을 목표로 하는 것입니다.

남을 가르친다고 생각해보세요. 소홀히 하거나 대충할 수 없습니다. 가르치는 대상을 생각하게 되고 '어떻게 말할까?, 어떻게 이해 시킬까?' 를 고민하게 됩니다. 생각이 구체화되고 목표가 뚜렷해집니다. 해도 그만, 안 해도 그만인 사람과 반드시 해야 하는 사람이 같을 수 없습니다.

우리는 일을 하면서 시작효과와 마감효과를 많이 경험합니다. 생산성은 일정한 곡선을 그리는 것이 일반적입니다. 작업에 있어 생산성이란 단위 시간당 작업능률을 말합니다. 하는 일의 난이도가 높을수록 집중이 필요합니다. 그렇지 않으면 생산성 저하는 물론이고 불량률이 증가합니다. 거기에 더해서 안전사고 위험도 올라갑니다. 정신노동은 생산성 편차가 더 심합니다. '일당백', '일당천'이란 말도 합니다. 시작효과와 마감효과는 두뇌 집중력의 차이라고 말할 수 있습니다.

우리가 가진 자원 중에서 가장 가동률이 떨어지는 것 가운데 하나가 두뇌가동률입니다. 두뇌 가동률을 높이는 방법에 무엇이 있을까요? 가르침은 두뇌 가동률을 높이는 최고의 수단입니다. 목표의식이 뚜렷한 데서 오는 긴장감은 집중력을 최대화 합니다. 회의, 세미나, 발표, 시험 등도 비슷한 효과를 가져옵니다. 집중하지 않는 것은 자동차를 세워두거나 10km이하의 저속으로 운행하는 것과 같습니다.

자동차의 엔진도 제 성능을 발휘하려면 여러 조건이 맞아야 합니다. 연료공급은 기본이고, 윤활유, 온도, 속도에 맞는 절절한 기어변속이 필요합니다. 똑 같은 자동차를 산 경우에도 자주 점검하고 잘 관리해주는 사람과 그렇지 않은 사람이 타는 자동차는 그 수명이 몇 배의 차이가 나기도 합니다.

우리의 두뇌는 이러한 단순한 자동차 엔진에 비교할 수 없습니다. 그러나 현실은 두뇌에 대하여 이러한 자동차 엔진이나 반복적인 일을 수행하는 기계장치에 쏟는 만큼의 관심과 관리도 하지 않는다는 것입니다.

누구를 가르치는 것을 좋아하는 사람은 많지 않습니다. 가르치는 것이 쉽다는 사람은 옛 성현들 가운데도 없습니다. 가르치는 것만큼 어려운 것이 없습니다. 제대로 가르치려면 배우는 사람보다 최소한 3배 이상의 노력이 필요하기 때문입니다.

직접 가르치는 일이 없는 분들도 역할을 바꾸어 가면서 혼자 가르치고 배울 수도 있습니다.
여러분들 중에서 많은 분들이 스터디 그룹을 구성하여 공부를 한 기억이 있을 겁니다. 일정부분 나누어서 학습하고, 서로 돌아가며 발표하고, 토론도 하는 이러한 모임은 학생 때, 신입사원 시절에 많이 볼 수 있습니다. 그러나 이를 지속적으로 하는 사람은 드뭅니다.

꼭 가르침이 아니라도 다른 사람에게 이야기 하는 것, 글 쓰는 것도 효과가 큽니다. 이것도 가르침의 일종입니다. 그러면 생각이 정리됩니다. 요즘은 글쓰기를 손쉽게 할 수 있는 길이 많습니다. 대표적인 것이 개인형 미디어라고 불리는 블로그입니다. 처음엔 좋은 글, 기사스크랩부터 시작합니다. 관심이 있는 내용을 스크랩했으니 거기에 대한 자신의 의견이 틀림없이 있을 것입니다. 글 말미에 자신의 의견을 추가하거나 덧글로 생각을 표현할 수 있습니다. 다른 사람의 의견도 경청할 수 있습니다. 더 나아가서 다른 사람의 블로그에 방문하여 자신의 의견을 피력할 수도 있습니다.

배우는 단계에서 가르친다는 분명한 목표가 있으면 열심히 배우고 익히게 됩니다. 가르치면서 또 배웁니다. 잘 설명하기 위해서 연구도 하고 고민도 하면서 다시 한번 새로운 사실을 깨닫게 됩니다. 묻고 답하면서 또 배웁니다. 내가 생각하지 못한 것을 질문 받을 수 있고, 대답을 하다가 깨닫는 것도 있습니다.

가르치는 사람은 먼저 잘 배울 수 있어야 합니다. 가르치는 사람도 가르치는데 한계가 있습니다. 냇가에 데려갈 수는 있지만 억지로 물을 마시게 할 수는 없습니다. 밥상을 차려 줄 수는 있지만 억지로 먹게 할 수는 없습니다. 배우는 사람은 최소한 차려진 밥상에서, 냇가에서 먹고 마시는 법은 알고 있어야 합니다. 현재 이것도 안 되어 있는 사람이 많습니다.

가르치는 사람과 배우는 사람의 자세는 달라야 합니다. 가르치는 사람은 하나의 모범 답과 그 과정을 이야기 할 수 있어야 합니다. 배우는 사람은 열 개의 의문점을 찾아야 합니다. 아니 같아야 합니다. 자세만은 같아야 합니다. 진지하게 임하며 열린 마음으로 모든 가능성을 다 추구해야 합니다.

배우는 사람과 가르치는 사람은 구체적으로 어떤 마음을 가져야 할까요?

배우는 자의 바른 자세

1. 의문을 가져라.
2. 문제를 해결하라.
3. 가르치는 연습을 하라.

가르치는 자의 바른 자세

1. 새로운 지식을 전달하라.
2. 새로운 사고를 하라.
3. 방향을 제시하라.

이러한 마음가짐을 가지고 임한다면 배우고 가르치는 것에 상관없이 많은 것을 얻을 수 있을 것입니다.

가르치면서 새로운 의문이 생기고, 새롭게 이해되는 것이 있고, 새롭게 알게 되는 것이 있습니다. 가르침은 배움이 전제가 됩니다.

가르치면 세 번 배웁니다.

--------------------------------------------

제공 : 코리아인터넷닷컴, a 2005년 02월 24일
저자 : 정용석  
필자: 정용석
인하대학교 전산학과를 졸업한 후 동대학원에서 공학석사 학위를 받음.
공군에서 전산장교로 DBA(데이타베이스 관리자), (주)데이콤에서 S/W개발,
인터넷 벤처 창업을 거쳐 현재는 아이디어 컨설턴트로 기업혁신 컨설팅을 하고있으며,
아이디어/혁신/발명 분야의 글을 연재.

2002, 2003년 대한민국 특허기술대전 수상
2002년 서울 국제 발명전 수상


Posted by SB패밀리
학창시절에 가르치는 데 뛰어난 재능을 가진 선생님을 한 번은 만난 경험이 있을 것이다.

그 선생님들은 배워야 할 핵심 개념을 잘 가르친 다음 아무리 복잡한 문제라도 그 핵심과의 관계를 통해 이해하기 쉽게 가르친다. 그 반대는 알고 보면 쉬운 개념도 아주 난해하게 풀어주는 교사가 아닐까.

대학시절에 고2 여학생의 영어 과외 선생 노릇을 한 적이 있었는데, 내가 취한 방법은 아주 단순했다. 영어 교과서의 모든 문장을 '문장의 5형식'으로 분해하게 하는 것. 몇 달에 걸쳐 그걸 다 한 다음에 그 학생은 눈에 띄게 독해력이 좋아졌던 기억이 난다.

내가 뛰어난 교사라서가 아니라 내가 선생님께 배웠던 방법을 그대로, 즉 아무리 복잡한 문장도 결국은 5형식 중의 하나일 뿐이라는 원리를 적용한 것뿐이었다. 최근에 고등학생이 쓴 어떤 글에, 개념을 익히기 위해 문제를 푸는 것이 아니라 문제를 풀기 위해 개념을 공부하고 있다고 푸념하는 대목이 있었는데 정말 기가 막혔다. 그것은 가르치는 올바른 방법이 아니니까.

포춘지가 뽑은 금세기의 가장 위대한 경영자, 전 GE 회장인 젝 웰치는 아무리 복잡하고 어려운 도전도 비즈니스의 핵심으로 가져와 문제를 해결했다고 한다. 그런데 그 비즈니스 핵심이란 게 사실 따져보면 길거리 노점상이나 동네의 작은 가게를 운영하는 사람의 지혜와 다르지 않다는 것이 램 샤란의 말이다.

경영 컨설턴트인 그는 자신의 책 `What the CEO wants you to know`에서 그 지혜를 `비즈니스 통찰력`(Business Acumen)이란 말로 표현했다. 어떻게 회사가 작동되고 돈을 버는지 그 원리에 대한 이해와 적용을 말하는 것이다.
동네에서 작은 가게를 운영하는 사람들은 사업에 영향을 미치는 것이 어떤 것이고, 어떻게 해야 자신의 사업이 더 잘되는지, 어떤 것이 방해가 되는지를 잘 알고 있다.

포춘 500대 기업에 들어가는 거대 기업도 따지고 보면 동네가게가 돌아가게 하는 동일한 요소들에 의해 번창하거나 내리막길을 걷는다는 것이다.
그는 이를 현금(Cash), 마진(Margin), 회전율(Velocity), 성장(Growth), 고객(Customer)의 5가지 개념으로 정립하여 `비즈니스의 핵`이라고 하고 이를 잘 이해하고 활용하는 것이 비즈니스의 통찰력이라고 했다.

똑 같은 세일즈맨이라도 자신이 '파는 사람'이고 '얼마나 많이 파느냐' 외에는 생각하지 않는 사람과 자기 회사의 현금흐름을 개선해야 하고 그를 위해 자신이 뭘 해야 하는지를 아는 세일즈맨이 있다면 그들의 조직에 대한 기여는 어떻게 차이가 있을까.

세일즈맨뿐 아니라 조직의 구성원들이 회사의 비즈니스 핵심이 어떻게 작동되고 있고 그 지표가 어떠한지, 자신이 어떤 행동을 해야 그 지표들을 개선하는 것인지를 잘 알고 있다면 어떨까.

재고회전율이나 성장률은 경영진 혹은 재무파트에서만 관심을 가지는 이슈라고 생각하는가. 그렇다면 직원들이 조직에 기여할 수 있는 많은 기회를 놓치고 있는 것일 수 있다. 한 때 풍미했던 직장인 성공학 책 중에서 'CEO처럼 생각하고 CEO처럼 행동하라'는 내용을 본 적이 있다. 그런데 이들이 CEO처럼 생각할 수 있게 필요한 지식과 스킬을 갖추도록 훈련시키는 것은 누구의 책임인가.

아는 CEO 중에 자신은 직원들에게 '그들이 하는 일이 어떤 의미가 있는지'만 끊임없이 얘기하지, 그 외의 자잘한 문제(근태나 고객응대 등)에 대한 훈계는 전혀 하지 않는다는 분이 있었다.

자신이 하는 일의 의미만 제대로 알면 그것으로 족하지 않느냐며 웃으며 말한 그 대목이 내겐 예사롭게 들리지 않았다. 그 회사는 직원 수가 많은데 주부사원의 비중이 높고 대부분 단순 고객응대와 판매가 주된 업무였다.
지난 연말에 그 회사가 높은 수익을 냈고, CEO분은 계열사의 더 큰 책임을 맡았다는 소식을 전해 들었을 때 나는 CEO의 그런 태도가 분명히 성과에 영향을 미쳤으리라고 짐작을 했다.

사람들은 자기 자신만이 아니라 그 이상의 것에 헌신하고 싶어하는 존재라고 믿는다. 자신의 일의 의미를 통해 세상과 연결되고 그것에 헌신하는 것. 이것은 결코 특별한 사람들의 얘기가 아니다. 직원들이 자신의 행동이 비즈니스에 어떤 영향을 미치는지를 자각하게 하기 위해서, 그들의 비즈니스 통찰력을 높이기 위해서 우리는 무엇을 할 수 있을까. / Helen@eklc.co.kr
< 저작권자 ⓒ머니투데이(경제신문) >


Posted by SB패밀리
http://korea.internet.com/channel/content.asp?kid=31&cid=435&nid=33847

[아이디어 낚시질] 맨땅에 헤딩은 없다
저자: 정용석 |  날짜:2005년 04월 06일

일하는데 맨땅에 헤딩은 없다!!!
찾고, 찾고, 또 찾아야 합니다. 원하는 것을 못 찾더라도 그 과정에서 많은 새로운 사실을 알게 되고, 일에 도움이 되는 경험을 하게 될 것입니다.

95%는 하나 더하기입니다. 99%는 완전히 새로운 것이 아닙니다. 창조적 문제 해결 기법으로 TRIZ란 것이 있습니다. TRIZ는 '발명 문제 해결 이론' 이란 의미의 러시아어 약자로 러시아의 발명가 겐리히 알트슐러(Genrich S. Altshuller, 1926~1998)가 지난 1950년대 개발한 체계적인 발명 방법론입니다. 그는 발명은 천재만이 할 수 있는 것이 아니며 보편적인 발명원리를 찾아낸다면 다른 사람들에게 가르칠 수 있을 것이라고 생각했습니다. 알츠슐러는 특허를 분석할 때 발명의 수준을 먼저 정하고 그에 따라 특허를 분류하였습니다.

발명의 수준을 Level 1부터 Level 5까지 5단계로 구분하였는데, 조사결과 너무나 자명한 해결책인 Level 1은 전체 특허의 32%, 사소한 개선을 통해 특허를 받은 Level 2는 45%, 기존 발명에서 눈에 띄게 진보를 한 것이라 보는 Level 3은 18%, 지금까지 없었던 새로운 개념의 발명이라 보는 Level 4는 4%, 과학적 발견 또는 선구자적 발명이라 볼 수 있는 Level 5는 1% 미만이었습니다.

알츠슐러는 과학적 발견의 영역인 Level 5에 해당하는 1%를 제외한 99%에 대해서는 체계적인 학습을 통해 결과에 도달할 수 있다고 판단했습니다. Level 1은 개인이 가진 지식수준으로, Level 2는 회사 내부의 지식수준으로, Level 3는 동일 산업계의 지식수준으로, Level 4는 동일 산업계를 벗어난 지식수준으로, Level 5는 인류의 모든 지식을 총동원하는 수준으로 결과에 도달 가능하다는 것입니다.


맨땅에 헤딩하지 말라는 얘기입니다. 당신이 직면한 대부분의 문제는 이미 누군가가 해결한 문제입니다. 당신이 직면한 문제의 99%는 해결의 실마리를 찾을 수 있습니다. 사실은 100% 해결의 실마리를 찾을 수 있다는 말이 더 맞는 말일 것입니다.

맨땅에 헤딩하지 않는 법

1. 처음부터 모든 것을 내가 다 하겠다는 생각을 버려야 합니다.
그것은 내가 절벽을 오르는데 이미 누군가가 가지고 있는 사다리나 밧줄을 이용하지 않고, 그것들을 만들어서 올라가겠다는 것과 같은 것입니다. 눈에 안 보여도 찾아보아야 합니다.

2. 전문가를 찾아라.
관련 정보 사이트를 방문하고, 관련 서적, 잡지, 신문 등을 읽고, 세미나, 전시회 등에 참석하여 나보다 먼저 고민한 사람의 경험을 얻을 수 있습니다. 당신이 판단을 내리기에 충분한 정도의 정보를 얻는 데는 약간의 수고만 하면 됩니다.

3. 최고의 제품/서비스에서 출발하라.
신제품 전시회에 나오는 제품을 눈 여겨 보고 거기서부터 출발점을 삼아야 합니다. 그리고 남보다 빨라야 합니다. 세상 돌아가는 것을 모르고, 새로운 제품이 나오는 것을 눈 여겨 보지 않으면, 수년, 수 십 년의 노력이 물거품이 될 수도 있습니다. 나의 노력과 관계없이 누군가가 유사한 제품을 먼저 출시하면 그 동안의 노력은 아무런 의미가 없습니다.

4. 자신과 다른 분야의 책을 읽고, 전시회에 참석하여 그들의 아이디어를 얻어라.
내가 가진 지식은 너무나 적고, 그 지식도 다 활용하지 못합니다. 자신이 필요로 하는 새로운 아이디어는 다른 분야에서 얻을 확률이 매우 높습니다. 당신이 자신의 분야에서 전문가라면 해당분야에서 해결책은 이미 다 찾아 보았을 것입니다. 자신의 분야에서 해결책이 안 보이면 즉시 밖으로 눈을 돌려야 합니다.

100미터 달리기의 출발선에 서 있는 선수가 다 같아 보일지 모르지만 사실은 이미 순위는 정해져 있는 것입니다. 아마도 날마다 몇 일을 경기해도 그 순위는 거의 변동이 없을 것입니다. 아니 변동될 수 없습니다. 맨땅에 헤딩하는 사람과 매사에 준비하고 노력한 사람의 차이는 쉽게 바뀌지 않습니다. 더 중요한 사실은 일은 우리가 아는 100미터 달리기가 아니라는 것입니다. 일은 노력여하에 따라서 다른 사람은 출발선에 서고, 당신은 결승선 바로 앞에서 출발할 수도 있다는 것입니다.


Posted by SB패밀리
[개발/IT] 공감가는 회사에 개발자로 있다면...

모든 회사가 이런 건 아니지만

공감하게 된다면... 이직을 고려해보라는 선배들의 말씀들을 그냥 넘길수는 없겠지요.

개발자에게 국한된 것이라 생각하면 오산.

 

노는 것과 기술개발을 동일시 하는 느낌을 받는다면... 바로 ===333

 

Posted by SB패밀리

백번 듣는 것 보다 한 번 직접 보는 게 낫다는 말처럼

책으로만 보는 것보다는 직접 만들어보고 경험해보는 것이,

알고 있는 것보다는 직접 가르쳐보는 것이

확실하게 자기의 것으로 만들 수 있다는 것을....


출처: 인터넷

아래의 글을 읽어 보자....



우유를 시켜먹는 사람보다 배달하는 사람이 더 건강하다.  
2004.06.10 10:23  

류(ryujt)   http://cafe.naver.com/codeway/137 

만년 초보 딱지를 달고 다니는 사람들이 있다.  스스로 초보 수준임을 모르는 사람까지 합하면 그 수는 무시 못할 정도에 이르게 된다.


무엇이 문제일까?  물론 수 많은 개발자들의 숫자만큼 수많은 이유가 있을 것이므로 몇 가지 말로 일반화하기란 너무 어렵다.  다만, 만약 지금 내가 거론하려는 조건들이 그대에게 적용된다면 부디 그 거추장스러운 딱지를 어서 떼어내기를 바란다.



1. 우유를 시켜먹는 사람보다 배달하는 사람이 더 건강하다.


대한민국 국민은 참으로 특이하다.  건강에 좋다고 하면 지렁이도 씨가 말라 버린다.  이러한 요상한 취미는 학문을 하는 사람에게도 고스란히 적용된다.  어떤 이의 방석을 훔쳐 앉으면 합격한다든가, 무엇을 어떻게 하면 성적이 오른다는 등의 비법들이 난무한다.


그 정도는 애교로 봐줄 수 있다.  하지만, 전문가의 길을 걷는, 프로의 길을 걷는 개발자들이 의식적이든 무의식적이든 젖어버린 이 비법 중독은 참으로 어처구니 없다.


간혹 좋은 책이 나오고 이것이 소문이 나면 금새 모든 개발자들은 반드시 그것을 읽어야 한다고 생각한다.  그리고, 그 책을 읽고 나면 자신이 무엇인가 업그레이드 된듯한 만족감을 느낀다.  좋은 강좌나 세미나에 참석했을 때는 그 환각증상이 더욱 심각해 진다.


하지만, 그것은 자신의 것이라고 할 수 없다.  아무리 좋은 것을 듣고 아무리 좋은 것을 읽어도 여전히 여러분의 실력은 그대로이다.  무엇인가 깨닫고 무엇인가 느낀 것이 있다면, 이제 여러분 스스로의 이론과 생각을 창조해 내고, 수없이 연마하는 시간이 필요한 것이다.


누구나 배트를 휘둘러 공을 쳐내는

"기술" 자체는 쉽게 이해할 수 있지만,

실재로 멋지게 공을 쳐내기 위해서는

수없이 헛 방망이질을 해야 하는 것처럼...




2. 재능의 부족을 탓하지 마라


재능이 부족한 그대여.  우리 부족한 재능의 덫에 걸려 넘어지지 말자.


자신감 부족이야 말로 가장 심각한 재난이다.  자신감을 잃어버린 자는 마치 사이드 브레이크를 걸어둔 채로 달리려는 자동차와 같다.  여기에 열정마저 잃어버리면 기름마저 떨어진 꼴이 된다.  계속 뒤를 돌아보고 자신의 부족한 위치에 한숨을 짓는 동안 그대의 발걸음은 늪 속으로 빠져들게 될 것이다.


재능의 차이는 있다.  인정해야 할 수밖에 없는 것을 외면하기 위해 시간을 낭비하지 말자.  하지만, 여러분들이 느끼는 것만큼 그 재능의 차이가 심각한 결과를 가져오는 경우는 없다.


가끔 소위 잘나가는 사람들을 보면, 무엇인가 특별하고 능력이 충만하여 보인다.  그리고, 각종 매스컴들은 그 차이점에 조명을 들이대기 시작한다.  그 때문에 그들이 겪었던 수많은 고난과 땀방울에 대해서는 쉽게 지나치게 된다.  그 어느 누구도 재능과 운으로 인해 쉽게 성공의 길에 들어설 수는 없다.  내가 장담한다.


곰곰이 생각해 보라, 자신보다 능력 있는 자들과의 자신의 차이점을.  현재 그 엄청난 차이에는 분명 재능이라는 거리도 있지만, 그들이 열정과 땀을 흘려가면 노력했던 시간이 더욱 크지 않게는 가?




3. 시작은 호기심의 힘으로, 중반은 열정으로, 마무리는 끈기와 신념으로


싹수가 노랗다고 한다.  그렇다.  그 동안 수많은 개발자들의 팀장을 맡으면서 나름대로 관상 보는 능력이 생긴 듯 하다.  싹수가 노란 놈이 보이기 시작한다.  반대로 “저 넘은 무엇인가 해낼 놈이다” 하고 느낌이 꽂히는 때가 있다.


시작부터 요란한 자는 중도에 반드시 포기한다.  잘나가다가 슬럼프에 빠지는 타입이다.  처음에 프로그래밍을 공부할 때는 모든 것이 신기할 뿐이었다.  무엇인가 만들어 보고는 대견한 자신을 뽐내고 싶어서 친구들에게 자랑하지 못해서 안달이 난다.  아직까지는 지극히 정상이다.  하지만, 그 정도를 넘어서 초보의 영역을 뛰어넘고자 안달이 나기 시작하면 일은 틀어지게 된다.


입문자는 반드시 그 호기심과 기본기 연마 사이에서 균형을 잃지 말아야 한다.  무엇인가 화려하고 어려워 보이는 문제에 대한 호기심은 지극히 정상이며 권장할만한 일이다.  하지만, 누군가에게 물어서 해결할 수 있는 일 보다는 자신 스스로 해결할 수 있는 문제에 대한 도전을 통하여 기본기를 연마할 시기에 너무 힘 빼지 말아야 할 것이다.


나중에 돌이켜 보면 입문자 시절만큼 돌아가고 싶은 시기도 없을 것이다.  그때의 그 기분을 다시는 느낄 수 없기 때문이다.


중도의 길을 들어선 자는 거침이 없어야 한다.  이제 서서히 개발하는 재미에 푹 빠져버려서 “이것이 내 천직이다” 하는 말을 거침없이 내뱉는 시기가 온다.  개발에 대한 예찬이 그 입에서 쉴새 없이 쏟아져 나온다.


하지만, 이 시기에서 입문 시기의 호기심으로만 행동하는 자는 반드시 쓰러지게 된다.  호기심과 열정의 차이는 무엇인가?  누군가 멋진 이성을 만났을 때 가슴 떨림이 호기심이라고 한다면, 사랑을 느끼고 그에게 완전히 녹아 버린 모습이 바로 열정이다.


프로그래밍의 세계에 녹아버려라.  일말의 망설임도 없이, 사랑할 때의 그 뜨거운 가슴으로 개발에 몰두하라.  돌부리를 반기고, 어려운 난관을 즐겨라.  절대 뒤돌아 서지 말고 언제나 승부를 걸어라.  해낼 수 있을 까 걱정하지 말고, “반드시 해내자” 하고 스스로를 위로하라.  자신만의 무용담을 훗날 후배들에게 자랑스럽게 이야기하게 될 그날을 기약하면서……


그리고 이제 완성의 시기.  이 시기는 조용하면서도 험난하다.  스스로 정체기를 느끼는 시절이기도 하다.  이제 교만을 버려야 할 시기이다.  어쩌면 이미 주눅이 들었을 지도 모른다.  여러 프로젝트를 통해 성공과 실패를 겪었을 것이고, 실무란 잘한 것보다 못한 것이 엄청난 위력으로 자신을 짓누르기 때문이다.

그대는 이제 잠시 쉬어도 좋다.  다만, 의미 있는 휴식을 취해야 할 시기이다.  객관적인 안목 그리고 보다 넓은 안목으로 개발을 이해하고 공부해야 할 시기이다.

지금까지는 개발이라는 것이 “고객과 나”, “문제와 나”와 같은 이차원적인 시야가 주된 관심사였을 지도 모른다.  하지만, 개발은 고객, 자신의 회사의 경영자, 마케팅 인원, 기획자, 등 수없이 많은 개발 이해관계자들과의 상관관계를 생각하지 않으면 안 되는 시기가 됐을 것이다.

문치무공(文治武功)이라고 했다.  무장도 결국 정치를 알아야 그 힘이 배가되며, 정치하는 자도 힘의 원리를 알고 인정할 줄 알아야 나라를 제대로 다스릴 수 있는 것이다.  이제는 호기심과 열정보다는 책임감과 끈기로 정체된 자신을 한 단계 업그레이드 시켜야 할 시기 인 것이다.


출근 길에 전철과 버스 안에서 이러 저러한 생각에 빠졌다가 생각난 데로 출근하자 마자 적어본 것입니다.  개인적인 생각일 뿐이니 넓은 아량으로 읽어주시길 바랍니다.

Posted by SB패밀리

 출처:  http://blog.naver.com/stbo/140035425781

초급개발자가 본 어이없는 프로젝트의 진행..

개발경력 1년이 조금넘는..개발자라고 말하기에는 스스로 아직은 부끄러워하는
신입개발자입니다.
컴공출신이긴 하나 졸업하고 전혀엉뚱한 일을 꽤 많은시간 하였고, 실제 학교에서도 공부를
거의 안한탓에 개발에 관한 지식은 전무한, 늦은 나이나마. 아 나도 '개발일을 하고싶다!'
의욕만 가득한 그런 사람입니다. (KLDP에는 개발관련자료훔쳐보기하고 가끔 아주 초보적인 질
문종종 올리곤 합니다. 고수님들이 바로 명쾌한 답변주실때 어찌나 행복하던지^^)

처음으로 들어간 회사의 개발팀이, 본연의 개발업무보다 고객시스템유지보수/관리등의
업무에 크게 치우쳐있어 못마땅하게 여기던중 여기저기 이력서를 넣다가 어렵사리
어떤기관의 개발팀에 입사할수있었습니다.
사내에는 기존 개발팀은 이미 존재하고 있고(주로 SI관련업무,거의다 외근을 나가십니다)
새로만들어진 개발팀에 새로운 인원으로 합류를 하게된것이죠.
면접당시 팀장님이 내가 해야할 업무를 알려주었을때, 하고싶은 분야에 하고싶은 일을
하게되어서 상당히 고무된상태였습니다.

프로젝트의 기간은 6개월, 인원은 고급1명(팀장),중급 2명(과장급,대리급) 이란거는
회사에 입사후 1주일후에 알았습니다. 당시 팀장은 중급중 1명을 본인(초급)으로 뽑았고
나머지 1명을 과장,대리급을으로 찾고있었지요. 저도 당시 사수없이 일을 할수없는 실력이란
것을 알고있기에 무조건 대리급이상으로 뽑으셔야합니다 하고 말했었습니다.
하지만 생각보다 사람 구하기가 무척 어렵다고 하더군요. 결국 중급인원을 못찾고 저와같은
신입이 1명 들어와 프로젝트를 시작하게 되었습니다.

여기서부터가 문제의 시작입니다.
자잘한 이야기는 하지 않겠습니다. 프로젝트중 자잘한 문제거리가 얼마나 많겠습니까?
가뜩이나 신입으로 들어온 개발인원이요. 그래도 프로젝트는 진행합니다.
코드는 C++로 진행한다고 하네요. 전회사에서 C만 만진탓에 당황스러웠지만
요즘엔 워낙 관련동강이 잘 되어있어서 공부하는게 크게 어렵진않더군요
(기본서를 벗어난 내용, 특히 디자인패턴 같은건, 뭐랄까.굉장히 난해하네요^^)

한달정도는 업무관련스터디로 시간을 보내고 한달후 본격적으로 코드를 만들기 시작합니다.
여기서부터가 조금 억지이긴하죠.
뭐 어쨋든 일단 코드를 만들어냅니다. 같이 새로들어온 신입(이하 옆친구)과 함께 어리숙하지만
조금씩 배워나가면서 코딩을 합니다. 그 친구가 벽돌을 만들면 전 그 벽돌로 건물을 짓는게
둘의 나눠진 업무였지요.

그친구, 벽돌..클래스를 못만듭니다. 자바를 했다고 들어온친구인데. 클래스를 모릅니다.
상속,포함관계..의 차이를 모릅니다. 좋습니다. 저도 몰랐고 여기 시작해서야 알기 시작했으니깐요.

그래도 일단 만듭니다. 설계 그런거 없습니다. 관련문서를 바탕으로 그것을 구현하는것인데.
일단 코드를 만들어야 합니다.
그래도 대강 벽돌 모양이 어떤지는 알아야 건물을 지을꺼 아닙니까?
대략적으로 디자인된 벽돌모양을...(당근, 동작안합니다) 상상을 하여서 아마 이런동작을..할꺼야.
하고 건물을 짖기시작합니다. 애당초 문서같은건 없습니다.

한 두세달 걸려 10층정도 지었습니다. 근데 벽돌 모양이 바뀌기 시작합니다.
이 친구 그래도 여전히 본인이 만든 벽돌. 설명못합니다.
클래스에 주석도 없고 본인설명도 없고, 걍 헤더파일, 라이브러리 딸랑입니다.
역시 상상의 나래를 펴서 건물을 짓습니다.
뭐 좋습니다. 문제는 저도 입장이 비슷한 신입이라 말없이일단 받아들이고 문제점 찾아낸다음에
지적해주고 다시 돌려받는식으로 업무를 진행했습니다.

한20층정도 지을때입니다. 이친구 벽돌이..아예 새로운 모양이 됐습니다.
솔직히 짜증은 대단히 많이 났지만, 그래도 조금씩 벽돌 모양을 하는거같아 반갑더군요.
그래서 20층 모조리 허물었습니다. 1층서부터 시작합니다

이미 이상황도 좀 웃기죠? 추상클래스? 그런거 없습니다. 클래스가 말도 없이, 주석도없이
한 뭉탱이가 날라옵니다. 만든 본인조차 이해를 못합니다. 설명을 못하는것이죠
주석을 달아달라고 해도 달지를 않습니다. 오히려 성질을 냅니다.
설명을 해달라면 황당하게 본인이만든 코드를 저보고 먼저 설명을 해보랍니다. 제 생각은 어떠냐구 물어봅니다. 황당.
더군다나 그 클래스의 메쏘드명조차 없어졌다 생겼다 수시로 바뀝니다.(이제와서야 이런게
콘크리트 클래스, 결합도가 너무 높은..이란걸 알았습니다. 하지만 팀장 지시로 계속 진행합니다.)
할말없습니다. 모르니깐 그럴수도 있죠.

다시 20층을 만들었습니다. 처음엔 무척 힘들었는데 두번째는 쉬워지더군요.
이제부터 진짜 문제가 시작합니다.
아예 기본적인 약속자체가 뒤흔들려 버립니다. 예를 들어 '코드내에서의 counter는 1부터
Index는 0부터 시작' 등의 약속내용이 바뀌어버립니다.
어느순간 그친구 클래스가 제동작을 안하나 했더니 이친구는 Index를 1부터 시작한걸로 바꿔버렸더군요
지적하면 화를 냅니다. '주석에 적어놓았다구! 왜 주석을 안보냐구!'
주석에 아무런 내용없습니다. 황당합니다만 참습니다. 제코드도 덕분에 그 기준을 맞추기위해
바뀌어 버립니다.
이친구 아예 코드 자체를 모릅니다. public과 private의 차이를 모릅니다.
new와 delete를 모릅니다. 이정도면 뭐 아실껍니다.

좋습니다. 전 이 프로젝트가 너무 맘에 들었고 꼭 하고싶었던 일이기에 사소한 감정싸움은
하기 싫었습니다. 그냥 참았지요(이게 나중에 굉장히 큰 화근이 되더군요)

하지만 이런일이 반복된다면 프로젝트가 산으로 가겠구나하는 걱정이 문득 들더군요.
팀장에게 제안을 했습니다.
'설계문서라던가 무언가의 기준이 정해져야합니다, 그렇지 않으면 이런일이 계속 반복될수있습니다'

팀장한테 혼났습니다.
팀장 : '장난하나? 넌 니 코드나 똑바로 만들기나해!'
황당했습니다. 그래서 데꾸했죠.
본인 : '팀장님, 기준이 없이 진행하는 지금 프로젝트 매우 위험합니다.
업무프로세스를 파악하기가 너무힘듭니다. 설계서같은것이 존재하는게 좋을듯 합니다.'
팀장 : '프로세스가 바로 코드다, 넌 코드를 만들어서 나한테 보고만 하면돼'

프로세스가..코드라..허..
....시키는 대로 했습니다. 팀장도 나름대로 무척 스트레스받겠지요. 회사에서 나름 중요한
프로젝트를 외부에 아웃소싱할것을 새로 만든 팀에게 주었는데 결과물은 제대로 안나오고있으니깐요.
일이 이상하게 진행되고있음을 알았지만.. 이런식으로 아옹다옹 4개월이 지났습니다.
중간에 회의석상에 팀장도 아닌 신입개발자가 오너이 하 간부들에게 너네 결과물이 대체 뭐냐?
뭐하고 있냐? 모 이런식으로 깨지는건 일상다반사이므로 얘기 안하겠습니다.

어쨋든 중간에 우리팀 모두가 박살이 나고 기간이 3개월 더 연장되었습니다.
계속~ 진행합니다.
벽돌에 새로운 기능이 추가됩니다. 만든 당사자는 역시 설명을 못합니다.
전 샘플코드를 요청합니다. 샘플코드를 못만드는지,안만드는지 안옵니다.
물어봅니다. 파라미터가 뭐고 리턴값이 무엇인지.
황당한 대답이 옵니다. 자기 소스코드를 디버깅 모드로 돌아가는걸 보여줍니다.
그랬더니 '자. 동작하죠?' 그리고 화를 냅니다.

그래서 다시 묻습니다. "내가 그 내용을 알필요는 없고 파라미터와 리턴값만 확실히 명시하라!"
대답못합니다. 다시 물으면 화를 냅니다. 아까 보여주지 않았냐구..
심지어는 컴파일 에라가 나오는 코드까지 넘어옵니다. 테스트라는건 애당초 기대도 할수없습니다.

이미 말이 안통하는 상황입니다.이 친구 둘러대기 바쁩니다.
저도 이쯤이면 화가 납니다만, 그래도 또 참아봅니다.

그리고 이친구 클래스를 제가 직접 테스트/검증합니다. 그리고 여기저기 문제점 찾아내면서
며칠을 보내고 그 사항을 지적해줍니다. 이건 모르겠다고 하면 저도 잘모르니 여기저기 찾아서
남의 소스긁어내거나 해서 직접 기능 구현하고 가르쳐주고 넘겨주고 그럽니다.
일단 제대로된 벽돌이 만들어져야 건물을 지을꺼 아닙니까?
그리고 이친구 바로 칼퇴근합니다. 전 제업무 남아서 야근하는수밖에요.

그리고 전 회의때 팀장한테 혼이 납니다. '넌 대체 지금까지 뭐를 했냐?'
그친구를 물끄러미 쳐다봅니다. 본척도 안합니다. 하핫.이쯤되면 웃음이 나옵니다.
무슨 드라마에서나 나올듯한 상황이네요.
뭐 이정도면 좋습니다.

프로젝트 중간 발표가 있었습니다. 오너이하 간부들이 모두 참석하는 자리에서 우리팀이
하고있는걸 정확히 파악하여야 한답니다.
이친구가 나이가 저보다 한살많으니. 팀장이 니가 선임해서 문서만들고
발표잘해라 이러더군요. 그친구 한 1주간 무언가 하는데 낑낑거리더군요. 내용도 보여주지 않습니다.
근데 발표를 코앞에 앞두고 결과물이 나오지않자 제가 너무 답답해서 팀장한테 직접 하겠다고 했습니다.

기존에 만든거 달라고 했더니 내용이 하나도 없습니다.
'허걱..업무자체를 파악을 못하고' 있더군요. 세상에 벽돌을 만드는 사람이, 그 벽돌이
무슨역할을 할지,무슨기능을 가져야하는지, 4개월동안 본 친구가 옆에서 곁눈질로 본 저보다
모르는겁니다.

답답하지만 급한와중에 일단 자료부터 만들었습니다(뭐 90%가 copy&paste)
도와달라고 했더니 바빠서 안된답니다. 당연히 바쁘겠지요, 업무파악을 못하고있는데..
ppt 20장정도? 반나절만에 휘리릭 만들었더니 발표를 같이 하겠답니다.
그래서 황당했죠. 아니 자료는 내가 만들었는데 왜 발표를 같이 하냐?
이친구 책상을 치고 소리지르며 나갑니다. 그래서 들어와서 하는말이 '같은 팀원인데 왜 혼자 다 하려그러냐?'
허..거참. 아니 발표야 둘중 아무나 하면 돼지 10분이면 할텐데, 그럼 당신이 할래?
그러니깐 입을 다뭅니다. 혼자서 알아서 잘하랍니다.

발표를 시작합니다.
그래도 내용전달은 오너+이하 간부들에게 잘 전달되었는지 고생많다고 칭찬받습니다.
이어서 바로 Q&A 시간입니다.

오너가 바로 옆친구한테 지적합니다.
오너: "자넨 모했나?"
옆친구 : "아 이번발표는 저친구가 말빨이 좋아서 발표를 하는거구 내용은 같이 만들었습니다'
나 : 황당..침묵.
오너: '너네 정해진 기간내에 프로젝트를 완수할수있는거지?'
나 : '정확히 표현한다면 지금 저희 작업속도로는 목표된 기일내에 맞추는것은 힘들듯합니다.'
오너: '야 그게 말이돼냐? 니들 기간알잔아?'
옆친구 정색을하며..'사장님 최선을 다해서 하고있습니다. 밤을 새서라도 기어코 만들어내겠습니다'
나 : 헐 ㅡ.ㅡ;

안믿겨지시죠? 저도 안믿겨집니다만 보통 이런식입니다.

매번 회의가 이러니 전 까다로운 녀석이 되버렸구, 옆친구는 성실한 친구가 되어버렸네요.
뭐 이것도 좋습니다. 전 이 프로젝트가 최우선이라 생각하고 올바른 결과물만 내면 된다고 생각하니깐요.
(뭐 이것도 혼자만의 착각이라는걸 후에야 알았습니다)

여하튼 이런식으로 또 시간이 흘러갑니다.
3개월이 늘어났다고 하나 도저히 그 기일을 맞출수 없을것같아서 팀장한테 또 제안해봅니다.
더 늦기전에 설계문서를 만들자구요. 또 혼납니다.

그리고 같은 일은 계속 일어납니다. 그나마아 이제는 클래스에 주석이 달려서 넘어오더라구요.
난 테스트를 하고넘기라고 제안합니다. 화를 냅니다. 주석에 다 있지 않느냐.
테스트가 다 끝났답니다. 그리고 직접 내가 테스트 하면 아예 동작을 안하는게 태반입니다.

도저히 안되겠다 싶어, 한바탕 난리를 친후..

팀장한테 말했습니다. 못참겠다. 저친구 저렇게 일하는거 바꿔야한다. 그렇지 않으면 프로젝트가 진행이 안된다.
그 친구 박살이 납니다. 공개적으로요.
그리고 팀장은 저에게 조용히 말하더군요.
'이미 너네둘이 프로젝트 중반이라 둘중 아무도 그만둘수 없다. 니가 참아라'

휴우. 하지만 바로 다음날부터 또 악순환의 반복입니다. 저한테 독한감정을 품은건지, 아예 팀장이 나가면 말을 안합니다.
벽돌이요? 이젠 의도적인지 아주 이상한 걸 주고 물먹이려 합니다. 세상에 이리 유치한 행동을 하다니..
주위에 말하기 조차 부끄러울정도입니다.
팀장들어오면 그래도 업무적인 얘기를 합니다. 쥐꼬리만한 목소리로. 아 그게 그건 그거고...어쩌구 저쩌구, 했던말 또하고
바쁘다고 나중에 얘기하자고 그럽니다.
팀장나가면 바로 소리칩니다. 저번에 말하지 않았냐구! 이해못하냐구!

이쯤되면 화도 안납니다. 기가막힐뿐이죠 이외에도 황당한 일이 많으나 너무 유치한거같아 그만하겠습니다.

휴. 저도 그래도 나름 많이 스트레스 받았나 보네요. 쓰다보니 이런 장문이..

결론입니다.

대단히 화가 많이 나있습니다. 인내심의 한계를 몇번 오르락내리락 반복하니 거의 제정신이 아닌것같습니다.
일단 가장먼저, 능력부족의 제스스로에게 화가 나고 부끄럽습니다. 제가 업무파악을 제대로 못하고 있고 변명이나마 지금 주어진
일은 능력밖의 일인것같습니다.(사수없이 혼자 설계,코딩,검증.. 너무 어렵네요. 솔직히 잘 모르겠습니다.)
나머지 절반은 일이 이지경이 되도록 방관하고 있는 팀장탓을 하고싶습니다.

좀더 정확하게 말하자면 옆 두사람에게 이젠 더이상 말이 아닌 주먹이 날아갈정도로 흥분된 상태입니다.(문제죠..이정도면)
이상태로 일이 되겠습니까? 어떻게 더 참으면서 일해볼까요? 다른분들은 이런상황에서 잘 일하고 그러고 계신지 궁금하네요?

무척이나 답답합니다.. 이거원.. 말도안되는 일을 해야하나 사직서를 쓰고 빨리 다른곳을 찾아야하나?
프로젝트 중반에 나가는 어이없는 실수는 하긴싫지만.. 이젠 참는 정도의 수준은 넘었다고 생각합니다.

뭐 나름 흥분해서 투덜투덜 해보았습니다. ㅡ.ㅜ

nike984의 그림

회사에 탄원 넣어서 다른분 짤라버려요 -_-a

jedi의 그림

그쪽 분야만 그런

그쪽 분야만 그런 것은 아닙니다.

제가 일하는 분야도 그렇고요.

아마 한국의 모든 산업분야가 "당장 하루만 어떻게 모면하자... "로 알고 있습니다.

그걸 바꾸려면 혁명을.....

+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년

맞습니다.

안녕하세요. 초보 리눅서입니다
잘부탁해요 ^^

저역시..다른분야도 제가받는정도이상의 스트레스를 받을것이라 냉정하게 생각해봅니다.
영업으로 일하는 제친구는 오너가 화나면 사무실에 재떨이가 날라다닌답니다.
역시 남의 돈을 받는 것은 결코 쉬운것이 아니겠죠.

아쉬운건. IT에서..개발프로젝트가..이모냥으로 진행되다니..다른 개발프로젝트도..정말 이지경이면..난감하네요.

저도 그런 경험을 지금 하고 있습니다..

그 사람들 엉터리로 해 놓고 기한 못 맞춘 상태에서 칼퇴근에 주말에 집에 쉴때..
제가 그 사람들 표준 스팩에 코드까지 분석끝내고..
그 사람들 부분까지 구현하고 있네요..

저의 황당한 경험도 이야기 해드려야겠네요

제가 다니던 회사의 상사가 경력 6년짜리였는데 어느날 나갔죠.

그리고 그 상사가 짠 코드를 두번째로 본 사람이
'어떤 놈이 이렇게 개념없이 만들었냐? 경력 6개월짜리밖에 안되는 놈이구먼' 하더군요.
참고로 두번째 본 사람은 경력이 4년 정도 되었고요.
제가 봐도 웃깁니다. 메소드 하나에 프로그램의 모든 기능이 다 들어가 있더군요 -_-; (참고로 mfc였음)

사장이 전화했습니다.
그러더니 오는 대답이 '내가 그동안 볼 때는 아무 이상 없었는데 왜 이제와서 딴소리냐' 합니다.
저한테도 '니가 잘짜세요' 그러고,
좀 손봐주겠다는거는 말은 기대하지도 않습니다. 어차피 나가버린 사람이니
근데 미안하다는 얘기 한마디도 안하더군요.

그 사람 저랑 같이 다녔을때는 컴퓨터 조립할때 나사 하나 빠진것까지도 뭐라고 혼내는 사람이었는데
지금 와서 보니 굉장히 괘씸하네요.

p.s.

자바 했다면서 클래스를 모른다면 그건 경력 구라친거 같군요.
자바 강좌 보면 클래스 얘기 하나도 안빠지던데. C++보다도 클래스개념이 더 중요한게 자바인데

Written By the Black Knight of Destruction

JuEUS-U의 그림

어떤 책에서는

어떤 책에서는 클래스의 개념을
"프로그램 하나에 한개" 정도로 설명했더군요....

즉, 어떤 사람은 Java를 써서 C처럼 코딩할수있다, 입니다...

난잡하게 나오는 그런 책들은 제발 사라져야 할텐데 말이죠...

superwtk의 그림

헉-_- 거의 독극물

헉-_- 거의 독극물 수준이군요

--------------------------------------------------------------------------------
http://blog.superwtk.com

프로젝트를

프로젝트를 진행하다가 보면 전혀 예상치 못한 적들이 생기게 됩니다.

이렇게 생기는 적들이 경쟁회사가 되면 좋겠지만,
대부분의 경우 고객, 영업, 팀장, 동료, 심지어는 부하직원까지도 적으로 변하게 됩니다.

밉죠.. 얼굴만 봐도 화가 납니다.
이상하죠? 같은 목표를 가지고, 같이 일을 하는데도
전혀 다른 일을 하는 타부서 사람들이 오히려 편하고 친하게 느껴질 정도니까요.

제 생각에는 회사생활에서 가장 중요한 것은
개발 스킬보다는 사람을 다루는 방법인것 같습니다.

싫은 사람, 나와 맞지 않는 사람...
이런 사람들은 잘 구슬려서 내가 원하는 방향으로 이끌어가는 것...
이것이 회사생활에서 가장 필요한 능력이 아닐까 싶습니다.

팀장, 동료, 부하직원과 맞지 않는다고 일이 늦어졌다는 것은
핑계일 뿐이죠...(절대 비난하는 것은 아닙니다.)

동료와 술이라도 한잔하면서 어떻게든 풀어가셔야지요...
잘 해결하시면, 최고의 스킬을 얻으실 것 같습니다.
부디 성공하시길 빕니다.
(저도 항상 같은 고민을 하게 됩니다. ㅜㅜ);

글 쓰신 내용을 보니

글 쓰신 내용을 보니 경력이 꽤 된 분 처럼 보이네요.

사실 개발쪽 일을 하다보면 적지 않은 개발자분들이 스킬 & 테크닉을 탐닉하는 경우가 아주 많죠. 그리고 그것이 자신의 가장 큰 의미로 생각하고 있구요. 물론 그 자체가 나쁘다고 생각하지는 않습니다.

언급하신 것 처럼, 일을 하다보면 실제로 웃음밖에 나오지 않는 코드를 생성하는 공부를 게을리 한 개발자들이 있습니다. 하지만 정작 본인은 무엇이 잘못되었는지 모릅니다. 그 이유는 자신이 알고 있는 최대한의 일을 했기 때문입니다. 젊은 날 공부를 게을리 하지 않고 열심히 했던 개발자들의 눈에는 그 것이 얼마나 한심한 것인지 다 보이지만 알고 있는 내용이 한심한 수준의 개발자는 그것이 보이지 않을 뿐입니다.

너무 그런 사람들을 몰아세우기 보다는 조금씩 조금씩 나은 스킬을 보여주고 그렇게 하도록 독려해서 조금이라도 내가 귀가하는 시간을 짧게 하도록 만드는 것이 더 현명하지 않을까 합니다.

그런데 경험상으로 코딩 실력이 제대로 되어있지 않은 개발자는 다른 사람들과 co-work 하는 것도 물론 제대로 하지 못했습니다. 그러면서도 원하는 것은 엄청 많죠. 왜냐면 스스로도 살아남아야 하니까요. 그 기본적인 생존본능을 당연하게 받아주지는 못하지만 어느정도 이해는 해 주어야 했습니다. 그래야 어떻게든 구슬려서 부려먹을(?) 수 있었으니까요.

개발자에서 긍정적으로 매니저로 가는 길이 바로 이런 것들을 이해하는 것이라고 생각합니다.

ydhoney의 그림

..

+1 
 
====================여기부터 식은어치====================
안녕하세요. 저는 야동 초등학교 2학년 6반 11번입니다!! 제 컴퓨터에 리눅스를 깔아보고 싶습니다. 리눅스라는건 어제 처음 들어 보았습니다.
리눅스에서도 카트라이더는 되겠지요? 설마 안되나요? 안되면 왜 쓰나요? =3=33 리눅스에서는 카트라이더 캐릭터 머리가 너무 커서 못받아들이나요?

gogisnim의 그림

작년 초 3년짜리

작년 초 3년짜리 프로젝트의 마지막 3년째에 투입되었습니다.

기존에 여자개발자가 한명있었는데 그 사람이랑 같이 개발하는 거였죠.
나보다 1년 먼저 투입되었는데 제가 오기까지 결과물이 없는겁니다
꼴랑 DB 명세서랑 어이없이 만든 클래스다이그램이 전부였죠(이것마저도 나중에 다 뜯어 고쳤죠)
저는 어떻게어떻게 제가 맡은 부분은 마무리가 되었는데 그때까지도 별다른 결과물이 안나와서 좀 어이가 없더군요.

성격은 지랄같은게 자존심은 있어서 물어보지도 않고 본인 혼자서만 끙끙거리는 그런 스타일..
나중에 보니 업무파악 자체가 안되어 있더라구요.
팀장한테 따졌죠. 왜 저런사람을 쓰냐고?
팀장도 포기한 그런 상태더군요.. 다행히 프로젝트가 큰 편이라서 인원도 많고 어떻게 어떻게 땜방식으로 무마했습니다.

결국은 나가더군요.
실력없고, 꼴에 자존심은 있고 성격 까칠한 개발자의 전형을 보았습니다.

picpic76 님 힘드시겠네요.
제가 보기엔 옆친구도 물론 잘못이지만 1차적으로 팀장의 잘못입니다.
그러한 인력은 뽑지도 말아야 하고 설사 뽑았더라도 그러한 문제가 있는 것을 알았으면 짜르던지 다른 개발자를 투입하던지 조치를 취해야 합니다.
제가 보기엔 그 프로젝트 100% 실패할거 같습니다.
picpic76님도 처신을 잘하셔야 할거 같구요.. 우울하네요 ㅠㅠ
좋은 결과 있으시길 바랍니다.

성격이 좋아야

성격이 좋아야 합니다. 주석을 안달았다고 마치 큰 잘못을 한 마냥 사장님앞에서 새로 들어온 사람에게 욕을 먹은적이 있는데 그 부분은 주석이 필요없는 부분이었습니다. 주석의 중요성을 교과서적으로 설명하고 얼마나 큰 잘못을 했는지 사장님앞에서 오버를 하는데.. 저는 미안하다.. 바쁘다보니 주석을 못달았다라고 했습니다. 많이 바빴거든요. 사장님이 더 잘아셔서 이해하고 넘어갔습니다. 얼마 안지나서 그 사람은 프로그래밍을 못하는 사람으로 판명되어서 쫓겨났습니다. 황당하더군요.

이런 부류도 있는데.. 사장님이 간단하지않은 일을 한사람에게 맡겼습니다. 이 사람은 좋은 대학나와서 평소 다양한 분야에대해 해박한 지식을 가지고 있으며 정말 많이 알고있는듯한, 의심의 여지가 없었습니다. 사장님도 믿고 맡겼는데 1개월이 지나고 2개월이 지날쯤에 진행사항을 모두가 궁금해 했습니다. 왜냐하면 뭘 하는지 아무에게도 말하지 않았기 때문에.. 그저 좀 안되는 부분이 있다, 어려운 말 써가며 애기하는데 그러냐며.. 열심히 해라고 하고 다시 3개월이 지나고 4개월이 지났는데 사장님은 조바심이 생기죠. 저희들은 의심을 하는거고.. 뚜겅을 좀 열어보자고 했는데 1개월만 더 달라고 해서 줬는데 5개월이 지나고 결국 6개월째 되던 날에 못만들었다며 모든걸 책임지겠다며 사표쓰고 나갔습니다. 사장님은 너무 화가나서 그 사람 pc에 작업물을 보자해서 보여줬더니 파워포인트 몇장.. 쓰다만듯한 워드문서.. 테스트용으로 만든듯한 예제 코드 몇개.. 결국 사장님 뚜겅이 열려버렸지요. 같은 사원들도 그 사람 욕 많이하고... 그런데 저는 달랐습니다. 그사람.. 반년동안 마음고생 정말 심했겠다 라는 생각이 들더군요. 불쌍했습니다.

atie의 그림

대놓고 맞부닥치지 말고...

버전 관리 싫다고 하는 상사 없습니다. cvs나 svn을 쓰십시오. 그러면 저런 경우에도 대처할 수단이 되고 커밋 로그만 봐도 무슨 생각으로 프로그램을 짜는지 볼 수도 있습니다. 물론 본인의 것도...
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

codebank의 그림

원문의 글 내용을

원문의 글 내용을 읽어보니 cvs, svn을 쓸 정도도 안되는 것 같습니다.
만일 그정도로 소스관리를 한다고하면 원문 같은 글은 나오지도 않았을 거라고 생각합니다.
그리고 만일 사용하다고 하더라도 개발자가 커밋 로그도 '...'정도만 남길 것 같다는
생각이 드네요. :-)
------------------------------
좋은 하루 되세요.

atie의 그림

예. 꼭 저 프로젝트가

예. 꼭 저 프로젝트가 아니더라도 후에 다른 프로젝트도 하실테니... 그 때는 도움이 될 겁니다. ^^;;

그리고, 둘이서 하는 일이라면, 화이트보드에 그리는 것은 같이 그리고 코딩은 혼자서 하는 편이 일 진행이 빠르겠지요. ㅎㅎ
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

분석설계없이 구현이라...

분석,설계없이 구현이라...

과장 조금 보태면 분석,설계없이 구현하고 계시는군요...

감리할때 티나지 않나요? ㅎㅎㅎ

"힘내세요!!" 라는 말 밖에 드릴말이 없네요..

공학에서 가장

공학에서 가장 필요한 것중에 하나가 커뮤니케이션입니다.
실무에서 말 안통하면 실력 유무를 떠나 같이 일하기가 힘듭니다..
전 개념없는 동료보다 관리자에 문제가 있다고 생각 드네요; 실력이나 개념은 어느날 깨달음을 얻으면 자라나기 마련이지만 -.-
대화를 자꾸 시도해 보세요. 같이 일할때 감정 세워서 좋은적은 없었습니다 -.-;
용서하세요; 탓도 마세요; 똘레랑스~

저 역시 커뮤니케이션이 문제라고 보입니다.

화난 사정도 이해하고 어쩔 수 없는 환경도 이해가 됩니다.
하지만 그런 극한 상황까지 가도록 된 것은 잘못한 팀원도 잘못이나 더 큰 책임은 관리자의 문제입니다. 상황 통제를 못한 탓이죠.
더우기 좀 더 상대방과 대화가 많이하고 명확하게 이야기를 나눴다면 적어도 문제점 자체가 무엇인지 최악의 상황 전에 어느정도 도출이 되지 않았을까 하는 아쉬움이 남습니다.
비록 상대방은 속으로 인정하지 못하더라도 들어난 결과물을 내밀었다면 겉으로 어느 정도 수긍을 했을 것 같군요.

맞짱 뜨세요.

계급장 떼고 맞짱 뜨세요.
이기는 사람 뜻대로 가는겁니다.

warpdory의 그림

꼭 소프트웨어 개발만이 아니더라도...

문서화 되지 않은 건 하지 않은 것이라고 보고 있습니다.
소프트웨어 개발뿐만이 아니라 다른 것 모든 것을요.

사장이 팀장이든 부장에게든 어떤 일을 지시하고, 팀/부장은 그것을 과장이든 대리든 사원이든 ... 쭉 업무분장을 하게 되죠. 그리고 그것을 모두 문서화 합니다.

그리고, 그 문서화 된 업무분장에 따라서 일을 진행하죠. 그리고 진행하는 모든 것은 또한 문서화시켜서 남깁니다. 그것이 협조전 형태로 되어 있든, 시행문이든 뭐든 ... 업무 지시, 업무 보고 모든 것을 문서화 하여 남겨야 합니다. 구두로 "여기까지 했어요." .... 이건 안됩니다.

그리고 업무가 끝나면(전체를 말할 수도 있고, 어떤 한 세션이나 파트가 될 수도 있습니다.) 그때마다 역시나 문서화 시킵니다.

문서화에 익숙지 않다면 시간낭비라고 볼 수도 있겠지만, 처음에 제대로 문서화시켜서 하게 되면 나중에는 그게 습관이 되어버립니다.

물론, 문서화에만 매달려서 일은 안하고 워드프로세서나 파워포인트만 붙잡고 있어서는 안되겠죠. - 가끔 이런 사람들이 .. 있죠 ... 그럴 때 쓰는 방법은 .. 문서화 작업은 모두 이사람에게 떠 넘겨 버리는 방법도 있습니다.

이렇게 해두면 나중에 '너 일안하고 뭐 했어' 라거나 ... 비슷한 일이 발생하는 것을 미리 방지할 수 있고, 또 설사 그런 일이 발생하더라도 최소한 책임을 뒤집어 쓰는 것은 피할 수 있습니다.

저희 회사의 경우는 보고서를 5단계로 관리합니다. 모든 일지는 회사의 KMS(Knowledge Management System (철자가 맞나...))에 자동으로 등록됩니다. - 아예 회사 인트라넷에 업무지시, 업무보고 가 따로 있습니다.

DPR - Daily Process Report ; 그냥 단순한 업무일지 정도라고 보시면 됩니다. 퇴근하기 10분전에 팀장에게 보내야 합니다. 일정횟수 이상 빼먹으면 기획팀에서 전화 옵니다. ...
WPR - Weekly ... ; 일주일 동안 진행한 상황을 적습니다. 보통 파워포인트 1,2 장 정도 됩니다. 일주일치 DPR 을 쭉 묶어서 첨부하여 제출합니다. 주간 회의할 때 이거 가지고 프로젝트든 어떤 과제든 일이든 ... 진행상황을 체크합니다.
MPR - Monthly ... ; WPR 을 묶어서 매월 2일에 지난달의 상황과 이번달에 할 일을 체크하고 보완하며 계획 수정이 필요한 것이 있다면 고치고 .. 합니다. 여기까지는 각 부서 단위로 움직입니다.
QPR - Quarter ... ; 1/4분기, 2/4분기, 3/4 분기, 4/4 분기 .. 각 분기별로 일의 진행상황을 체크합니다. QPR 부터는 회사 전체가 모여서 체크 합니다. 팀장과 각 팀의 PL 급이나 선임 과장 정도가 같이 회의에 참가해서 각 팀의 일이 어떤지, 계획 대비해서 진행상황은 어떤지, 그리고 그 구체적인 수치까지 들어가야 합니다. 단순히 일정이 늦어지고 있다. 가 아니라 일정상 3월 4일에 끝나야 하는 일인데, 이러 저러한 사정으로 인하여 4월 4일까지 끝낼 수 있을 것으로 예상되며 이것으로 인하여 생기는 영향은 이러 저러한 것이 있을 것으로 여겨지며, 그것은 이러저러하게 하여 보완할 수 있다. ... 뭐 이런 내용입니다.
YPR - Yearly ... ; 1년치를 모은 거죠. 이것으로 인사평가 합니다. 즉, DPR 부터 시작해서 쭉 써온 것을 가지고 인사평가가 쌓여서 이루어지죠. 문서화가 안되어 있다면 일은 했더라도 근거가 없으므로 인사평가에서 좋은 소리 못 듣습니다.

이렇게 5단계로 되어 있고, 각 프로젝트는 각 프로젝트 별로 또 정해져 있는 규정에 따라서 문서화가 됩니다. 그래서 KMS 를 뒤져보면 5,6 년전에 퇴사한 사람이 어떤 실험을 어떤 조건에서 해서 어떤 결과가 나왔다.. 까지도 찾아볼 수 있습니다. 그래서 했던 삽질을 또 하는 것을 미연에 방지하는 효과도 있습니다.

이렇게 문서화 하는 게 아예 시스템화 되어 있습니다. 즉, 김팀장이 강과장에게 A 를 시켜놓고서 나중에 '왜 이거 했냐 내가 시킨 건 B 다.' 라고 우겨댄다거나, 반대로 강과장이 김팀장에게 '전번에 보고 했지 않느냐' 라고 우기는 건 가능하지만, 설득력이 전혀 없습니다. 'KMS 에 등록돼 있어 ?' 라고 하면 거기서 결정됩니다. KMS 에 등록되어 있으면 그것을 안 읽은 사람 잘못입니다. '몰랐는데...' 이거 안 통합니다.

물론, 이렇게 문서화만 시킨다고 끝나는 건 아닙니다. 제일 앞에서 얘기했던 업무분장 한다고 했는데, 그때 참 신나게들 치고 박습니다. 예를 들어서 K 프로젝트의 범위는 우리팀의 소관을 벗어나니깐 옆팀의 누구까지 끌어들여야 한다.. 라든가 ... 등등. 하지만, 일단 결정되면 쭉 .. 업무분장을 합니다.
예를 들어서, 플라즈마 해석은 warpdory 가, 열처리 조건은 박과장이, 압력 및 time profile 은 유대리가, PR 및 ER 조건은 또 누가 잡고 ... 이런 식으로 쭉 .. 업무분장하고 이걸 전부 문서화해서 시스템에 남깁니다. 그리고 각각의 진행상황을 역시 쭉 ... KMS 에 등록시킵니다. 그러면 굳이 서로 바쁘고 해서 회의에 못 들어오거나 출장을 나가 있더라도 ... 진행상황을 알 수 있고, 만일 일의 방향이 조금 이상하다 싶거나, 괜히 삽질하고 있다.. (전공분야가 다 다르므로 일을 하다보면 가끔 다른 전공분야를 해야 하거든요.) 느끼면 조언을 구하거나 조언을 해줄 수도 있습니다.

이렇게 하는데.. 3년 걸렸다더군요... 회사 문화 바꾸는 게 힘들다고 합니다. 특히, 차장 이상급에서 이걸 받아들이는데.. 힘들어 했다더군요. 기존처럼 '말'로 지시하고 ... 이런 것에 익숙하다가 문서로 작성해서 지시하려니... 힘들었지만, 회장이 아예 못을 박아버리니 ... 그냥 다들 따라왔다고 하더군요.

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com

와우~ 너무 좋은 경험담~ 감사~

저도 가끔 사내의 정보 흐름의 단절 때문에 많은 생각을 하고 있었는데,

어떤 문제의 발생부터 해결과정을 찬찬히 읽다보니,

그간의 상황이 좌르륵 머리속에 지나가는 느낌입니다.

형상관리 서버를 통한 소스 관리(CVS나 SVN등)와

KMS와 같은 history가 남는 서버를 통한 업무 관리가 되면,

지금보다 더 많이 효율적이 될 것 같네요~

태터툴즈 사이트를 보면, SVN으로 소스 관리하고, issue관리자로 일을 관리하고,

Wiki로 명세서나 Changelog를 관리하는 것을 봅니다.

좋은 프로젝트 관리 사례가 될 것 같네요.

Sheep의 그림

와....

악필님의 내공이 엿보이는 글이네요...

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sheep.tistory.com (블로그 주소 바꼈습니다)

warpdory 씀:

warpdory 씀:
모든 일지는 회사의 KMS(Knowledge Management System (철자가 맞나...))에 자동으로 등록됩니다.

KMS (Knowledge Management System) ; 지식관리 시스템 ※ 출처 : 텀즈 에서...

철자가 맞네요. =)

warpdory 씀:
제일 앞에서 얘기했던 업무분장 한다고 했는데,

근데 여기서 분장이 분장( 分掌 ) 맞나요?

warpdory의 그림

한자가 그거 맞습니다.

- 한자를 한글로 바꿔주는 글꼴을 쓰고 있어서 왜 한글을 쓰고 괄호치고 또 한글을 쓰셨나 했습니다. -_-

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com

문서화 동감합니다.

문서화 동감합니다. 최소한 어떻게 돌아간다는 전체적인 흐름도 정도는 있어야 합니다.

그것도 없이 주먹구구식으로 개발한다면 모래성이 될게 뻔합니다.

윗글 보니까 공통적인 표준도 없고 주먹구구식으로 개발이 되는거 같아 안타깝습니다.

가장 좋은 방법은 술한잔하면서 진솔하게 대화나눠 보는것도 좋을듯 하네요.

커뮤니케이션이 안 통하면 절을 나오시는게 좋을듯 합니다.

Sheep의 그림

Death March....

http://en.wikipedia.org/wiki/Death_march_(software_development)

the project is doomed....

글쓴분 진짜 답답하시겠어요..

--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sheep.tistory.com (블로그 주소 바꼈습니다)

현재 Team의 성숙도가 얼마일까요?

The Joel Test
====================================================================
1. Source Control(소스 컨트롤)을 사용하십니까?
2. 한번에 빌드를 만들어낼 수 있습니까?
3. daily build(일별 빌드)를 만드십니까?
4. 버그 데이타베이스를 가지고 있습니까?
5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
6. up-to-date(최신) 스케줄을 가지고 있습니까?
7. spec(설계서)를 가지고 있습니까?
8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
10. 테스터들을 고용하고 있습니까?
11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?
====================================================================

위의 12가지에서 몇개나 되고 있나요? 아닌 팀이면 이런 방식으로
일해가도록 설득하십시오. 당근 자기 자신부터 이런 식으로 해야지요.

하지만 안된다면? 나가야 합니다. 그래야 같이 안망합니다. 물론 9점
이상 되도 짱나는 일 많습니다. 하지만 이게 지켜진다면 최소한 기본은
갈 수 있습니다. 화띵입니다. ^^

http://www.devjob.co.kr/

1day1의 그림

시스템의

시스템의 문제입니다.

팀장, 팀원, 동료. 사장, 투자자. 모두 한가지 목표를 가지고 있습니다.
'프로젝트의 성공'

서로가 적이되면 안됩니다.
프로젝트가 잘 안된다면, 시스템에 문제가 있는지 살펴봐야 합니다.

소스버전관리(svn,cvs) , 문서관리(wiki ..) 정도만 도입해도 해결되는 문제 프로젝트들이 많이 있습니다.

시스템을 점검해보세요.


F/OSS 가 함께하길.. (F/OSS서포터즈 : FOSS/Supporters, FOSS/Supporters/Group)
- 추천 프로젝트 : 추천하기 힘드시나요? 추천 꾹 눌러주세요! -

정말

정말 엄청나군요...

제가 기업 업무용 프로그램 만드는 회사 다닐 때는 우리 회사가 제일 주먹구구인줄 알았는데, 그보다 더 한 곳이 많군요...

적어도 우리 회사는 프로젝트 시작할 때, 명세서나 DB SPEC 같은 건 확실하게 다 많들고 시작했었거든요...

물론, 시작은 괜찮았지만, 중간 중간에 엄청나게 많은 수정이 가해졌고 그 수정에 대한 문서화가 제대로 이루어지지 않아서 결국은 싸움도 많이 하고 기간도 많이 늘었었죠...

그런데, 처음부터 문서화가 되지 않았으면 왜 그걸 짚고 넘어가지 않으셨나 싶습니다...

물론, 팀장한테 이야기를 하셨다고 했지만, 좀 약했던 거 같습니다... 그런 건 아주 팀장하고 틀어질 각오를 하고 해야 하는 얘기가 아닐까 합니다...

머... 제가 성격이 까칠해서 그런 것일 지는 몰라도 회사 다니는 3년 동안 정말 엄청 많이 싸웠습니다...

그리고 의사 소통에 문제가 있으면 참거나 하지 않고 회의 시간에 반드시 얘기했고 어떤 문서화된 결과물이 없으면 아예 일을 진행하지 않았습니다...

그렇게 진행해도 결국은 기간이 연장되고 문제가 많이 발생하더라구요...

솔직이 제 생각에 설계에 문제가 있는 프로젝트는 정상적인 프로젝트라고 봅니다... 그런데, 구현체에 문제가 많다면 그건 정말 기본의 문제라고 보거든요... 설계를 반영하는 구현체를 못 만드는 회사라면 아주 심각한 문제인거죠...

계속 그런 문제가 있을 경우에는 그 회사 그만 두는 게 더 좋을 거라고 봅니다...

언제까지 몸고생 마음고생 하시렵니까...

cvs/svn을 사용하지 않는 회사들이 많은가요?

저는 입사해서 가장 처음 배운게 vss (Visual Source Safe)사용법이었고, 두번째로 할당받은 계정이 vss계정이었는데... (첫번째는 회사 메일) vss는 MS에서 나온 형상관리 툴입니다. 아마 지금은 별로 사용되지 않을겁니다.

cvs/svn에서 개발이력 관리만 되더라도 위와같은 최악의 상황은 피할 수 있으리라 생각됩니다만...

(누가 어떤 일을 얼마나 했는지, 어디서 어떤 문제가 왜 발생했는지가 파악이 되지요)

개발이던, 이력 관리던 결국 사람이 하는 것이기 때문에 cvs/svn에 모든걸 해결해줄 수는 없지만, 위와 같은 문제점들을 많이 예방하고 해결할 수 있는 것은 사실입니다.

실제 개발자들 열명

실제 개발자들 열명 중 여덟명은 형상관리가 뭔지도 모릅니다.
대부분 공유폴더를 이용하더군요. 그과정에서 수정한 파일 옛날껄로 되돌리는 사고도 자주 일어나고요.

그리고 mfc 프로젝트 같은 경우 비주얼스튜디오에서 생성하는 각종 리소스나 코드들이 버전관리시스템때문에 엉켜서
알면서도 안쓰는 사람도 있습니다.
아무리 얘기해도 윗사람들이 귀찮아하면 다 꽝이죠.

Written By the Black Knight of Destruction

sozu의 그림

^^

스스로 해결하기 힘든 문제를 만났을 경우 문제를 공론화 해야 합니다.

동료분께 요청한 문제가 해결되지 않았을 경우 혹은, 중요한 문제임을 인식하지 못하여 일정에 차질을 주는 경우에는

개인적인 커뮤니케이션을 해결하려 들면 본인만 까다로운 사람으로 되기 쉽습니다. (다른 사람은 그 상황을 알수 없으니까요)

동료분께 현재 업무 프로세스의 문제점을 메일로 작성하시고 프로젝트 관련자들을 참조하세요. (증거가 있어야 합니다.)

이때 중요한 점은 프로젝트 관련자들도 문제를 쉽게 파악할수 있게 작성해야 한다는 것입니다.

자잘한 건단위로 해결하지 마시고 살짝 모아서 해결해주는 센스도 필요합니다.

건단위로 할경우 사소한 것까지 문제를 크게 만든다라는 인식을 가져올수 있습니다.

만약, 프로젝트 관련자들이 해당 문제점을 인식하지 못한다면~~ 대략 낭패입니다.ㅠㅠ

그럴 경우에는 문제가 너무 어렵습니다. 답이 않나와요( .. )

특히 상사가 그럴경우...신입사원의 말을 고분고분 들어주는 경우는 드물죠..이미 자기 고집에 빠져있기 때문에..

음...같이 일하시는 그분...

어떻게 취업하셨데요? -ㅁ-;

아직 학생인 저도...그 분보다는 잘할 수 있을듯;;

우선 제가 봤을때 팀장의 프로젝트 관리 능력이 조금 문제가 있는듯하고요.

예를들면 처음 프로젝트 시작때 문서화에 대한 내용, 업무보고방식같은걸 정해두고

일을 시작했으면 지금 처럼 팀이 흔들리는 일은 없었을듯 한데요.

지금 제가 있는 연구실에서 프로젝트하면 하루,1주일,1달 단위로 진행 보고서를 만들어서

1주일에 한번,한달에 한번씩 자기가 맡은 내용과 진행상황을 점검하면서 프로젝트 진행관리를 하는데

학교에서 하는 엉터리 프로젝트 -ㅁ-;보다도 더 프로젝트 관리가 안되는것 처럼 보이네요;;

그리고 같이하는 그 동료분....짤라내고 다른 개발자를 구하는게 최적의 solution일겁니다.

고생많으시겠네요. 물

고생많으시겠네요.

물론 급해서 인력은 초급으로 뽑았다지만

주관적인 견해로는
프레임웍 설계서를 만들려면 중급에 근접한 실력은 되어야 되는데.
몇년되지 않은 초급2분께 맡긴것 차체가 ...
일차적으로 개발이 지연되는건 개발자의 문제가 아닙니다.
보통 개발자가 욕을 많이 먹게 되지만 개발자의 잘못은 거의 없다고 할수 있을정도지요.
개발이 무너지고 또 세우고 무너지고 하는건 전형적인 인력운영의 문제지요.
프레임웍을 잡아줄 사람이 없기 때문이죠.

동료에 대해서 떠벌리잔니 나쁜놈되는것 같고 안 떠벌리자니 프로젝트 안되고
업무를 조절하는건 어떻까요. 서로 부닺히지 않게요.
공용으로 사용하는 기본 class는 일반적으로 많지 않으므로 각기능(서비스)별로 분리하시고
해당파트를 맡는겁니다.

그리고 모든 내용을 팀장을 통해서 주고 받도록 하는걸 제안해보세요.
어떤 부분이 안되면
가령 무슨 모듈을 받았는데 작동이 안되더라...
모든 내용을 자연스럽게 알릴수 있는 방법이죠 나쁜놈(? 사실 피해자죠 ㅎㅎ)도 안되요.
팀장한테 메일을 보내서 해당 내용을 알리고 팀장이 수정하도록 이야기 하세요.
팀장이 배를 같이 탔으니 같이 가야된다고 말했으니 팀장에게 이정도 부탁은 해보세요.

아울러 팀장이 설계부분을 피하는건 자신도 자세히 어떻게 해야될지 모를 가능성이 높아요.
즉, 기술성팀장이 아닌 영업성 팀장일가능성이 높네요...
경험풍부한 개발자가 필요한 시점이네요.

체스맨의 그림

팀장이 코딩

팀장이 코딩 안하거나, 코딩을 모르는 분인가요...?

아무튼 글 내용 상으론 프로젝트 결과는 실패이겠군요. 차라리 예상되는 결과에 맞춰서 앞으로 행동을 결정하시는 게 현명할 것 같습니다.

윗 분들 말씀처럼 문서화나 계획이 아주 중요하긴 하지만, 말씀하신 팀 규모에서 그런 체계를 갖추기란 쉽지 않아서, 대개 그런 경우는 프로젝트 성공 여부가 참여한 개발자의 개인기에 달려있다고 봐도 과언이 아닐 겁니다.

그 팀원을 뽑고, 그 팀원을 조율하지 못한 팀장 책임이 가장 큽니다. 물론 프로젝트가 실패했을때 그 분이 선뜻 책임을 질지는 의문입니다만.

제가 그 상황이라면 차라리 현재의 프로젝트 상황에 대한 분석 문서를 작성해서 다 까발리고 자폭을 각오할 것 같습니다만. -_-

하지만...
경력에 누가 되는 일은 되도록 피하세요...

저는 개발자는

저는 개발자는 아닙니다만... 아무튼 형상관리가 뭔지 모릅니다. 소스를 버젼별로 관리 하고 그러는 건가요? TODO리시트, 소스코드의 버젼, Bug리스트 등등.. 그런거 관리하고 Trace하고 그러는 것이... 형상 관리인가요? 음.
----
Lee Yeosong(이여송 사도요한)
E-Mail: yeosong@gmail.com
MSN: ysnglee2000@hotmail.com
----
웃음... 행복... 평화... (진정한...) 희망... 사랑... 이 세상 모든것이 그렇다면 얼마나 좋을까...(꿈 속의 바램일 뿐인가...)

CEO를 향하여

이글에 댓글다신분들 모두 CEO가 됩시다.
죽기살기로 일해서 여기댓글다신분들 모두 CEO되면 울나라 정보통신 강국될꺼라 믿습니다.

제가 항상생각해왔던건데, IT조직은 기술쪽보다 인사쪽 힘이 쎄다는거입니다.
근데, 인사과는 사람의 학력이나 됨됨이나 보고 기술력에대해서 전혀 의심치 않다는거 입니다.
또한 의심을할래야, 인사과쪽사람들이 머 아는게 있어야 의심을 하겠죵..

우리 엔지니어들이 CEO가되야 정보통신 강국 만들어갈수 있을꺼십니다.!
우리 노력하십시다!!

lacovnk의 그림

집 부근에

집 부근에 배팅볼(?)이라고 해야 하나요.. 야구공 치는 게 좀 전에 생겼습니다.

처음 그걸 봤을 때는 좀 멋쩍어서 안들어갔는데.. 요즘은 자주 갑니다. 시원시원하더군요 ㅎㅎㅎㅎ

그나저나, 커뮤니케이션은 정말 참 어려운 것 같습니다. 아아~

저는 메일로 모든 것을 해결하(려)는 것 보고 많이 당황스러웠습니다. 어허라~

저만 그런게 아니었군요..

제가 몇년전에 부푼 가슴을 안고 정부에서 추진하는 프로젝트를 따온 업체에서 잠시 알바?로 참여한적이 있습니다만.
참...기대가 우르르 무너지두만요..DB부터web까지 매일 코딩하고 매일 바뀌고...일관성..전혀 없고..비효율적이고..프로세스요?그런건 아예 생각도 안합디다...감리 나오면...접대하기 바쁘고...감리하시는분 나왔는데..마우스클릭도 제대로 못하더이다...연세가 꽤 있으셔도..임무가 감리면 좀 배우고 나와야 하지 않겠습니까? 당연히 검색 하나도 안되고...말해서 뭐합니까?그래도 잘 마무리된거 보면 평가는 잘 나온것 같더군요..흠흠;그곳만 그런줄 알았더니..제대로 안된곳이 꽤 있군요..놀랍습니다.....
일부 그런 몰지각한 기업에서의 팀프로젝트는 모든게 문제지만 젤 문제는 아마도 피드백의 문제라고 봅니다..전혀 피드백을 받아들일 생각을 안하더라구요...동료등..부하직원이듯...의견수렴은 없고...까라면 까...뭐 이런거 있잖습니까?참 많은걸 느꼈습니다...내가 생각했던 고수들은 다 어디 있을까?.창업생각했습니다..제 인생에 처음으로 더럽고 치사해서...돈 더달라는것도 아니고 처우 개선해달라는것도 아니고 제대로 좀 해보자는건데.....차라리 임시직이여서 얼마나 다행이었는지 모릅니다....정직원이었다면 아마 미쳐버렸을겁니다..결국엔 CVS 는 아니더라도.비스므리하게 해서 작업했습니다..공동작업인데..무슨 컴퓨터간에 공유도 안되어있고...최소한으로 버전쓰고 유저쓰고..그러니까 조금씩 진도가 나가더이다..6개월짜리 1년만에 했으니...이 무슨 국민들 세금으로 장난칩니까?....몇년전일임에도 확~ 오르는군요....별로 드릴수 있는 말이 없군요...힘내라고 하기도 참 뭐하고..그만두라고 하기도 거시기 하고...

CVS를 했어야하는데..이제서야..

안녕하세요. 초보 리눅서입니다
잘부탁해요 ^^

지금 진행중인 프로젝트는 현재 윈도에서 작업하지만 Unix계열에 포팅되는시간도 포함돼있는데요, 뭐 간단하게, '우리 ansi C/C++을 벗어나는 함수는 사용하지말자!' 이러고 시작했습니다. 정확히 툴은 VS6.0을 쓰는데 요게 C99표준은 커녕 기존은 C95표준보다도 약간 더 느슨하게,좀 여유있게 받아주고 있는듯하는데요, 프로젝트 막바지에 우리가 말로만 C/C++표준함수로 만들자 하고 만든 코드가 Unix계열에서 컴파일이나 될지 무척이나 걱정입니다.(무언가 크게 엉켜있을꺼라 예상됩니다.ㅋ)

더군다나 프로젝트 초기에 여러분이 다수 지적하신 CVS 도입건이 나왔었는데 그때 적극적으로 하자고 했어야지..하는 후회가 새삼드네요. 실제 코드를 만드는 인원은 2이기에,,없어도 돼겠지..한
착각이 이제와 낭패를 불러오고있네요.

결정적으로 무심하고 능력부족인 제탓이 많기에..부끄러울따름입니다.

일단 출근은 했으니 그래도 뭐라도 해야죠.^^
삼각김밥하나 먹고 시작해봅니다. 즐거운 한주되시길!

GUI가 아니라면

GUI가 아니라면 몇몇부분(process, thread관련함수중 일부)를 제외하고는 거의 호환됩니다.
생각보다 고칠거 별로 없어요.

tinywolf의 그림

버전 관리는 혼자라도 시작을..

학생 때부터 개인적으로 cvs을 설치하고 사용해 보았는데
사용할 때마다 정말 편리함을 느꼈었습니다.
졸업하고 나서는 svn을 써보고 훨씬 개선된 기능에 감동 받았었구요.

레포트나 중간중간 메모하는 텍스트들, 혹은 내문서를 통채로!!
버전 관리라는 것을 경험해 본다면 얼마나 편리한가를 다들 알 수 있죠.
사용하는 것을 보여준다거나 레포지토리를 나눠줘서 사용해 보라고 추천하면 같은 세계로 이끌기 쉽지요..

Posted by SB패밀리