본문 바로가기

프로젝트 1주차 KPT : 모두가 같은 마음일 수는 없다. 그리고..

프로젝트 1주차 KPT : 모두가 같은 마음일 수는 없다. 그리고..

모두가 같은 마음일 수는 없어, 그건 당연해.

 

  • 직장을 다니기는 했지만 커뮤니케이션 적으로 문제가 생긴 적은 단 한 번도 없었다. 학교에서는 각자의 업무가 별개여서 안내만 하면 되는 것이었고 보통은 그 업무에 대한 것은 업무 담당자가 가장 잘 알기에 관리직을 제외하고는 말을 얹을 이유가 없는 부분이었다.
    • 특히 나의 경우, 정보 부장을 맡았을 때도 사실 정보부엔 나 혼자(ㅋㅠㅠ)였기 때문에 내가 정보부의 대소사를 결정하고, 사업 신청하고, 예산 집행하고, 시스템을 구축하여 회의 시간에 통보만 하면 되는 문제였다.
    • 하지만, 본격적으로 팀 프로젝트를 하면서 같은 장소, 다른 마음, 각자의 전문성을 가진 사람들과 협업하여 하나의 방향을 잡고 하나의 결과를 만들어야 하는 것은 정말 쉽지 않은 부분이라는 생각이 들었다.
    • 의견이 다를 때 어떻게 해결해야 하느냐, 의 부분이 아마 이 팀 프로젝트에서 얻어가야 할 가장 중요한 소프트 스킬이 될 것이다.

 

  • 의견을 내는 것에도 용기가 필요하다. 따라서, 모든 의견을 내기 위해 허용적인 분위기를 조성하기 위해 노력은 했다.
    • 회의가 길어지며 계속 의견 충돌이 나다보니 어떨 때는 좀 의견을 내는 데에 있어 조심스러워 지기도 했다.
    • 그래도 회의 마무리 즈음에, 모두가 지친 마음은 알지만 다른 의견을 적극적으로 이야기해줘서 고맙다는 이야기는 꼭 하고 회의를 마무리하고자 노력했다.

 

  • 다른 의견이 충돌하는 팀 분위기는 건강한 조직이다. 단, 그 과정에서 서로 감정이 상하지 않는 경우에.
    • 어떻게 하면 건강하면서 자유롭게 의견이 부딪히는 조직이 될 수 있을까? 를 생각해보면 당연한 이야기로 돌아가게 된다.
    1. 의견을 낼 때에는 최대한 레퍼런스에 기반하여 객관적인 이유를 들어 이야기하기
    2. 상대방의 의견에 대해 우선 장점에 대해 이야기하고 (기술의 장점, 팀원의 노고 등)
    3. 쿠션어를 섞어서 이야기하기 (”아~ 그렇게 생각할 수도 있군요.”, “공유 감사합니다”)
    4. 감사합니다, 미안합니다 진심을 다해 자주 말해주기

 

나의 KEEP

 

1. 팀원들에게 내가 할 수 있는 최대한 칭찬을 많이 해주었다.

  • 이게 나의 큰 장점이라는 것을 알게 된 것은, 동료 교사와의 얘기 중에서 학생들에게 칭찬을 해주는 것이 가장 어렵다는 이야기를 듣고 부터였다.
    • 제일 기억에 남는 나의 칭찬은 수업 시간에 정말 듬직하게 여동생을 챙기는 남학생 얘기가 나와서 나는 다음 생에 태어나면 ㅇㅇ이 동생으로 태어날래. ㅇㅇ같은 오빠가 있으면 참 듬직할 것 같아. 라고 이야기했는데 그 듬직한 아이가 울어버린 것이었다.
    • 정말 그 사람의 장점이 자연스럽게 눈에 보이고, 진심을 담아 얘기할 수 있다는 것이 내 소프트 스킬에서 keep해야 할 우선 순위일 것이다.

2. 진심으로 느낀 바 대로 고마우면 고맙다, 미안하면 미안하다 얘기를 해주었다.

  • 사람들 사이에서는 이기고 지는 것이 없다. 특히 우리 팀은 함께 성장해가는 것이니 더더욱 의미가 없는 것이다.
  • 나를 내려놓고 솔직하게 모르면 모른다, 고마우면 고맙다, 미안하면 미안하다 이야기를 해 주었다.
  • 혹여나 그 과정에서 나를 동등한 사람으로 생각하지 않은 사람은, 그건 그저 그 사람의 문제인 것이다.

 

나의 PROBLEM

 

팀장 일에 매몰되어 코드 치는 것에 대한 효율이 줄어 들었다.

  • 프리 프로젝트 때는 묵묵히 코드만 치면 됐었는데 팀장이 되고 나니, 팀원 분들께 역할을*(특히 회의록 은비님, PM 현석님 감사해요)* 어느 정도 분배 했음에도 불구하고 팀장으로서 해야 할 일이 너무나도 많았다.
  • 얼마나 정신이 없었냐면, 퇴실 QR을 찍는 것을 메인 프로젝트하면서 3번이나 놓친 것이었다.
  • 자리에 앉으면 관련된 잡생각과 의견 조율의 무한 굴레, 팀장의 업무로 막상 코드를 치는 시간을 확보하기 쉽지 않았다.

 

나의 TRY

능률적으로 일 처리를 하기 위해 시간표를 짠 후, 그 안에서 선택과 집중을 한다. (일과 시간 이후에는 무조건 코드에 집중하는 시간)

  • 팀과 상의하여 코어타임(2시간)을 정하고, 그 시간 동안은 긴급한 상황을 제외하고는 코드 치는 것에만 집중하기로 했다.

 

느리지만, 멀게 가는 거야

 

우리 팀의 경우 각자 적극적으로 의견을 내는 분위기이기 때문에 기획에서 부터 코드를 치는 스타일까지 모든 부분에서 진전이 더디게 흘러갈 수 밖에 없었다.

  • 그 과정에서 의견 조율에 대한 어려움, 팽팽한 긴장감 등을 느끼기도 했다.
    • 회의 중간 중간에 당황하여 할 말을 잊어 잠깐 정적이 흐른 적도 있었다.
    • 프로젝트 초반만 해도 우리 팀은 만장일치 팀이야! 라고 생각했던 것과는 정 반대의 과정을 정말 제대로 겪고 있었다.

 

하지만 그러면서, 정말 지금 꼭 필요한 커뮤니케이션 스킬을 정제해나갈 수 있었다.

  • 일례로 회의를 하다가 문득 나의 말 버릇 중에 쿠션어를 초반에 사용하고 그 뒤에 “그러나!!” 이렇게 강조하는 습관이 있다는 것을 깨달았다.
  • 이렇게 되면 듣는 사람들은 “그러나!!” 가 나오는 그 뒤의 말만 집중하게 되는 문제가 있다.
  • 따라서 “그리고~”와 같이 좀 더 완화된 맥락에서 의견을 이야기 하도록 습관을 잡으려고 노력하고 있다.
  • 다시 말해, 지금 이 과정은 함께 공동 작업물을 창출해야하는 프로젝트에서, 또한 앞으로 있을 수 많은 커뮤니케이션 과정을 위해 반드시 필요한 과정인 것이다.

 

혼자 가면 빨리 가고, 함께 가면 멀리 간다.

  • 부트캠프 과정 내내 이 말을 참 많이 들었지만, 그저 좋은 말이군~ 라고 생각하며 그저 지나가는 말 중 하나일 뿐이었다.
  • 심지어 프로젝트 진입 전, 이론을 익히는 과정에서는 새로운 내용을 숙지하는 것도 힘든데 페어 프로그래밍까지 하며 일의 능률이 60%로 줄어들자 저 말에 대한 의구심도 품기도 했다.
  • 이 때서야 나는 이 말의 진짜 의미가 마음 속 깊숙하게 와 닿기 시작했다.

 

그래, 이런 거 였구나. 애초에 빨리 갈 수 없는 것이었다. 멀리 가기 위함인 것이다.

728x90
⬆︎