시안 사인만으로 개발을 시작해도 되나

흐름 동의로는 상세 설계를 이어 갈 수 있다. 예외와 권한이 비어 있는 줄을 개발 착수로 그리면, 그 줄은 나중에 범위 다툼이 된다.

현업이 화면을 봐야 예외를 말한다면

그래서 시안 검토와 규칙 확정을 다른 주로 나눈다. 화면을 본 뒤의 예외는 표로 옮겨 확정하거나 변경으로 올린다.

프로토타입이 있으면 명세를 줄여도 되나

프로토타입은 이해 속도를 높인다. 이해와 확정은 다른 산출물이다. 규칙 표가 없으면 검수 시나리오의 분모가 없다.

시안 도구 댓글을 요구로 볼 수 있나

댓글은 검토 흔적이다. 요구 ID와 확인 날짜가 없는 댓글을 기준선으로 쓰면, 다음 버전에서 그 흔적이 사라진다.

화면 시안 사인, 요구 확정 - 와이어를 범위로 쓰면 어디서 깨지나

착수 6주 차, 현업 팀장이 피그마 시안에 사인을 했다. 그 사인을 요구 확정으로 읽은 수행사는 설계를 닫고 개발을 켠다. 두 달 뒤 검수 조서에서 현업은 그거 요청한 적 없다고 한다. 시안은 흐름과 칸 배치를 보여 줄 뿐, 예외 규칙과 권한과 계산식은 칸 밖에 있다. 와이어에 날짜를 찍었다고 기준선이 생긴 것은 아니다. 시안 사인과 요구 확정을 한 문서로 취급하는 현장에서, 변경은 개발 중에 감정으로 들어온다. 시안 검토 주간에 확정 칸을 비워 두면, 그 칸은 오픈 주간에 시나리오로 돌아온다. 화면을 보고 난 뒤에야 예외를 말하는 습관을, 확정 절차로 나누는 법을 적는다.

칸	시안 검토	요구 확정
대상	흐름, 레이블, 칸 배치	규칙, 권한, 예외, 계산
산출물	화면 버전과 댓글 정리	화면 ID별 표와 확인 날짜
사인 의미	이 방향으로 상세를 이어 가자	이 줄은 오픈 범위다
빠진 예외	다음 시안 댓글	변경요청 또는 미확정 목록
나중에 다툼	그때 그 그림	그때 그 표의 날짜

시안 사인과 요구 확정이 담는 칸

시안에 사인하면 요구가 확정된 건가?

아니다. 시안 사인은 흐름과 칸 배치의 검토다. 예외, 권한, 계산이 없는 사인은 기준선이 아니다.

시안 화면을 띄워 두고 이 방향이면 될 것 같다는 말을 듣는 주가 있다. 그 말을 회의록에 확정으로 적으면, 수행사는 설계 마일스톤을 닫는다.

닫힌 뒤에 현업이 들고 오는 것은 버튼 위치가 아니다. 부분 취소 때 원장 숫자, 대리 결재가 막히는 권한, 마감일 다음날 입력이 되는지의 규칙이다.

그 규칙은 와이어 칸에 원래 없다. 요구사항 식별이 화면 스케치로 끝나면, 식별은 된 것처럼 보이고 분석은 안 된 상태로 개발이 시작된다.

시안 검토서의 사인 칸에는 범위를 적지 말고 검토 범위를 적는다. 흐름 동의, 레이블 동의.

그 아래에 미확인 규칙 목록을 붙이지 않은 사인은, 나중에 양쪽이 다른 문서를 본 셈이 된다.

시안에 없는 예외는 어디로 가나?

확정 문서의 예외 표로 간다. 표가 없으면 예외는 개발 중 구두 요청이 되고, 검수에서 원래 범위가 된다.

화면 시안은 정상 경로를 그리기 쉽다. 로그인해서 조회하고 저장하는 선은 그림이 된다.

저장 실패, 중복, 권한 없음, 연계 지연은 그림이 잘 안 된다. 안 되는 줄을 시안 댓글로만 남기면 댓글은 다음 버전에 묻힌다.

예외는 요구 ID를 붙인 표로 옮긴다. 조건, 기대 메시지, 권한, 관련 화면.

네 칸이면 개발이 코드를 어디에 넣을지 보인다. 댓글에만 있는 예외는 검증(Validation) 시나리오에도 안 올라간다.

시나리오에 없으면 시험도 없고, 시험이 없으면 오픈 다음날 그 경로가 장애 티켓이 된다. 시안 도구의 댓글을 요구 도구로 쓰지 마시기 바란다.

댓글은 검토 흔적이고, 확정은 표다.

확정 문서에는 어떤 칸이 있어야 하나?

화면 ID, 업무 규칙, 권한, 예외, 확인 주체와 날짜. 그림 첨부만 있는 문서는 시안 보관이다.

확정이라고 이름 붙인 파일이 슬라이드 40장이면, 그 파일은 아직 기준선이 되기 어렵다. 슬라이드는 설득용이다.

기준선은 행이 있는 표다. 화면마다 한 줄, 그 줄에 규칙 요약과 권한과 예외 ID와 현업 확인 날짜.

날짜가 없는 줄은 미확정이다. 미확정 줄이 섞인 채 개발 착수를 그리면, 그 줄의 변경은 나중에 범위 다툼이 된다.

확인 주체가 팀 이름만 있고 사람 이름이 없으면, 두 달 뒤 그 팀은 그때 그 사람이 없다고 한다. 사람 이름과 날짜가 같이 있는 칸이 기준선이다.

이 칸을 착수 후 요구 검증 마일스톤에 붙이면, 시안 사인과 확정 사인이 두 번의 회의로 갈린다. 한 자리에서 둘을 받으면 시안 기분이 확정이 된다.

시안 변경과 요구 변경을 같이 받으면?

칸 이동은 시안 수정, 규칙 추가는 변경요청이다. 한 티켓으로 섞으면 공수와 재시험이 같이 숨는다.

개발 중에 버튼 위치를 옮기는 일과, 저장 시 원장을 두 번 푸는 일을 한 메일에 담는 현장이 있다. 전자는 시안 수정이고 후자는 규칙 추가다.

한 티켓으로 받으면 수행사는 화면 공수만 적고, 발주사는 당연히 될 줄 알았던 규칙이 들어갔다고 본다. 변경관리 양식에 구분을 한 칸 둔다.

시안, 규칙, 권한, 연계. 규칙, 권한, 연계로 표시된 줄만 CCB 안건이다.

시안 칸은 디자인 리뷰에서 닫는다. 구분 없이 받은 메일은 주간회의에서 다시 분류한다.

분류를 미루면 개발자는 이미 규칙을 코드에 넣었고, 넣은 코드는 거절이 아니라 철거가 된다. 철거 공수는 최초 산정에 없다.

발주가 착수 주에 나눠 둘 두 회의는?

시안 검토와 규칙 확정을 다른 주에 연다. 같은 날 같은 자리에서 둘을 받으면 사인의 의미가 섞인다.

한 시간에 화면을 넘기며 느낌과 규칙을 같이 물으면, 현업은 느낌에 답한다. 규칙은 숙제가 되고 숙제는 다음 주로 밀린다.

시안 검토 주에는 흐름과 용어와 필수 칸만 본다. 그 다음 주에 같은 화면 ID로 예외와 권한과 계산을 표로 확인한다.

두 회의의 산출물이 다르면, 나중에 시안 파일을 열어 그때 합의했다고 주장하기 어렵다. 주장이 어려워야 정상이다.

합의는 표에 남아야 한다. 공공 발주에서 시안 도구 접근 권한이 현업에 없으면, 검토는 수행사 회의실 프로젝터가 된다.

프로젝터 합의는 기록이 약하다. 출력 또는 요구 관리 도구의 첨부 버전을 같은 날 올린다.

버전 없는 시안 사인은 날짜만 있는 사인이다.