개발 워크플로우 입문
요구사항은 화면이 아니라 목적과 조건으로 씁니다
참고 사이트를 모아 건네면 견적은 빨리 나오지만 결과는 어긋납니다. 목적 · 조건 · 판정 기준 세 가지를 적으면 A4 한 장으로 충분합니다.
Technote
기술을 모르는 창업가가 기술 인력과 일할 때 손해 보지 않는 법. 요구사항을 쓰는 법, 견적을 읽는 법, 인수하는 법을 실제 문서 형태로 다룹니다.
글 8편
개발 워크플로우 입문
참고 사이트를 모아 건네면 견적은 빨리 나오지만 결과는 어긋납니다. 목적 · 조건 · 판정 기준 세 가지를 적으면 A4 한 장으로 충분합니다.
개발 워크플로우 입문
견적서에서 가장 중요한 부분은 금액이 아니라 범위와 제외입니다. 이 둘이 문장으로 적혀 있지 않으면, 나중에 생기는 논쟁이 전부 기억력 싸움이 됩니다.
개발 워크플로우 실무
이 연재에서 가장 많은 후회가 나오는 항목입니다. 계정이 남의 이름으로 되어 있으면, 관계가 좋을 때는 아무 문제가 없고 끝날 때 전부 문제가 됩니다.
개발 워크플로우 실무
완료 기준이 없으면 인수는 감상평 교환이 됩니다. 미리 정한 판정 기준은 발주자를 지키는 동시에 수주자를 무한 수정에서 지킵니다.
개발 워크플로우 실무
사이트가 열렸다고 인수가 끝난 것은 아닙니다. 파일 · 계정 · 문서 세 묶음을 받아야 다음 사람이 이어받을 수 있습니다.
개발 워크플로우 실무
월 정액을 내는데 무엇을 받고 있는지 모르겠다면, 계약서에 범위와 응답 시간이 없기 때문입니다. 네 가지만 적으면 서로 편해집니다.
개발 워크플로우 실무
어느 쪽이 낫다는 답은 없습니다. 다만 두 방식은 서로 다른 위험을 갖고 있고, 그 위험을 계약으로 메우는 방법도 다릅니다.