[당신이 해결하고 있는 문제, 정말 그 문제가 맞나요?]

고객사의 숨겨진 요구사항이 발견될 경우 기민하게 대처해야 하는 것과 새로운 도메인(ai 음성봇) 이라는 것, 이 두 개의 특징에 대응 하기 위해 우리 조직은 에자일 방법론을 채택했다. 하드웨어에 비해 소프트웨어는 요구사항이 프로덕트에 빠르게 반영될 것이라는 이상한 시장 논리로 인해 오늘도 소프트웨어 엔지니어들은 갈려나가고 있다. 또한 새로운 도메인은 초장에 완벽에 가까운 설계를 하고 워터풀로 개발을 하기에 매우 부적절하다. 이러한 특성에 대응하는 방법 중 하나로 '에자일'이라는 방법론이 탄생한 것으로 이해하고 있다. 개인적으로 우리 조직의 상황에 적합하다고 생각한다. 이러한 상황에서 요즘 내가 가장 집중하는 것은 '문제 정의'다. 하나의 기능을 이용자 혹은 사용자에게 딜리버리하기 까지의 과정은 다음과 같다고 생각한다. '요구사항 분석' - '기능 도출' - '기능 설계' - '개발' - '테스트' - '배포' 이 중 아마 '요구사항 분석'이 '문제 정의'와 가장 근접한 단계일 것이다. 나의 (짧은) 경험상 고객이 전달한 하나의 요구사항이 그대로 하나의 문제로 직결되는 경우는 많지 않다. 대부분의 요구사항은 여러 문제를 혼재하고 있다. "요구사항이 담고 있는 문제를 잘 분리하는 작업". 이것만 잘해도 아주 훌륭한 소프트웨어 엔지니어라고 할 수 있지 않을까 한다. 위 작업만 잘하더라도 어쩔 때는 요구사항이 잘못 되었다는 것을 인지하고 고객 인터뷰를 다시 할 수도 있다. 혹은 요구사항이 담고 있는 여러 문제 중 하나의 문제만 해결하더라도 고객을 만족시킬 수도 있다. 또는 요구사항을 해체해서 여러 개의 문제로 분해해두고 바라보면 전혀 새로운 문제를 정의해서 새롭게 접근하여 고객의 요구사항을 고객의 기대 이상으로 풀어내버릴 수도 있다. 정공법으로 문제를 해결할지 편법으로 문제를 해결할지, 이에 대한 결정은 문제 해결 능력에 달려있겠다. 이러한 작업이 끝나면 '기능 도출'까지 끝날 것이고, 이후는 '문제 해결'의 영역이라고 생각한다. 반대로, '문제 정의'를 잘못 할 경우, 프로덕트는 나락으로 떨어지고 프로젝트는 파국으로 치닫을 수 있다. 당연한 논리다. 문제 정의를 잘못하면 요구사항을 해결하는 기능이 아닌 전혀 별개의 기능을 개발하게 되고, 리소스는 소비했지만 업무 진척도는 나아지지 않는다. 산출물은 쌓이는데 시장과는 멀어진다. 우리 프로덕트 이런 것도 되고 이런 것도 돼요! 훌륭한데 사람들이 안쓰네! 이거 기획자 문제 아니야? 라고 한다면... '문제 정의를 제대로 하지 못한 우리네 책임도 크다'라고 말해주고 싶다. '문제 정의' 아주 중요하다고 생각하며 경력에 상관없이 '문제 정의'는 모두가 해야할 업무라고 생각한다. PS. 주니어의 관점에서 '문제 정의' - '문제 해결' 단계를 유연하게 연결해주는 도구가 설계에 앞서서 진행하는 '테스트 코드 설계' 작업이라고 생각한다. 이에 대한 글은 이후에..