코드에 관한 이야기는 블로그에 따로 작성 예정입니당. (천천히….ㅋ) 여러분이 가장 보고 싶어할 KPT 등의 이야기만 담아봤어요
모두가 같은 마음일 수는 없어, 그건 당연해.
- 직장을 다니기는 했지만 커뮤니케이션 적으로 문제가 생긴 적은 단 한 번도 없었다. 학교에서는 각자의 업무가 별개여서 안내만 하면 되는 것이었고 보통은 그 업무에 대한 것은 업무 담당자가 가장 잘 알기에 관리직을 제외하고는 말을 얹을 이유가 없는 부분이었다.
- 특히 나의 경우, 정보 부장을 맡았을 때도 사실 정보부엔 나 혼자(ㅋㅠㅠ)였기 때문에 내가 정보부의 대소사를 결정하고, 사업 신청하고, 예산 집행하고, 시스템을 구축하여 회의 시간에 통보만 하면 되는 문제였다.
- 하지만, 본격적으로 팀 프로젝트를 하면서 같은 장소, 다른 마음, 각자의 전문성을 가진 사람들과 협업하여 하나의 방향을 잡고 하나의 결과를 만들어야 하는 것은 정말 쉽지 않은 부분이라는 생각이 들었다.
- 의견이 다를 때 어떻게 해결해야 하느냐,의 부분이 아마 이 팀 프로젝트에서 얻어가야 할 가장 중요한 소프트 스킬이 될 것이다.
- 의견을 내는 것에도 용기가 필요하다. 따라서, 모든 의견을 내기 위해 허용적인 분위기를 조성하기 위해 노력은 했다.
- 회의가 길어지며 계속 의견 충돌이 나다보니 어떨 때는 좀 의견을 내는 데에 있어 조심스러워 지기도 했다.
- 그래도 회의 마무리 즈음에, 모두가 지친 마음은 알지만 다른 의견을 적극적으로 이야기해줘서 고맙다는 이야기는 꼭 하고 회의를 마무리하고자 노력했다.
- 의견이 적극적으로 충돌하는 팀 분위기는 건강한 조직이다.
- 중요한 것은 그 과정에서 서로 감정이 상하지 않아야 한다.
- 어떻게 하면 건강하면서 자유롭게 의견이 부딪히는 조직이 될 수 있을까? 를 생각해보면 당연한 이야기로 돌아가게 된다.
- 의견을 낼 때에는 최대한 레퍼런스에 기반하여 객관적인 이유를 들어 이야기하기 ←양, 속도 보다는 질이다. 명심하자!!!!
- 상대방의 의견에 대해 우선 장점에 대해 이야기하고 (기술의 장점, 팀원의 노고 등)
- 쿠션어를 섞어서 이야기하기 (”아~ 그렇게 생각할 수도 있군요.”, “공유 감사합니다” 등)
- 감사합니다, 미안합니다 진심을 다해 자주 말해주기
- 그 사람의 공로를 이야기해주기 (”ㅇㅇ님이 말씀 주셨는데요~ 도움 주셨는데” 등)
나의 KEEP
- 팀원들에게 내가 할 수 있는 최대한 칭찬과 함께 고맙다면 고맙다, 미안하다면 미안하다는 이야기를 많이 해주었다.
- 이게 나의 큰 장점이라는 것을 알게 된 것은, 동료 교사와의 얘기 중에서 학생들에게 칭찬을 해주는 것이 가장 어렵다는 이야기를 듣고 부터였다.
- 제일 기억에 남는 나의 칭찬은 수업 시간에 정말 듬직하게 여동생을 챙기는 남학생 얘기가 나와서
나는 다음 생에 태어나면 ㅇㅇ이 동생으로 태어날래. ㅇㅇ같은 오빠가 있으면 참 듬직할 것 같아.
라고 이야기했는데 그 듬직한 아이가 울어버린 것이었다. - 정말 그 사람의 장점이 자연스럽게 눈에 보이고, 진심을 담아 얘기할 수 있다는 것이 내 소프트 스킬에서 keep해야 할 우선 순위일 것이다.
- 진심으로 느낀 바 대로 고마우면 고맙다, 미안하면 미안하다 얘기를 해주었다.
- 사람들 사이에서는 이기고 지는 것이 없다. 특히 우리 팀은 함께 성장해가는 것이니 더더욱 의미가 없는 것이다.
- 나를 내려놓고 솔직하게 모르면 모른다, 고마우면 고맙다, 미안하면 미안하다 이야기를 해 주었다.
- 혹여나 그 과정에서 나를 동등한 사람으로 생각하지 않은 사람은, 그건 그저 그 사람의 문제인 것이다.
나의 PROBLEM
- 팀장 일에 매몰되어 코드 치는 것에 대한 효율이 줄어 들었다.
- 프리 프로젝트 때는 묵묵히 코드만 치면 됐었는데 팀장이 되고 나니, 팀원 분들께 역할을(특히 회의록 은비님, PM 현석님 감사해요) 어느 정도 분배 했음에도 불구하고 팀장으로서 해야 할 일이 너무나도 많았다.
- 얼마나 정신이 없었냐면, 퇴실 QR을 찍는 것을 메인 프로젝트하면서 4번이나 놓친 것이었다.
- 자리에 앉으면 관련된 잡생각과 의견 조율의 무한 굴레, 팀장의 업무로 막상 코드를 치는 시간을 확보하기 쉽지 않았다.
→ 나의 TRY :
능률적으로 일 처리를 하기 위해 시간표를 짠 후, 그 안에서 선택과 집중을 한다. (일과 시간 이후에는 무조건 코드에 집중하는 시간)
- 팀과 상의하여 코어타임(2시간)을 정하고, 그 시간 동안은 코드 치는 것에만 집중하기로 했다.
느리지만, 멀리 가는 거야
- 우리 팀의 경우 각자 적극적으로 의견을 내는 분위기이기 때문에 기획에서 부터 코드를 치는 스타일까지 모든 부분에서 진전이 더디게 흘러갈 수 밖에 없었다.
- 그 과정에서 의견 조율에 대한 어려움, 어떨 때는 팽팽한 긴장감 등을 느끼기도 했다.
- 회의 중간 중간에 당황하여 할 말을 잊어 잠깐 정적이 흐른 적도 있었다.
- 프로젝트 초반만 해도 우리 팀은 만장일치 팀이야! 라고 생각했던 것과는 정 반대의 과정을 정말 제대로 겪고 있었다.
- 하지만 그러면서, 정말 지금 꼭 필요한 커뮤니케이션 스킬을 정제해나갈 수 있었다.
- 일례로 회의를 하다가 문득 나의 말 버릇 중에 쿠션어를 초반에 사용하고 그 뒤에 “그러나!!” 이렇게 강조하는 습관이 있다는 것을 깨달았다.
- 이렇게 되면 듣는 사람들은 “그러나!!” 가 나오는 그 뒤의 말만 집중하게 되는 문제가 있다.
- 따라서 “그리고~”와 같이 좀 더 완화된 맥락에서 의견을 이야기 하도록 습관을 잡으려고 노력하고 있다.
- 다시 말해, 지금 이 과정은 함께 공동 작업물을 창출해야하는 프로젝트에서, 또한 앞으로 있을 수 많은 커뮤니케이션 과정을 위해 반드시 필요한 과정인 것이다.
혼자 가면 빨리 가고, 함께 가면 멀리 간다
.- 부트캠프 과정 내내 이 말을 참 많이 들었지만, 이는 그저 흠~ 좋은 말이군~ 과 같이 그저 지나가는 말 중 하나일 뿐이었다.
- 심지어 프로젝트 진입 전, 이론을 익히는 과정에서는 새로운 내용을 숙지하는 것도 힘든데 페어 프로그래밍까지 하며 일의 능률이 60%로 줄어들자 저 말에 대한 의구심도 품기도 했다.
- 이 때서야 나는 이 말의 진짜 의미가 마음 속 깊숙하게 와 닿기 시작했다.
- 그래, 이런 거였구나. 애초에 빨리 갈 수 없는 것이었다. 멀리 가기 위함인 것이다.