녹호두

유튜브에 올라와있는 앱 시트 Appsheet 노코드 강의 <코딩하는 약사>님의 강의를 수강하며 기록한 개인 공부 목적으로 기록한 자료입니다. 

구글 스프레드시트 데이터입력 > 확장 프로그램 > 앱 시트 > 앱 만들기

구글 스프레드시트의 데이터를 바탕으로 껍데기는 만들어짐

Data > Colums > 직원 정보에서 데이터 타입을 설정

UX 탭으로 옴, + 버튼을 눌러서 데이터를 입력함

저장하면, 입력한 데이터가 구글 스프레드시트에 반영되어있음

디테일뷰, 목록 뷰로 노출됨

구성은 UX에서 변경할 수 있음

(TBD)

애자일 조직 제품 관리자의 고객중심 문서 작성 가이드! (에픽, 유저스토리)

https://youtu.be/Z6tgjS3cMcA

case 1 - 기획자

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → 기획자가 분석, 설계
  • 이때 설계된 문서를 "스토리보드"라고 부름 (국내에만 있음)
  • 스토리보드에는 ui, 정책, 기능 명세 등이 담기게 됨
• → 이를 바탕으로 디자이너, 개발자가 작업
  • 디자이너와 개발자는 주로 제작 단계에 참여

# 스토리보드

좌) ui 우) desc

case 2 - pm, po

• 비즈니스 관계자 or 고객으로부터 요구사항 수집
• → po, pm도 분석을 함. 하지만 설계를 하진 않고 고객의 목적과 행동을 정의 (왜 쓰고 뭘 불 편해하고 뭘 원하는지, 니즈) = 니즈를 중심으로 정의
  • 이때 작성된 내용을 Epic, User story라고 함
• → 이 내용을 바탕으로 디자이너, 개발자가 소통해가면서 설계를 함께 진행하고 제작에도 모두 함께

# epic, userstory

문서로 구성

• 테마가 최상단에 가장 크게
  • 에픽
  • (flow chart)
    • 유저 스토리
      • 누가 무엇을 위해서 어떤 기능을 원한다. (유저의 관점에서 작성)
      • acceptance criteria (인수기준)
        • 제품이 최종 사용자 혹은 시스템이 제시하고 있는 요구사항을 만족하고 있는지를 판별하기 위한 기준
        • 인수조건의 가장 큰 특징은 철저하게 사용자의 관점에서 제품의 기능을 정의한다는 것입니다
          • 테스트

→ pm 은 ui 가아니라 위와 같은 문서를 주로 작성한다.

→ 스토리보드는 ppt로 제작해 검색이 어려운데 이런 건 위키로 되어있어서 검색이 용이하다.

→ 유저 스토리는 고객 입장에서 고객이 원하는 것을 고민하는 것으로 서비스 기획과 view(관점)이 많이 다르다.

잘하는 기획자의 기준은 무엇인가?

https://youtu.be/A5yHcKrgTHk

1. 기획을 잘한다는 것 = 업무 스타일이 맞는다는 것

• 넓게 트인 시야로 구체화
• 정리의 신
• 체계적인 위계 정리
• 일정관리의 신

2. 기획을 못한다는 것 = 쟤랑은 일 못하겠어

그게 아니라면, 어느 정도 기획을 하는 범주에 들어오는 것 → 그렇게 되면 업무 스타일이 생기게 된다.

ex. 잘하는 기획자 = 자신과 손발이 잘 맞는 기획자

ㄴ 여러 역량 중에, 동료들과 손발이 잘 맞느냐로 동료들에게 평가받을 수 있다.

ㄴ 기획을 잘한다는 객관적 지표는 없다. 누구와 손발이 잘 맞는가가 잘한다의 기준을 판단하는 것이고 그것은 개인마다 차이가 있을 수 있다.

if 내가 기획을 못하는 거 아닐까란 생각이 들 때

1. 정말 자질이 없을 때
2. 지금 이 팀이 안 맞을 때. 자신의 기획자로서의 성향과 안맞을때 → 조직 또는 팀을 바꿔보자

PO : 프로덕트를 이끄는 전문가

기획자 : 프로덕트의 완성도를 높여주고 현실화해주는 전문가

Con. 잘하는 기획자?

1. 객관적인 기준은 없다.
2. 주변 동료에 의해 평가된다.
3. 나와 손발이 잘 맞는 동료들을 주변에 두면 자연스럽게 잘하는 기획자가 된다.

디자이너와 개발자가 뽑은, 내 인생 최고의 Product Manager!

https://youtu.be/U3JhQlTFxWw

내 인생 최고의 프로덕트 매니저

• 콘텍스트/데이터/리서치 기반으로 커뮤니케이션
• 팀원들과 동등한 위치
• 개발자와 논쟁할 수 있는 지식을 갖춘 pm 이 좋은 pm이다.
• 로드맵을 지속적으로 리뉴얼하는 것이 좋다.
• 마감일보다는 해결책에 초점을 맞춘다 → 마감일도 중요하지만 해결책에 초점을 맞추는 게 중요하다. 마감일을 조금 유연하게 조절했다.
• 고객 중심으로 최고의 제품을 위해 C레벨과 마찰을 이겨냄
• 다양한 이해관계자들과의 커뮤니케이션 ← 디자인과 엔지니어링에 대한 이 해이 필요. 직접 개발/디자인 하진 않더라도 문제를 직접적으로 집어내는 역할은 필요
• 해결책보다는 문제를 찾아내고 소통하는데 더 많은 시간을 사용
• 디자이너와 개발자를 파트너로 대우. 보상보다는 제품 출시에 더 많은 신경을 쓴다.

BEST PM requirement

• 목표와 비전 설정
  • 왜 이 일을 해야 하는지 비전과 목표를 제대로 설명할 수 있다.
  • 지속해서 사용자, 경쟁사, 시장조사를 진행하고 이를 제품에 반영
  • 해결책보다는 문제를 더 깊게 고민
• 의사결정
  • 본인이 아닌 소비자, 비즈니스, 팀을 위한 결정을 내림
  • 중요한 것에 집중하고 불필요한 것들은 걸러낸다
  • 데이터에 기반한 의사결정을 내릴 줄 안다
• 업무지식
  • 해당 산업의 도메인에 대해 깊게 이해
  • 디자인과 엔지니어링을 이해함
  • 데이터를 제대로 사용할 줄 알고, 데이터를 이해하는 사람과 협업할 수 있다.
• 커뮤니케이션
  • 팀원 의견을 경청하고 올바른 실행방안을 만든다.
  • 이해관계자에 따라 상황에 맞는 모자를 쓰고 커뮤니케이션
  • 커뮤니케이션 메시지가 잘 되어있고 일관적이고 명확하다
  • 언더 커뮤니케이션보다는 오버가 낫다.
• 협업
  • 동료를 도구가 아닌 중요한 파트너로 대한다
  • 동료의 업무방식을 존중하고 효율적으로 일할 수 있도록 돕는다 → 마이크로 매니징보다는 역할을 위임함
  • 팀원의 질문 및 요구사항에 제때 답변을 해준다.
• 태도/자세
  • 제품을 더 좋게 만들기 위해 경영진에 의의를 제기할 수 있다.
  • 피드백을 감정적으로 받아들이지 x
  • 자기 아이디어와 사랑에 빠지지 x