협업

스프린트

스프린트의 목표를 이해관계자들과 같이 만들고, 각자 해야 할 일을 나누면 의존성을 파악하기 쉬움

일의 완료 조건

업무 수행을 끝난 것은 단순히 스스로 업무 수행이 일단락된 것이다. 일의 완료 조건은 이해관계자들도 납득할 수 있는 업무 수행 완료를 의미한다. 예를 들어 스스로가 리서치를 완료했어도 리서치를 기반으로 의사결정이나 개발을 진행해야하는 이해관계자가 리서치를 이해하지 못하거나 납득하지 못한다면 일이 완료된 것으로 보기 힘들다.

최근에 있었던 일을 기록해보면, 내 스스로는 기획서를 완료했다고 생각했다. 하지만 이해관계자들이 봤을 때 설명이 부족한 부분이 있거나 서비스가 왜, 어떻게 사용되는 지 이해하기 힘들다고 피드백을 줬다.

시간을 효율적으로 사용하려면 최우선적으로 이해관계자들과 일의 완료 조건을 협의하는 게 좋을 듯하다.

업무 전달을 받으면 바로 승락을 하는 것 보다 무엇/언제까지/일의 완료 조건 또는 기준을 이야기하는 게 좋을 듯하다.

백엔드 협업자와 프로젝트 개발전 협의했으면 하는 내용

1. 배포 페이즈
   • 회사 정책을 따르거나
   • 개발 일정에 맞게 조절할 수 있음(예: sandbox, production 만 사용. dev, cbt 미사용)
2. REST API 전달 시 전달 방법
3. REST API의 Request/Response에 사용되는 JSON의 필드 네이밍

프로젝트 빌딩을 위한 질문

1. 프로젝트의 목표(무엇, 왜, 언제까지)
2. 고객? 이해 관계자(함께 만들 조직)?
3. 조직의 미션
4. 코드 작성 외 목표 달성을 위해 챙겨야 하는 일(일의 완료 기준, 담당자)
5. 1차 제품 릴리즈를 기준으로 언제/어떤 기능?
6. 1차 릴리즈 기준의 최소 요건 / 일정 언제 / 어떻게 완성 확인?

백엔드 데이터 엔지니어와 업무할 때

• 데이터의 보관 기간을 중요하게 생각함
  • 예를 들어 "1일 보관만 해도 됨"과 같이 알려줘야 함
• 협업 시, 데이터의 보관에 대한 정보를 전달해야 함

역량

기획서에 꼭 필요한 내용

기획서에는 서비스에 기능이 간단한 화면과 설명으로 작성되어있다. 어떤 기능이 필요한지 작성된 것이다. 하지만 해당 도메인에 익숙하지 않은 사람은 기획서를 보더라도 "이 기능이 왜 필요한지" 그리고 "이 기능을 사용자가 어떻게 활용하는지" 모를 수 있다. 그래서 기획서에는 "어떤 기능이 필요한지", "이 기능이 왜 필요한지", "이 기능을 사용자가 어떻게 활용하는지" 상세하게 작성이 필요하다.

기획자는 해당 기획을 위해 도메인 조사 그리고 시장 조사를 했을 것이다. 때문에 기획자는 해당 도메인에 대한 지식을 충분히 가지고 있을 것이다.

그것을 보고 구현해야 하는 이해관계자들은 도메인 조사 그리고 시장 조사에 대한 정보는 있을 가능성이 희박하다. 때문에 기획서에는 도메인 정보를 담을 필요가 있다.

기획서에 필요한 내용

• 어떤 기능이 필요한지
• 이 기능이 왜 필요한지
• 이 기능을 사용자가 어떻게 활용하는지
• 도메인을 이해할 수 있는 정보

기획자가 필요한 역량

• 서비스 도메인 지식
• 상용화된 서비스 직접 사용해보기
• 서비스 기획 후 어떻게 사용되고 왜 필요한지 작성하기
• 변경된 기획은 신속하게 공유