초급개발자가 본 어이없는 프로젝트의 진행..
개발경력 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개월이 늘어났다고 하나 도저히 그 기일을 맞출수 없을것같아서 팀장한테 또 제안해봅니다.
더 늦기전에 설계문서를 만들자구요. 또 혼납니다.
그리고 같은 일은 계속 일어납니다. 그나마아 이제는 클래스에 주석이 달려서 넘어오더라구요.
난 테스트를 하고넘기라고 제안합니다. 화를 냅니다. 주석에 다 있지 않느냐.
테스트가 다 끝났답니다. 그리고 직접 내가 테스트 하면 아예 동작을 안하는게 태반입니다.
도저히 안되겠다 싶어, 한바탕 난리를 친후..
팀장한테 말했습니다. 못참겠다. 저친구 저렇게 일하는거 바꿔야한다. 그렇지 않으면 프로젝트가 진행이 안된다.
그 친구 박살이 납니다. 공개적으로요.
그리고 팀장은 저에게 조용히 말하더군요.
'이미 너네둘이 프로젝트 중반이라 둘중 아무도 그만둘수 없다. 니가 참아라'
휴우. 하지만 바로 다음날부터 또 악순환의 반복입니다. 저한테 독한감정을 품은건지, 아예 팀장이 나가면 말을 안합니다.
벽돌이요? 이젠 의도적인지 아주 이상한 걸 주고 물먹이려 합니다. 세상에 이리 유치한 행동을 하다니..
주위에 말하기 조차 부끄러울정도입니다.
팀장들어오면 그래도 업무적인 얘기를 합니다. 쥐꼬리만한 목소리로. 아 그게 그건 그거고...어쩌구 저쩌구, 했던말 또하고
바쁘다고 나중에 얘기하자고 그럽니다.
팀장나가면 바로 소리칩니다. 저번에 말하지 않았냐구! 이해못하냐구!
이쯤되면 화도 안납니다. 기가막힐뿐이죠 이외에도 황당한 일이 많으나 너무 유치한거같아 그만하겠습니다.
휴. 저도 그래도 나름 많이 스트레스 받았나 보네요. 쓰다보니 이런 장문이..
결론입니다.
대단히 화가 많이 나있습니다. 인내심의 한계를 몇번 오르락내리락 반복하니 거의 제정신이 아닌것같습니다.
일단 가장먼저, 능력부족의 제스스로에게 화가 나고 부끄럽습니다. 제가 업무파악을 제대로 못하고 있고 변명이나마 지금 주어진
일은 능력밖의 일인것같습니다.(사수없이 혼자 설계,코딩,검증.. 너무 어렵네요. 솔직히 잘 모르겠습니다.)
나머지 절반은 일이 이지경이 되도록 방관하고 있는 팀장탓을 하고싶습니다.
좀더 정확하게 말하자면 옆 두사람에게 이젠 더이상 말이 아닌 주먹이 날아갈정도로 흥분된 상태입니다.(문제죠..이정도면)
이상태로 일이 되겠습니까? 어떻게 더 참으면서 일해볼까요? 다른분들은 이런상황에서 잘 일하고 그러고 계신지 궁금하네요?
무척이나 답답합니다.. 이거원.. 말도안되는 일을 해야하나 사직서를 쓰고 빨리 다른곳을 찾아야하나?
프로젝트 중반에 나가는 어이없는 실수는 하긴싫지만.. 이젠 참는 정도의 수준은 넘었다고 생각합니다.
뭐 나름 흥분해서 투덜투덜 해보았습니다. ㅡ.ㅜ
그쪽 분야만 그런
그쪽 분야만 그런 것은 아닙니다.
제가 일하는 분야도 그렇고요.
아마 한국의 모든 산업분야가 "당장 하루만 어떻게 모면하자... "로 알고 있습니다.
그걸 바꾸려면 혁명을.....
+++ 여기부터는 서명입니다. +++
국가 기구의 존속을 위한 최소한의 세금만을 내고, 전체 인민들이 균등한 삶을
영위할 수 있는 착취가 없는 혁명의 그날은 언제나 올 것인가!
-- 조정래, <태백산맥> 중에서, 1986년
맞습니다.
안녕하세요. 초보 리눅서입니다
잘부탁해요 ^^
저역시..다른분야도 제가받는정도이상의 스트레스를 받을것이라 냉정하게 생각해봅니다.
영업으로 일하는 제친구는 오너가 화나면 사무실에 재떨이가 날라다닌답니다.
역시 남의 돈을 받는 것은 결코 쉬운것이 아니겠죠.
아쉬운건. IT에서..개발프로젝트가..이모냥으로 진행되다니..다른 개발프로젝트도..정말 이지경이면..난감하네요.
저도 그런 경험을 지금 하고 있습니다..
그 사람들 엉터리로 해 놓고 기한 못 맞춘 상태에서 칼퇴근에 주말에 집에 쉴때..
제가 그 사람들 표준 스팩에 코드까지 분석끝내고..
그 사람들 부분까지 구현하고 있네요..
저의 황당한 경험도 이야기 해드려야겠네요
제가 다니던 회사의 상사가 경력 6년짜리였는데 어느날 나갔죠.
그리고 그 상사가 짠 코드를 두번째로 본 사람이
'어떤 놈이 이렇게 개념없이 만들었냐? 경력 6개월짜리밖에 안되는 놈이구먼' 하더군요.
참고로 두번째 본 사람은 경력이 4년 정도 되었고요.
제가 봐도 웃깁니다. 메소드 하나에 프로그램의 모든 기능이 다 들어가 있더군요 -_-; (참고로 mfc였음)
사장이 전화했습니다.
그러더니 오는 대답이 '내가 그동안 볼 때는 아무 이상 없었는데 왜 이제와서 딴소리냐' 합니다.
저한테도 '니가 잘짜세요' 그러고,
좀 손봐주겠다는거는 말은 기대하지도 않습니다. 어차피 나가버린 사람이니
근데 미안하다는 얘기 한마디도 안하더군요.
그 사람 저랑 같이 다녔을때는 컴퓨터 조립할때 나사 하나 빠진것까지도 뭐라고 혼내는 사람이었는데
지금 와서 보니 굉장히 괘씸하네요.
p.s.
자바 했다면서 클래스를 모른다면 그건 경력 구라친거 같군요.
자바 강좌 보면 클래스 얘기 하나도 안빠지던데. C++보다도 클래스개념이 더 중요한게 자바인데
Written By the Black Knight of Destruction
헉-_- 거의 독극물
헉-_- 거의 독극물 수준이군요
--------------------------------------------------------------------------------
http://blog.superwtk.com
프로젝트를
프로젝트를 진행하다가 보면 전혀 예상치 못한 적들이 생기게 됩니다.
이렇게 생기는 적들이 경쟁회사가 되면 좋겠지만,
대부분의 경우 고객, 영업, 팀장, 동료, 심지어는 부하직원까지도 적으로 변하게 됩니다.
밉죠.. 얼굴만 봐도 화가 납니다.
이상하죠? 같은 목표를 가지고, 같이 일을 하는데도
전혀 다른 일을 하는 타부서 사람들이 오히려 편하고 친하게 느껴질 정도니까요.
제 생각에는 회사생활에서 가장 중요한 것은
개발 스킬보다는 사람을 다루는 방법인것 같습니다.
싫은 사람, 나와 맞지 않는 사람...
이런 사람들은 잘 구슬려서 내가 원하는 방향으로 이끌어가는 것...
이것이 회사생활에서 가장 필요한 능력이 아닐까 싶습니다.
팀장, 동료, 부하직원과 맞지 않는다고 일이 늦어졌다는 것은
핑계일 뿐이죠...(절대 비난하는 것은 아닙니다.)
동료와 술이라도 한잔하면서 어떻게든 풀어가셔야지요...
잘 해결하시면, 최고의 스킬을 얻으실 것 같습니다.
부디 성공하시길 빕니다.
(저도 항상 같은 고민을 하게 됩니다. ㅜㅜ);
글 쓰신 내용을 보니
글 쓰신 내용을 보니 경력이 꽤 된 분 처럼 보이네요.
사실 개발쪽 일을 하다보면 적지 않은 개발자분들이 스킬 & 테크닉을 탐닉하는 경우가 아주 많죠. 그리고 그것이 자신의 가장 큰 의미로 생각하고 있구요. 물론 그 자체가 나쁘다고 생각하지는 않습니다.
언급하신 것 처럼, 일을 하다보면 실제로 웃음밖에 나오지 않는 코드를 생성하는 공부를 게을리 한 개발자들이 있습니다. 하지만 정작 본인은 무엇이 잘못되었는지 모릅니다. 그 이유는 자신이 알고 있는 최대한의 일을 했기 때문입니다. 젊은 날 공부를 게을리 하지 않고 열심히 했던 개발자들의 눈에는 그 것이 얼마나 한심한 것인지 다 보이지만 알고 있는 내용이 한심한 수준의 개발자는 그것이 보이지 않을 뿐입니다.
너무 그런 사람들을 몰아세우기 보다는 조금씩 조금씩 나은 스킬을 보여주고 그렇게 하도록 독려해서 조금이라도 내가 귀가하는 시간을 짧게 하도록 만드는 것이 더 현명하지 않을까 합니다.
그런데 경험상으로 코딩 실력이 제대로 되어있지 않은 개발자는 다른 사람들과 co-work 하는 것도 물론 제대로 하지 못했습니다. 그러면서도 원하는 것은 엄청 많죠. 왜냐면 스스로도 살아남아야 하니까요. 그 기본적인 생존본능을 당연하게 받아주지는 못하지만 어느정도 이해는 해 주어야 했습니다. 그래야 어떻게든 구슬려서 부려먹을(?) 수 있었으니까요.
개발자에서 긍정적으로 매니저로 가는 길이 바로 이런 것들을 이해하는 것이라고 생각합니다.
..
+1
====================여기부터 식은어치====================
안녕하세요. 저는 야동 초등학교 2학년 6반 11번입니다!! 제 컴퓨터에 리눅스를 깔아보고 싶습니다. 리눅스라는건 어제 처음 들어 보았습니다.
리눅스에서도 카트라이더는 되겠지요? 설마 안되나요? 안되면 왜 쓰나요? =3=33 리눅스에서는 카트라이더 캐릭터 머리가 너무 커서 못받아들이나요?
작년 초 3년짜리
작년 초 3년짜리 프로젝트의 마지막 3년째에 투입되었습니다.
기존에 여자개발자가 한명있었는데 그 사람이랑 같이 개발하는 거였죠.
나보다 1년 먼저 투입되었는데 제가 오기까지 결과물이 없는겁니다
꼴랑 DB 명세서랑 어이없이 만든 클래스다이그램이 전부였죠(이것마저도 나중에 다 뜯어 고쳤죠)
저는 어떻게어떻게 제가 맡은 부분은 마무리가 되었는데 그때까지도 별다른 결과물이 안나와서 좀 어이가 없더군요.
성격은 지랄같은게 자존심은 있어서 물어보지도 않고 본인 혼자서만 끙끙거리는 그런 스타일..
나중에 보니 업무파악 자체가 안되어 있더라구요.
팀장한테 따졌죠. 왜 저런사람을 쓰냐고?
팀장도 포기한 그런 상태더군요.. 다행히 프로젝트가 큰 편이라서 인원도 많고 어떻게 어떻게 땜방식으로 무마했습니다.
결국은 나가더군요.
실력없고, 꼴에 자존심은 있고 성격 까칠한 개발자의 전형을 보았습니다.
picpic76 님 힘드시겠네요.
제가 보기엔 옆친구도 물론 잘못이지만 1차적으로 팀장의 잘못입니다.
그러한 인력은 뽑지도 말아야 하고 설사 뽑았더라도 그러한 문제가 있는 것을 알았으면 짜르던지 다른 개발자를 투입하던지 조치를 취해야 합니다.
제가 보기엔 그 프로젝트 100% 실패할거 같습니다.
picpic76님도 처신을 잘하셔야 할거 같구요.. 우울하네요 ㅠㅠ
좋은 결과 있으시길 바랍니다.
성격이 좋아야
성격이 좋아야 합니다. 주석을 안달았다고 마치 큰 잘못을 한 마냥 사장님앞에서 새로 들어온 사람에게 욕을 먹은적이 있는데 그 부분은 주석이 필요없는 부분이었습니다. 주석의 중요성을 교과서적으로 설명하고 얼마나 큰 잘못을 했는지 사장님앞에서 오버를 하는데.. 저는 미안하다.. 바쁘다보니 주석을 못달았다라고 했습니다. 많이 바빴거든요. 사장님이 더 잘아셔서 이해하고 넘어갔습니다. 얼마 안지나서 그 사람은 프로그래밍을 못하는 사람으로 판명되어서 쫓겨났습니다. 황당하더군요.
이런 부류도 있는데.. 사장님이 간단하지않은 일을 한사람에게 맡겼습니다. 이 사람은 좋은 대학나와서 평소 다양한 분야에대해 해박한 지식을 가지고 있으며 정말 많이 알고있는듯한, 의심의 여지가 없었습니다. 사장님도 믿고 맡겼는데 1개월이 지나고 2개월이 지날쯤에 진행사항을 모두가 궁금해 했습니다. 왜냐하면 뭘 하는지 아무에게도 말하지 않았기 때문에.. 그저 좀 안되는 부분이 있다, 어려운 말 써가며 애기하는데 그러냐며.. 열심히 해라고 하고 다시 3개월이 지나고 4개월이 지났는데 사장님은 조바심이 생기죠. 저희들은 의심을 하는거고.. 뚜겅을 좀 열어보자고 했는데 1개월만 더 달라고 해서 줬는데 5개월이 지나고 결국 6개월째 되던 날에 못만들었다며 모든걸 책임지겠다며 사표쓰고 나갔습니다. 사장님은 너무 화가나서 그 사람 pc에 작업물을 보자해서 보여줬더니 파워포인트 몇장.. 쓰다만듯한 워드문서.. 테스트용으로 만든듯한 예제 코드 몇개.. 결국 사장님 뚜겅이 열려버렸지요. 같은 사원들도 그 사람 욕 많이하고... 그런데 저는 달랐습니다. 그사람.. 반년동안 마음고생 정말 심했겠다 라는 생각이 들더군요. 불쌍했습니다.
대놓고 맞부닥치지 말고...
버전 관리 싫다고 하는 상사 없습니다. cvs나 svn을 쓰십시오. 그러면 저런 경우에도 대처할 수단이 되고 커밋 로그만 봐도 무슨 생각으로 프로그램을 짜는지 볼 수도 있습니다. 물론 본인의 것도...
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam
예. 꼭 저 프로젝트가
예. 꼭 저 프로젝트가 아니더라도 후에 다른 프로젝트도 하실테니... 그 때는 도움이 될 겁니다. ^^;;
그리고, 둘이서 하는 일이라면, 화이트보드에 그리는 것은 같이 그리고 코딩은 혼자서 하는 편이 일 진행이 빠르겠지요. ㅎㅎ
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam
분석설계없이 구현이라...
분석,설계없이 구현이라...
과장 조금 보태면 분석,설계없이 구현하고 계시는군요...
감리할때 티나지 않나요? ㅎㅎㅎ
"힘내세요!!" 라는 말 밖에 드릴말이 없네요..
공학에서 가장
공학에서 가장 필요한 것중에 하나가 커뮤니케이션입니다.
실무에서 말 안통하면 실력 유무를 떠나 같이 일하기가 힘듭니다..
전 개념없는 동료보다 관리자에 문제가 있다고 생각 드네요; 실력이나 개념은 어느날 깨달음을 얻으면 자라나기 마련이지만 -.-
대화를 자꾸 시도해 보세요. 같이 일할때 감정 세워서 좋은적은 없었습니다 -.-;
용서하세요; 탓도 마세요; 똘레랑스~
저 역시 커뮤니케이션이 문제라고 보입니다.
화난 사정도 이해하고 어쩔 수 없는 환경도 이해가 됩니다.
하지만 그런 극한 상황까지 가도록 된 것은 잘못한 팀원도 잘못이나 더 큰 책임은 관리자의 문제입니다. 상황 통제를 못한 탓이죠.
더우기 좀 더 상대방과 대화가 많이하고 명확하게 이야기를 나눴다면 적어도 문제점 자체가 무엇인지 최악의 상황 전에 어느정도 도출이 되지 않았을까 하는 아쉬움이 남습니다.
비록 상대방은 속으로 인정하지 못하더라도 들어난 결과물을 내밀었다면 겉으로 어느 정도 수긍을 했을 것 같군요.
꼭 소프트웨어 개발만이 아니더라도...
문서화 되지 않은 건 하지 않은 것이라고 보고 있습니다.
소프트웨어 개발뿐만이 아니라 다른 것 모든 것을요.
사장이 팀장이든 부장에게든 어떤 일을 지시하고, 팀/부장은 그것을 과장이든 대리든 사원이든 ... 쭉 업무분장을 하게 되죠. 그리고 그것을 모두 문서화 합니다.
그리고, 그 문서화 된 업무분장에 따라서 일을 진행하죠. 그리고 진행하는 모든 것은 또한 문서화시켜서 남깁니다. 그것이 협조전 형태로 되어 있든, 시행문이든 뭐든 ... 업무 지시, 업무 보고 모든 것을 문서화 하여 남겨야 합니다. 구두로 "여기까지 했어요." .... 이건 안됩니다.
그리고 업무가 끝나면(전체를 말할 수도 있고, 어떤 한 세션이나 파트가 될 수도 있습니다.) 그때마다 역시나 문서화 시킵니다.
문서화에 익숙지 않다면 시간낭비라고 볼 수도 있겠지만, 처음에 제대로 문서화시켜서 하게 되면 나중에는 그게 습관이 되어버립니다.
물론, 문서화에만 매달려서 일은 안하고 워드프로세서나 파워포인트만 붙잡고 있어서는 안되겠죠. - 가끔 이런 사람들이 .. 있죠 ... 그럴 때 쓰는 방법은 .. 문서화 작업은 모두 이사람에게 떠 넘겨 버리는 방법도 있습니다.
이렇게 해두면 나중에 '너 일안하고 뭐 했어' 라거나 ... 비슷한 일이 발생하는 것을 미리 방지할 수 있고, 또 설사 그런 일이 발생하더라도 최소한 책임을 뒤집어 쓰는 것은 피할 수 있습니다.
저희 회사의 경우는 보고서를 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를 관리하는 것을 봅니다.
좋은 프로젝트 관리 사례가 될 것 같네요.
와....
악필님의 내공이 엿보이는 글이네요...
--------
From Buenos Aires, Argentina
No sere feliz pero tengo computadora.... jaja
닥치고 Ubuntu!!!!!
To Serve My Lord Jesus
blog: http://sheep.tistory.com (블로그 주소 바꼈습니다)
warpdory 씀:
모든 일지는 회사의 KMS(Knowledge Management System (철자가 맞나...))에 자동으로 등록됩니다.
KMS (Knowledge Management System) ; 지식관리 시스템 ※ 출처 : 텀즈 에서...
철자가 맞네요. =)
제일 앞에서 얘기했던 업무분장 한다고 했는데,
근데 여기서 분장이 분장( 分掌 ) 맞나요?
네
한자가 그거 맞습니다.
- 한자를 한글로 바꿔주는 글꼴을 쓰고 있어서 왜 한글을 쓰고 괄호치고 또 한글을 쓰셨나 했습니다. -_-
---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도
즐겁게 놀아보자.
http://akpil.egloos.com
문서화 동감합니다.
문서화 동감합니다. 최소한 어떻게 돌아간다는 전체적인 흐름도 정도는 있어야 합니다.
그것도 없이 주먹구구식으로 개발한다면 모래성이 될게 뻔합니다.
윗글 보니까 공통적인 표준도 없고 주먹구구식으로 개발이 되는거 같아 안타깝습니다.
가장 좋은 방법은 술한잔하면서 진솔하게 대화나눠 보는것도 좋을듯 하네요.
커뮤니케이션이 안 통하면 절을 나오시는게 좋을듯 합니다.
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점
이상 되도 짱나는 일 많습니다. 하지만 이게 지켜진다면 최소한 기본은
갈 수 있습니다. 화띵입니다. ^^
시스템의
시스템의 문제입니다.
팀장, 팀원, 동료. 사장, 투자자. 모두 한가지 목표를 가지고 있습니다.
'프로젝트의 성공'
서로가 적이되면 안됩니다.
프로젝트가 잘 안된다면, 시스템에 문제가 있는지 살펴봐야 합니다.
소스버전관리(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
^^
스스로 해결하기 힘든 문제를 만났을 경우 문제를 공론화 해야 합니다.
동료분께 요청한 문제가 해결되지 않았을 경우 혹은, 중요한 문제임을 인식하지 못하여 일정에 차질을 주는 경우에는
개인적인 커뮤니케이션을 해결하려 들면 본인만 까다로운 사람으로 되기 쉽습니다. (다른 사람은 그 상황을 알수 없으니까요)
동료분께 현재 업무 프로세스의 문제점을 메일로 작성하시고 프로젝트 관련자들을 참조하세요. (증거가 있어야 합니다.)
이때 중요한 점은 프로젝트 관련자들도 문제를 쉽게 파악할수 있게 작성해야 한다는 것입니다.
자잘한 건단위로 해결하지 마시고 살짝 모아서 해결해주는 센스도 필요합니다.
건단위로 할경우 사소한 것까지 문제를 크게 만든다라는 인식을 가져올수 있습니다.
만약, 프로젝트 관련자들이 해당 문제점을 인식하지 못한다면~~ 대략 낭패입니다.ㅠㅠ
그럴 경우에는 문제가 너무 어렵습니다. 답이 않나와요( .. )
특히 상사가 그럴경우...신입사원의 말을 고분고분 들어주는 경우는 드물죠..이미 자기 고집에 빠져있기 때문에..
음...같이 일하시는 그분...
어떻게 취업하셨데요? -ㅁ-;
아직 학생인 저도...그 분보다는 잘할 수 있을듯;;
우선 제가 봤을때 팀장의 프로젝트 관리 능력이 조금 문제가 있는듯하고요.
예를들면 처음 프로젝트 시작때 문서화에 대한 내용, 업무보고방식같은걸 정해두고
일을 시작했으면 지금 처럼 팀이 흔들리는 일은 없었을듯 한데요.
지금 제가 있는 연구실에서 프로젝트하면 하루,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가되야 정보통신 강국 만들어갈수 있을꺼십니다.!
우리 노력하십시다!!
집 부근에
집 부근에 배팅볼(?)이라고 해야 하나요.. 야구공 치는 게 좀 전에 생겼습니다.
처음 그걸 봤을 때는 좀 멋쩍어서 안들어갔는데.. 요즘은 자주 갑니다. 시원시원하더군요 ㅎㅎㅎㅎ
그나저나, 커뮤니케이션은 정말 참 어려운 것 같습니다. 아아~
저는 메일로 모든 것을 해결하(려)는 것 보고 많이 당황스러웠습니다. 어허라~
저만 그런게 아니었군요..
제가 몇년전에 부푼 가슴을 안고 정부에서 추진하는 프로젝트를 따온 업체에서 잠시 알바?로 참여한적이 있습니다만.
참...기대가 우르르 무너지두만요..DB부터web까지 매일 코딩하고 매일 바뀌고...일관성..전혀 없고..비효율적이고..프로세스요?그런건 아예 생각도 안합디다...감리 나오면...접대하기 바쁘고...감리하시는분 나왔는데..마우스클릭도 제대로 못하더이다...연세가 꽤 있으셔도..임무가 감리면 좀 배우고 나와야 하지 않겠습니까? 당연히 검색 하나도 안되고...말해서 뭐합니까?그래도 잘 마무리된거 보면 평가는 잘 나온것 같더군요..흠흠;그곳만 그런줄 알았더니..제대로 안된곳이 꽤 있군요..놀랍습니다.....
일부 그런 몰지각한 기업에서의 팀프로젝트는 모든게 문제지만 젤 문제는 아마도 피드백의 문제라고 봅니다..전혀 피드백을 받아들일 생각을 안하더라구요...동료등..부하직원이듯...의견수렴은 없고...까라면 까...뭐 이런거 있잖습니까?참 많은걸 느꼈습니다...내가 생각했던 고수들은 다 어디 있을까?.창업생각했습니다..제 인생에 처음으로 더럽고 치사해서...돈 더달라는것도 아니고 처우 개선해달라는것도 아니고 제대로 좀 해보자는건데.....차라리 임시직이여서 얼마나 다행이었는지 모릅니다....정직원이었다면 아마 미쳐버렸을겁니다..결국엔 CVS 는 아니더라도.비스므리하게 해서 작업했습니다..공동작업인데..무슨 컴퓨터간에 공유도 안되어있고...최소한으로 버전쓰고 유저쓰고..그러니까 조금씩 진도가 나가더이다..6개월짜리 1년만에 했으니...이 무슨 국민들 세금으로 장난칩니까?....몇년전일임에도 확~ 오르는군요....별로 드릴수 있는 말이 없군요...힘내라고 하기도 참 뭐하고..그만두라고 하기도 거시기 하고...
CVS를 했어야하는데..이제서야..
안녕하세요. 초보 리눅서입니다
잘부탁해요 ^^
지금 진행중인 프로젝트는 현재 윈도에서 작업하지만 Unix계열에 포팅되는시간도 포함돼있는데요, 뭐 간단하게, '우리 ansi C/C++을 벗어나는 함수는 사용하지말자!' 이러고 시작했습니다. 정확히 툴은 VS6.0을 쓰는데 요게 C99표준은 커녕 기존은 C95표준보다도 약간 더 느슨하게,좀 여유있게 받아주고 있는듯하는데요, 프로젝트 막바지에 우리가 말로만 C/C++표준함수로 만들자 하고 만든 코드가 Unix계열에서 컴파일이나 될지 무척이나 걱정입니다.(무언가 크게 엉켜있을꺼라 예상됩니다.ㅋ)
더군다나 프로젝트 초기에 여러분이 다수 지적하신 CVS 도입건이 나왔었는데 그때 적극적으로 하자고 했어야지..하는 후회가 새삼드네요. 실제 코드를 만드는 인원은 2이기에,,없어도 돼겠지..한
착각이 이제와 낭패를 불러오고있네요.
결정적으로 무심하고 능력부족인 제탓이 많기에..부끄러울따름입니다.
일단 출근은 했으니 그래도 뭐라도 해야죠.^^
삼각김밥하나 먹고 시작해봅니다. 즐거운 한주되시길!
버전 관리는 혼자라도 시작을..
학생 때부터 개인적으로 cvs을 설치하고 사용해 보았는데
사용할 때마다 정말 편리함을 느꼈었습니다.
졸업하고 나서는 svn을 써보고 훨씬 개선된 기능에 감동 받았었구요.
레포트나 중간중간 메모하는 텍스트들, 혹은 내문서를 통채로!!
버전 관리라는 것을 경험해 본다면 얼마나 편리한가를 다들 알 수 있죠.
사용하는 것을 보여준다거나 레포지토리를 나눠줘서 사용해 보라고 추천하면 같은 세계로 이끌기 쉽지요..
'IT-개발트렌드' 카테고리의 다른 글
| [IT/개발] 프로그래밍을 잘하는 방법 10가지 (0) | 2010.10.13 |
|---|---|
| [IT/개발] 버그 없는 프로그램은 없다 (0) | 2010.10.07 |
| [IT/개발] 개발자의 레벨을 나누자면 (0) | 2010.10.07 |
| [IT/개발] 파워빌더 뉴스지 2006년 12월호 (0) | 2010.02.12 |
| [IT] 와이파이(WIFI)와 와이브로(WIBRO)의 차이점 (0) | 2010.02.04 |
댓글