회고에서 팀원들이 말해준, PM이 잘 한 것들

1. 플로우차트의 적극적인 활용 : 고객과 나, 팀에서 효과적으로 싱크하도록 - 이미 만들어진 제품을 킥오프 미팅에서 다른 고객에게 설명할 때 플로우차트와 이미지로 이해도를 높일 수 있었다. - 새 고객은 기존 제품 이해도가 없기 때문에 기존 고객이 사용하는 제품 스펙을 문서, 텍스트로 전달해도 쉽게 이해하기 어려워 킥오프 미팅에서 공유 및 설명해주는 내용을 다 이해한 것 처럼 반응하는 경우가 많은데, - 바로 눈으로 볼 수 있도록 구체적인 이미지와 유저 입장에서의 흐름을 플로우차트로 시각화 해 보여줘 쉽게 이해했다. - 나와 고객 모두 동일한 선에서 제공되는 제품의 스펙을 이해하고 시작하기 때문에, 개발 중간에 예기치못한 요청사항이 접수될 리스크를 낮출 수 있다. - 뿐만 아니라, 팀에서 프로세스를 논의할수록 구체화되는 정책들을 플로우차트로 그려두면 요건이 헷갈릴 때 이 플로우차트를 기준점으로 다시 이해도를 맞출 수 있다. 2. 필요한 데이터와 계약을 미리 완료 - 빠르게 개발하다보면 애플리케이션 개발과 필요 데이터 확보를 병행하게되는 경우가 많은데, 이 데이터는 높은 확률로 제휴사나 다른 팀에 의존적이게 된다. - 의도치 않게 애플리케이션 개발보다 데이터 확보가 느려질 경우, 애플리케이션 개발은 모두 완료했는데 데이터가 확보되지 않아 테스트를 할 수 없는 상황을 만나게 된다. - 이번에는 초장부터 챙겨야 할 계약과 데이터 확보를 해둔 상태에서 본격적인 애플리케이션 개발을 진행해 애플리케이션 개발보다 데이터 확보가 먼저 되었고 - 애플리케이션 개발이 완료되자마자 확보한 데이터를 기반으로 테스트를 할 수 있었다. --- 번외로, 회고에서 나온 내용 중 앞으로 해볼 점을 추가하자면 3. 고객에게 테스트를 요청할 때 테스트 환경과 함께 어떤점을 어떻게 테스트 해야하는지 같이 전달 - 고객이 요청한 기능이기 때문에 고객이 알아서 발생할 수 있는 케이스를 기반으로 테스트 할것이라고 생각해 어떤 가이드도 전달하지 않았는데, - 사례는 알더라도 제품을 써보지 않은 경우 어디서부터 테스트를 해야할지 막막해 적극적인 테스트가 진행되지 않을 위험이 있다. - 팀 단위로 테스트를 요청하는 것 보다 담당자 한명을 지정해 테스트가 잘 되고 있는지 계속 체크하는것이 더 효과적이다. - 고객 입장에서는 문제가 생겨도 개발팀이 고쳐주겠지.. 라는 생각을 할 수 있기 때문에, 만약 테스트가 잘 되지 않을 경우 문제가 발생할 수 있다면 그 리스크도 잘 고지하는것이 중요하다.