팀문화를 위한 작은 발버둥

목마른 자가 우물을 판다.

회사의 대부분이 TF팀 형태로 그때 그때 프로젝트 구성원이 매핑된다(?). 서로 공유하는 업무 체계가 없는 상태에서 다양한 사람들과 일을 하다 보니 자연스럽게(?) 팀문화랄게 딱히 없고, 좋은 노하우와 경험이 전파되지 못하는 상황인 것 같다.

드디어 바쁘게 돌아가던 프로젝트에서 숨구멍이 트였고, 같은 업무를 하는 동료들끼리 힘을 모아 여러 시도를 시작했다.

데일리 스탠드업 미팅

아이스 브레이킹 용이기도 하고, 별다른 커뮤니케이션 비용을 들이지 않고 근황이나 업무 현황을 캐치하기 좋다. 삭막한 TF팀에서 한줄기의 빛 . 매일 5분~10분 정도로 진행하기로 했다.

주간 회고

회고를 통해 자체적인 피드백 시스템을 적용했다. (+속풀이)

현 회사에서 구성하는 묘한 TF팀은 각 팀원이 느낀 좋은 경험이나 아이디어, 노하우가 자연스럽게 공유되지 않는다. 분위기가 독서실같다. 음, 일 이야기나 점심 때가 아니면 자연스럽게 말 섞을 기회도 별로 없다.

회고는 매주 1회 진행할 예정이며, 회고 방식은 KPT 방법론을 라이트하게 적용했지만 그때그때 상황에 맞게 조정할 계획이다.

내가 회고에서 중요하게 생각하는 것, 세 가지

1. 태도와 마음가짐 '그럴 수 있지'
   • 냉소와 비난은 아무것도 해결해주지 않는다
   • 비판과 반대의견은 좋으나 비난은 허용하지 않는다
   • 타인의 의견을 평가하는 게 아니라 나의 성장의 발판으로 삼는다 (팔짱끼기 X)
   • 최고의 의견을 찾는 게 아니라 다양한 의견을 듣고 우리에게 맞는 방식을 찾는다
   • 불만을 말할 때에는 되도록 해결책이나 방향도 함께 말한다
2. 주제는 다양하며 제한이 없음
   • 코드에 대한 질문도 OK, 단 상황설명을 자세히 한다.
   • 업무 방식, "기획자와 이런 식으로 협의 했더니 좋았어요 불편했어요."
   • 회고 방식, "KPT방법론을 정석적으로 시도해보고 싶어요/다른 방식을 시도해보고 싶어요."
3. 모두 공평하게, 흥분하지 않고 발언할 시간을 갖기
   • 이 부분은 회고 진행자가 잘 조절하도록 한다

문서화

한 달 동안 서버개발자 둘이서 관리자 플랫폼을 제작하면서 구두로 했던 자잘한 약속들이 있었다. 나중에 팀원이 한 명 늘어나면서 문서화를 시작했다. 추가로 팀원들이 들어왔을 때 헤매지 않도록(얼른 일하시도록ㅎㅎ) 설치 방법, 디버깅 방법, 공부하기 좋은 자료부터 코딩 컨벤션까지 필요한 정보들을 문서로 옮기기 시작했다.

예상치 못하게 리액트를 하게 되었지만, 같은 업무를 맡은 팀원들이 긍정적이고 적극적으로 함께 해줘서 즐겁게 일하는 중이다.

시너지 효과(애자일과 스크럼)

사실 위에 나열된 것들을 함께 적용하면 팀 운영 시 시너지 효과를 발휘한다. 현재 회사에서는 하고 있지 않지만, 과거에 애자일 소프트웨어 개발(Agile software development) 이라고 불리는 개발 방법론 중에서 스크럼(Scrum)이라는 기법으로 개발팀을 운영하는 회사에서 일한 적이 있었다.

소프트웨어 개발이라는 게 전부 사람에 의존하여 탄생하는 제품이다. 그래서 인력과 그들의 작업 관리가 핵심이라고 생각한다. 애자일 개발 프로세스는 서비스 혹은 프로젝트를 개발하면서 필요한 인력 관리, 작업 현황 파악부터 요구사항과 개발, 테스트, 버그리포팅 등을 하나의 프로세스로 묶어서 효율적이고 저렴하게 관리하게 해준다. 그리고 이런 애자일 기법을 잘 수행할 수 있도록 많은 도구(Jira, MS-devops 등)들이 개발되어 있다. 이런 도구를 통해 유휴 자원과 랙 자원, 그리고 작업 현황을 팀 단위로 한 눈에 파악이 가능하다.

개인적으로 스크럼(Scrum)이 좋았던 점은 이 과정을 통해 구성원이 스스로 배울 수 있는 피드백 시스템(회고)이 있기 때문에 역량 강화와 넓은 사고를 하는 데에 도움이 되었다. 그리고 서로 건강하고 밝게 소통하는 분위기가 형성되어 있어서 동료들과 대화를 나누는 것이 즐거웠다. 동료들과의 소통이 즐겁고, 내가 성장하고 있다는 착각(ㅎ)을 할 수 있다는 게 가장 큰 장점이라고 생각한다.

스크럼 : https://ko.wikipedia.org/wiki/스크럼_(애자일_개발_프로세스)

스크럼 (애자일 개발 프로세스) - 위키백과, 우리 모두의 백과사전

애자일한 조직이 아니더라도 데일리 미팅, 코드리뷰, 회고가 주는 장점은 충분하다. 다만, 시너지 효과를 발휘하려면 애자일을 팀원이나 팀 레벨이 아닌 조직 차원에서 고려해야 한다.

지금 우리 회사는

애자일하게 운영되지 않는다. 하지만 상관없다. 조직을 운영하는 많은 방법 중 애자일이 있는 것일 뿐이니, 효율적이고 체계적으로 운영만 된다면 이름 없는 방법론도 상관없다고 생각한다. 다만 슬픈 건 내가 이직한 회사의 업력이 10년인데 아직도 업무 체계가 undefined하다는 것이다. 아마 치열한 생존을 위한 선택이었으리라. 이제는 시장에서 어느 정도 인정을 받았기 때문에 큰 도약을 위해 체계 변화와 복지, 인력 관리에 대해 조직 차원에서 고민하려고 시작한 것 같다. 물론 앞으로 1-2년 동안에는 큰 변화는 없을 것이라 예상한다(이미 예정된 일들이 있기 때문이다). 그래도 회사와 문화가 성장을 시작하는 단계를 지켜보는 것은 좋은 경험인 것 같다. 이제 어떤 땅에 어떤 씨앗을 뿌릴까 알아보는 느낌이다.

내가 팀원들과 데일리 미팅, 회고를 시작한다고 해서 회사가 애자일하게 운영되는 것은 다른 이야기다. 이것은 조직 차원에서 결정해야 하는 부분이기 때문에 팀원들끼리 '데일리미팅을 하자! 회고를 하자!' 외치는 것은 자기 만족에 가깝다. 어쩌면 회사에서 이런 시간을 업무 시간으로 여기지 않을 수도 있기 때문에 동료들끼리 짬을 내서 진행해야 했다. 하지만 이런 변화를 팀원 레벨에서 일으키고, TF팀으로 전파되고, 다시 개발팀으로 전파되고, 이게 전 조직에 전파될 수 있을 것이라 소망한다. 이런 작은 움직임에 대해 다른 팀에서 흥미를 느끼고 '한번 해보면 어떨까?'라는 생각을 일으킨다는 것 자체에 의미를 두기로 했다. 그래도 이런 시도는 나와 동료 개발자들을 즐겁게 일할 수 있게 만들었다.

현재 회사의 인력 운용이 TF단위라서 애자일을 도입하기 애매한 부분이 있다. 소속팀 단위가 아닌 프로젝트별로 TF팀이 그때 그때 여유 팀원이 차출되기 때문에 소속팀의 의미가 없다. 그리고 인력에 비해 진행되는 프로젝트가 많아서 데일리 미팅이나 회고도 6개월이 지나서야 겨우 시도해 볼 수 있게 됐다. 애자일은 중간 관리자의 롤이 중요한데, TF 특성상 중간 관리자의 존재 자체가 애매하다. 이런 운영 방식은 회사의 BM과도 맞물린 것 같다.

 

(+추가)

으아아, 투입된 TF팀에서 업무가 갑작스럽게 바뀌었다. 인력 부족으로 내가 다른 파트로 차출되서, 같은 업무를 맡았던 팀원들과 의기투합하여 약속했던 시도들은 어떻게 되는 건가 잠깐 우울했다. 그래도 같은 프로젝트를 진행하는 TF팀이니까 내심 중요하게 생각했던 Jira 활용과 회고는 같이 할 수 있을 것 같다! 아직 괜찮아!

---

연관된 글

협업을 위한 작은 발버둥 : prohannah.tistory.com/115

협업을 위한 작은 발버둥