C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[15018] [잡담] 디테일의 차이가 결과의 차이를 만든다.
김호광 [testcode] 3226 읽음    2008-09-04 01:36
개발자나 외주 용역 회사의 직원을 보다보면 가끔 그 미래가 보일 때가 있답니다.

1. 업무 일지를 작성하지 않는다.

2. 회의록은 작성하지 않는다.

3. 개발 완료까지 "글쎄요..."라고 얼버무린다.

4. 기획이 수시로 변경된다.

5. Risk를 안고 가는 것과 사기에 가까운 행동을 하는 것을 구분 못한다.

6. 사장이나 팀장 말에 반론이 없다.

7. 버그나 사용자가 불편할 것을 알면서도 그냥 출시한다.

8. 사익을 위해서 개발을 지연한다.

9. 생각하지 않고 지시대로 일한다.

10. 입으로 개발한다.

개인적으로 디테일이 가장 중요하다고 생각합니다. 일의 마무리와 과정이 디테일해야 결과가 만족스럽게 나온다고 생각합니다.

세상은 늘 그렇지만 그렇게 디테일하지 않고 머리를 믿는 사람들이 많습니다. 업무 일지와 회의록조차 작성을 안하는 회사가 많습니다.

특정 회사의 예를 들면 그렇겠지만, SK C&C쪽에서 업무를 진행할 때 몇가지 업무 일지 작성 테크닉을 배웠습니다.

주제 - 설명 - 작업 - 누가 - 언제까지 - 결과물 - 참조 사항

으로 표를 만들어 회의를 합니다.

결론이 명쾌합니다.

하나를 배웠습니다.

그 이후에 일의 진행과 업무 체크에 큰 도움이 되었습니다.

대기업의 생산성이 자본이 있어서 생기지만, 업무 프로세스와 디테일의 완성도 덕분에 생겨 났다는 점은 요즘들어 느낍니다. 대기업이 왜 회사 연수, 교육 등에 많은 재원과 시간을 투입하는지는 자명합니다.

요즘 업무 일지와 회의록 덕분에 미수 3000만원짜리를 처리할 기본적인 자료가 있습니다. 우리의 '갑'은 제대로된 회의록이나 업무 일지가 있는지 조차 의심스럽습니다. '갑'의 직원이 진행한 일에 대해서 '을'에게 물어보고 있는 형편입니다. 그것도 반년도 되지 않은 일로 말이지요.

회의록은 업무 분쟁이 발생했을 때 그 '을'이 대응할 수 있는 거의 유일한 문서입니다. 문제는 슈퍼 '갑'의 경우 회의록 자체를 안만드는 경향이 있습니다. 그래서 업무 일지라도 죽어라 씁니다. 저는...

가장 무서운 일 중 하나가 '갑'이 욕심 많은 바보일 경우입니다. 이만 저만한 골치가 아닐 수 없을 것입니다.

회사를 하면서 저희 회사와 합병하겠다는 사람, 회사들이 많았습니다. 1년에 한 두 번 그런 제안을 받습니다.

주고 받는 것이 동일하면 모든 일이 문제가 없고 시너지가 나면 더 좋습니다.

하지만, 제가 들은 가장 최악의 합병 이야기는 다음과 같습니다.

우리 '갑' - 1년 동안 매출이 천만원이 안됨, 자본 잠식, -5억, 4억 자본금 회사

'을' - 1년간 흑자 약간, 1억 자본금 회사, 매출이 발생하는 판매 소프트웨어 5개 소유

주식 비율대로 합병하자더군요. 합병하면 '을'이 원래 가지고 있었던 현금 보유 액으로 몇 달 비용 밖에 처리 안될 상황이였습니다. 더구나 매출을 늘려서 코스탁을 가자더군요.....

코스탁은 저도 가봤기 때문에 별 메리트가 없습니다만, 코스탁을 가려면 얼마나 매출이 있어야하는지를 아는 저한테는 웃긴 일이였습니다.

외주처 중에서 해외의 회사 중 저 위의 표에 5개 정도가 걸치던 개발사가 있었습니다. 사장이 코스프레를 입고 다니고 동일 타이틀 하나만 가지고 울궈 먹으려고 하더니 결국은 소멸하더군요..

이리저리 일하다 보니 얼마전에 거래처 명함을 정리해 보았습니다.

2000장 정도되던데...

3년 이상 살아 남은 기업은 정말 대단한 기업이 되어 있더군요..

게임 회사의 경우 2년

SI나 솔루션 회사의 경우 3년

평균 수명을 가지고 있더군요. 명함에 있는 많은 회사들이 없어지거나 어둠 속으로 사라졌습니다.

엄청난 기술을 가진 회사도 있었지만, 연구 개발만 몇년 하다가 망한 회사도 있었고, 잘 나가던 개발자 출신 사장님께서 회사를 차리니까 순간 "갑"이 되었다는 착각을 하시다가 개발자 시절에 잘 정리하던 회의록, 업무 일지 조차 작성 안하시다가 개발진들에게 뒤통수 맞은 경우도 봤습니다.

편집광적으로 디테일과 업무 체크에 강박이시던 개발자 출신 사장님은 합병되어 지금 N 사 모바일 자회사에서 근무하십니다. 엄청난 대우를 받으시구요...

차이는 분명 있습니다.

그것은 아주 세밀한 차이지요.. 하지만 몇년이 지나면 큰 차이가 되는 디테일입니다.

오늘 개발자에게 실망하고 외주사에게 실망하다가 주저리주저리 썼네요

testcode~
Lyn [tohnokanna]   2008-09-04 07:07 X
3년 내에 대부분의 회사가 망하는건가요 =_ㅜ
GomSun2 [vhrvnd723]   2008-09-04 09:12 X
좋은글 잘 읽었습니다.
와이군 [yypbd]   2008-09-04 09:40 X
좋은 정보라고 해야할까요.
잘 봤습니다~

장성호 [nasilso]   2008-09-04 10:07 X
찔리는 부분이 좀 있네요...
무심객 [mrtery]   2008-09-04 10:20 X
1, 2, 8, 10번 정도만 수긍이 가는군요.

나머지는 현실은 배제한 내용이라고 보여집니다.

3번 같은 경우는 좀 문제가 있습니다만

4번 내용은 개발자가 오히려 피해자가 아니던가요?

5번은 대부분의 개발자들은 잘 알고 잘 구분합니다. 그걸 구분 못하는건 윗선이죠.

6번은 회사에 따라서 문제가 될수도 있겠습니다만 저의 경우는 팀장이나 사장에게

계속적으로 반론 펼치다가 어떻게 되는지를 수도없이 봐왔습니다.(상상에 맡기겠습니다)

7번은 이게 정말로 개발자의 잘못이라고 생각하시는지요?

9번같은 경우는 반론의 여지도 있겠습니다만 생각은 있지만 6번 내용과 결부되어서

심각한 문제가 있는게 아니라면 그냥 시키는데로 하는게 편한 경우가 많으니 그런거라고

생각합니다.

본문이 틀렸다고 생각하지는 않습니다. 아니 오히려 구구절절 맞는 글이죠.

하지만 앞뒤 고려없이 개발자들은 기본적으로 저래야한다는건 아니다 싶습니다.

+ -

관련 글 리스트
15018 [잡담] 디테일의 차이가 결과의 차이를 만든다. 김호광 3226 2008/09/04
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.