누가 앱을 쓰는지 어떻게 정하나요?
관리자와 현장 담당자, 고객이 같은 화면을 쓰는지 구분합니다. 역할마다 볼 수 있는 목록과 바꿀 수 있는 상태가 다르면 권한과 화면을 따로 설계해야 합니다.
사용자가 여러 종류라면 각 역할이 처음 앱을 열었을 때 하는 일을 적어 보세요. 필요한 정보만 보여 주고 실수로 바꾸면 안 되는 항목을 제한할 수 있어 업무 흐름이 더 명확해집니다.
기능 목록은 어떤 문장으로 작성하면 좋나요?
“신청 내용을 등록하고 담당자가 상태를 바꾼다”처럼 행위와 결과를 함께 씁니다. 누가 언제 입력하며 완료를 누가 확인하는지 적으면 필요한 화면과 데이터 항목을 나누기 쉽습니다.
알림과 보고서는 목적을 분명히 합니다. 누락을 줄이려는 알림인지, 관리자가 현황을 보는 보고서인지 정하면 기능의 우선순위를 비교할 수 있습니다.
| 항목 | 적을 질문 | 산출물 |
|---|---|---|
| 사용자 | 누가 입력하고 승인하나요? | 역할 목록 |
| 흐름 | 상태가 어떤 순서로 바뀌나요? | 업무 단계 |
| 결과 | 누가 어떤 보고서를 보나요? | 조회·보고서 목록 |
견적과 일정 문서만 먼저 받아도 되나요?
업무용 모바일 웹앱의 STANDARD는 화면·기능 목록과 예상 견적·일정 문서 1장을 제공하는 10,000원·5일 패키지입니다. 이 금액에는 앱 개발과 납품이 포함되지 않습니다.
요구가 정리되면 실제 제작 패키지를 선택할 수 있습니다. 문서에서 기능 수와 사용자 역할을 확인하고, 포함되지 않은 항목이 구현 비용으로 어떻게 반영되는지 상담에서 협의하세요.
계약 전에 어떤 범위를 문서에 남기나요?
화면 목록, 입력 항목, 상태 규칙, 사용자 권한과 보고서 형식을 남깁니다. 데이터 이전, 알림 연동, 외부 서비스 사용처럼 별도 판단이 필요한 기능도 포함 여부를 명확히 해야 합니다.
검수 기준은 정상 사용뿐 아니라 빈 값, 중복 입력, 잘못된 상태 변경까지 포함합니다. 결과를 확인하는 사람이 누구인지 정하면 납품 완료 시점도 서로 같은 기준으로 이해할 수 있습니다.
테스트 데이터는 어떻게 준비해야 하나요?
화면 설계와 견적을 논의할 때는 실제 고객 자료 대신 열 이름과 자료 형식만 같은 익명 샘플을 준비합니다. 학생·고객 식별자와 연락처는 가리고, 파일에 접근 가능한 계정과 보관 기간을 정하세요. 샘플에 날짜·선택값·첨부 여부 같은 필드가 있으면 필요한 화면과 저장 규칙을 설명하기 쉽습니다. 각 화면에서 같은 대체 식별값을 사용해 자료 간 연결 관계를 보여 주되 실제 사람을 추정할 수 있는 정보 조합은 피하세요.
자주 묻는 질문은 무엇인가요?
어플 제작 의뢰 전에 화면 설계가 꼭 필요한가요?
완성된 화면 설계가 없어도 됩니다. 사용자와 업무 흐름을 먼저 설명하면 상담에서 화면 목록과 기능 범위를 함께 정할 수 있습니다.
10,000원 견적 문서 후 제작을 꼭 진행해야 하나요?
아닙니다. 기획 문서와 예상 견적·일정을 검토한 뒤 실제 제작 여부와 범위를 결정하면 됩니다.
수정 횟수가 정해져 있지 않은 패키지는 어떻게 하나요?
표에 미기재된 조건은 견적 전 확인해야 합니다. 수정 대상과 범위를 문서로 합의하고 시작하세요.
핵심을 다섯 줄로 정리하면 무엇인가요?
- 사용자와 역할에 따라 화면을 나눕니다.
- 입력·상태·알림·보고서 흐름을 문장으로 적습니다.
- 10,000원 표준은 기획 문서이며 앱 납품이 아닙니다.
- 데이터 이전과 연동 기능의 포함 여부를 정합니다.
- 정리한 기능 목록으로 어플 제작 상담을 요청하세요.
모바일 앱 제작 범위는 어떻게 정할까요?
현재 자료와 필요한 결과를 함께 적어 주시면 범위와 가격, 기간을 안내해 드립니다.