프로젝트를 진행하는데 가장 중요한 구성 요소로서 ‘팀'과 ‘팀원'이 있는데요.
우리는 프로젝트를 왜 혼자가 아니라, 팀원들과 함께, 팀이 되어 일하는 걸까요?
여기, Software Developmet: Why Teamwork Is Conductive to a Thriving Work Environment
(소프트웨어 개발: 팀 워크가 더 발전적인 업무 환경에 도움이 되는 이유)의 아티클을 한번 함께 볼까요?
In Software Development, Teams that Work Together Closely Over Extended Period Found to Be More Efficient.
소프트웨어 개발 업계에서는 오랜 기간동안 긴밀하게 협력하는 팀들이 훨씬 더 효율적인 것으로 나타났다.
팀으로써 ‘잘’ 일하는 것은 누구에게나 매우 중요한 능력이지만,
높은 수준의 기술을 효과적이고 효율적으로 활용해야하는 소프트웨어 개발자에게는 더더욱 중요합니다.
소프트웨어 개발자들이 그들 개인의 장점과 강점을 결합 했을 때 비로소 ‘혁신’이 일어납니다.
다양한 경험과 능력을 가진 개발자들이 협업하는 팀이 올바르게 나아가면, 셀 수 없이 많은 장점들이 생깁니다.
그 중 몇 가지 대표적인 장점을 소개합니다.
1) Increased Efficiency (효율성 향상)
: 팀은 기능을 갖춘 제품을 완성한다는 공동의 목표를 향해 함께 노력합니다. 협업의 궁극적인 목적은 공통의 문제를 해결하는 동시에 팀원 개개인이 맞닥뜨리는 문제 또한 효과적인 솔루션을 찾기 위해 협력한다는 점입니다.
2) Enhanced Creativity (창의성 향상)
: . 팀 동료들이 자신을 표현하는데 편안함을 느낄 때, 보다 효과적으로 새로운 아이디어, 개념, 프로세스의 도입으로 이어진다는 연구 결과가 있습니다. 이는 개인이 혼자서 작업 할 때는 떠오르지 않을 수 있는 최종적 아이디어나 결과에 혁신과 변화를 일으킬 수 있는 매우 중요한 요소 입니다.
3) Strengthened Innovation (강화된 혁신)
: 우리는 개인이 일할 때 보다 팀원과 ‘한 팀’으로 일할 때 훨씬 더 큰 시너지와 결과를 기대할 수 있습니다.
프로젝트를 진행하기 위해서는 프로젝트 전체를 이해하고, 이끌어 갈 수 있는 팀장 역할이 반드시 필요합니다.
팀장 선정 tip 아래의 항목들을 가지고 팀원분들과 이야기를 나눠보세요.
팀장은 리더십 + 프로젝트 이해도 + 커뮤니케이션 능력 다방면으로 능력이 있는 분이 하시는게 가장 좋습니다.
팀원들의 의견을 모두 들어보고, 필요한 부분과 불필요한 부분을 구분해서 팀을 이끌어 갈 줄 알아야 하며, 팀원들의 일정관리를 통해 프로젝트의 작업 진행을 이끌어야하며, 지속적으로 팀원들과 소통해 프로젝트의 문제점을 파악하고 있어야 하는 등 정말 많은 부분에 기여를 해야합니다.
이번에는 팀원들과 프로젝트에서 기본적으로 지켜야할 팀 규칙에 대해서 생각해보겠습니다.
어떻게 본다면 단순한 규칙으로 받아들일 수 있지만, 해당 팀의 분위기를 전반적으로 파악할 수 있습니다.
팀원들과 지킬 수 있는 범위 안에서의 규칙을 정하고 모두가 볼 수 있는 문서에 기록해서 주기적으로 보는 것이 매우 중요합니다.
단순히 회의시간, 휴식시간만 기록하는 것 보다 우리 팀만의 색다른 규칙도 있으면 좋은 팀 분위기를 보여줄 수 있을것 입니다. 여러분들만의 커스텀한 규칙을 만들어보세요.
규칙을 만들었다면, 당연히 프로젝트 기간동안 팀원들을 위해서 무조건 지켜야하는 부분입니다. 서로가 규칙 안에서 배려하면서 무사히 프로젝트를 완주하시기 바랍니다.
(메타버스만 블로깅)
ZEP 초심자 가이드 : https://docs-kr.zep.us/guide/beginner
엔트리코스, 페어 활동을 위해서 게더타운을 이용해 보신 분들이 계실 텐데요!
게더타운은 상시 접속이 가능하고, 팀 별로 분리된 공간에서 선택적 on/off가 가능하다는 장점이 있죠.
또한 여러명이 동시에 화면 공유가 가능해 복수의 팀원의 화면을 모두 띄워 함께 보며 이야기 할 수 있답니다.
이전 기수의 많은 수강생분들은 프로젝트 기간 중 게더에 상시 접속 후 평소에는 채팅으로 소통, 필요시 카메라와 마이크를 켜고 즉시 미팅을 진행하시는 경우가 많았습니다.
게더타운 이용의 단점이라 하면, 아직 게더타운 공식적으로 가상배경 설정 기능을 지원하지 않아 우회적인 방법을 사용해야하는 번거로움이 있다는 것이 있겠네요!
인간 본성의 가장 심오한 욕구는 ‘중요한 존재로 인정받고자 하는 욕구'라고 말했습니다.
우리는 모두 스스로의 존재를 인정 받고, 중요한 존재로서 인식 되기를 원합니다.
팀 구성원 서로서로가 서로의 존재 이유를 인정하고 계속해서 확인시켜주며, 개인의 크고 작은 기여를 알아봐주세요.
우리는 서로에게 당연한 존재가 아니며, ‘함께’ 중요하고 의미있는 일을 해내고 있다는 사실을 잊지 않는 것이 중요합니다. 서로의 존재 확인과 인정을 통해 더 열심히 일 하고자 하는 동기를 불어 넣어주세요.
성숙하고 젠틀한 대화를 이끌어주세요.
너무 진부한 말이기도 하지만 우리는 종종 말을 예쁘게, 또는 너무 못나게 하는 사람들을 두고 ‘말 한마디로 천냥 빚을 갚는다’고 말하죠.
“프로젝트 기획안을 짜주신 것은 너무 좋았어요. >>하지만 구성이나 디자인이 좀 아쉽더라구요.” 라고 이야기 하는 것 보다
”프로젝트 기획안을 짜주신 것 너무 좋았어요. >>그리고 구성이나 디자인을 좀 다듬으면 좋겠더라고요.”
라고 이야기 하는 것이 훨씬 더 긍정적인 수용이 가능하다는 연구결과가 있었다고 해요.
우리도 우리의 문장 속 ‘근데', ‘그러나'와 같은 반의어 사용을 줄이고 자연스럽게 상대의 행동을 요청할 수 있는 간접적인 표현들을 연습해보는 것은 어떨까요?
나의 실수를 먼저 인정해주세요.
관계의 친밀감을 높이는 가장 빠른 방법 중 하나는 바로 ‘공감대' 형성 입니다. 상대의 실수나 오만 또한 너의 부족으로 인한 실수가 아니라
’우리 모두가 할 수 있는 실수이며, 나도 종종 실수를 하기 때문에 의기소침 해질 필요가 없다’의 기조로 전달한 다면 서로의 기분이 상하지 않고도 더 나은 행동의 결과로 이어질 수 있습니다.
또한 프로젝트를 진행하는 과정 중에서도 개인의 역할과 책임의 부분을 분명 나누게 되겠지만,
프로젝트 자체는 협업의 큰 과정이기 때문에 개인의 실수를 ‘개인의 탓'으로만 두기에는 ‘우리 모두의 공동의 책임'인 것임을 잊지 말아주세요. “이 부분을 잘못하셨네요.” 라고 이야기 하는 것 보다
”이 부분에 오류를 찾았어요. 저도 어렵더라고요. 우리가 같이 해결해볼까요?” 라고 이야기 하는 것이 훨씬 더 바람직한 결과로 이어질 수 있을 거에요.
개인의 선호나 가치관에 대한 사적인 대화는 가급적 지양해주세요.
직장 동료에게 하기 어려운 말, 할 수 없는 것 같은 말, 그리고 조심스럽게 대해야하는 말들은 프로젝트 팀원들과도 마찬가지 입니다.
동기, 학생 동지임을 넘어서 우리는 현재 실무를 예행하는 연습 중임을 기억해주세요.
많은 시간을 함께 하면서 가까워지고 편해지는 것 좋은 일이지만, 상대가 불편할 수 있는 대화의 주제는 가급적 지양하고
모두가 함께 참여하고 즐길 수 있는 대화를 지향하는 성숙한 관계를 진심으로 응원합니다!
칭찬과 격려를 아끼지 말아주세요.
미국의 저명한 심리학자 B. F. Skinner는 실험을 통해 긍정적인 행동에 대한 보상을 받은 동물이 부정적인 행동에 대한 처벌을 받은 동물보다 많은 양을 빨리 학습하고, 그 내용을 더 효과적으로 보유한다는 사실을 밝혀냈습니다. 그리고 이후 연구를 통해서 인간에게도 같은 원칙이 적용된다는 것을 보여주었다고 해요.
건강하지 않은 ‘피드백'이라는 탈을 쓴 비판이나 비난은 상대로 하여금 즉각적인 분노나 적의를 일으키는 것 뿐만 아니라 영구적인 행동의 변화를 이끌어 낼 수 없다고 합니다. 여러분도 누군가 나로부터 잘못을 지적 받거나 비난 받았을 때, 되려 자기방어적인 태도를 보이거나 스스로의 행동에 대해 정당화하려는 노력을 해보신 적이 있으실 겁니다. 우리는 모두 타인의 비난이나 단죄를 무서워하고 두려워 합니다.
그럼에도 불구하고 웃는 얼굴의 칭찬과 격려만이 능사는 아니죠. 우리는 머리를 모아 최선의 결과를 내기 위한 과정 중에 있으니까요.
종종은 서로의 실수와 잘못에 대해 건강한 발전을 도모해야할 때도 분명히 있을 것입니다.
우리가 피드백을 원하는 이유는 단 한가지 입니다.
그것은 바로 내 팀원과 우리의 성장 인데요.
그렇기 때문에 피드백을 전달하는 이유와 목적은 저 방향성과 일치해야만 의미있고, 건강한, 정말 필요한 피드백이 됩니다.
좋은 피드백을 주기 위해서는 먼저 상대방을 충분히 이해 할 만한 상호 관계를 유지했어야합니다.
나의 섭섭함이나 답답함 등 부정적인 감정을 단순 전달하는 것이 아니라,
내가 전달하는 피드백의 내용이 팀원의 성장에 도움이 되게 하고, 팀 구성원의 성장은 우리 팀에도 도움이 된다는 믿음이 가는 피드백만 전달해주세요.
실제 구체적 사례를 기반으로 이야기 할 수 있어야 합니다.
개인의 성향이나 특성이 일방적으로 반영된 감정의 싸움이 아니라, 어떠한 일이 왜 일어났는지 그리고 그것의 문제는 무엇이었다고 생각했는지
정확한 사례를 기반으로 이야기 해야 우리는 비로소 문제의 근본을 찾아 해결책을 강구할 수 있습니다.
피드백을 준다는 것은 결국 내가 하고 싶은 말을 하는 것이 아니라 상대방에게 필요한 말을 해주는 것 이라고 정의할 수 있겠습니다.
‘성공적인 프로젝트’란 무엇을 의미하는 것일까요? 그리고 무엇을 기준으로 그 ‘성공’을 판가름 할 수 있을까요?
한 방향을 바라보며 나아가길 지향하는 우리 코드스테이츠 SE 부트캠프에서는 크게 Hard Skill적인 목표와 Soft Skill적인 목표로 나눠 보도록 하겠습니다.
그리고 그 세부 항목들은 아래와 같습니다.
Hard-
Soft-
내가 동료를 신뢰 할 수 있기 위해서는 동료가 신뢰있는 사람이길 바라기만 하는 것으로는 충분하지 않습니다.
나부터 좋은 동료가 되기 위해서 앞서서 행동해야합니다.
프로젝트 성패와 무관하게 내가 나의 동료를 전적으로 신뢰할 수 있고, 동료도 나를 믿어주었으며, 우리 팀이 프로젝트를 향해 달려온 길이 보람차다고 느껴질 때
우리는 개발자로서의 커리어를 함께하고 업계의 네트워킹을 함께 만들고 즐길 동료를 얻어갈 수 있게 된 것입니다.
우리는 종종 지나온 경험에서 교훈을 얻지만, 그 경험과 교훈 조차도 얼마 가지 않아 망각하고 맙니다.
망각은 인간의 너무나 자연스럽고 능동적인 삶의 방식 중 하나이지만, 우리는 앞으로 계속해서 성장할 개발자로서 부트캠프에서 느꼈던 크고 작은 일들에 대해서
보다 오랫동안, 자세히 기억하고 싶습니다. 좋은 자기소개서의 재료가 되어줄 뿐만 아니라 훗날 문득 돌아보았을 때 스스로를 동기부여 시켜줄 수 있는 좋은 에너지가 되어줄 수 있기 때문입니다.
과거의 내가 미래의 나에게 주는 스스로의 동기부여와 도전의식을 오늘의 게으름 때문에 놓쳐버리지 않으셨으면 좋겠습니다. 🙂
기업들로 부터 신입 개발자들에게 더 요구되는 역량이 기술적인 능력을 나타내는 Hard Skill 보다
협업과 도전의식, 그리고 커뮤니케이션 스킬로 대변되는 Soft Skill의 중요성이 앞도적으로 높은 현상만 보아도 우리가 지금 이 시점에 더 집중해서 키워야하는 역량이 무엇인지 증명되기도 하죠.