[Report] 프로젝트에서 문서 관리법!

 

회사를 다니면서 인프라쪽 관련해서

프로젝트를 할 수 있는 기회가 생겨서 참여를 하게되었습니다.

 

토이프로젝트가 처음은 아니지만

그래도 회사에서 기획도 잠깐하고

개발도 잠깐했던 사람으로써

두번 다시 같은 실수가 일어나지 않기를 바라며...

 

의사소통에 중간단계인 문서화를 통해

주먹구구식 프로젝트가 아닌

진행 상황을 팀원들과 공유하며

단계적으로 나아가는 프로젝트를 하면 진행하기로

팀원들에게 동의를 구했습니다!!

 

물론 여기에 작성하는 내용이 맞는 내용은 아니고

단계적으로 피드백 받고 수용해 나아가며 진행할 예정입니다!!

 

일단, 따로 기획자가 없음을 인지하고

읽어주시면 감사하겠습니다

 

---

 

 

 

첫번째!!

WBS(Work Breakdown Structure)

업무 분업 구조 또는 작업 분해 구조를 작성하기로 했습니다.

 

저는 이를 엔지니어들로만 프로젝트에서 적합하다고 생각했습니다.

기획문서에는 여러가지 파생되어서 문서가 따라 옵니다

요구사항정의서, 업무프로세스 정의서,메뉴 구조도 등등....

 

짧은 시간, 구성원을 고려해보았을때

기획문서에 따라오는 문서들은 사실 현실성이 떨어지죠....

 

파생되는 몇가지 문서를 제외하고는

다 버리고 WBS위주로 작성해서 진행하기로 했습니다.

 

WBS는 저도 아직 작성해보지는 않았지만

여러 방면으로 장점이 많은거 같더라고

 

업무를 시각적으로 표현 가능 프로젝트 진척률 관리가 용이 업무 중복 방지 휴먼 에러 최소화 커뮤니케이션 증대 등등.... 참고 자료: https://salaryblues.tistory.com/3

 

참고자료에서 잘 설명 되어있고 엑셀로 폼도 형성해주셨습니다~

큰틀을 잡고 진행할 수 있는 문서 인거 같아서

회의할때 주요 안건으로 사용해보고자 넣었습니다!

 

뭐든 하다가 커스터마이징 해야하니깐~

 

 

두번째!!

개발일지 작성~

저는 매주 목요일이나 작업이 완료된 날짜에

개발 일지를 작성해달라고 부탁드릴 예정입니다.

개인적으로 저도 제 블로그에 포스팅도 진행할 예정!

 

이 부분에 대해서는 굳이? 작성할 필요가 있을까?

개인적인 고민이 있었지만

 

개발일지를 넣기로 마음 먹은 이유와 목적은

 

생각없이 프로젝트를 진행하지 말자!

 

 

항상 프로젝트를 하다보면 빨리 빨리가 되고

왜?라는 질문을 던지면서 진행한거 같지는 않더라고요

 

예를 들어

EC2 인스턴스를 선택할 때 t2말고 m5를 선택한다면

무지성으로 그냥 이렇게 됫어가 아니라

"나는 이런 이유때문에 이렇게 했어"

 

 

 

항상 선배 엔지니어들이나 개발자 세션을 가게되면

왜? why? 

스프링과 장고중에 스프링을 선택했다면

왜 선택했어?

라는 이유가 있어야 한다고 합니다.

 

개인적으로, 이게 뭐 왜?라는 생각을 해야합니다 해서

안하던 사람이 그런 것들을 하기는 힘드니깐

 

개발일지라는 장치를 활용해서

저 뿐만 아닌 팀원들의 생각의 확장을 넓히고자!

 

개발일지를 작성하기로 했습니다!!

 

---

 

 

팀원이 같이 작성해야할 문서: WBS

개인이 작성해야할 문서: 개발일지

 

두 가지 문서로 의사소통하며 진행할 예정입니다!!

 

프로젝트 화이티잉~~!~!