Index
Date
의 회의록 마스터 : 이하령
Participants
TEAM FIRE (고주형 윤영기 이하령) + WonYong Jeong
Discussion topics
데모는 어떻게?
초기에 기획한게 원활하게 진행되고 있는지
진척률
모도코 대회
너무 잘했다!!
스프린트 데모 목적성 있게 진행한 케이스는 드물다
우리가 잘했다!
스프린트 데모 규모를 명확하게 좁히지 못해서 개발 진행하다가 성과 없이 다음 스프린트로 넘어가는게 많음.
하지만 우리는 초반부터 데모 목적성과 범위가 분명해서 좋은 결과로 이어진 듯
동기부여가 잘됐고 시행착오의 기간들이 짧아졌음
간단한 피드백
되게 좋았고 완성도가 높았다.
다른 사람들이 카메라 키고 싶었다고 한다.
아는 사람끼리 하는 경우에는 카메라가 필요할 것 같다.
중간평가 기획서 리뷰
추진일정
중간평가 발표자료를 작성하는 것은 결국 우리가 주는 메세지.
우리 잘하고 있다는 메세지를 주기 위함.
우리 원래 프로덕트 전체에 대한 계획이 이랬는데, 지금까지 한 것에 대해 디테일하게 들여다 보면 요런 모습이야!
위 내용 그대로 가도 될 것 같다. 자료 수정은 불필요.
발표 자료에서는 계획대로 잘 하고 있다는 걸 강조 했으면 좋겠다.
모니터링
이건 기능.
우리가 개발을 했다라고 해도 무방할까?
개발 안끝난게 많은데 그런 기능에 대해 모니터링이 70%나 됐다라는게 물음표가 있다.
커밋 기록 캡쳐도 넣으면 좋을 듯. (정량적으로 열심히 했다는 것을 보여줌)
결과물 형태 및 서비스 방식 → 페이지 나누기
전체 공지한 메신저 스크린 샷
개발진행현황 1, 2, 3, 4, 5 해서 섹션으로 주는게 좋을 듯.
개발 진척률 얼마, MVP1.0 개발이 완료됨. 이에 대해 데모 언제했고 피드백 완료.
결국 심사위원들이 개발 진행 현황위주로 볼거임.
주요기능이 1, 2, 3, 4, 5가 있고 이를 하나씩 설명해줄게!
요런식으로 toc 있으면 좋을것 같다.
Q. 발표때 시연영상 vs 실제 웹사이트로?
시나리오 기반의 영상 준비하는걸로 하자. (1분정도, 이것도 좀 길수도?)
product를 제공하는게 아니라 중간 산출물 제공하는 것이므로 완결성 보여줄수 있는 팀들이 많지 않음.
우리 서비스 실제로 들어가는 상황은 질의응답때!
우리 서비스를 데모하게 되면 하반기엔 어떻게 하게 될까? 라는 궁금증이 생길텐데 이는 발표자료 & 질의응답때 해소하면 될듯.
MVP가 만들어지면 이를 이용해 사용자 인터뷰 하게 되는데, 여기서 나온 의견으로 데이터를 쌓는 행위를 한다.
시간이 지날수록 변수가 상수로 바뀜
처음 프로토타이핑을 하고 MVP를 만들고 이를 하면서 나온 여러 의견들로 또 다른 발산이 생성되고 이 중에서 MVP의 순기능(이렇게 가자, 말자 라는 기로점으로)을 제대로 이용할 수 있을 듯.
후속 질문
우리 서비스에서 제공할 수 있는 한계점?
어느 정도의 해상도로 몇명 정도가 참여할 때 버벅임이 없나?
인터넷 환경이 다를 텐데, 이에 대해서 따로 처리 가능하나?
완성된 대답보다, 고민을 해봤다 정도로만 피드백이 되어도 준수할 듯
앞으로 부하테스트, 1명에 대한 지표가 있으면 좋을 듯.
비즈니스
벤치마킹을 하는게 정론
우리와 유사 서비스 확인해보자
발표자료에서는 차이점으로
우리 비즈니스 모델이 보다 합리적이고 기능적인 막강함이 있다고 어필하면 됨
강의자 혹은 세미나 개최자 → 빼는게 좋을 듯
누구나 가질 수 있는 물음표를 가장 발빠르게 증명하고 판단하고자 하는 시도. 그래서 우리는 증명해보고 싶다. 시장이 있고, 그 시장에서 우리 제품을 기다리는 사람이 있었단걸 증명해 보이고 싶다. 그래서 항상 발빠르게 의사결정하고 프로토타이핑을 빈번하게 가져왔고 이를 통해 MVP와 피드백을 얻는 시간까지 얻었다. 남은 3개월도 이와같이 보낼 수 있다고 생각한다. 우리는 준비되어 있다!!!
개발자 특화기능은 차별화하게끔 하는게 사실 어렵다.
그렇다면, 차라리 우리 프로그램에서 extension을 제공하는게 어떨까?
기능적인 피봇.
MVP의도는 핵심기능을 가지고서 피봇을 할지, 아니면 이게 맞았는지 판단하는게 MVP
우리가 여기에서 향후 필요한 기능이 요거다라고 정하는 것.
개발자 특화기능을 차용할지 말지에 대한 판단.
차용한다면 무엇으로 결정할지에 대한 정의 → 이를 하반기에 증명하겠다.
우리는 MVP1.0 만들어서 피드백 받았다.
이를 바탕으로 앞으로 이렇게 하겠다.
중간발표때 우리의 의사를 fix할 필요는 없다. 여러 가능성을 열어두어도 ㄱㅊ
이슈화를 해서 이에 대해 브레인스토밍을 해보자.
개발진행현황
주요기능 toc
추진일정은 그대로 놓되, 발표자료에서 심의때 추진일정 언급
추진일정에서 지표 수정 (인프라 구축, 모니터릴ㅇ 진척도)
커밋수 캡쳐
페이지 나누기 (결과물 형태 및 서비스 방식)
기대효과 (비즈니스 측면에서 빼기)
결과물 활용 방안 마지막 줄 정돈 혹은 빼기
기획심의 개선 요구사항 반영 결과
개발자 도구는 vscode extension으로 귀결 되니까 우리가 해볼 수 있는 시도 중 하나는 우리 제품 자체를 vscode extension화 하는 것. 개발자 ide와 결합된 형태의 서비스를 개발하겠다..!
우리 서비스 내에 extension넣는 것도 가능할거고 open api로 공개해도 되고
개발도구와의 결합도가 높은 서비스를 개발하겠다.
