제품과 제공 · 사업과 부

프로젝트 시작부터 화면을 그리면 일이 시작되었다고 느끼기 쉽다. 버튼, 색, 배치가 생겨 손에 들고 논의하기도 좋다. 하지만 화면은 완전해도 안의 사람이 어떤 일을 끝내야 하는지는 여전히 불분명할 수 있다.

먼저 몇 가지를 밝혀야 한다고 생각한다. 누가 언제 쓰며 이 단계 뒤 어디로 가는가? 기능 이름은 목차일 뿐이며 기능이 어떻게 이어지는지가 사용 가능성을 정한다. 사용법의 이해가 다르면 세밀히 그릴수록 나중에 뒤집을 부분도 늘 수 있다.

설계에 들어갈 때 구체적인 상황 하나를 먼저 따라가 보자. 각자가 무엇을 제공하고 보고 마지막에 얻는지 밝히며 이해가 다른 곳을 곧바로 기록한다. 핵심 문제가 확정된 뒤 화면으로 바꾸면 소통에 공통 근거가 생긴다.

물론 그려야 보이는 생각도 있다. 그때는 문제 발견용 초안을 그리되 최종안으로 서두르지 마라. 준비 정도는 다음에 해결할 것에 달려 있다. 설계를 요구 확인 도구로 삼는 것과 확인 안 된 설계를 개발 지시로 삼는 것은 영향이 다르다.

불편하다는 말은 여러 일을 가리킨다. 조작법을 모르거나 오류를 겪거나 흐름이 매끄럽지 않거나 없던 기능을 원할 수 있다. 모두 수정 목록에 넣으면 팀은 곧 바빠지지만 같은 유형의 문제를 풀고 있는 것은 아닐 수 있다.

문제를 만나면 나는 먼저 종류를 나누려 한다. 조작에 익숙하지 않으면 설명과 교육이, 약속한 기능이 안 되면 수리가, 사용 과정이 불합리하면 설계 점검이 필요하다. 새 생각은 요구를 다시 논의해야 한다. 처리 방식이 다르면 참여자와 완료 기준도 다르다.

문제를 제기할 때는 무엇을 했고 기대했으며 실제 무슨 일이 생겼는지 최대한 밝히자. 재현할 현상을 남겨 관련자에게 확인하게 하라. 논의가 편한지 아닌지에서 어디가 문제인지로 나아가고 변경이 기존 사용에 영향을 주는지도 판단하기 쉽다.

분류는 수리를 대신하지 못하고 지연의 이유도 될 수 없다. 분명한 것은 추진하고 불분명한 것은 제때 확인하자. 특히 모두 사용자가 못 쓴다고 해서는 안 된다. 제품이 피드백을 잃는다. 구분은 우회를 줄이고 진짜 해결할 일을 처리하기 위해서다.

기능 하나는 정상이어도 전체 일은 못 끝낼 수 있다. 자료 제출이 된다고 다음 사람이 받는 것은 아니며 주문 생성이 된다고 후속 처리가 보장되는 것은 아니다. 화면별로만 테스트하면 화면, 사람, 상태 사이 문제를 놓치기 쉽다.

그래서 나는 업무가 끝까지 어떻게 돌아가는지 더 본다. 실제 사용자의 자리에서 현실에 가까운 데이터로 시작, 처리 중, 끝까지 가 보자. 누가 조작하고 기다리며 문제가 생기면 처리하는지 같은 흐름에서 보아라. 기능의 존재와 업무의 완료 가능성은 따로 확인해야 한다.

테스트도 개발 진도에 따라 갈 수 있다. 완성 부분부터 점검하고 연결할 흐름부터 이으며 문제를 기록해 알리자. 모두 끝난 뒤 처음 쓰면 앞에서 잘못 이해한 것이 마지막에 몰려 나오고 제때 조정할 수 있던 일도 급해진다.

불완전한 버전을 곧바로 모두에게 써도 된다는 뜻은 아니다. 준비가 부족하면 표본 데이터로 명확한 범위에서 시험하고 안 되는 단계를 알아두면 된다. 단계 테스트는 조기 발견을 돕지만 최종 검수는 약속한 전체 용도로 돌아와야 한다. 화면으로 판단하기는 줄이고 일을 따라가는 것은 늘리자.

제품 논의에서는 생각이 늘어나기 쉽다. 누구나 그럴듯한 기능을 보태고 목록에서도 불필요해 보이지 않는다. 하지만 실제 설계, 개발, 테스트, 유지보수에는 담당자가 필요하다. 겹쳐 쌓이면 제품이 늘 조금 모자란 단계에 머물 수 있다.

현재 해결할 문제로 돌아가야 한다고 생각한다. 이 기능 없이 주된 사용 흐름을 마칠 수 있는가? 이미 생긴 문제인가, 상상 속에 생길지도 모를 문제인가? 없어도 주 용도가 된다면 기록해 두고 실제 사용에서 명확한 피드백을 얻은 뒤 판단할 수 있다.

덜어 낼 때도 이유를 말해야 한다. 무엇을 남기고 미루며 왜인지 참여자가 알게 하라. 완성된 부분은 고칠 문제를, 안 한 부분은 진짜 부족한 기능을 나열하자. 둘을 나눠야 다음이 기존 제품 보완인지 범위 확대인지 팀이 안다.

덜 한다고 기본 품질을 낮추는 것은 아니며 급한 일정으로 핵심 흐름 미완료를 설명할 수 없다. 현재 단계에 필요한 완전함은 지켜야 한다. 실제 사용에 영향을 주는 곳에 힘을 쓰는 것이 풍성해 보이는 기능을 계속 더하는 것보다 전달 가능한 결과에 가까울 때도 있다.

다른 업체의 새 기능을 연구할 필요는 있다. 하지만 왜 만들고 어떤 사용자와 업무를 위한 것인지 모두 알지는 못한다. 버튼 하나를 보고 서둘러 더하면 우리 제품이 경쟁사 기능 종합표처럼 될 수 있다.

갱신은 자신의 사용 과정에서 시작해야 한다고 생각한다. 업무가 변했는지, 고객이 반복해 묻는지, 기존 흐름 어디가 불편한지 보자. 그런 뒤 외부 제품이 비슷한 문제를 푸는 법을 보아라. 얻는 것은 반드시 따라갈 이름이 아니라 비교할 방법이다.

새 기능 논의에서는 기존 흐름과의 연결도 점검해야 한다. 누가 쓰고 어떤 자료가 필요하며 끝나면 누구에게 영향을 주는가? 이를 모르면 기능과 함께 사용 난도도 늘 수 있다. 운영상 실제 필요가 분명해야 기술 갱신의 방향도 비교적 안정된다.

외부 혁신이 못 보던 필요를 일깨울 수는 있다. 구체적인 상황에서 먼저 이해한 뒤 채택할 가치가 있는지 판단하자. 업계를 살피면서 자신의 선택도 남겨라. 제품은 계속 변해야 하지만 매번 누구의 어떤 일을 더 잘하게 하는지 답할 수 있는 것이 좋다.