천객만래 [千客萬來] (It has an interminable succession of visitors)
성공학칼럼 - 카리스마 5가지 조건



카리스마? 이 5가지 조건만 갖춰라~  

[성공학칼럼]


성공으로 가는 필수 요건 중의 하나인 카리스마. 누구나 카리스마를 가질 수 있다. 지루한 일상을 초특급 다이너마이트로 만들어줄 5가지 열쇠만 있다면.

1. 절대적인 자신감
위험을 무릅쓰고, 기회를 잡아 새로운 일을 시도해보자. 종종 실패와 실수를 저지를 수 있다는 사실을 받아들이자.

실패할지 모른다는 생각에서 성공을 위한 시도를 하지 못하면, 결국 남는 것은 실패뿐이다. 실수를 하고, 그것을 통해 무엇인가를 배웠을 때, 그것으로 좌절하는 일은 없도록 해야 한다.

카리스마가 강한 사람들은 성공을 이루는 과정에서 실패하고, 실수를 저지른다.


2. 미래에 대한 비전
자신의 부음 기사를 써보자. 내가 죽은 후에 사람들이 어떻게 말해주기를 바라는가? 인생의 종착역에서 자신이 무엇을 성취하기를 바라는지 알고 있다면, 살면서 자신이 어떤 사람이 되어야 하는지를 이미 잘 터득하고 있는 것이다.

자신의 미래를 상상하는 것은 목표를 달성하는 데 큰 도움이 된다. 자신이 달성하고자 하는 목표가 무엇이든, 그것을 성취하는 내 모습을 상상해보자.

3. 남다른 커뮤니케이션 능력
누군가와 대화를 나눌 때는 상대방의 말에 귀를 기울이고 있으며, 그들의 생각과 느낌을 존중하고 있음을 보여주자. 또한 직관을 살려보자. 다른 사람들이 무엇을 원하고, 필요로 하는지 감지하기 위해 노력하자.

사람들에게 관심을 집중시키고, 자신의 본능적인 직감에 마음을 열고 있으면, 말로 표현되지 않는 그들의 요구에 반응하는 요령을 키울 수 있게 된다. 또한 유머 감각을 잃지 않아야 한다. 진정한 카리스마는 뛰어난 유머 감각을 요구한다.

4. 자신만의 스타일
옷을 고를 때는 신중하자. 옷은 자신의 독특한 개성을 반영하고 있어야 한다. 동시에 어떤 상황에서도 편안함을 느낄 수 있어야 한다.

나만의 '진정한' 스타일을 찾아낼 때까지 옷, 메이크업, 헤어 스타일을 여러 가지로 실험해 보도록 하자. 확신이 들 때까지 새로운 것을 계속 시도해보도록.

5. 창의성
내가 하는 모든 일에 열정을 쏟자. 카리스마가 강한 사람들은 어떤 일도 건성으로 하지 않는다. 그들은 하겠다고 마음먹은 모든 일에 150%의 에너지를 쏟는다.

칭찬과 격려로써 사람들을 고무시켜 내가 진행하는 프로젝트, 인생과 비전에 참여하고 싶다는 생각이 들게 만들자. 그들에게 도움이 필요하면 언제든 달려가 도움을 줄 수 있어야 한다.

인생의 특정 영역에서 정열을 느낄 수 없다면, 변화를 시도할 필요가 있다. 그것은 바라보는 시각을 새롭게 하는 것을 의미하는 것일 수 있다. 항상 변화하고 성장할 수 있는 방법들을 모색해보자.



Posted by SB패밀리

[경영/리더십] 부인의 바람기를 가장 늦게 아는 사람은




부인의 바람기를 가장 늦게 아는 사람은
[사람&경영] 권위주의는 커뮤니케이션을 방해한다

출처: 한근태 한스컨설팅 대표 | 06/05/10
한 동안 비행기 사고가 잦았던 때가 있었다. 비행기의 노후, 기상의 악화, 업무 과다로 인한 피곤함 등등 여러 가지 것들이 원인으로 제기되었다.

그 중에서도 기장과 부기장 사이의 커뮤니케이션 부재가 큰 원인으로 꼽혔다. 기장과 부기장은 상호 보완을 하는 동시에 상호 견제를 하는 역할이다.

한 사람이 사고 시에 다른 한 사람이 그 일을 대행하기 때문에 같은 식사를 하지 못하게까지 한다. 또 한 사람이 무리한 비행을 하는 것을 다른 사람이 견제하는 역할도 한다.

하지만 두 사람 사이가 상하관계로 정의되면 할 말을 제대로 못하고 독주하면서 위험이 높아진다.

그런데 사관학교 선후배 사이가 많은 현실에서 이는 말처럼 쉬운 일이 아니었다. 뻔히 기장이 무리하고 있다는 사실을 느끼지만 후배인 부기장은 감히 얘기를 못 꺼냈고 이것이 사고로 연결되었다는 것이다.

부인이 바람 핀 사실을 가장 늦게 아는 사람이 누구라고 생각하는가. 바로 남편이다. 회사의 고질적인 문제점을 제일 모르는 사람은 누구인가. 바로 사장이다. 조직의 정점에 있는 이들이 가장 늦게 정보를 안다는 사실은 아이러니하다. 이들의 잘못일수도 있지만 이들이 가진 위치와 권위가 정보 단절을 만들기 때문이다. 그런 의미에서 권위주의는 커뮤니케이션과 상극이다.

카리스마 넘치는 리더는 상대를 제압하는 카리스마의 대가로 커뮤니케이션 단절을 경험해야 한다. 자신감 넘치는 목소리, 뻣뻣한 어깨, 상대를 기죽게 하는 눈빛 앞에서 많은 사람들은 작아지는 자신을 발견한다. 당연히 할 얘기를 못하고, 해야 할 말도 못한다.

그저 상대가 원하는 말이 무언지, 상대가 싫어할 말이 무언지를 파악하여 가능한 심기를 건드리지 않고 이야기 하는 것을 목표로 한다. 당연히 솔직함은 없다. 사실을 사실대로 이야기하기는 더욱 쉽지 않다. 이는 집안에서도 마찬가지이다. 집안에서 파워가 강한 가장일수록 모든 정보에서 제외된다.

무게를 잡고 늘 가족을 야단치고 호통치면서 통제하는 것을 업으로 하는 가장은 그 정도가 더욱 심하다. 그런 집안에는 두 종류의 커뮤니케이션 통로가 존재한다. 가장이 있을 때와 없을 때가 그것이다. 가장이 있을 때는 별로 이야기를 하지 않고 하더라도 의례적인 이야기들이 오고 간다.

하지만 가장이 없을 때는 솔직한 얘기들이 오고 간다. 마음 속 이야기도 나오고, 실수한 얘기와 고민거리도 자연스럽게 나온다. 그렇기 때문에 모든 가족이 알고 있는 사실을 가장만이 모르는 경우가 흔하다.

리더십은 커뮤니케이션이다. 커뮤니케이션 없이 리더십 발휘는 불가능하다. 커뮤니케이션은 몸의 혈액순환 같은 것이다. 혈액이 돌지 않는데 건강할 수 없듯이 좋은 아이디어와 비전이 있어도 커뮤니케이션이 제대로 이루어지지 않으면 생산성 높은 조직을 만들 수 없다.

권위주의 냄새가 나는 조직이 있다. 임원전용 엘리베이터와 식당이 있는 곳이 그렇다. 서열 순으로 앉는 자리가 정해져 있는 조직도 그렇다. 사람들의 얼굴이 굳어 있고, 걸을 때 어깨가 굳어 있는 사람이 많은 곳도 그렇다. 이런 조직에서는 틀림없이 커뮤니케이션이 제대로 이루어지지 않는다.

권위주의가 판을 치고 관료주의가 무럭무럭 자라고 있는 조직이다. 윗사람과 아랫사람이 따로 놀고, 전체 이익보다는 부서이익을 중요시하고, 예전 방식을 고집하고 새로운 시도를 싫어하고, 아이디어를 내고 혁신적인 사람을 왕따 시키고, 가만히 앉아 불평하는 것을 낙으로 삼는 사람들이 득세하는 것이 관료주의이다.

관료주의와 권위주의는 커뮤니케이션을 막는 암적 존재이다. 이를 없애지 않고는 조직의 생산성을 올릴 수 없다. 장마철에 옷장 안에 쌓아둔 이불에서 나는 곰팡이 냄새를 없애기 위해서는 옷장 문을 열고, 이불을 털고, 햇빛에 말려야 한다. 조직에서 이런 역할을 하는 것이 바로 커뮤니케이션이다.

숨어있는 문제점, 움츠려 드는 사람을 밖으로 표출시켜야 한다. 활발한 커뮤니케이션이 일어나게끔 분위기를 만드는 것, 사람들에게 좋은 질문을 던져 생각을 자극하는 것, 이를 통해 피가 활발히 돌게 함으로서 관료주의의 텃밭을 제거하는 것이 리더가 해야 할 일이다. 커뮤니케이션은 리더십이다. (서울과학종합대학원 교수)


Posted by SB패밀리

[경영/리더십] 효과적 업무 지시와 커뮤니케이션




팀원들과 멀어져 가는 팀장
예스주식회사의 한방향 팀장은 최근 시장전략팀의 팀장으로 새로 부임했다. 그는 해외영업팀을 3년 동안 이끌면서 빠른 업무처리와 카리스마적 리더십으로 명성을 날렸다. 지난해 회사는 그를 경영자 승계관리 프로그램의 대상자로 선정했고, 새로운 업무 환경에서 그의 잠재력과 성과를 평가해 보기 위해 이번에 시장전략팀으로 인사 발령을 냈다.
 
시장전략팀은 한 팀장이 기존에 맡던 해외영업팀과는 팀 구성과 조직문화가 많이 달랐다. 해외영업팀은 현장 영업 경력이 있는 남자 직원이 대부분이었고, 상황 변화에 대한 일사불란한 조직적 대응이 장점이었다. 그러나 시장전략팀은 MBA를 마치고 스카우트된 외부 인력과 여성, 신입사원 등 다양한 팀원으로 구성돼 있었다. 팀원들이 회식 참여를 꺼리는 등 한 팀장이 생각하기에는 조직문화도 적극성이 부족했다.
 
새 팀을 맡은 지 얼마 되지 않은 어느 날, 직속상사인 홍길동 상무가 한 팀장을 불렀다.
 
“이번 정기 임원회의 때 논의해야 하니 지난번에 조사한 신제품의 시장 환경에 대해 추가적인 자료조사를 해 주게. 자네도 이번 신제품이 회사에 얼마나 중요한 것인지 내가 전에 자세하게 설명해 줘서 충분히 이해하고 있지? 이번에는 신제품이 경쟁사제품과 어떤 점에서 차별성을 가져야 할지를 특별히 고민해 보게.”
 
홍 상무와의 회의를 마친 한 팀장은 자리로 돌아오자마자 해외영업팀에서 하던 대로 팀원들에게 업무 지시를 했다.
 
“홍 상무님이 이번 신제품에 대한 시장조사를 다음 임원회의 때 발표한다고 하시니 여러분이 준비해서 이번 주 목요일까지 나한테 보고해 줘.”
 
그런데 팀원들의 표정이 예사롭지 않았다. 여기저기서 웅성웅성하는 소리도 들렸다. 선임 과장인 전우치 과장이 머리를 긁적이며 말했다.
 
“팀장님, 그 신제품에 대해서는 지난번에 보고를 했습니다. 팀장님 말씀은 조사를 처음부터 다시 하라는 것인가요, 특정한 부분을 보완하라는 것인가요?”
 
“상무님께서 차별화 얘기를 하시긴 했는데, 다시 보고하라는 말씀은 지난번 보고 내용이 충분하지 않았다는 뜻일 거야. 처음부터 다시 철저하게 조사해서 보고해 줘.”
 
목요일 오후 한 팀장은 홍 상무의 방을 찾았다. 그런데 보고 자료를 본 홍 상무의 표정이 일그러졌다.
 
“아니, 한 팀장. 지난번 보고 내용과 별로 다른 점이 없지 않나? 내가 이번에는 특히 경쟁사와의 차별성에 대해 신경을 쓰라고 한 것 같은데…. 다시 해 오도록 하게.”
 
한 팀장과 홍 상무의 미팅이 있는 날이면 팀원들이 모여 자기들끼리 한탄을 하는 경우가 잦아졌다.
 
“또 야근을 해야겠군. 도대체 팀장은 왜 만날 상무님이 지시하는 내용을 잘못 전달해서 우리를 이렇게 고생하게 하는 거야? 그리고 그 업무를 해야 하는 목적이나 업무 효과에 대해서는 한마디도 설명하지 않고 그냥 우리에게 일을 나눠 주기만 하니 대체 뭐가 어떻게 돌아가는지 알 수가 있어야지. 그래 놓고 ‘왜 말을 못 알아듣느냐, 짬밥이 아깝다’는 식으로 쪼아대기만 하면 어떻게 해?”
 
이런 불평불만이 늘면서 한 팀장과 팀원들 사이에는 대화가 끊기고 냉기류가 감돌기 시작했다. 한 팀장이 시장전략팀을 맡은 것을 후회하고 있던 어느 날 인사팀장이 미팅하자는 연락을 해 왔다. ‘무슨 일 때문이지?’ 인사팀으로 가는 그의 마음은 복잡하기만 했다.
 
업무 지시를 올바로 하는 방법
인사팀 김노경 팀장이 “한 팀장님, 새로운 팀을 맡으면서 어려운 점이 많으시죠?”라고 먼저 인사를 건넸다. 한 팀장은 한숨을 내쉬며 “그렇지 않아도 요즘 생각이 많은데, 어디에 논의할 곳도 없고…. 그런데 무슨 일로 저를 보자고 하신 거죠?”라고 말했다.
 
“다름이 아니라, 매년 실시하고 있는 직원성과 몰입도 조사에서 시장전략팀 팀원들의 몰입도 수준이 지난해보다 훨씬 낮게 나왔습니다. 그 원인을 파악하기 위해 잠시 한 팀장님과의 면담을 요청했습니다.”

출처 : [타워스페린의 HR스쿨] 18호(2008.10.01)
Posted by SB패밀리

직장 내 커뮤니케이션, 안 되는 이유 1위는?

출처: 잡코리아


얼마 전 잡코리아에서 직장인을 대상으로 직장 내 커뮤니케이션에 대한 설문조사를 실시했습니다.

60.9%의 직장인이 직장 내 직원들 간의 소통이 원활하지 않다고 응답했는데요많은 직장인들은 왜 직장 내 소통이 원할하지 않다고 생각했을까요?

직장 내 소통이 원할하지 않은 이유로 절반에 가까운 직장인들이 수직적인 조직문화(48.1%)를 1위로 꼽았습니다그 외에 서로의 의견을 잘 이야기 하지 않아서(27.0%), 팀 내 혹인 사내 이슈가 잘 공유되지 않아서(14.1%) 등의 항목이 뒤를 이었는데요.

기업별 형태로 살펴보면 중소기업 직장인중 직장 내에서 소통이 잘 되지 않는다고 답한 응답자가63.1% 비율로 가장 많았으며대기업(60.5%), 공기업(51.9%), 외국계기업(47.1%) 순으로 나타났습니다‘직장 내 커뮤니케이션에 어려움을 겪은 적이 있습니까’라는 질문에는 직장인 10명 중 9명에 달하는 92.1%가 ‘그렇다’고 답했는데요.

직장 내 커뮤니케이션이 가장 어려웠던 순간에 대해서는 ‘상사와 의견이 다를 때’가 60.4%로 가장 높았고다음으로 ‘다른 팀과 업무를 진행할 때’가 16.1%로 그 뒤를 이었습니다.이처럼 많은 직장인들이 직장 내 커뮤니케이션이 원활하지 않다는 것을 인지하고 있음에도 ‘직장에서 본인의 의견을 잘 말하는 편인가’라는 질문에 56.9%가 ‘그렇지 않다’고 답했는데요.

직장 내에서 자신의 의견을 말하지 않는 이유는 ‘의견을 얘기해도 들어주지 않을 거란 생각때문에’가 28.9%로 가장 많았고이어 ‘수직적인 조직문화 때문에’(24.9%), ‘말실수를 하게 될까봐’(13.3%)등의 의견이 뒤를 따랐습니다.

 



Posted by SB패밀리
효과적 업무 지시와 커뮤니케이션

출처: http://www.dongabiz.com/PersonalCapacity/Leadership/article_content.php?atno=1306003801&chap_no=1&sdkey=15672042988


팀원들과 멀어져 가는 팀장

예스주식회사의 한방향 팀장은 최근 시장전략팀의 팀장으로 새로 부임했다. 그는 해외영업팀을 3년 동안 이끌면서 빠른 업무처리와 카리스마적 리더십으로 명성을 날렸다. 지난해 회사는 그를 경영자 승계관리 프로그램의 대상자로 선정했고, 새로운 업무 환경에서 그의 잠재력과 성과를 평가해 보기 위해 이번에 시장전략팀으로 인사 발령을 냈다.
 
시장전략팀은 한 팀장이 기존에 맡던 해외영업팀과는 팀 구성과 조직문화가 많이 달랐다. 해외영업팀은 현장 영업 경력이 있는 남자 직원이 대부분이었고, 상황 변화에 대한 일사불란한 조직적 대응이 장점이었다. 그러나 시장전략팀은 MBA를 마치고 스카우트된 외부 인력과 여성, 신입사원 등 다양한 팀원으로 구성돼 있었다. 팀원들이 회식 참여를 꺼리는 등 한 팀장이 생각하기에는 조직문화도 적극성이 부족했다.
 
새 팀을 맡은 지 얼마 되지 않은 어느 날, 직속상사인 홍길동 상무가 한 팀장을 불렀다.
 
“이번 정기 임원회의 때 논의해야 하니 지난번에 조사한 신제품의 시장 환경에 대해 추가적인 자료조사를 해 주게. 자네도 이번 신제품이 회사에 얼마나 중요한 것인지 내가 전에 자세하게 설명해 줘서 충분히 이해하고 있지? 이번에는 신제품이 경쟁사제품과 어떤 점에서 차별성을 가져야 할지를 특별히 고민해 보게.”
 
홍 상무와의 회의를 마친 한 팀장은 자리로 돌아오자마자 해외영업팀에서 하던 대로 팀원들에게 업무 지시를 했다.
 
“홍 상무님이 이번 신제품에 대한 시장조사를 다음 임원회의 때 발표한다고 하시니 여러분이 준비해서 이번 주 목요일까지 나한테 보고해 줘.” 
 
그런데 팀원들의 표정이 예사롭지 않았다. 여기저기서 웅성웅성하는 소리도 들렸다. 선임 과장인 전우치 과장이 머리를 긁적이며 말했다.
 
“팀장님, 그 신제품에 대해서는 지난번에 보고를 했습니다. 팀장님 말씀은 조사를 처음부터 다시 하라는 것인가요, 특정한 부분을 보완하라는 것인가요?”
 
“상무님께서 차별화 얘기를 하시긴 했는데, 다시 보고하라는 말씀은 지난번 보고 내용이 충분하지 않았다는 뜻일 거야. 처음부터 다시 철저하게 조사해서 보고해 줘.”
 
목요일 오후 한 팀장은 홍 상무의 방을 찾았다. 그런데 보고 자료를 본 홍 상무의 표정이 일그러졌다.
 
“아니, 한 팀장. 지난번 보고 내용과 별로 다른 점이 없지 않나? 내가 이번에는 특히 경쟁사와의 차별성에 대해 신경을 쓰라고 한 것 같은데…. 다시 해 오도록 하게.” 
 
한 팀장과 홍 상무의 미팅이 있는 날이면 팀원들이 모여 자기들끼리 한탄을 하는 경우가 잦아졌다.
 
“또 야근을 해야겠군. 도대체 팀장은 왜 만날 상무님이 지시하는 내용을 잘못 전달해서 우리를 이렇게 고생하게 하는 거야? 그리고 그 업무를 해야 하는 목적이나 업무 효과에 대해서는 한마디도 설명하지 않고 그냥 우리에게 일을 나눠 주기만 하니 대체 뭐가 어떻게 돌아가는지 알 수가 있어야지. 그래 놓고 ‘왜 말을 못 알아듣느냐, 짬밥이 아깝다’는 식으로 쪼아대기만 하면 어떻게 해?”
 
이런 불평불만이 늘면서 한 팀장과 팀원들 사이에는 대화가 끊기고 냉기류가 감돌기 시작했다. 한 팀장이 시장전략팀을 맡은 것을 후회하고 있던 어느 날 인사팀장이 미팅하자는 연락을 해 왔다. ‘무슨 일 때문이지?’ 인사팀으로 가는 그의 마음은 복잡하기만 했다.
 
업무 지시를 올바로 하는 방법
인사팀 김노경 팀장이 “한 팀장님, 새로운 팀을 맡으면서 어려운 점이 많으시죠?”라고 먼저 인사를 건넸다. 한 팀장은 한숨을 내쉬며 “그렇지 않아도 요즘 생각이 많은데, 어디에 논의할 곳도 없고…. 그런데 무슨 일로 저를 보자고 하신 거죠?”라고 말했다.
 
“다름이 아니라, 매년 실시하고 있는 직원성과 몰입도 조사에서 시장전략팀 팀원들의 몰입도 수준이 지난해보다 훨씬 낮게 나왔습니다. 그 원인을 파악하기 위해 잠시 한 팀장님과의 면담을 요청했습니다.”



한 팀장의 얼굴이 화끈 달아올랐다. 그는 지금까지의 상황을 김 팀장에게 설명했다.
 
“물론 팀원들에게 같은 작업을 여러 번 하게 한 것은 저도 미안하게 생각합니다. 지시 과정에서 오해도 있었던 것 같고요. 하지만 팀장이 시키면 일단 그대로 실행해 보는 것이 팀원의 의무 아닌가요? 그전 팀원들은 아무런 군소리 없이 제 지시를 잘만 따랐습니다. 그런데 이번 팀원들은 제가 생각하는 대로 따라주지 않아서 저도 답답하네요.” 
 
“한 팀장님은 팀원들이 왜 자신의 지시를 안 따라준다고 생각하시는가요? 이런 때는 보통 팀원들이 지시의 합리성에 의문을 가지는 경우가 많은데….”
 
“저도 나름대로 합리적으로 지시했습니다. 팀원별로 할 업무를 세분화해서 지시하고 일정을 체크하는데도 내가 원하는 결과가 안 나오더라고요. 제 생각에 지금의 팀원들은 적극성이 좀 부족한 것 같습니다. 업무 지시 후에는 꼭 ‘왜 이 업무를 해야 하느냐’ ‘어느 정도까지 알아봐야 하느냐’ ‘이 일을 하면 우리 회사에 어떤 효과가 있느냐’를 물어보더군요. 그렇잖아도 바쁜 시간에 팀장이 그런 것을 일일이 설명해 줄 수도 없을뿐더러 웬만한 것은 자기가 알아봐야 하는 것 아닌가요?” 
 
“음…. 이 문제는 한 팀장님에게만 해당하는 것이 아닙니다. 우리 회사에서도 많은 팀장이 비슷한 고민을 얘기하시더군요. 중간관리자는 경영진의 업무지시 사항을 부하 직원들에게 전달해 그들이 업무를 수행하도록 하는 사람입니다. 따라서 우선 중간관리자 자신이 지시 내용을 명확히 파악해 핵심을 짚어내고, 그것을 부하 직원들에게 명확히 전달해야 합니다. 이와 관련해 많은 분이 구두 커뮤니케이션에만 의존하다가 실수합니다. 이를 보완하기 위해서는 경영진의 지시 사항을 노트에 간략히 요약 정리해 e메일로 전달하거나, 자신이 직접 재확인하는 것이 좋습니다.
 
또 한 팀장님처럼 배경설명 없이 세분화된 지시사항을 전달하면 실무자가 방향을 못 잡고 헤매기 쉽습니다. 따라서 왜 그 업무를 해야 하는지, 어떤 자원을 사용할 수 있는지, 업무를 수행함으로써 어떤 효과가 있는지 등을 전체적 관점에서 설명하는 것이 필요합니다. 다시 말해 전사적으로 구성원들이 한 방향으로 역량을 집중하도록 비전과 전략이 필요하듯이 각 팀원이 업무를 수행하는데 있어서도 큰 그림 또는 방향성을 보여 주는 것이 중요합니다. 간략한 설명 몇 마디만 덧붙이면 업무가 엉뚱한 방향으로 진행되어 생기는 낭비를 줄일 수 있습니다. 특히 이 과정에서 팀장님의 의견만 말씀하지 마시고 팀원들의 의견도 물어보셔서 팀원들이 생각을 발전시킬 수 있는 기회를 줄 수 있으면 성과 향상과 동기부여 차원에서 더욱 좋을 것입니다.”(표1) 



한 팀장은 이런 이야기를 들으면서 자신이 업무 지시를 할 때마다 팀원들이 의아해하며 무슨 일을 해야 할지 모른다는 표정을 지은 것을 떠올렸다. 그는 그때마다 팀원들의 반응을 무시하며 ‘역량이 있으면 알아서들 하겠지’라고 생각했다.
 
‘앞으로 내 업무 지시 전달 방식을 좀 바꿔야겠군.’ 한 팀장은 이러한 생각을 곧 실천으로 옮겨 사내 커뮤니케이션 관련 교육 프로그램에 등록했다
 
효과적인 업무 커뮤니케이션이란?
교육은 예상 외로 알차고 도움되는 내용으로 가득했다. 특히 한 팀장의 뇌리에 남은 것은 ‘효과적인 업무 커뮤니케이션은 일회적인 노력이 아니라 커뮤니케이션 전략 개발, 이에 따른 교육과 피드백, 강화 및 개선이라는 단계를 거치는 일련의 지속적이고 주기적인 과정’이란 점이었다.(그림1) 



이것은 특히 업무 처리가 서툴고, 자신의 지시가 잘 통하지 않는 부하직원과의 커뮤니케이션 문제 해결에 큰 도움이 될 것 같았다. 한 팀장은 우선 안확신 대리에게 새로 배운 것을 적용해 보기로 했다. 안 대리는 한 팀장의 지시에 대해 항상 “잘 되지 않을 것 같은데요”라고 부정적인 태도를 보일 뿐 아니라 맡은 일을 제때 처리하지도 못해 한 팀장에게 스트레스를 주고 있었다.
 
효율적인 업무 지시 방법을 고민하던 한 팀장은 우선 안 대리에게 성공 사례를 제시해 업무에 대한 몰입도를 높이고, 수시로 피드백을 제공해 업무 기한을 맞추도록 하기로 했다.
 
“안 대리, 내가 이번에 새로운 시장 분석 기법을 도입해 우리 팀의 분석 역량을 올려 보려고 해. 자네가 다음주 화요일까지 그 기법에 대해 구체적으로 조사해 볼 수 있겠지?”



아니나 다를까 안 대리 반응은 “팀장님, 그 기법이 과연 효과가 있을까요?”였다.
 
한 팀장은 차분하게 “그 분석 기법은 글로벌 회사에서 모두 다 사용해서 어느 정도 검증이 된 것이라 우리 회사도 도입하려고 하는 거야. 왜 그 분석 기법을 사용하면 안 되는지에 대해 자네가 생각하는 특별한 이유라도 있나?”라고 물었다.
 
“아니, 특별히 그런 것은 없습니다만….”
 
“그럼 선진 기업들의 이용 성공 사례와 구체적인 활용 방법에 대해 다음주 화요일까지 조사하고, 그 다음에 구체적인 도입 시기를 정하면 되겠군.”
 
언제나 일정을 맞추지 못하는 안 대리의 습관을 알고 있는 한 팀장은 업무를 지시한 뒤 수시로 e메일을 통해 업무진행 상황을 체크하고, 항목별로 업무를 세분화해 다시 지시했다. 자신이 알고 있는 자료와 주요 접촉 포인트(contact point)도 제공했다. 업무 진행상 도움이 필요할 때는 e메일, 커피타임 등 공식·비공식 미팅을 통해 안 대리가 스스로 역량을 향상시킬 수 있도록 지원했다. 
 
그리고 우수한 업무 결과에 대해서는 긍정적인 피드백을 통해 안 대리가 더욱 분발할 수 있도록 했다. “안 대리, 이번에 조사한 내용을 상무님이 보시더니 아주 만족해 하셨어. 다음에도 기대하겠어!”
 
이제 모든 것이 해결된 것인가?
김 팀장의 조언을 참고하고 교육에서 배운 커뮤니케이션 전략을 실천하다 보니 한 팀장은 업무와 관련해 예전만큼 스트레스를 받지 않게 됐다. 부하 직원들 역시 업무에 대한 부담감이 줄고 자신감도 향상되는 듯 보였다. 한 팀장은 뿌듯한 느낌이 들었다. 그러나 이런 기쁨도 잠시, 뭔가가 부족한 느낌이 들기 시작했다. 대표적으로 안 대리의 경우 한 팀장이 지시하는 업무는 이제 잘 따라오긴 하는데 언제까지 그렇게 뒤를 봐줘야 할지 막막한 느낌이었다. 
 
또다시 고민에 빠진 한 팀장은 지난번에 만난 커뮤니케이션 교육 담당자에게 연락을 해 조언을 구했다. 
 
“이제 팀원들과의 커뮤니케이션도 어느 정도 원활해지고, 업무 성과도 나아지고 있는데 아직도 부족한 것이 있네요. 제가 무엇을 좀 더 배워야 할까요?”


 
“이제 한 팀장님께서는 커뮤니케이터로서의 역할을 한 단계 발전시켜야 할 듯 합니다. 다시 말하면 단순히 업무 지시 사항에 대한 정보 공유나 행동에 대한 피드백을 주는 단계에서 부하 직원들이 새로운 행동을 모색하도록 하는 코칭과 멘토링을 하는 단계로 변화하여야 된다는 말입니다.”(그림2)
 
‘쉬우면서도 어려운 이야기군.’ 한 팀장은 이 새로운 역할을 통해 팀원들의 성과를 향상시킬 전략을 짜기 위해 팀원들과의 미팅을 소집하기로 했다. 그는 이번에는 팀원들의 의견을 좀 더 많이 수렴해 더욱 건설적인 계획을 세워 보겠다고 다짐했다.
 
필자는 세계 최고의 글로벌 인사관리(HR) 컨설팅펌인 타워스페린 서울오피스와 글로벌 경영을 1996년부터 맡고 있다. 타워스페린 130년 역사상 아시아에서 두 번째, 한국에서는 최초로 2000년 글로벌 사장(global managing principal)에 올랐다. 풍부한 컨설팅 경험으로 클라이언트 기업들로부터 높은 평가를 받고 있는 HR 전문가이다.


-----------------------
팀장이나 소장이나 장의 역할로서 단순히 업무지시만이 아니 팀원들의 업무와 개인의 개성과 역량을 이해하고 활용하기가 글로배운 것처럼 쉽지는 않지만 조직마다 더 좋은 방향으로 나아가야할 숙제이다.
나도 실무보다는 관리자로서의 역할에 좀 더 비중을 실어야 할 때가 왔다.
 
Posted by SB패밀리

팀원들과 멀어져 가는 팀장
예스주식회사의 한방향 팀장은 최근 시장전략팀의 팀장으로 새로 부임했다. 그는 해외영업팀을 3년 동안 이끌면서 빠른 업무처리와 카리스마적 리더십으로 명성을 날렸다. 지난해 회사는 그를 경영자 승계관리 프로그램의 대상자로 선정했고, 새로운 업무 환경에서 그의 잠재력과 성과를 평가해 보기 위해 이번에 시장전략팀으로 인사 발령을 냈다.
 
시장전략팀은 한 팀장이 기존에 맡던 해외영업팀과는 팀 구성과 조직문화가 많이 달랐다. 해외영업팀은 현장 영업 경력이 있는 남자 직원이 대부분이었고, 상황 변화에 대한 일사불란한 조직적 대응이 장점이었다. 그러나 시장전략팀은 MBA를 마치고 스카우트된 외부 인력과 여성, 신입사원 등 다양한 팀원으로 구성돼 있었다. 팀원들이 회식 참여를 꺼리는 등 한 팀장이 생각하기에는 조직문화도 적극성이 부족했다.
 
새 팀을 맡은 지 얼마 되지 않은 어느 날, 직속상사인 홍길동 상무가 한 팀장을 불렀다.
 
“이번 정기 임원회의 때 논의해야 하니 지난번에 조사한 신제품의 시장 환경에 대해 추가적인 자료조사를 해 주게. 자네도 이번 신제품이 회사에 얼마나 중요한 것인지 내가 전에 자세하게 설명해 줘서 충분히 이해하고 있지? 이번에는 신제품이 경쟁사제품과 어떤 점에서 차별성을 가져야 할지를 특별히 고민해 보게.”
 
홍 상무와의 회의를 마친 한 팀장은 자리로 돌아오자마자 해외영업팀에서 하던 대로 팀원들에게 업무 지시를 했다.
 
“홍 상무님이 이번 신제품에 대한 시장조사를 다음 임원회의 때 발표한다고 하시니 여러분이 준비해서 이번 주 목요일까지 나한테 보고해 줘.”
 
그런데 팀원들의 표정이 예사롭지 않았다. 여기저기서 웅성웅성하는 소리도 들렸다. 선임 과장인 전우치 과장이 머리를 긁적이며 말했다.
 
“팀장님, 그 신제품에 대해서는 지난번에 보고를 했습니다. 팀장님 말씀은 조사를 처음부터 다시 하라는 것인가요, 특정한 부분을 보완하라는 것인가요?”
 
“상무님께서 차별화 얘기를 하시긴 했는데, 다시 보고하라는 말씀은 지난번 보고 내용이 충분하지 않았다는 뜻일 거야. 처음부터 다시 철저하게 조사해서 보고해 줘.”
 
목요일 오후 한 팀장은 홍 상무의 방을 찾았다. 그런데 보고 자료를 본 홍 상무의 표정이 일그러졌다.
 
“아니, 한 팀장. 지난번 보고 내용과 별로 다른 점이 없지 않나? 내가 이번에는 특히 경쟁사와의 차별성에 대해 신경을 쓰라고 한 것 같은데…. 다시 해 오도록 하게.”
 
한 팀장과 홍 상무의 미팅이 있는 날이면 팀원들이 모여 자기들끼리 한탄을 하는 경우가 잦아졌다.
 
“또 야근을 해야겠군. 도대체 팀장은 왜 만날 상무님이 지시하는 내용을 잘못 전달해서 우리를 이렇게 고생하게 하는 거야? 그리고 그 업무를 해야 하는 목적이나 업무 효과에 대해서는 한마디도 설명하지 않고 그냥 우리에게 일을 나눠 주기만 하니 대체 뭐가 어떻게 돌아가는지 알 수가 있어야지. 그래 놓고 ‘왜 말을 못 알아듣느냐, 짬밥이 아깝다’는 식으로 쪼아대기만 하면 어떻게 해?”
 
이런 불평불만이 늘면서 한 팀장과 팀원들 사이에는 대화가 끊기고 냉기류가 감돌기 시작했다. 한 팀장이 시장전략팀을 맡은 것을 후회하고 있던 어느 날 인사팀장이 미팅하자는 연락을 해 왔다. ‘무슨 일 때문이지?’ 인사팀으로 가는 그의 마음은 복잡하기만 했다.
 
업무 지시를 올바로 하는 방법
인사팀 김노경 팀장이 “한 팀장님, 새로운 팀을 맡으면서 어려운 점이 많으시죠?”라고 먼저 인사를 건넸다. 한 팀장은 한숨을 내쉬며 “그렇지 않아도 요즘 생각이 많은데, 어디에 논의할 곳도 없고…. 그런데 무슨 일로 저를 보자고 하신 거죠?”라고 말했다.
 
“다름이 아니라, 매년 실시하고 있는 직원성과 몰입도 조사에서 시장전략팀 팀원들의 몰입도 수준이 지난해보다 훨씬 낮게 나왔습니다. 그 원인을 파악하기 위해 잠시 한 팀장님과의 면담을 요청했습니다.”

출처 : [타워스페린의 HR스쿨] 18호(2008.10.01)
Posted by SB패밀리

부인의 바람기를 가장 늦게 아는 사람은
[사람&경영] 권위주의는 커뮤니케이션을 방해한다

한근태 한스컨설팅 대표 | 06/05/10 13:02


한 동안 비행기 사고가 잦았던 때가 있었다. 비행기의 노후, 기상의 악화, 업무 과다로 인한 피곤함 등등 여러 가지 것들이 원인으로 제기되었다.

그 중에서도 기장과 부기장 사이의 커뮤니케이션 부재가 큰 원인으로 꼽혔다. 기장과 부기장은 상호 보완을 하는 동시에 상호 견제를 하는 역할이다.

한 사람이 사고 시에 다른 한 사람이 그 일을 대행하기 때문에 같은 식사를 하지 못하게까지 한다. 또 한 사람이 무리한 비행을 하는 것을 다른 사람이 견제하는 역할도 한다.

하지만 두 사람 사이가 상하관계로 정의되면 할 말을 제대로 못하고 독주하면서 위험이 높아진다.

그런데 사관학교 선후배 사이가 많은 현실에서 이는 말처럼 쉬운 일이 아니었다. 뻔히 기장이 무리하고 있다는 사실을 느끼지만 후배인 부기장은 감히 얘기를 못 꺼냈고 이것이 사고로 연결되었다는 것이다.

부인이 바람 핀 사실을 가장 늦게 아는 사람이 누구라고 생각하는가. 바로 남편이다. 회사의 고질적인 문제점을 제일 모르는 사람은 누구인가. 바로 사장이다. 조직의 정점에 있는 이들이 가장 늦게 정보를 안다는 사실은 아이러니하다. 이들의 잘못일수도 있지만 이들이 가진 위치와 권위가 정보 단절을 만들기 때문이다. 그런 의미에서 권위주의는 커뮤니케이션과 상극이다.

카리스마 넘치는 리더는 상대를 제압하는 카리스마의 대가로 커뮤니케이션 단절을 경험해야 한다. 자신감 넘치는 목소리, 뻣뻣한 어깨, 상대를 기죽게 하는 눈빛 앞에서 많은 사람들은 작아지는 자신을 발견한다. 당연히 할 얘기를 못하고, 해야 할 말도 못한다.

그저 상대가 원하는 말이 무언지, 상대가 싫어할 말이 무언지를 파악하여 가능한 심기를 건드리지 않고 이야기 하는 것을 목표로 한다. 당연히 솔직함은 없다. 사실을 사실대로 이야기하기는 더욱 쉽지 않다. 이는 집안에서도 마찬가지이다. 집안에서 파워가 강한 가장일수록 모든 정보에서 제외된다.

무게를 잡고 늘 가족을 야단치고 호통치면서 통제하는 것을 업으로 하는 가장은 그 정도가 더욱 심하다. 그런 집안에는 두 종류의 커뮤니케이션 통로가 존재한다. 가장이 있을 때와 없을 때가 그것이다. 가장이 있을 때는 별로 이야기를 하지 않고 하더라도 의례적인 이야기들이 오고 간다.

하지만 가장이 없을 때는 솔직한 얘기들이 오고 간다. 마음 속 이야기도 나오고, 실수한 얘기와 고민거리도 자연스럽게 나온다. 그렇기 때문에 모든 가족이 알고 있는 사실을 가장만이 모르는 경우가 흔하다.

리더십은 커뮤니케이션이다. 커뮤니케이션 없이 리더십 발휘는 불가능하다. 커뮤니케이션은 몸의 혈액순환 같은 것이다. 혈액이 돌지 않는데 건강할 수 없듯이 좋은 아이디어와 비전이 있어도 커뮤니케이션이 제대로 이루어지지 않으면 생산성 높은 조직을 만들 수 없다.

권위주의 냄새가 나는 조직이 있다. 임원전용 엘리베이터와 식당이 있는 곳이 그렇다. 서열 순으로 앉는 자리가 정해져 있는 조직도 그렇다. 사람들의 얼굴이 굳어 있고, 걸을 때 어깨가 굳어 있는 사람이 많은 곳도 그렇다. 이런 조직에서는 틀림없이 커뮤니케이션이 제대로 이루어지지 않는다.

권위주의가 판을 치고 관료주의가 무럭무럭 자라고 있는 조직이다. 윗사람과 아랫사람이 따로 놀고, 전체 이익보다는 부서이익을 중요시하고, 예전 방식을 고집하고 새로운 시도를 싫어하고, 아이디어를 내고 혁신적인 사람을 왕따 시키고, 가만히 앉아 불평하는 것을 낙으로 삼는 사람들이 득세하는 것이 관료주의이다.

관료주의와 권위주의는 커뮤니케이션을 막는 암적 존재이다. 이를 없애지 않고는 조직의 생산성을 올릴 수 없다. 장마철에 옷장 안에 쌓아둔 이불에서 나는 곰팡이 냄새를 없애기 위해서는 옷장 문을 열고, 이불을 털고, 햇빛에 말려야 한다. 조직에서 이런 역할을 하는 것이 바로 커뮤니케이션이다.

숨어있는 문제점, 움츠려 드는 사람을 밖으로 표출시켜야 한다. 활발한 커뮤니케이션이 일어나게끔 분위기를 만드는 것, 사람들에게 좋은 질문을 던져 생각을 자극하는 것, 이를 통해 피가 활발히 돌게 함으로서 관료주의의 텃밭을 제거하는 것이 리더가 해야 할 일이다. 커뮤니케이션은 리더십이다. (서울과학종합대학원 교수)
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패밀리