Archive for the ‘팀’ Category
리더의 자세 2 – 사람은 나쁘지 않다
누구는 열심히 일하는 것 같고, 누구는 좀 노는 것 같은 느낌을 받을 때가 있다. 이런 경우에 쉽사리 사람 탓을 하기 쉬운데, 리더라면 환경의 탓을 먼저 생각해야 한다.
사람은 나쁘지 않다. 환경이 나쁘다.
이런 경험이 한 번 있었다. 어떤 사람은 좋은 제안을 많이 한다. 뭔가 팀을 위해서 적극적으로 공헌하는 느낌이다. 반면에, 어떤 사람은 팀 공동의 일에는 관심이 없어 보인다.
그 사람에게 개발 프로세스의 이벤트를 진행시키는 역할을 주었다. 그 역할은 이벤트를 진행시키는 것 뿐만 아니라 프로세스를 개선시키기 위해서도 노력해야 하는 역할이었다. 그 역할을 맡고 나서는 지속적으로 좋은 제안을 많이 해주고, 다른 사람들을 위해 궂은 일을 맡아서 하는 모습도 볼 수 있었다.
사람을 탓하기에 앞서서 그 사람이 능력을 발휘할 환경이 갖추어져 있는지 살펴봐야겠다. 업무 스타일이 성격과 안맞는 것은 아닌지, 동기부여가 안되고 있는 것은 아닌지, 업무의 난이도가 너무 낮거나 높지는 않은지, 그 밖의 어떤 이유로 업무 집중에 방해를 받고 있지는 않은지 등등.
리더의 자세 1 – 성장시키거나 받아들이거나
인수인계를 하려고 보니 이것저것 얘기해주고 싶은 것이 많다.
근데 내 생각들이 다 맞다는 보장도 없고, 블로그에나 좀 적어봐야겠다.
성장시키거나 받아들이거나
- 장기적인 안목으로 동료가 성장할 수 있도록 꾸준히 도와주거나
- 결과의 품질을 받아들이거나
지금보다 철이 없던 시절에는 "이렇게 하는 것 보다는, 요렇게 하면 더 좋을 것 같네요" 라고
조언을 하고는 했는데 몇 가지 문제가 생긴다.
- 내 제안이 나쁠 수도 있는데, 권력의 힘으로 강요하는 것이 될 수도 있다.
- 동료의 결과나 내 제안이나 사실 거기서 거기인데, 괜히 기분만 나쁘게 한다.
- 내 제안이 더 좋다고 한들, 언제까지나 일을 대신 해줄 수는 없다.
요점은 이렇다. 실무자들의 능력이 곧 팀의 능력이다. 리더가 아무리 실무를 기똥차게 한다고 해도, 모든 업무의 품질을 자신의 수준으로 끌어올리려는 것은 욕심이다. 이게 욕심이 아니라면, 아무나 뽑아서 좋은 리더에게 맡기면 된다. 굳이 개발자들이 몇 년씩 공부할 필요가 없다.
정리해보면.
동료가 더 좋은 결과물을 내놓기를 원한다면 성장시켜야한다. 이는 장기적인 관점에서 진행해야한다.
동료를 성장시킬 마음이 없다면 지금의 결과물에 만족해야한다.
당장 다그치는 것 만으로 좋은 결과물이 나오길 바란다면 아까운 인생을 허비하고 있는 셈이다.
스크럼 일기 3 – 모자
어떤 모자를 썼는지 명확하게 하자
자격증을 가진 스크럼 마스터가 있는 것도 아니고 기존의 조직 체계도 있다보니 한 사람이 여러 역할을 맡을 수 밖에 없다. 우리 팀장님은 실장님, 팀장님, 프로덕트 오우너, 경력많은 개발자(조언자) 역할을 해야하고, 노예형 스크럼 마스터는 개발자 역할을 병행해야 한다.
그러다보니 지금 “경력많은 개발자”의 모자를 쓰고 조언을 해주는 것인지, “프로덕트 오우너”의 모자를 쓰고 요청을 하는 것인지 오해가 생기기 쉽다. 이렇게 설계하는게 좋았다라는 경험을 말해주는 것 뿐인데, 명령으로 받아들여 프로덕트 백로그에도 없는 일을 열심히 하고 있는 불상사가 생길 수도 있다.
지금 어떤 모자를 쓰고서 말하는 것인지 오해하지 않도록 서로 신경 쓸 필요가 있다.
스크럼 일기 2 – 프로덕트 로그
프로덕트 로그도 점진적으로 발전한다
개발팀에게 전달되는 요구사항이나 스펙이 완벽하지 않다고 불만을 가질 일이 아니다. 좋은 설계를 반복없이 한 번에 만들어 낼 수 없는 것처럼 좋은 프로덕트 로그도 한 번에 만들어 낼 수 없다.
보통 고객이란 불특정 다수이므로 완벽한 요구사항을 건네줄 사람이 있는 것도 아니고, 개발 도중에도 시장환경이나 조직의 상황이 계속 변하므로 스펙이나 우선순위 조정이 불가피하고, 기술적인 한계나 복잡성에도 영향을 받는데 이는 개발팀이 연구, 조사, 스파이크 같은 것을 해봐야 알 수 있는 것이라 초기에는 예상하기 힘들다. 이런 이유들로 처음부터 완벽한 프로덕트 로그를 만드는 것은 어렵다.
지난 글에서는 오우너와 개발팀의 역할을 명확히 나눠야 한다고 했지만, 기술적인 한계, 기술의 장단점과 같이 오우너가 프로덕트 로그를 개선하는 것을 돕기 위해서 개발팀이 오우너에게 제공해야 하는 정보도 있다. 다시 말해 개발팀도 좋은 프로덕트 로그를 만드는 일에 일정 부분 공헌할 필요가 있다는 얘기. (스프린트 준비회의에서 많은 대화가 필요하다.)
프로덕트 로그가 완벽하지 않다거나, 자주 변한다고 투덜대지 말자.
스크럼 일기 1 – 역할
새해가 되어 스크럼마스터와 새 스크럼을 구상하면서 그동안 잘못해오던 것들이 몇 가지 드러났다. 작년에도 많은 교훈을 얻었는데 적어두지 못한게 아쉽던 터라, 올 해는 같은 실수를 반복하지 않도록 잘 적어두기로 했다.
프로덕트 오우너와 개발팀의 역할을 명확하게 하고 그에 맞는 정보를 줘야 한다.
좀 당연한 얘기라서 쑥스럽지만 ^^;; 일단 프로덕트 오우너(이하 오우너)란 우리말로는 “제품 책임자”. 제품의 스펙을 결정하고, 스펙 중에 우선순위를 결정해주는 사람이다. 개발팀은 당연히 제품 책임자에게 요청받은 스펙을 구현하는 사람들.
역할을 명확하게 하는 것이란?
다른 말로는 “책임”과 “권한”을 명확하게 하는 것. 예를 들면 아래와 같이,
- 오우너는 개발팀에게 A라는 스펙을 주고 구현할 책임을 준다
- 개발팀은 A라는 스펙을 어떻게 구현할지 결정할 권한을 갖는다
역할이 명확하지 않은 경우에 발생하는 현상
- 개발팀이 책임 이상의 것을 하거나, 요청받는 경우
- 개발팀이 A라는 스펙이 올바른 것인지 고민하고 있다
- 개발팀에게 A라는 스펙을 올바르게 수정하기를 요구한다
- 오우너가 책임 이상의 것을 하거나, 요청받는 경우
- 오우너가 구현 방법에 대해 일일이 관여한다
- 오우너에게 구현방법에 대해서 일일이 물어본다
- 책임이나 권한이 있는 것 같은데, 막상 정보가 부족하다
- 개발팀이 A라는 스펙을 개선하기에는 프로젝트의 비전, 사업 우선순위에 대한 정보가 부족하다.
해결책은?
- 개발팀이 A라는 스펙이 올바른가 고민하지 않기를 바란다면, 그 사실을 명확히 하고 합의한다.
- 개발팀이 일정부분 스펙을 수정해주기를 바란다면, 그 사실을 명확히 하고 필요한 정보를 준다.
- (위 그림의 파란박스에서)개발팀이 어느 높이까지 책임과 권한을 갖는지 명확히 하고 합의한다.
- 개발팀의 역할을 수행하는데 필요한 프로젝트의 목표, 비전, 가치, 우선순위와 같은 정보 제공한다.
- 개발팀이 구현 방법에 대해서 오우너에게 물어본다면
- 역할을 명확하게 해서 개발팀 스스로 판단할 권한이 있음을 주지시킨다.
- 혹은 판단하기에 충분한 정보를 주지 않은 것은 아닌지 확인한다.
현실에서는 알아차리기 힘들 수 있다
“오우너가 스펙을, 개발팀이 구현을”. 설명을 쉽게하려고 이렇게 말했지만 좀 더 원칙적으로 얘기하면 “오우너가 더 추상적인 스펙을, 개발팀이 더 구체적인 스펙을”이 되어서 현실에서는 구분이 어려울 수 있다.
스펙이 “폰트를 바꾸는 기능 추가”와 같이 유저 관점의 기술(記述 description)인 경우에는 구분이 명확하지만, 스펙이 “3가지 DB 지원”과 같이 기술(技術 technology)적인 경우에는 헷갈리기 쉽다. 그래서 라이브러리나 미들웨어 같이 제품을 쓰는 사람도 개발자고, 만드는 사람도 개발자인 경우에는 스펙과 구현의 선을 명확히 긋고 역할을 합의하는 일이 중요한 것 같다.
마무리
오우너가 자꾸 이상한 일을 시킨다거나, 개발팀이 원하는 일을 해오지 않는다거나 하는 문제가 생겼을때는 각자의 자질을 의심하기 보다는 역할을 명확히 합의했는지 확인해 볼 일이다.