<길거나 혹은 짧은 회고>

#개발프로세스 #애자일 #오픈소스 프로덕트 디자인 업무를 하면서 개발과 디자인의 협업으로 인한 갈등은 누구나 겪을 것입니다. 그리고 어떤 프로세스를 차용하느냐에 따라 디자이너의 업무 프로세스도 변화를 갖게 됩니다. 또한 회사마다, 프로덕트마다 프로세스를 다르게 차용하고 있습니다. 여러분의 회사에서는 어떤 프로세스를 사용하고 있는지 궁금합니다. 😊 개인적으로 대략적으로 3개의 프로세스(애자일,폭포수,나선형모델)를 경험하면서 이 프로세스가 독이 되지않게 유연하게 대처하는 방법을 갖는 것도 경험의 스킬입니다. 생각해보면 애자일을 할 것인지, 나선형 모델을 할 것인지 개발프로덕트의 유형과 유저의 환경마다 프로세스가 각각 다르게 진행되어야 한다고 생각되어지는 요즘입니다. 다행히 현재의 오픈소스라는 환경이 프로세스가 갖고 있는 단점과 장애를 더욱 개선하기도 하고, 위험 요소를 줄일 수 있다고 생각했습니다. 그리고 무엇보다도 디자이너가 질문을 하는 이유는 제품의 성숙도를 높이기 위한 여러가지 차원에서 고려하기 때문입니다. 제가 가장 많이 경험했던 최소기능제품(mvp)를 개발하는 초기단계의 saas를 만드는 애자일 방식을 이야기해보고 싶습니다. 스타트업은 어느 정도 사용화를 갖춘 프로토타입으로 투자를 받고 싶고, 유저의 리텐션을 높이고 싶다는 것이 사업의 첫번째 목표입니다. 흔히 아는 애자일의 경우 정의된 기능과 디자인 화면이 나오고 분석된 개발을 토대로 스크럼일정이 정해지면, 일정대로 한 가지 혹은 두 가지의 기능을 추가해서 배포를 합니다. 그러면 디자이너 입장에서는 인체로 치자면 팔다리로 움직이면서 걸어야하지만 우선 다리로만 걸어다니는 프로덕트를 보고 있다는 것을 압니다.(아쉽다만 다음 태생(스프린트)에 더 멋지게 만들어줄께라는 소망을 하면서) 그리고 다음 스프린트를 진행하게 됩니다. 그러나 문제는, 유저의 만족지연을 선행한 프로덕트를 만들고 배포하였기 때문에 프로덕트 디자이너 입장에서는 그 결과에 따른 리텐션이나 드라마틱한 효과를 기대하기 어렵다는 것을 알지만 여전히 사업팀에서는 왜 이렇죠 라는 반문에 갈등시나리오가 생길 때가 있습니다. 그럼, 유저 리서치를 할까요? 라고 묻기 시작하여 유저의 피드백을 수집하고 수집된 의견을 본 사업팀에선 객관화하기 어렵다는 뜻으로 데이터의 결과가 무의미한 상황으로 빚어지곤 합니다. 그리고 "애자일은 유저의 의견을 수집하고 디벨롭한다"에서 텍스트를 본 인프제 성향의 디자이너는 더욱 마음 아파합니다.^^; 그렇게 애자일의 프로세스는 유저의 목소리가 아닌 내부 의사결정에 의해 만들어지는 프로덕트로 움직이고 있다는 사실을 깨달았습니다. 이것이 저에게 난관이었습니다. 그렇다면, 다른 프로세스가 매우 통찰력있는 피드백을 가져줄만한 프로세스인가라는 질문을 하자면 또 그렇다는 것은 아닙니다. 애자일의 특성이 좀 더 그렇다는 의견입니다. 그리고 종합적으로 견주어볼 때, 프로덕트를 개선하기 위해 프로세스도 중요하고, 협업과 소통, 리뷰가 계속적으로 다양하고 열린 자세로 일어나야지만 굉장히 기나긴 여정을 즐거운 퍼포먼스로 만들어낼 수 있다고 생각합니다. 물론 모두가 다 아는 이상적인 방향이지만요. 🤔 한 때의 짧고 여러 차례 스타트업의 개발환경과 , 지금은 좀 더 긴 장기프로젝트를 하면서 숨고르기를 하면서 저의 포지션을 고민하면서 개발 프로세스를 다시 한번 회고하게 되었습니다. 🙄 여러분의 조직은 어떻게 올 한해 시작하실까요? 비록 짧은 회고라 큰 도움은 되지 못했지만 지금 계시는 곳에서 대화,분석,통찰로 거듭나며 결정을 이루어내었으면 합니다.