How we work

프로젝트가 흔들릴 때 돌아갈 기준을 먼저 만듭니다.

끝나는 조건부터 적습니다. 누가 결정하고 무엇을 확인하고 어떤 문서를 남길지를 착수 주에 정합니다. 일정표는 그다음입니다.

상담 문의

6단계 표준 프로세스

Built-in 검증 내장

문서화 인수 기준

회귀 반복 검증

Process

단계마다 남는 문서가 있습니다.

작은 화면 하나여도 운영까지 이어져야 합니다. 요구를 측정 가능한 기준으로 바꾸고 구축한 뒤 반드시 검증하고 인수 문서로 남깁니다.

모호한 요구를 측정 가능한 범위와 인수 기준으로 바꿉니다. 요구사항이 문장으로 {{2}}장이면 그대로 착수합니다. {{40}}장이면 {{3}}개로 쪼개자고 먼저 말씀드립니다.

데이터 모델, 권한, 연동 지점, 화면 흐름을 운영 관점에서 설계합니다.

ERP·관리자·연동 API를 운영 가능한 형태로 구현합니다. 변경 이력을 추적합니다.

외부 솔루션과 레거시 시스템을 연동해 데이터가 끊기지 않게 묶습니다. 모두투어 수집에서는 소스 {{14}}곳 중 {{2}}곳이 매주 형식을 바꿨습니다. 재시도 규칙은 그래서 넣었습니다.

테스트 케이스, 회귀, 예외, 권한, 데이터 정합성을 검수하고 결함을 추적합니다. 같은 오류가 {{3}}번 반복되면 원인을 따로 파고 재발 방지 항목으로 올립니다.

담당자가 바뀌어도 다음 사람이 그대로 읽을 수 있어야 하므로 인수 문서는 고객사 담당자가 직접 읽고 서명한 뒤에 끝냅니다. 여기서 질문이 나오면 문서를 다시 씁니다.

Quality System

착수할 때 테스트 범위를 정하고 개발 중에 결함을 기록하며 변경할 때마다 주변 기능까지 다시 돌립니다. 출시 직전에 몰아서 하지 않습니다.

01
검증 범위 핵심 기능과 사용자 흐름을 놓고 확인 순서를 매깁니다.
02
결함 기록 재현 순서와 기대 결과, 영향 범위를 함께 적습니다. 개발자가 결함표만 보고 재현하지 못하면 그건 저희 잘못입니다.
03
회귀 확인 수정한 기능뿐 아니라 주변 기능까지 다시 확인합니다.
04
자동화 이관 반복할 가치가 있는 검증만 Selenium·Tosca·Qoretix로 옮깁니다. 한 달에 한 번 도는 화면은 그냥 손으로 봅니다.

기획서가 없어도 괜찮습니다. 현재 쓰는 방식, 불편한 점, 원하는 완료 시점만 알려주세요.