커뮤니케이션

커뮤니케이션

FE 개발자가 해야할 일

과제(비즈니스)에 대한 이해

• 왜 지금 해야하는가?

• 어떤 속도로 개발 되어야 하는가?

• 개발의 영향범위는 어느 수준인가?

• 개발 수준은 어느정도여야 하는지 판단

• PO와 이 과제에 대해 서로가 이해하는 싱크업 과정을 통해서 같이 어떠한것들을 할 수 있는 과정이 매끄럽게 연결될 수 있다.

개발

• 이해 단계에서 검토한 내용을 바탕으로 실제 코드 레벨에서의 구현

• 실제 개발을 하고 나서, 이해를 하면 그것은 개발의 코드나 이런 부분에 대해 다 달라질 수 있다.

  • 처음 과제에 대해서 경중을 따지고, 추후 이 과제가 어떻게 될지 이런것들을 복합적으로 생각을 해야, 그 복합적인 생각을 통해서 개발의, 코드의 상황, 지금 상황과 미래의 상황을 적절히 판단해서 녹여내야 추후에 재작업이 필요없을 수 있고, 추후 더 확장 가능한 형태로, 어느정도 예측가능한 범위 내로 개발을 할 수 있기 때문이다.

  • 그래서 이해가 먼저 순환되고, 개발이 진행되어야 한다.

배포

• 배포 날짜에, 어떻게 배포할 것인지?

• 배포 후 QA, 전 QA는 어떻게?

PRD

Product Requirements Document

제품이나 기능을 개발하기 전 무엇을 만들지, 왜 만들지, 어떻게 동작해야 하는지를 명확하게 정의하는 문서

비즈니스(과제)에 대한 이해

보통 과제를 진행하게되면, 단순히 기획서대로 개발하는 경우들이 많다. PO도 사람이다. 실수 할 수도있고, 개발의 디테일한 부분까지 모두 다 알 수 없다. PO분들이 기획을 러프하게 잡아준다면 러프한걸 기반으로 디테일을 잡아 나가야 한다. 모든 것들을 PO분들이 정리해서 주신다는 관점으로 보면 안됨 그 상황에서 이 프로젝트에 참여하는 개발자로서, 더 훌륭한 프로덕트를 만들기 위한 고민들을 더 많이 하는 그런 생각을 많이 해보면 좋다.

항상 비즈니스가 왜 진행되는지, 앞서서 왜 이게 중요한지를 먼저 이해해보자.

• PO와 비즈니스 과제를 "지금 왜 해야 하는지?", "얼마만큼의 시간이 필요한지?"를 커뮤니케이션

• 지금 해야 하는 이유 - Ex

  • 최근 MZ 세대의 전통주에 대한 관심이 증가 추세

  • 전통주 구매에 대한 CS가 월 N건 발생, 주요 구매 고객층을 넓혀야 하는 내부 요구사항

    • Q) 그렇다면 이 것을 통해 매출을 얼마정도 확보하고 기대하는지? 와 같은 질문 필요.

      • A) 연 매출의 10% 향상을 기대한다 -> 빠르게 할 수록 큰 효과를 볼 수 있는 것. -> 빠르 드라이브 필요

      • A) 연 매출의 0.1% 향상 -> 이보다 더 임팩트 큰 과제가 있을것 같다. 다른거 해보는게..

    • 달성 목표가 매출이라면 그것에 대해 우리가 더 효과적으로 해결할 수 있는 그런것들이 있지 않을까? 라는 것들을 고민

  • "따지기 위한게 아닌" 지금 어느 속도로 중요한지 체크하기 위한 목적

PO가 과제에 대히 얘기할 떄 나의 리소스가 어느정도의 파워를 가지고 있고, 그 상황에서 내 리소스를 바탕으로 문제 해결을 더 잘할수 있는 그런상황에 대해 더 고민해보는것이 비즈니스에 대한 이해이며 동시에 본인 메타인지의 수단이 될 수 있다.

개발 전 요구사항 확인

• 쿠팡은 고객에게 다음날 배송하는 로지스틱스를 이용해 매우 빠른 배송의 비즈니스를 갖고 있음

  • 그 과정에서 "주류"를 진행하려면 어떻게 해야할까?

• "주류"가 먼저 배송이라는 비즈니스가 가능한지 확인이 필요

  • "주류"중 비즈니스가 가능한 것은? - 국가로부터 전통주 인증 받은것

  • "전통주"는 배송을 하고, "주류"는 픽업으로 주변 편의점과 연동을하면 되지 않을까.

  • 주류 배송을 위해서 사용자에게 프로덕트 방면, 실제 라스트 마일 기준으로 어떤 보완이 더 필요할까?

• "주류"는 여러 엣지 케이스가 있으므로 프로세스 적용이 필요.

  • "19세 이상"에게 팔 수 있으니 인증 필요 - 기존 프로세스에는 인증 프로세스가 없을지? - 성인 대상 상품 참고 필요

  • "픽업" 대상의 주류는 어떤 경로로 편의점으로 픽업될 수 있을지, 시스템상으로 물류는 어떻게 조절할지?

• 성공 지표 확인을 위한 로깅은 어떤 형태로?

팀의 범위, 요청의 범위 확인

우리 팀의 범위를 빠르게 알고, 그것을 외부에 빠르게 요청하기 위해 빠르게 정리해야 한다.

• 우리 팀은 사용자 화면을 개발하는 팀 즉, 사용자단의 비즈니스를 통해 사용자 매출을 끌어올리는데 기여하는 B2C

  • PRD도 앞단의 플로우를 기획했고, 이를 위해서는 플랫폼적인 기여가 필요함

    • 픽업이 가능해지려면 = 플랫폼에 "여러 편의점에서 맡고 있다"는 상태가 필요

    • "맡고 있다" 상태가 되면 사용자가 가져갈 수 있게 알람을 주고, 등 플랫폼 레벨에서 이벤트 시스템 필요.

    • 전통주의 경우 일반 배송 프로세스로 가되, "주류"라는 개념을 플랫폼에서 추가해야해하며, "주류"중에서도 "배송/픽업"에 대한 상태 체크가 가능해야 한다.

  • 플랫폼에 요청해야할 것이 무엇인지, API는 언제 나오는지 등이 필요하며, 그에따라 전시 레벨에서의 개발 기간이 정해짐.

  • 회원팀이 따로 존재한다면 "서인인증"에 대한 요청도 보내야 한다.

PRD 기반 요구사항 분석

PO와의 구현 사항 조율을 위한 논의

구현과 트러블슈팅