첫번째 프로젝트 Sodam 복기(1)

프로젝트 기간 : 6주[1.9(월) ~ 2.17(금)]의 프로젝트를 진행했습니다.

팀만 짜고 아직 아무것도 정하지 않은 상태

처음에 어떤것을 만들지, 어떤 스텍으로 할지 모두 정하지 않았던 단계였기에 막막했습니다.

 

제가 다니던 기관에서 도와준것은 설계를 하는 방법에 대한 간단한 강연, 추천 스텍들 정도였습니다.

그래서 각자가 원하는 방향성을 먼저 잡고 2주간 기획 단계를 밟아나갔습니다.

---

첫번째 주

우선, 노션에 해야할것과 앞으로 팀원간 협의할 것들에 대해서 각종 사이트를 찾아보면서 정리해갔습니다.

기획단계의 중요성을 중요하게 생각했기 때문에

아무리 시간이 걸리더라도 구체적으로 작성하고자 했습니다.

(지금 생각해보면 힘을 조금 뺀상태로 만들었어야 했지 않았나 할정도로 ㅎㅎ)

 

 

 

 

 

 

 

 

 

 

 

저희는 webRTC를 통한 상담사의 편의사이트를 만들고자 했습니다.

이것을 짜기 위해서 20가지가 넘는 아이디어를 냈지만,, 마지막에 추려진게 상담사이트라 조금 아쉬웠습니다 ㅠㅠ

(가장 많은 아이디어를 내지 않았나 할 정도였는데 다음 기회에 또 구현할 수 있다고 생각합니다 ㅎㅎ)

스크롤 길이 보이시나요 ㅠㅠ

 

 

 

 

 

 

 

 

 

 

 

그 다음한것은 "프로젝트 기획서!"

1. 주제 : 명확한 내용을 담았습니다.

2. 기획의도 : 타겟를 구체화하고 기존의 문제점을 찾았습니다.

3. 특징 : 핵심기능을 구체화하고, 그 기능을 살리기 위해 구현할 것을 찾아보았습니다.

4. 차별화 포인트 및 시장성 : 현재 경쟁업체를 확인하고 그 경쟁업체보다 나은 방향의 포인트가 무엇인지 확인해보았습니다.

5. 기대 효과 : 이러한 특징을 통해 기대할 수 있는 효과가 무엇이 있는지 찾아보았습니다.

 

---

2번째 만든것은 요구사항 정의서!

각각의 기능을 구체화하고 추가로 넣을 경우 어떤 기능을 구현할지 정했습니다.

대부분 비슷할지 모르지만 정확하게 하지 않을 경우 나중에 기능구현간 불편함이 많을수 있다는 생각에 최대한 자세하게 구현했습니다.

---

3번째는 정말 많은 시간을 투자했던 와이어프레임... 중간에 기획 대상이 바뀌면서 거의 무산되었지만 그래도 프론트의 기준이 되었던 자료였습니다.

와이어 프레임이 정말 중요한 점은 프론트의 전반적인 디자인의 틀이 구성된다는 점에 있습니다.기본적인 사용 방법을 구체화 했을 때, 공장처럼 해당 구성들을 만들때, 만들어져있는 피그마는 엄청 도움이 된답니다

---

4번째는 "기능 명세 및 우선순위"

각각의 기능에 따라 역할을 정하기 위해서 대분류, 중분류, 소분류로 나누고 역할과 우선순위를 부여합니다.

4-6번째의 기능은 한세트로 차후 지라를 관리하는데 있어서 기준이 됩니다.

위와 같은 형식으로 만들었습니다. 0,1,2순위 까지는 순차적으로 구현하고 3,4순위는 부분적으로 구현하는데 사용했습니다. 특히 요구사항 정의서를 기반으로 만들었기 때문에 놓친 부분이 많지 않았습니다.

이런 단계적인 흐름을 파악한다면 완성도 있는 프로젝트 설계를 하는 것이라 생각합니다.

---

5번째는  "시퀀스다이어그램"입니다.

저희 프로젝트는 뷰와 스프링으로 프론트 백이 구성되었는데 axios를 받을 때 시퀀스 다이어그램을 통해 확인한다면 보다 쉽게 확인 할 수 있고 api명세를 구현하기 쉽다는 데 장점이 있습니다.

시퀀스 다이어그램은 백과 프론트의 소통을 구체화시킨 다는 점에서 중요합니다. 처음 만들어본것이니 만큼 프로젝트 중간마다 변경되었지만 다음 프로젝트때는 더 명확하게 구현될것이라 생각합니다.

 

---

6번째는 api 연동규격서 !! 모든 api를 이차트에 만들어서 차후 swagger에 연동할 때 참고 했었습니다.

특히, 페이지네이션, erd를 참고할 때 이 차트에서 많이 참고 했었습니다.

차트에는 api명, crud 방식, 간단한 주제, 구체적인 설명, 요청단, 출력단, 출력결과 이렇게 구성했습니다. 

api연동규격서 예

---

7번 째는 "ERD" 입니다.

저희 대상은 상담사와 내담자(상담 받는 고객) 이었기 때문에 이를 중심으로 작성했습니다.

오른쪽 메모는 세부사항, 그룹코드들 입니다.

cf) 그룹코드를 이용하면 해킹을 당하더라도 테이블의 내용을 이해하기 어렵기 때문에 안전하게 이용될 수 있다는 장점을 가지고 있습니다.

erd는 각각의 테이블에 어떤 entity들이 들어가는지 미리 생각하고 정확하게 구분해서 코드를 작성할 때 도움을 줍니다.

이름을 짓기도 어려우니 미리 통일성을 갖춰 작성하면 좋겠죠 ㅎㅎ

저는 Django에 익숙해서 id를 다르게 맞췄었지만 Spring은 그럴 필요가 없더라구요... 나중에 알았지만;

해당 기술들의 특징에 따라서 다를수 있다는 점도 유의해 주세요!!

---

8번째는 "간트차트"!!

미리 각자 개인의 역할을 정하고 몇일동안 진행하면 해결할 수 있을지에 대해 정해두는 것입니다.

이 사진을 찍었을 때 기획단계가 끝났을 때였기에 기획단계에만 차있는 것을 볼수 있습니다.

하지만!!

간트차트를 통해 Jira를 작성한다면 조금 더 효율적으로 운영할 수 있다고 느꼈습니다.

그럼 Jira도 잠깐 볼까요?

해당 간트차트 자료들을 모두 넣어두고 각자마다 포인트를 시간 단위로 부여해서 관리하면

프로젝트의 전체 진행도, 지금까지 한 결과를 모두 한눈에 확인할 수 있다는 점에서 좋습니다.

저는 시간이 조금 더걸렸는데 이유는 ... 실제 상담사와 토론을 통해서 의견을 조율할 필요성을 느꼈습니다.

만약 이 점을 빨리 느꼈다면 신청을 조금 더 일찍했을 것이고, 기획도 빨리 끝났을 텐데 말이죠.. ㅎㅎ 

이 글을 읽으시는 분들은 그런 신청들이 필요하다면 과감하게 빨리 신청해서 기획을 공고히 할수 있도록 하셨으면 해요 

저느 이 토론을 끝나고 2일동안 밤새면서 기획을 거의 다시 했거든요.......

---

기획주에 대한 글이었답니다 ㅎㅎ

다음글은 프로젝트를 하면서 맡았던 역할과 힘들었던 내용들에 대해 말해볼게요 

 

모든 프로젝트 기획단계를 간단하게만 설명했지만 다음기회에 좀더 자세하게 설명할 수 있는 글을 만들어 보겠습니다. ㅎㅎ