25.11.27 TIL 14: 본캠프 4일차👊

📌 오늘의 진도:

강의: 체계적으로 배우는 피그마 기초 완전 정복

➡️ 챕터 3: 비 디자인 환경 이해 및 비 요소 만들기

 

영상:

➡️[우아한형제들] 개발자가 생각하는 좋은 PM 나쁜 PM-> 팀원들과 컨퍼런스 스터디 진행 

https://www.youtube.com/watch?v=WVvFRh1vGv8&list=PLu6f31_SRNTjfCd5y7aLypDTI_IKDxL-t&index=7

 

오늘의 인사이트  👀

➡️ 오늘은 피그마 강의를 사전캠프때 다 듣지 못 하여서 마무리를 하려고 한다! 초반에는 솔직히 이론베이스여서 좀 지루하였는데.. 이제 버튼 만드는 방법도 알려주시고 뒤로 갈 수록 더 재밌어지는거 같아서 집중이 훨씬 잘 되는거 같다.

오늘 새로운 방식을 도입하였다. 며칠동안은 아티클을 읽고 그것에 대한 생각보다는 글 속 안에서의 핵심들을 얘기하려고 했다면 이번에는 우리의 인사이트가 더 담겨있는 방식으로 옮겨갔다..! 아무래도 이 방식이 사람들이 어떤 생각에서 나랑 같은지 다른지를 구별 할 수 있어서 좋았다..! 

 

 

오늘 강의에서..

버튼의 구조: 컴포넌트는 항상 구조 파악이 첫번째에요!

1. container : 버튼의 높이는 컨테이너 안의 상하 여백 + 안에 있는 요소의 높이로 정해져요.

2. label : UI에서 사용자가 입력하는 글자는 텍스트, UI가 사용자에게 ‘이렇게 하세요’를 안내하는 글자는 라벨이라고 불러요.

3. leading element : 버튼 라벨보다 더 앞쪽에 있다는 뜻에서 리딩(이끄는) 엘리먼트라고 불러요.

4. trailing element : 버튼 라벨보다 더 뒤쪽에 있다는 뜻에서 트레일링(뒤따르는) 엘리먼트라고 불러요

 

➡️ UI 만들기 실습

 ✅ 컴포넌트로 만들기 Create component <MacOS> cmd + opt + k

 ✅ 오토레이아웃 shortcut key <MacOS> shift + a

 

텍스트필드의 구조: 

플레이스홀더와 밸리데이션:

- 사용자가 입력해야 하는 예시를 제공하는 용도로 사용해요.

- 사용자가 글자를 입력하기 시작하면 사라지고, 글자를 모두 지우면 다시 나타나요.

<유의>

- 입력값의 조건을 적지 않는 것을 권장 -> 조건이 복잡하지 않은 경우에는 괜찮지만, 조건이 복잡하거나 어려운 경우에는 사용자가 입력 중에 조건을 까먹을 수도 있어요.

 

➡️  [우아한형제들] 개발자가 생각하는 좋은 PM 나쁜 PM

[기억에 남았던 구간]

01:08 - 01:18 -> 배민 개발자(경력이 있으신)가 생각하는 3가지 특징들을 말씀 해주셨어서 개발자편에서는 이런 점이 좋은 PM이라고 간단하게 생각 할 수 있었습니다. 

02:39 - 03:50  -> '마음'을 써야한다는 문구에서 많이 와닿았습니다. 공부를 할 때도 누가 시켜서 억지로 하는 것보단 내가 동기를 가져 마음을 먹고 하는게 더 재밌다는건 누구든지 알거 같다고 생각하였습니다. 

8:50 -  8:58 -> 저 고민있어요=[문제+인정+겸손] -> 개발자의 touching point, 개발자 입장에서 문제를 풀어야한다, 인정 받고 싶어한다는 해결해주고 싶게 하는 마법의 주문 ~

 

 

[인사이트]

컨퍼런스를 보기 전에 좋은 PM은 뭐냐에 대한 질문에 저는 소프트 스킬을 언급했었는데요. 저는 큰 단어들만 생각을 하게 되었던거 같습니다. 오직 설득, 요청을 어떻게 잘해야하는지만 배웠고 그 부분을 집중을 하였습니다. 하지만 이 영상을 보고 나서 아무래도 개발자이기 전에 사람이잖아요..! 사람은 유대감을 형성 시켜주는게 중요하다고 생각을 했습니다. 그리고 개발자분들이 저의 요청에 대한 것을 더 극대화 시켜드릴 수 있는 동기부여나 개발자님이 하시는 일에 대한 가치를 설명을 해줘야된다고 하는 부분에서는 머리 한대 맞은 기분이였습니다. 왜 이 중요한것을 놓치고 있었는가 하면서요...ㅎ 

그리고 영상을 보며 한가지 오해를 했던 부분도 있었습니다. PM 혼자 일정 및 문제의 대안을 정리해서 다른 분들과 공유를 하면 그 분들의 시간을 뺏지 않는다고 나는 내 일을 하는거야!  라는 생각을 했었지만 다른 분들은 참여한다는 느낌을 안 받기에 프로젝트가 재미없고 혼자서 결정하는 PM은 안 좋다고 한 말을 듣고 생각 전환을 하는 계기가 되었습니다.

그리고 가장 고민이 많았던 것 중에서는 개발을 어디까지 알아야하는지에 대해서도 알려주셔서 너무 좋았는데요..! 이 부분에서 프로젝트 하는 도중에 커피챗을 하면서 전체 시스템을 이해하려고 개발자 분들에게 여쭤보는 그런 노력이 개발자 분들 입장에서도 좋을거 같다는 생각이 들었고 또한 저에게도 많은 도움이 될거라고 생각했습니다..! 아무래도 개발의 대한 지식이 한겹 더 쌓이는거니까요! 거기에서 오는 뿌듯함과 프로젝트의 대한 이해도가 높아질거라고 저는 믿습니다! 끝내 저는 이 영상을 보면서 PM은 정말 마음가짐과 이 프로젝트의 대한 관심도, 다른 이해관계자들에게 유대감 형성이 가장 중요하다고 생각했습니다. 

 

 

[공통 질문: 내가 생각하는 좋은 PM과 나쁜 PM은?]

컨퍼런스를 보기 전:

소프트 스킬 중에서도 문제를 정의 할 수 있는 관찰력, 커뮤니케이션(설득, 요청)이 잘 되는 PM이면 이정도면 반 이상은 한다고 생각해 좋은 PM이라고 생각을 했습니다.

나쁜 PM은 어제 강의에서 들으면서도 무척이도 공감을 했던 거였는데요. 그것은 통보만 하는 PM이라고 생각을 했습니다. '위에서 아니면 상사가 시켰어요' 이런 말이 그 직책을 맡고 있는 사람으로서 너무 책임감 없는 말이고 저여도 일 하기 싫을거 같다는 생각이 마구마구 들었어요. 그리고 이거는 포괄적으로 얘기하는거 같은데..! 어느 부분에서든 나는 이 점에서 전문가가 아니니깐 그 일에서 노력을 안 하는게 진짜 안 좋은 PM이라고 보였습니다.  

 

컨퍼런스를 본 후: 

좋은 PM은 동기유발/유대감이 정말 중요하다고 생각을 했어요. 어떤 일을 하든 동기가 없으면 열정과 인내심, 끈기 등이 없을거라고 저는 생각이 들었습니다. 왜 해야하는지 고객 관점과 이 회사의 가치라는 관점에서 설명을 들으면 내가 하는 일에 대한 목적과 목표가 더욱 더 뚜렷해지지 않을까라는 생각이 많이 들었습니다. 그리고 마지막으로 느낌이 좋은 PM^^;;. 

나쁜 PM은 영상 속 개발자님께서 정책에 관하여 말씀을 하셨을때 연차가 쌓이면서 정책에 관하여 이해를 하지 않았던 PM분들도 계셨다.. 이런 말씀을 하셨을때 경력이 쌓여도 흔히 말하는 초심을 잃지 말아야겠다..! <- 요런 맘이 뭔가 멋있는 프로페셔널한 PM이 될거 같다는 생각이 들었슴다.