시스템 구축 가이드루브릭랩스···
출시 후 기능 요청을 고르는 기준
들어오는 요청을 모두 개발하면 기존 운영과 일정이 흔들릴 수 있습니다. 오류, 규칙 변경, 신규 기능을 나눠 우선순위를 정합니다.
미확인 사례와 성과 수치를 제외하고 업무 판단 가이드로 개정했습니다.
출시 후에는 실제 사용자가 처음 계획할 때 보이지 않았던 불편을 알려 줍니다. 요청을 그대로 개발 목록에 넣기 전에 어떤 업무가 막히는지 확인하는 과정이 필요합니다.
요청한 화면보다 문제를 기록합니다
'버튼을 추가해 주세요'라는 요청에는 사용자가 하려던 일과 현재 처리 방법을 함께 적습니다. 얼마나 자주 발생하는지, 누가 영향을 받는지, 우회할 방법이 있는지 확인합니다. 이 자료가 있어야 요청끼리 우선순위를 비교할 수 있습니다.
합의한 기능이 작동하지 않는 오류, 업무 규칙이 바뀌어서 필요한 수정, 새로운 업무를 지원하는 기능을 구별합니다. 구분이 애매하면 계약과 검수 기록을 함께 확인합니다. 유지보수 범위를 한쪽이 임의로 해석하지 않도록 처리 기준을 남깁니다.
바꾸지 않을 기능도 결정합니다
자주 쓰이는 업무를 막는 문제와 개인의 선호에 가까운 요청은 다르게 다룰 수 있습니다. 보류한 요청에는 이유와 다시 검토할 조건을 적습니다. 요청 창구를 모으고 최종 순서를 정할 업무 책임자를 두면 개발팀이 개별 요청자 사이에서 결정을 떠안는 일을 줄일 수 있습니다.
배포 전에는 바뀐 기능뿐 아니라 영향을 받는 주문, 재고, 정산 흐름도 확인합니다. 사용 방법이 달라지면 담당자에게 변경 내용을 알리고 문제가 생겼을 때 연락할 경로를 둡니다.
월별로 배포 건수만 세기보다 어떤 불편이 해결됐고 어떤 일이 남았는지 검토해 보세요. 다음 개발 범위는 그 기록을 바탕으로 정할 수 있습니다.