[번역] 디자이너 좀 더 고용하세요, 네?
본 글은 John Cutler의 'Hire More designers, OK?'를 번역한 글입니다. 글 안에 사진이 포함되어 있지만, 동영상으로 보는 것이 이해가 훨씬 쉽기 때문에 영상과 함께 읽는 것을 추천합니다.
실제로 많은 스타트업에서 개발자 채용에 공을 들이는 것에 비해, 디자이너 채용이 왜 필요한지, 얼마나 중요한지 잘 모르고 있다고 생각합니다. 소수로 일하는 디자이너는 흔히 말하는 '팀 내 외주인력'처럼 변하기 쉽고, 한국에서도 많은 스타트업의 디자이너가 이로 인한 문제 상황을 겪고 있지 않을까 싶어 글을 번역하게 되었습니다.
이 글에 말하듯 실패는 느리고 알아채기 어려운 순간에 다가옵니다. 너무 늦기 전에 이 글의 제목처럼, 이제 디자이너 좀 더 고용합시다.
디자이너 좀 더 고용하세요, 네?
이 짧은 비디오에서, 저는 당신이 더 많은 디자이너를 고용하고 그들을 팀에 포함하도록 설득할 것입니다.
생산적이고 능력 있는 디자이너들은 훌륭한 제품을 만드는 데 꼭 필요합니다. 하지만 디자이너들을 당신의 팀에 녹아들게 만들려면 기술이 필요합니다. 잘못된 경우, 디자이너들은 다른 팀으로부터 격리되고 결과적으로 디자인 퀄리티, 흐름 및 전체적인 팀의 단합력에 영향을 미칠 수 있습니다. 이 비디오에서, 저는 당신에게 디자이너들을 고용할 때 제품 팀이 직면하곤 하는 일반적인 시나리오를 소개할 것입니다.
비디오 보기
숙련된 소프트웨어 개발자들로 구성된 소규모 팀에 오신 것을 환영합니다.
이들에게는 훌륭한 스타트업 아이디어가 있지만, 문제가 있습니다. 디자이너를 꼭 채용해야 했기에, 그렇게 했죠. 바로 펠릭스를 고용했습니다. 펠릭스는 팀과 함께 앉아 매일 개발자와 짝지어 일하고, 그들의 프로덕트는 견인력을 얻기 시작합니다. 팀은 두 명의 개발자를 더 고용합니다.
이 시점에서, 팀은 하나의 할 일 리스트를 기반으로 작업을 진행합니다. 펠릭스는 디자인과 관련된 작업 항목에 자신의 할 일을 추가합니다. 팀은 더 많은 개발자를 고용합니다.
펠릭스는 일손이 꽉 찼지만, 아직 감당할 만은 합니다. 리스트에 어떤 일들이 있는지 알고 있다면, 그의 시간과 에너지를 어떻게 효율적으로 쓸지 관리할 수 있습니다.
어떤 시점부터는 8명의 개발자를 한 팀으로 운영하는 것이 어려워지고 팀은 이들을 4명의 두 팀으로 분리합니다. 펠릭스에게 일어난 변화는 크지 않습니다. 몇 가지 예를 들자면, 그는 이제 두 개의 스탠드업과 다른 공동의 미팅들에 참석해야 합니다.
이제 그는 각 팀의 리스트를 파악하기 위해 두 개의 보드를 살펴봐야 합니다. 펠릭스는 다른 여러 가지 일을 오가는 빈도가 늘어나고, 관리 비용 또한 증가합니다.
이전에 펠릭스가 팀 동료들과 함께 자신 있게 일을 시작할 수 있었던 반면에, 이제 그의 스케줄이 정신없이 바빠지기 시작하면서 미리 작업을 진행하고, 어떻게든 일을 끝내려고 애쓰고, 작업을 개발자에게 넘기기 이전에 디자인을 끝내는 방향으로 일을 하게 됩니다.
이상적인 상황은 아니지만, 펠릭스는 그렇게 할 수밖에 없습니다. 그렇지 않으면 펠릭스는 자신의 시간을 확실하게 관리할 수 없으니까요.
이제, 펠릭스는 자신만의 리스트를 운영하기 시작합니다. 그의 리스트에 있는 할 일들은 다른 사람의 할 일 리스트와 연결되어 있습니다. 그는 아직 자신을 팀의 일원이라고 생각하지만, 조금씩 팀과 멀어지기 시작합니다.
또 다른 문제가 일어나기 시작합니다. 펠릭스는 할 일들의 상대적인 우선순위를 모른 채로 남겨집니다. 그가 비슷한 일들의 잠재적인 가치에 대해 비교할 방법이 없기 때문입니다.
펠릭스의 시간은 소중하기에, 일의 양을 추정하고 여러 가지 일을 하나로 통합하는 것이 점점 중요해집니다 펠릭스는 자신의 스케줄 안에 이를 다 구겨 넣어 보려고 애를 써봅니다. 펠릭스는 할 일들을 가지고 테트리스를 쌓을 수밖에 없고, 이는 즉각적인 요구를 처리하거나 협업할 만한 유연성은 훨씬 더 적어진다는 걸 의미합니다.
동시에, 팀은 스케줄을 꽉꽉 채워 넣기 시작하고, 그 덕에 협업이나 이터레이션을 더욱더 어렵게 만듭니다.
이전에는 자주 배포하고, 이터레이션을 돌리고, 결과물에 집중했던 것에 비하여 지금은 프로젝트를 한 번의 주기로 내보내고 즉시 다음 프로젝트로 넘어갑니다.
이제 아주 점진적인 하락세를 관찰할 수 있습니다. 펠릭스가 점점 고립된 채 개발 전에 먼저 작업을 진행하고, 솔루션에 집중하는 모습이 보입니다. 일을 다른 사람에게 넘기는 경우나 일정으로 테트리스 쌓는 일이 잦아집니다. 이렇게 테트리스를 쌓는 일이 일어나면, 사람들은 한 주기에 더 많은 일을 채워 넣습니다. 한 주기의 크기는 늘어나고, 실험과 이터레이션은 줄어듭니다.
이러한 일련의 일들은 디자인 퀄리티를 저하하고, 임팩트를 줄이고, 팀의 결속을 낮추고, 일의 흐름과 속도를 늦춥니다.
당신은 이제 모든 게 명백하니, 스타트업은 그저 팀에 넣을 디자이너를 더 고용해야 한다고 생각할 겁니다. 서두르지 마세요. 이런 현상들이 일어나기 시작했을 때의 흔한 반응은 디자이너 대신에 개발자를 더 고용하는 것입니다.
이런 일이 일어난 이유 중 하나는 펠릭스가 아마 몇 번이나 잠재적인 위험을 경고했음에도, 그 또한 현실적인 사람이고 현 상황에 익숙해졌기 때문입니다. 아주 망가진 상황은 아니라고 느껴집니다. 팀의 크기가 커지면서 생산성이 떨어지기 시작하고, 효율성은 처음에는 오르나 전반적으로 떨어지기 시작합니다.
모든 사람의 시스템에 대한 이해도가 떨어집니다. 그 마지막 부분은 매우 중요합니다. 점점 대체 무슨 일이 일어나고 있는 건지 이해하기가 어려워집니다.
펠릭스가 마침내 다른 디자이너들을 고용했을 때, 그는 이것이 모두가 기대했던 만큼 큰 도움이 되지 않는다는 것을 알게 됩니다.
왜 그럴까요? 조직 전체가 지금의 일하는 방식에 적응해있습니다. 펠릭스의 상황 또한 아마 그리 특이한 경우는 아닐겁니다. 종종 같은 일이 ops 테스팅, 데이터 사이언스 그리고 프로젝트 매니저 같은 다른 직군에서도 일어납니다.
각각의 경우, 상황을 잘못 파악하고 증상을 고치려고 하기 십상입니다. 여기서 우리가 할 수 있는 게 뭘까요? 이런 상황은 그냥 피할 수 없는 걸까요? 다시 요약해 봅시다.
펠릭스는 처음에는 진정한 팀원으로 시작했습니다. 그리고 자신의 시간을 두 팀으로 나눠서 쓰기 시작했지만, 그의 능력을 최대한 발휘하는 데 성공했습니다. 그리고 요구사항과 팀의 크기가 커지자, 그는 다른 팀들의 요청사항을 받아내면서 자신만의 리스트를 운영하기 시작합니다. 결국 펠릭스는 영원히 앞단에 선행해서 일하는 포지션으로 자리를 잡게 됐습니다.
당신이 할 수 있는 첫 번째 일은 전체 시스템을 시각화하는 것입니다. 나는 이렇게 생각합니다. 사람들이 여러 팀 간에 공유될 때마다 하나의 큰 팀이 만들어집니다. 좋든 싫든 간에요. 펠릭스가 무척 바쁘다는 건 금방 알 수 있습니다.
이 복합적인 보드가 미션을 어떻게 다루고 있는지, 그리고 팀들이 이 미션들을 실현하기 위해 하는 일이 무엇인지에 주목하세요. 이런 식으로 작업을 시각화하면 실제로 무슨 일이 일어나고 있는지 알 수 있습니다. 일들 사이에 공간이 보입니다. 우리를 제한한다고 생각하는 것이 실제론 우리를 제한하고 있는 게 아닐지도 모릅니다.
우리가 할 수 있는 또 다른 일은 우리의 제품 결정을 검토하는 것입니다. 일이 제대로 돌아갔나요? 오직 20%의 노력만이 실제로 결과를 창출한다고 쳤을 때, 효율성을 내는 건 아마도 당신의 문제가 아닐 것입니다. 개발자를 더 데려오는 것은 도움이 되지 않습니다. 픽셀을 더 예쁘게 만드는 것도 아마 도움이 되진 않을 겁니다. 당신은 더 나은 제품 결정을 내려야 합니다.
여기에 도움이 되는 것은 팀의 충분한 디자이너 동료들과 함께 연구와 발견을 해나갈 권한이 주어진 디자이너입니다. 우리는 사실 덜 복잡한, 더 좋은 결과물을 원합니다. 우리는 더 빨리 배우고 싶습니다. 복잡함을 더 늘리고 싶지 않습니다.
펠릭스가 한 것처럼 앞단에서 선행해 작업함으로써 상황을 안정시키고 싶은 유혹이 들 수도 있습니다. 실제로 이 방법은 디자인이 반복되는 주기에서 뒤처지지 않도록 보장해줍니다. 이 방법은 디자인의 통제권을 줍니다. 팀이 프로덕트를 출하(deliver)하는 데에 집중하는 상황인 경우에는 어느 정도의 관리를 보장하지만, 이는 그저 임시방편일 뿐입니다. 진짜 문제를 해결하지는 못합니다. 곧 팀은 이 임시방편일 뿐인 방식에 맞춰서 최적화됩니다.
그 대신에 어떻게 의미 있는 미션에 맞춰 일의 범위를 정할지 알아보십시오. 함께 시작하고 함께 프로젝트를 킥오프하세요. 함께 발견하고 함께 일하세요. 결과를 측정하세요. 단 한 번의 노력으로 이게 가능하다고 해도, 그만한 가치가 있습니다.
요약하자면, 실패로의 표류는 때로 느리고 알아채기 힘들다는 걸 기억하세요. 적극적으로 저항해야만 합니다. 때로는 말이 안 되는 일을 하고, 속도를 늦추고, 엉망진창인 상태를 받아들여야 할 겁니다. 팀 전반에 걸쳐 일을 시각화하십시오. 점검하고 조정하십시오. 정답이란 건 없습니다.
심지어 동시에 여러 가지 운영 모델을 돌려야 할 수도 있습니다. 가능할 때마다 함께 시작하고, 함께 일하세요. 그리고, 자자, 디자이너를 더 고용하세요.
