애자일, 민첩하고 유연한 조직의 비밀(스티븐 데닝)
나는 스타트업에서 PM 직무를 맡고 있다. 주위에서 무슨 일을 하냐고 물었을 때 PM이라고 답하면 무엇을 하는지 모르는 사람이 많다. 맞다. 생소한 개념이다. 만만찮게 생소한 개념이 있다. 바로 '애자일'이다.
애자일이 뭘까.
애자일 하게 일한다는 것은 참 여러 의미를 담는다.(이것은 지극히 개인적인 의견이다. 그건 아니야 생각이 든다면 그 생각이 맞을 것이다.) 그 단어 자체가 가지는 스펙트럼이 넓어서라기보다는 아직 생소한 개념이다 보니 받아들이는 사람마다 해석하고 정의하는 개념이 달라서 인 것 같다.
나는 애자일이란 단어를 이렇게 정의한다.
"외부 변수에 유연하게 대응하고자 프로젝트를 짧게 진행하여 처리하는 방식"
스타트업에 있다 보면 정말 다양한 내외부의 변수를 만난다. 도대체가 뭘 하나 진득하게 진행할 수가 없다. 실컷 제휴사와 얘기가 오갔음에도 불구하고 프로젝트가 완료되지 않는 경우가 그렇고, 투자사로부터 텀싯 하나 받기도 정말 많은 시간이 걸린다. 외부 디팬던시(Dependency)가 높은 솔루션일수록 그 변수는 더욱 다이내믹하다. 어쨌든 그랬다.
그렇다고 매번 하는 일을 중간에 그만두고 새로운 일을 다시 찾고, 시작하고를 반복할 수 없다. 그래서 나는, PM으로서 나는 이렇게, 애자일 하게 일을 했다.
1. 인력과 시간이 가능한 선에서 몇 가지 프로젝트를 퍼러럴(parallel)하게 진행했다.
각 프로젝트의 사이즈가 크든 작든 중요하지 않다. 아니 중요하지만 2번째 이야기를 들으면 알게 된다. 스타트업은 무슨 프로젝트를 진행하든 완료가 되지 못할 가능성을 배제하면 안 된다. 그래서 이 프로젝트가 크다고 했을 때, '아 이거는 대형 프로젝트니까 모두 투입해서 진행하자'는 위험할 수 있다. 그런 식으로 진행하면 종국에는 남는 게 없을 수 있다. 결과가 없을 수 있다.
그것은 개개인에게나 회사에게나 뼈 아픈 패착이 된다. 성과가 없으면 다음이 없어진다. 때문에 몇 가지 프로젝트를 병행해서 진행해야 한다. 가능하면 그 몇 개의 프로젝트가 서로 시너지를 낼 수 있는 연결성이 있으면 좋지만, 극 초기라면 달라도 무방하다.
2. 프로젝트를 태스크(Task) 단위로 쪼개, 짧게 짧게 처리한다.
업무를 할 때는 관리를 위해 칸반 보드를 활용했다. 그리고 하나의 프로젝트가 있으면 주별로(스프린트) 진행할 태스크를 작은 단위로 쪼갰다.
예시) 프로젝트 : 아이폰 개발
1주 차
Task 1 : 타깃, 페르소나 설정
Task 2 : 광고 집행 계획
Task 3 : 디자인 레퍼런스 수집
2주 차
Task 1 : ...
Task 2 : ...
Task 3 : ...
위처럼 하나의 프로젝트가 있으면 그 안에 해야 하는 일을 모두 적는 것이 아니라 스프린트 별로 해야 하는 일을 쪼갰다. 그리고 각 주차에 완료하거나, 혹은 못한 일이 있으면 각각 회고했다.
그리고 만약 못한 일은 그다음 주차로 넘어간다. 기존 예정되어 있던 일은 우선순위를 고민하여 조정하거나 병행한다.
이러한 방법이 별 것 아닐 수도 있다. '우리도 그렇게 하는데?'라는 생각이 들 수 있다. 하지만 꼭 하나 말하고 싶은 것은 위와 같은 방식으로 하게 되면 결과와 기록을 남길 수 있다. 돌아봤을 때 '내가 뭘 했지?'라는 물음에 답을 줄 수 있다.
내가 했으면 어떻게 했고, 못했으면 어떠한 변수 때문에 못했는지에 대해서 명확하다. 또한 외부 변수에 대한 대응이 원활하다. 더 급한 일이 생기면 해당 Task나 프로젝트를 만들어서 진행하면 된다. 기존하던 일은 TBD(to be determined)가 된다.
이렇게 되면
1. 어떤 변수에도 유연하게 대응하고 적극적으로 일에 임할 수 있다.
2. 우선순위에 대한 고민과 판단이 빨라진다.
3. 팀원을 납득시키는 데에 많은 노력을 하지 않아도 된다.
나 역시 애자일을 나의 방식대로 정의하고 진행한다. 그렇지만 애자일이란 말을 남용하고 싶지는 않다. 그럼 뭐 어떤가. 애자일은 별 것 아니다. 판교 사투리에 주눅 들 필요 없다. 직접 경험해보고 보다 효율적이고 능동적으로 일할 수 있는 프레임 워크를 만들면 된다.
그것이 전부인 곳이다. 여기는.