IT 개발팀 조직문화 1년 후기(1)
- 팀 리더로서의 1년 후기
1년 동안 팀을 운영했던 경험을 글로 남겨본다. 2016년 7월에 팀장이 발령이 되었고, 2017년 7월에 내려놓게 되었다. 딱 1년이라는 시간이라서 아쉽게 끝났지만 그래도 짧은 경험을 글로 남겨놓고자 한다. 추후에 내가 어디서든 팀리더가 되었을 때 이 글을 보면 감회가 새로울 것이다. 1년동안 IT 웹서비스 개발팀을 이끌면서 매일같이 고민하면서 만들고자 했던 팀문화는 아래와 같다.
기술블로그
신입사원 파일럿 프로젝트
코드리뷰
업무 진행 현황판
주간 기술 스터디 모임
기술부채 제거
자기 조직화(Self-organizing)팀
빠른 의사결정
간결하게, 가치있게, 하나씩 완성하기
상호 존중
자유로운 연차 사용 및 야근 최소화
단, 좋은 팀을 만들려고 노력을 하는 과정속에서... 품질 높은 서비스를 만들고, 좋은 팀문화를 만드는 것에 대한 정답은 바로 그 팀안에서 찾을 수 있다는 점이다. 누군가의 지시가 아니라, 윗분들의 명령이 아니라 바로 팀 내에서 찾아가야 한다는 사실!!
어쩃든 사람! 프로세스는 프로세스 일 뿐!! 팀원에 의한, 팀원의, 팀원을 위한 팀문화
1.웹서비스 개발팀 팀문화
기술블로그, 파일럿 프로젝트, 코드리뷰, 업무진행현황판, 주간 스터디 모임, 기술부채 등의 팀문화를 소개해보겠다.
1.1 기술블로그
기술블로그는 공유, 소통을 위해 만들었는데, 팀원들이 개발팀에 애정을 갖고 포스팅 하나하나에 진심을 담아서 글을 올린다. 그리고, 팀원이 쉽게 작성 및 업로드를 할 수 있도록 github 및 markdown 으로 관리를 한다. 글 작성을 위한 일정을 반드시 배려해줘야 하며, 팀원들 스스로 글 작성에 대한 의지가 있어야 한다. 억지로 쓴다면 차라리 안쓰는게 나을 수도 있다. 기술블로그에 작성되는 글은 아래와 같다.
잉여 시간에 스터디한 내용
신입 개발자 파일럿 프로젝트
개발팀 문화 및 소소한 이야기들
사내 서비스 활용 사례
리팩토링 사례 공유
다양한 주제로 포스팅을 한다. 처음 블로그를 시작하게 된 계기는 https://zumdev.github.io/first/ 에서 확인할 수 있다.
팀장, 팀원 모두가 블로그 주도형 개발자가 되길 바라며!!
#2018년10월 내용 추가
필자가 만든 회사 팀 블로그(지금은사라진zumdev.github.io)가 회사 대표 기술 블로그(zuminternet.github.io)로 바뀌었다. 필자가 팀을 운영했던 2016년~2017년에는 블로그에 아무도 관심을 주지 않다가, 필자가 팀을 이동할때쯤... 갑자기 필자가 만든 팀 블로그를 없애고 신규 블로그를 만들었다. 기존에 작성한 모든 글을 그대로 옮겼는데, 필자가 작성한 팀문화 관련 글만 모두 지웠졌다.(지워진 것을 몰랐다가 한참 후에 나중에 알았다.) 아무튼 필자가 썼던 글은 이제 회사 블로그에서는 확인할 수 없다. 아무래도 회사 조직문화와 맞지 않았던 것 같은데 직접 전해들은 적이 없기 때문에 자세히는 모르겠다.
1.2 신입사원 파일럿 프로젝트
신규 입사자는 두 번의 파일럿 프로젝트를 수행한다. 첫번째 프로젝트는 공통 주제로 게시판 구축 프로젝트이다. 팀원의 도움 없이 혼자서 3주~5주 일정으로 진행한다. 지도선임 개발자는 신입사원에서 git 사용법, 요구사항,필수 기술 스펙 정도만 지도해주며 알아서 일정에 맞춰서 개발을 해야 한다. 두번째 프로젝트는 팀 회의를 통해서 주제를 결정한다. 1차 프로젝트는 신입사원 혼자서 끙끙 앓아가면서 해결해 나기자만 2차 프로젝트는 전폭적인 지원을 받고 프로젝트를 수행한다. 신입사원은 2차 프로젝트에서 코딩 방법, 스펙 선정, 일정 수립, 기술 지원 등 전반적인 가이드를 모두 지도사원과 함께 수행하며, 설계/개발/배포 포함 4주~6주 정도 일정으로 진행을 한다. 수습 3개월 기간 동안은 파일럿 프로젝트만 집중한다. 파일럿 프로젝트가 끝나면 신입사원은 아래와 같은 능력을 습득하게 된다.
git 사용법 숙지
기본적인 코딩 컨벤션
설계 능력 향상
개발 환경 셋팅
협업 능력 향상
파일럿 프로젝트를 통해서 많은 점을 느끼고 배울수 있도록 적극 지원한다. 1명의 신입사원을 키우는 것은 쉽지 않은 일이지만, 팀원이 성장할 수 있도록 적극 지원한다. 파일럿 프로젝트가 종료되면 바로 업무에 투입이 된다. 단, 일부 신입사원은 파일럿 프로젝트 기간에도 업무를 바로 투입되기도 한다. 잘해서는 아니고, 업무가 많이 몰렸을 경우에는 일부 업무를 지원하기는 하지만, 웬만해서는 파일럿 프로젝트에 집중할수 있도록 최대한 배려와 시간, 믿음을 주는 편이다. 또한, 파일럿 프로젝트를 진행 한 이후 반드시 후기를 작성하도록 시간적 여유를 주고 있다. 1년 후에 자신이 작성했던 글을 다시 돌아본다면 1년 사이 훌쩍 성장해버린 자신을 보고 감회가 새로울 것이다. https://zumdev.github.io/category/pilot/ 에서 팀원들이 작성한 파일럿 후기를 확인할 수 있다. 또한 지도하는 과정 중 선임들도 많은 것을 깨달을 수 있다. 신입사원, 지도사원 모두 함께 동반성장 하는 계기가 되는 분위기를 만드는 것이 중요하다.
파일럿 프로젝트는 개발팀의 팀원이 되는 매우 중요한 과정
1.3 코드리뷰
개발팀은 모든 배포를 대상으로 거의 매주 코드리뷰를 수행한다. 단, 간단한 수정 건에 한해서는 팀 코드리뷰 없이 머지리퀘스트(1:1코드리뷰)를 통해서 검증 후 배포를 한다. 일정에 쫓기다 보면 QA와 코드리뷰를 병행해서 진행하기도 하는데, 코드리뷰 일정을 확보하도록 지속적으로 기획팀과 협업이 필요하다. 코드리뷰는 정답이 있는 것이 아니라고 생각을 하는 편이다. 윗사람이 아래사람에게 일방적으로 지시하는 코드리뷰 보다는 서로의 의견을 공유하는 시간이 더 효율적이라고 생각하는 편이다. 단, 기술적 가이드, 표준화 가이드 등을 잘 수립해야 혼란스럽지 않은 코드리뷰를 수행할 수 있겠다는 의견이다.
1.4 업무 진행 현황판
팀을 5개월 정도 운영한 이후부터 트렐로를 사용하였다. 트렐로는 프로젝트 진행상황을 한 눈에 확인할 수 있어서 다양한 포털서비스를 정해진 인력으로 운영하는 개발팀에 적합하다고 판단했었다. 하지만, 트렐로를 한달 정도 해본 결과 의도한 생각과 맞지 않는 점이 있었다.
트렐로는 카드 색상으로 프로젝트 구분을 할수는 있었지만, 명확하게 프로젝트 단위로 나누기에는 부족함이 있었다.
팀원들이 함께 대화하면서 보기에는 완벽하게 좋지는 않았다.
인터넷으로 같이 공유하면서 작업하기에는 좋았지만 내가 바라던 방향은 아니었다. 고민 끝이 이동식 화이트보드를 구매하였다. 화이트보드는 기존에 사용하던 트렐로의 역할과 비슷하고, 애자일의 스크럽보드, 칸반보드 등과도 유사하다. 개발팀에서는 현재 최소3개 이상의 프로젝트를 동시에 수행하고 있기 때문에 보드에 모든 프로젝트의 현황을 표현하고자 했고, 프로젝트 구획을 나누고 싶었다. 즉, 스윔 레인 으로 구성하였다. 스윔레인에 대한 관련 내용은 [칸반과 스크럼-인사이트-68page] 에 좀 더 자세히 설명이 되어있다.
프로젝트 현황판얼핏 보면 애자일에서 사용하는 보드판과 유사하다. 내가 생각하는 팀문화 가치 등이 애자일과 유사하지만, 애자일 프로세스를 도입하겠다고 말하고 다니지는 않는다. 사실 애자일의 원칙에 대해서 잘 모른다. 단지, 그동안 생각했던 방향이 애자일과 일부 유사해서 참고만 하고 있다. 프로세스는 프로세스일 뿐, 프로세스가 강제화 되어서는 안된다고 생각을 한다. 개발팀은 화이트보드 앞에서 일주일에 두세번 정도 스탠드업 미팅을 진행한다. 일일 스탠드업 미팅을 할려고 했으나, 매일 진행하는 것이 오히려 부담일것 같았다. 오전에는 서비스 배포를 자주하며 개인 자유시간, 담배 타임 등 고려하여 팀 특성상 필요한 경우에만 진행을 하였다. [애자일&스크럼 프로젝트 관리-길벗출판사-86page] 이라는 책에서는 백로그에 작성되는 건은 아래와 같은 지침을 제안한다.
1. 상호 독립적이어야 한다.
2. 변경이 가능해야 한다.
3. 사용자와 고객에게 가치가 있어야 한다.
4. 추정이 가능해야 한다.
5. 크기가 적절해야 한다.
6. 테스트가 가능해야 한다.
하지만 개발팀 일정판에 붙이는 포스티잇(카드)에 명확한 규제는 아직 없다. 하나하나 실천 가능한 것부터 해보면서 꾸준히 개선이 필요할 것 같다.
처음부터 강한 규제보다는 실천 가능한 일부터 하나씩 해보는게 어떤지?
1.5 주간 기술 스터디
개발팀에서는 매주 기술스터디를 진행하고자 한다. 하지만 업무가 몰리고 정신없이 일하다 보면 매주 못하는 경우도 있다. 팀원들이 스터디에 부담이 없어야 한다. 잉여력 시간이 반드시 할당이 되어야 하고, 하루종일 일만하는 건 바람직하지 않다고 생각한다. 두가지 트랙으로 진행을 하였는데 토비싀 스프링 과 상시주제로 나눠서 진행을 해봤다. 토비의 스프링은 올한해 동안 스터디 하기로 계획을 정하고 신입사원들이 돌아가면서 공유하는 방법으로 진행을 하였다. 상시 주제는 신기술공유, 아키텍처, 리팩토링, AWS, 포털서비스 동향, 빅데이터 등 다양한 주제로 스터디를 진행하였다. 주제에 따라서는 다른팀 팀원들도 함께 스터디 하고 고, 함께하면 더 즐거운 스터디 문화를 만들려고 노력을 했었다.
상반기 스터디 일정스터디는 꾸준히! 그리고, 모두 함께 스터디하는 팀문화!
1.6 기술 부채 제거
기술 부채를 제거하는 일은 매우 중요하다. 그동안 여러 건의 기술부채를 없애는 일을 진행하였다. 개발 환경 개선, 플랫폼 전환, 리팩토링 등의 작업이 포함된다. 기술 부채는 어느 한 순간에 전부 해결할 수 있는 것이 아니다. 꾸준히 개선해 나가야 한다. 다음 설계를 위해서, 다음 개발 건을 위해서 리팩토링을 수행해야 한다고 생각한다. 단, 리팩토링이 불가능한 수준이 되어 완전 새롭게 신규구축으로 진행이 필요하다면, 반드시 신중하게 결정해야 한다. 반드시 기획팀 또는 제품 책임자와 사전 커뮤니케이션 및 이해와 동의가 반드시 필요하며, 기획팀과 개발팀 같이 협업하여 진행할 수 있을 때 바로 상호존중의 가치를 발휘하면서 좋은 품질의 서비스를 운영할 수 있다.
기술부채! 당연히 제거해야 ! 하지만, 개발리소스, 일정, 리스크 등 검토해야 할 사항이 많습니다. 소프트웨어 개발/운영 은 절대 쉬운일은 아닙니다.
지난 1년동안의 경험을 바탕으로 팀문화에 대한 글을 작성해 보았는데 다시 정리를 해보면 아래와 같다.
기술블로그
코드리뷰
신입파일럿 프로젝트
업무 진행 현황판
주간 기술 스터디 모임
기술부채 제거
사실 많이 부족한 팀 리더였다고 생각한다. 피드백을 통해서 끊임없이 개선해 나갔어야 했는데, 지나고 생각해보니 더 잘할수 있었는데 라는 생각에 아쉽기는 하다. 다음 글에서는 개발팀의 팀 가치에 대한 글을 작성할 예정이고 아래와 같은 내용이 포함될 예정이다.
자기 조직화(Self-organizing)팀
빠른 의사결정
간결하게, 가치있게, 하나씩 완성하기
상호 존중
자유로운 연차 사용 및 야근 최소화
https://brunch.co.kr/@springboot/10
참고로 해당 글은 아래 링크에서도 확인할 수 있다.
https://zumdev.github.io/portaldevteam2017/
