종료되지 않는 모바일 앱 요구사항의 추억
기획팀은 처음으로 요구사항이 도착하는 곳입니다. 그런데 만약 불가능한 요구사항이 기획팀에 도착하면 어떻게 해야 할까요?
작년(2023년) 초에 겹치지 않는 UID를 수동 생성하는 요구사항을 소개했습니다. 이 글의 사례 자체는 별로 중요하지 않고 엔지니어 관점에서 기술적으로 해결해 앞으로 수많은 시간을 절약할 수 있는 요구사항을 다른 부서 사람들이 수동으로 대응하게 만들어 앞으로 수많은 시간을 낭비하게 만들고 또 실수를 유발해 거대한 비용을 낭비하려는 시도와 이를 지금 생각하면 조금 공격적인 방법으로 틀어 막은 이야기라는 점이 중요합니다.
이런 이상한 시도는 인터넷에서 흔히 접하는 능력 있는 엔지니어님들의 말씀과 상당히 다른 경험이어서 처음엔 우리들이 지금 무슨 일을 당하고 있는 것인지 잘 인식하기조차 힘들지만 조금만 시간이 지난 다음 돌아보면 인터넷에서 흔히 접하곤 하는 능력 있는 엔지니어님들을 만나 우리들이 함께 일할 수 있는 가능성은 생각보다 그리 높지 않다는 사실을 알 수 있습니다. 엔지니어님들이 중요한 의사결정을 하고 우리들의 생산성이 이에 따라 큰 영향을 받으며 나악 우리들의 생산성은 프로젝트의 개발비용을 통제하는데 엄청난 영향을 끼쳐 결국 프로젝트의 성공과 실패를 나누게 되지만 지금 당장의 의사결정이 거기까지 영향을 기친다는 사실을 인지하기는 쉽지 않습니다. 그러니 위에 소개한 기술적으로 대응할 문제를 사람이 직접 해결하도록 만드는 이상한 시도가 일어날 수 있게 됩니다.
오늘은 오래 전에 모바일 게임을 만들다 맞닥뜨린 이상한 요구사항을 소개할 작정인데 앞서 작년에 소개한 사례가 엔지니어 관점에서 기술적으로 해결해 미래의 큰 비용을 절약하고 필요 없는 실수를 절약할 수 있는 방법이 있음에도 이를 다른 부서에 수동으로 수행하도록 요구하는 것이었다면 이번에는 기획 관점에서 기술적인 이해가 부족한 상태에서 겪은 한 가지 경험을 기술적으로 가능하다고 믿고 이를 요구하며 여러 부서에 큰 비용을 낭비하게 만든 사례입니다.
