학교에서나 회사에서나 피할 수 없는 것 중 하나가 ‘팀 프로젝트’입니다. 그런데 왜죠? 왜 꼭 자신이 속한 팀원들은 완벽하게 ‘열성’ 인자로 구성된 것일까요. 업무 능력이 안 좋은 사람, 비협조적인 사람, 협조는 잘하나 일 처리 속도가 느린 사람, 실체 없는 말만 많이 늘어놓는 사람 등 매번 이런 동료들과 팀 프로젝트를 진행하려니 억울하기도 합니다.
이럴 땐, 누구나 한 번쯤 두뇌 명석한 ‘인재’만 모아놓은 드림팀을 꿈꿉니다. 그런데 과연, ‘우성’ 인자로 구성된 똑똑한 인재만 모아놓은 팀이 성과 측면에서도 우월할까요?
살다 보면, 옛말 틀린 거 하나 없다고 느낄 때가 많습니다. 사공이 많으면 배가 산으로 가듯이, 자신만의 인사이트로 꽉 찬 명석한 두뇌들이 모이면 의견이 좁혀지기 쉽지 않습니다.
산으로 가는 건 아닐 거야…;
학교와 회사 생활에서 익힌 경험, 각종 ‘리더십’과 ‘팔로어십’에 관한 책을 통해 얻은 개인적인 철학을 살짝 공개할게요. 그간 팀 워크가 안 좋았던 이유, 팀 프로젝트 시 생겼던 불만 사항을 꼼꼼히 생각해 보니, 이 정도만 지켜도 좋은 팀워크가 완성되더라고요. 제가 알려드리는 방법의 비밀은 대부분은 배려와 책임감에 있답니다. 좋은 팀워크, 배려에서 시작합니다.
– 구성원이 맡은 각각의 역할을 인정해줘라. 그리고 공개적으로 칭찬해라
– 논리 없는 비판은 비난일 뿐이다. 비판을 하려거든 건설적인 비판을 하라
– 달리기에서 1등을 못한 이유는 다리 때문이 아니다. 실패할 경우, 누군가에게 책임을 전가하지 마라.
– 구성원과의 약속을 지켜라. 개인 사정은 나만 있는 것이 아니다.
– 팀 구성원의 이야기를 들어라, 들어라 또 들어라. 그리고 기억해라
– 업무만 논하는 만남은 그만! 만남 자체를 즐겨라
빨리 가려면 혼자 가고, 멀리 가려면 같이 가라.외나무가 되려거든 혼자서고, 푸른 숲이 되려거든 함께서라.– 아프리카 속담
'프로그래밍 > ETC...' 카테고리의 다른 글
코딩 테스트 연습할 곳 (0) | 2018.01.27 |
---|---|
GPL·AGPL·MPL…한눈에 보는 오픈소스SW 라이선스 (0) | 2018.01.21 |
조직, 프로젝트 구성원의 역할 (0) | 2018.01.07 |
[ 개발자 업무 파악 ] SI와 SM의 차이와 하루일과 (0) | 2018.01.03 |
[ 개발자 업무 파악 ] Front-end 개발자와 Back-end 개발자 (0) | 2018.01.03 |