많은 개발자분들을 만나서 이야기를 해보면 본인의 잘하는 부분에 대해서 이야기를 할때가 있다.
"저는 풀스택이에요. 백엔드 프론트 모두 할 수 있어요"
"(어떤 기술에 대해서)그건 쉬워요. (여차저차) 금방 구현할 수 있어요"
"이미 클라우드에 모든걸 사용하고 있습니다. 저희 시스템은 엄청 복잡해요"
주로 기술에 대한 프라이드와 본인이 핸들링 해본 영역에 대해서 이야기하는 개발자들이 많지만, "크고 작은 (사회적, 비즈니스적, 아이디어 등)문제를 제대로 해결해 보았어요"라고 이야기를 하는 사람은 많지 않았다. 개발은 특정 문제를 해결하는 하나의 방법이고, 개발자로써 테크닉 실력을 키우는것도 중요하지만, 특정 문제를 제대로 이해하는 자세, 방법을 갖는것도 필수 능력이다.
다양한 비즈니스, 도메인 생각해보기
개발자가 소속해 있는 회사 또는 창업한 회사에서 다루는 비즈니스 이외의 다양한 도메인 영역을 다뤄보기는 쉽지 않다. 그래서 주변에 개발자 친구들이 있다면 그들이 어떤 일들을 하고 있는지, 특히 어떤 문제를 보고 있고 그 문제를 어떻게 해결하고 있는지 이야기를 많이 나누면 좋다. 그들의 비즈니스 이해도를 내가 깊게 이해하려고 노력할수록 나의 간접적 경험이 될 수 있다. 또한 다양한 문제를 해결하는 스타트업들의 인터뷰 기사들을 보고 깊게 이해하려고 하면 도움이 된다. 스타트업들은 대기업과 달리 매출 중심의 사업이라기 보다는, 초반에는 쉽게 해결하지 못했던 문제를 똑똑하게 해결하려고 할것이다. 이러한 스타트업의 인터뷰를 보면 내가 처음보는 문제들도 알게되고, 그 문제에 대한 파운더의 철학과 생각, 그리고 그걸 어떻게 해결하려고 하는지도 자세히 알 수 있다.
솔루션을 사용하는 고객의 최종 모습 상상하기
개발자들이 개발 스프린트를 하면서 '다했다' 라는 표현은 단순히 '코딩을 완료했다' 의 의미다. 하지만 '코딩을 완료했다'와 그 기능을 사용하는 '고객의 만족도'가 크게 차이가 날때가 많다. 이는 개발자들이 해당 비즈니스 문제를 사용하는 '고객 모습' 을 생각하지 않기 때문이다. '코딩을 완료했다' 이후에 테스트를 하면서 '고객의 모습'을 테스트 내내 상상하며 디버깅을 해야한다. 처음에는 그 상상력이 충분하지 않겠지만, 나중에 상당히 디테일한 고객 상상 능력을 갖추게 되면, '코딩 완료'는 '고객의 만족도'와 1:1 이상의 비율로 일치하게 될것이다.
Requirements Engineering
Computer science 전공 출신이더라도 학교에서는 잘 가르치지 않는 분야인데, 비즈니스에서 요구사항을 제대로 듣고, 제대로 이해하고, 제대로 정제하고, 제대로 문서화 또는 표현하는것은 정말 중요하다.
보통 client들, stakeholder들은 본인들이 뭐가 불편한지, 뭐가 필요한지 표현은 하지만, 그게 정확한 문제의 포인트가 아닐 수 있다. 이 단계는 단순히 문제 인식정도의 단계이며, 이 요구사항을 더 자세히 분석하고, 유저 스토리를 상상하고, 문제에 대한 모델링을 하여, specifications을 도출하고, 그 specs에 대한 validation까지의 일련의 요구사항을 다루는 매니지먼트를 배울 수 있다.
PO, PM 포지션들 뿐만 아니라 개발자, 더 나아가서는 제품을 만드는 모든 사람들이 이 과정에 대해서 이해하고 있으면 일이 더 수월하게 진행될 것이다.
단순 코딩 구현을 넘어, 고객 만족까지 가기 위해서는 제대로된 이해가 필요하다. 다양한 도메인에 대한 이해의 폭이 넓고 깊은 사람일 수록, 솔루션 구현에 있어서 더 쉽게, 더 간결하게, 더 정확하게 진행될 수 있으며, 이는 고객 만족 100%에 가까운 software delivery를 할 수 있게 된다.