brunch

You can make anything
by writing

C.S.Lewis

by 에디의 기술블로그 Dec 01. 2017

IT 개발팀 조직문화 1년 후기(2)

- 팀 리더로서의 1년 후기

  1년 동안 팀을 운영했던 경험을 글로 남겨본다. 2016년 7월에 팀장이 발령이 되었고, 2017년 7월에 내려놓게 되었다. 딱 1년이라는 시간이라서 아쉽게 끝났지만 그래도 짧은 경험을 글로 남겨놓고자 한다. 추후에 내가 어디서든 팀리더가 되었을 때 이 글을 보면 감회가 새로울 것이다. 1년동안 IT 웹서비스 개발팀을 이끌면서 매일같이 고민하면서 만들고자 했던 팀문화는 아래와 같다.

기술블로그

신입사원 파일럿 프로젝트

코드리뷰

업무 진행 현황판

주간 기술 스터디 모임

기술부채 제거

자기 조직화(Self-organizing)팀

빠른 의사결정

간결하게, 가치있게, 하나씩 완성하기

상호 존중

자유로운 연차 사용 및 야근 최소화


  단, 좋은 팀을 만들려고 노력을 하는 과정속에서... 품질 높은 서비스를 만들고, 좋은 팀문화를 만드는 것에 대한 정답은 바로 그 팀안에서 찾을 수 있다는 점이다. 누군가의 지시가 아니라, 윗분들의 명령이 아니라 바로 팀 내에서 찾아가야 한다는 사실!!


어쩃든 사람! 프로세스는 프로세스 일 뿐!! 팀원에 의한, 팀원의, 팀원을 위한 팀문화


https://brunch.co.kr/@springboot/7



2.웹서비스 개발팀 팀가치

  자기 조직화팀, 빠른 의사결정, [간결하게,가치있게,하나씩완성하기], 상호존중, 자유로운 연차 사용 및 야근 최소화 등의 팀 가치를 소개해 보겠다. 참고로 추상적이고 진부(?)한 글이기 때문에 팀을 운영해본 경험이 없다면 굳이 안읽어도 되는 글이다. 이제 막 팀장이 되었거나, 팀장으로서의 역할에 고민이 있다면 한번쯤은 같이 고민해볼 필요는 있는 글이다. 


2.1 자기 조직화(Self-Origanizing) 된 팀

  내가 맡은 개발팀은 팀원 한명이 2~3개의 서비스 를 담당하고 있다. 또한 기획 부서의 요구사항의 변화가 항상 많다. 부족한 인력 및 잦은 요구사항의 변화에 대응하면서 품질 높은 서비스를 제공하기 위해서는 자기조직화 된 팀 구성이 되어야 한다고 판단하였다. 자기조직화된 팀은 자율성, 책임감, 상호존중의 가치를 실현해야 한다. 이런 팀문화로 동시다발적인 제품 개발이 가능하다. 전통적인 팀 커뮤니케이션과 자기조직화된 팀 커뮤니케이션을 비교한 그림이다. (참고-구글 이미지)

  각자 맡은 서비스에 대한 결정권을 갖고 운영을 하고 고민을 많이 해야한다고 생각한다. 쉽지 않은 일이지만 시키지 않아도 말하지 않아도 알아서 잘 하면 얼마나 좋을까? 어쨋든 자기 조직화된 팀에서의 팀원은 아래와 같은 사항을 주체적으로 결정해야 한다. 

개발 일정 검토

신규 개발건에 대한 분석/설계(아키텍처 검토)

자기 주도적인 리팩토링 계획 수림 및 수행

서비스에 추가되면 좋은 기능에 대한 제안

  단, 아키텍처 결정 및 중요 리팩토링 사항에 대해서는 진행 전에 반드리 리뷰를 수행해야 한다. 자율성을 중요시 하지만, 상호 존중을 더 중요하게 생각한다. 팀원들의 의견을 수렴하여 좋은 방향으로 개선할 수 있도록 함께 협업을 해 나간다. 그리고, 서비스를 혼자서 책임지는 것이 아니다. 코드리뷰를 통해서 공동 책임감을 키우고 남의 서비스가 아닌 모든 서비스가 자기일인 것처럼 서로 도와가면서 협업을 해야 한다. 자기 조직화된 팀에 대한 참조는 [애자일&스크럼 프로젝트 관리-43page],[애자일&스크럼 프로젝트 관리-181page~206page] 등의 서적에서도 참고할 수 있다. 자기 조직화된 팀 관련해서는 서번트리더, 마이크로서비스 아키텍처, 리팩토링, 애자일, TDD 등 하고 싶은 얘기는 많지만 얘기가 너무 길어지므로 생략한다. 


자기 조직화(Self-organizing)된 팀이 포털서비스 개발/운영 에 최고의 성과를 낼 수 있다.


2.2 빠른 의사결정

  팀원의 제안은 가능하면 빠른 결정 및 빠른 실행을 진행 할 수 있도록 한다. 느린 결정은 동기부여를 떨어뜨리고 호기심을 낮춘다. 나는 빠른 결정을 항상 원했으며 복잡한 고민보다는 심플하고 빠른 실행을 선호하였다. 실행을 방해하는 과도한 설계과 과도한 기술 논의는 자칫 팀원의 동기부여를 낮출수 있다고 생각했다. 단, 그 실행은 반드시 가치있고 간결하고 하나씩 완성할 수 있도록 해야 한다. 가치 있는 일이라는 판단이 들었을 때 진행하는 것이 좋다. 

  하지만 반대 의견으로는 불확실한 상황을 해결하기 위해서 빠른 결정을 하게 되는 상황은 오히려 좋지 않은 결과를 초래할 수 있다. 그렇다. 너무 잘 알고 있고, 경험도 많이 했다. 급한 결정과 잘못된 설계로 돌이킬수 없는 첫단추를 잘못 끼우는 것에 대한 리스크는 항상 존재한다. 

  균형감각을 어떻게 찾아야 할지 어려운 일이며, 그 결정은 독단적인 결정이 되어서는 절대 안되고 경영진,기획부서,개발리더,개발자,테스트 등 전체 상황을 현명하게 파악해서 진행해야 하는데, 참 어려운 일이다. 몇줄 안되는 문장인데 도대체 빠른 결정을 하라는 것인지 하지 말라는 것인지 글을 쓰면서도 혼란스럽다. 


어려운 일이지만, 그래도 공식적으로 팀원들 또는 다른팀 분들께는 빠른 의사결정의 중요성에 대해서 항상 전달하고 실천했었는데... 쉽지 않았다. 지금은 팀 리더는 아니라서 크게 신경은 안쓰고 있다. 


2.3 KEEP IT SIMPLE, MAKE IT VALUABLE, BUILD IT PIECE BY PIECE

  올해 읽었던 중에서 가장 잼있게 읽었던 책을 소개해보겠다. The Nature Of Software Development 라는 책이다. 


  간결하게, 가치있게, 하나씩 완성하기 라는 책 제목처럼 올바른 소프트웨어를 개발/운영하기 위한 심플하면서도 쉽지 않은(??) 가이드를 제공하는 책인데, 책에서는 쉽게 설명했지만 현실에서는 쉽지는 않다. 책의 내용을 그대로 옮기기는 무리가 있으니 관심있는 분들은 한번 읽어보면 도움이 될것 같다. 소프트웨어 특히 포털서비스는 필연적으로 복잡해질 수 밖에 없다고 생각한다. 복잡해지는 소프트웨어를 간결하고, 가치있고, 하나씩 완성할 수 있도록 하는 것에 대해서 고민을 많이 했었지만, 쉽지 않았다. 어려운일 투성이다. 팀원들도 그 가치에 대해서 조금이라도 이해할 수 있는 날이 오면 좋겠다고 생각했었으나... 지금은 내 신념이 많이 흔들린 상황이기는 하다. 


2.4 상호존중

  추상적이고 어려운 주제다. 장문의 글을 작성했다가... 지우는게 낫겠다는 판단하에 지웠다. 

말이 아닌 실천함으로 절대적으로 빛나는 가치


2.5 자유로운 연차 사용 및 야근 최소

  팀의 가치라기 보다는, 회사 분위기가 자유롭게 연차를 쓰는 분위기이다. 야근을 최대한 줄이고 부득이하게 프로젝트 일정상 야근이 필요하다면 주2회 정도로 제한을 주었다. 제한이라기 보다는, 왜 야근하는지? 무슨 일이 막혀있는지 같이 해결해주고 일정 조정해주는 역할을 수행하였다. 물론, 빡쎈 프로젝트가 있으면 어쩔수 없기는 하다. 어차피 시키는 일을 해야하는 직장인이기 때문에 사회생활은 쉽지는 않다. 부득이하게 야근이 많은 프로젝트의 경우에는 플젝 종료 후에는 반드시 재충전(리프레시) 할 수 있는 시간을 주도록 지원한다. 



  정리해보면 아래와 같다. 

자기조직화(Self-organizing) 팀

빠른 의사결정

간결하게, 가치있게, 하나씩 완성하기

상호 존중

자유로운 연차 사용 및 야근 최소화

  개발팀은 본부에서 연초에 수립한 계획에 집중한다. 기획 부서의 요구사항을 정해진 일정에 맞게 품질 높은 서비스를 신규 개발 오픈, 운영 하는 일이 주 업무이다. 하지만 이런 일을 다 수행한다고 해서 개발팀이 훌륭한 팀이라고 단정지어 말하기는 어렵다고 생각한다. 한 때는 팀원들에게 하는 일이 즐거운지? 재미있는지? 물어보곤 했다. 다행히도 팀원들은 YES 라고 대답을 했었지만 물론 항상 즐거울 수는 없다는 걸 잘 안다. 아니면 내 앞에서만 즐겁다고 대답했을 수도 있다. 모든일이 힘들지만 IT 업무 역시 스트레스도 있고 쉽지 않은 일이다. 


 지금 하고 있는 개발 업무가 즐겁나요? 라고 팀원에게 물어봤을 때 팀원의 대답이

네. YES 라는 대답을 할 수 있다면 그것만으러도 개발팀은 반은 성공이라고 확실하게 얘기할 수 있다. 


  하지만 내 자신도 즐겁게 잘 하고 있는지 확신이 들지 않고, 추상적이기도 하고, 논란의 여지가 조금 있어서 글을 쓸까말까 고민을 많이 했다. (참고로 이 글은 팀장이었을 때 쓴 글을 다시 옮긴 것이다.) 뭐 어쨋든 지난 경험에 대한 후기는 정말 중요하다고 생각하며 앞으로 발전해 나갈수 있도록 해야 한다. 너무 부족한 중간관리자 이지만 조금이라도 팀과 함께 성장할 수 있으면 좋겠다는 마음으로 글을 남겨본다. 


간결하게, 가치있게, 하나씩 완성하기... 그리고 즐겁게!! 








매거진의 이전글 IT 개발팀 조직문화 1년 후기(1)
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari