프로젝트가 마무리 국면이다. 자료를 정리하면서 폴더 구조를 봤다.
개발 항목 목록
사업계획서
참고자료
서비스 흐름표
시장 조사·특허
표준 산출물 가이드
견적·계약
현장 사진
펌웨어 패키지성격이 제각각인 것들이 한 자리에 섞여 있었다.
Table of contents
Open Table of contents
종류를 나눠 봤다
정리하려면 먼저 무엇이 있는지를 성격으로 갈라야 했다. 네 갈래로 모였다.
[왜 하는가] 사업계획서 · 시장 조사 · 특허
[무엇을 만드는가] 개발 항목 목록 · 서비스 흐름표
[어떻게 하는가] 표준 산출물 가이드 · 참고 기술 자료
[실제로 한 것] 견적·계약 · 현장 사진 · 펌웨어 패키지첫째 사업계획서 쪽이 착수 근거이고 둘째가 대상이며 셋째가 방법이고 넷째가 결과와 증거다.
폴더 이름만 볼 때는 아홉 개의 잡동사니였다. 갈라 놓으니 네 종류가 되고 쓸모가 정해졌다.
넷이 다 있었다
네 갈래가 전부 있는 것이 눈에 띄었다. 다만 양이 크게 달랐다.
[왜] 빠지기 쉬움 — 시작할 때만 필요해 보임
[무엇] 대개 있음
[어떻게] 대개 있음
[실제] 흩어지기 쉬움가운데 둘은 대개 있는데 서비스 흐름표 와 개발 항목 목록 은 없으면 개발이 안 되니 남는다.
첫째와 넷째가 위태로운데 앞은 시작할 때만 필요해 보이고 뒤는 여러 자리로 흩어진다.
원인 — 먼저 사라지는 것
시간이 지나면 왜 이것을 했는지가 제일 먼저 사라진다.
[코드] 남음
[설계 문서] 남음
[왜] 사람 머릿속코드는 SVN 에 남고 설계는 명세서 로 남는데 이유는 마음먹어야 남는다.
만든 것은 명세서 가 잡아 주고 한 일은 시험 결과서 가 잡아 준다. 왜는 잡아 주는 문서가 따로 없다.
담당자가 바뀌면 그 자리가 통째로 비는데 이어받는 사람에게 가장 필요한 것이 그것이었다.
없으면 못 고친다
사업계획서 에 이유가 안 남으면 어떻게 되는지를 놓고 보면 분명해진다.
"이 기능이 왜 이렇게 돼 있죠?"
↓
아무도 모름
↓
못 고침 또는 잘못 고침이상해 보이는 부분이 어떤 조건 때문일 수 있고 그것을 모르고 정리하면 조건이 다시 깨진다.
반대로 정말 잘못된 것인데 이유가 있을 것으로 보고 안 건드리는 경우도 생긴다. 어느 쪽이든 이유가 없으면 판단 자체가 안 된다.
앞서 무전원 중계 보드를 읽을 때 제약이 이름에 있어서 이해가 됐다. 제약과 이유가 남아 있어야 다음 사람이 판단한다.
결과 — 납품한 것의 사본
넷째 갈래도 걸린다. 견적서 와 계약서와 사진과 .bin 이 메일함과 개인 폴더로 흩어지기 쉽다.
그중 펌웨어 패키지 가 자료 폴더에 함께 있는 것이 좋아 보였다.
[없으면] 어느 판을 넣었는지 모름
[있으면] 그대로 다시 넣을 수 있음장비가 몇 해 뒤에 고장 나면 그때 넣은 것과 같은 .bin 을 넣어야 하고 최신이 아니라 그때 것이 필요하다.
최신 판은 그 사이 바뀐 것이 들어 있어 같게 돌지 모른다. 납품 시점 사본이 있어야 그 물음이 없다.
비교 — 두 시점의 사진
현장 사진 이 여러 장 있었는데 날짜가 둘로 갈렸다.
[설치 시] 이렇게 설치했다
[점검 시] 이 상태였다시점이 다른 기록이라 나중에 문제가 생기면 언제 무엇이 달라졌는지가 대조된다.
한 시점만 있으면 원래 그랬다는 것만 말하고 두 시점이 있어야 변화가 보인다.
파일명에 날짜가 들어 있는 것도 눈에 띄었다. EXIF 에도 촬영 시각이 있지만 파일명이면 바로 정렬된다.
선택지 — 여러 벌의 견적
견적 관련 파일이 여러 벌이었다.
견적서
견적서 (별본)
발주서수량이나 사양이 다른 안이거나 받는 곳에 따라 형식이 다른 것으로 보이는 협상 과정의 흔적이다.
최종본만 두면 깔끔한 대신 왜 이 조건이 됐는지를 잃고 여러 벌이 있으면 검토 과정이 남는다.
다만 어느 것이 최종인지가 파일명에서 드러나야 하고 표시가 없으면 다음 사람이 헷갈린다.
판단 기준 — 남길 것과 버릴 것
정리하면서 기준이 하나로 모였다.
[남길 것] 다음 사람이 판단하는 데 필요한 것
[버릴 것] 그 시점에만 의미 있던 것판단의 근거가 되느냐가 기준이었고 견적서 든 사진이든 이 기준으로 갈랐다.
왜 이 방향을 골랐나 — 검토했다 접은 안
왜 이 제약이 있나 — 요구사항·규제
무엇이 안 정해졌나 — 미결 목록
실제로 무엇을 납품했나 — 산출물 사본안 하기로 한 안도 남긴다
셋째 줄이 특히 눈에 띄는데 발주서 로 가지 않은 안을 남기면 같은 검토를 반복하지 않는다.
[최종안만] "왜 저렇게 안 했지?" → 다시 검토
[접은 안] "이미 봤고 이래서 접었구나"다만 이것을 최종 문서에 섞으면 안 되고 명세서 는 지금 유효한 것만 담는다.
미결도 마찬가지다. 여러 문서에서 차주 보완 예정 이나 협의 필요 라고 적힌 것을 봤다.
끝날 때도 남은 미결이 있으면 적어야 하고 안 적으면 다음 사람이 다 정해진 줄 알고 시작한다.
마무리 — 정리할 시점
마지막으로 남은 생각은 시점이다. 진행 중에는 정리가 안 된다.
무엇이 최종인지 모르는 상태라 무엇을 버릴지도 정할 수 없고 끝날 때 한 번 정리해야 남는다.
그때 안 하면 흩어진 채로 잊히는데 자료가 없어지는 것이 아니라 아는 사람이 없어진다.
정리
- 자료를 성격별로 나누면 왜와 무엇과 어떻게와 실제 넷이다
- 가운데 둘은 만들지 않으면 개발이 안 되니 자연히 남는다
- 왜가 제일 먼저 사라지는 것은 잡아 주는 문서가 없어서다
- 이유가 없으면 못 고치거나 잘못 고친다
펌웨어 패키지사본이 있어야 최신이 아닌 그때 것을 넣을 수 있다- 사진은 설치 시와 점검 시 두 시점이 있어야 변화가 보인다
- 파일명에 날짜가 있으면 목록에서 바로 정렬된다
- 여러 벌의 견적은 검토 과정을 남기되 최종본 표시가 필요하다
- 남길 기준은 다음 사람의 판단에 필요한가다
- 접은 안과 남은 미결도 남기되
명세서와는 섞지 않는다