협업

처음에 초석을 다질때 디자인을 잘하는 것이 중요예:항상 공통적으로 들어가는 데이터 => product네비게이션에서 카테고리 페이지로 들어가서리스트에 나오는 product를 select해서거기에 있는 product page로 들어가서거기에서 더 상세한 product information을 본 다음에거기에서 체크아웃공통적으로 보이는 정보가 product information디자인도 틀리고 거기에 나오는 정보도 조금씩 틀릴수도 있지만결국은 같은 정보들이 다른 방법들로 나열되고다른 디자인을 입혀서 다른 식으로 나오는 거지결국은 하나의 정보가 여러페이지에 나오는거임'예'의 로직이 디자인과 프론트엔드 코드에 적용이 되어야 함프로덕트의 이미지가 카테고리 페이지에서 보이는 이미지와 프로덕트 페이지에서 보이는 이미지 요..
싫은점같이 배포하기로 한 날이 있는데 그 전날에 개발 서버를 배포하는 개발자뭐 바꿔놓고 안알려주는 벡엔드 개발자상태코드가 바뀌었다거나갑자기 property명이 바뀐걸 안알려줬다거나뭔가에서 안 됐는데 쓸모없는 에러메시지를 뱉어주는 벡엔드 개발자서버 에러일 수도 있는데 InvalidArgument등을 내려준다던가인터페이스 변경해놓고 알려주지 않는 개발자좋은 사람그런걸 다 공유해주는 사람 API를 만드는데 있어서 흐름까지 전부 다 그려가지고 그거까지 공유해주는 개발자
· 협업/PM
https://www.youtube.com/watch?v=WVvFRh1vGv8&t=368s  동기 유발하는 PM정책을 깊게 이해하는 PM대충 개발 시스템을 이해하는 PM 개발자의 능력을 100% 끌어내주는거대충 정리해서 일 던져주는 PM 별로 OWN (나의 일)내 마음을 쓰는 진짜 나의 일어떤 일을 더 많이 신경쓰고 고민할 때 더욱 OWN기획자는 스스로 업무를 준비하면서 OWN누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다개발자도 마찬가지좋은 PM이걸 왜 해야하는지 정말 집요하게 설명데이터랑 고객 관점과 어떤 회사의 가치라는 관점에서 되게 설명을 잘해줌이런 것땜에 하는게 좋고 이러면 고객 가치가 뭐가 높아지고 이런걸 되게 잘 얘기해줌피드백을 받을 수 있는 창구를 열어놈기획서만 리뷰하고 기..
· 협업/PM
프로덕트 매니저 != 프로젝트 매니저 프로젝트 매니저단기적인 실행과 완료의 액션 위주독특한 결과물이 있어야 하고한시적이어야 하고점진적으로 구체화되는 특성이 있다어떤 기능을 만들고 배포할 때까지를 프로젝트라고 함일정관리, 범위관리, 이해관계자 관리, 커뮤니케이션 관리, 품질 관리 등보통 메이커들이 직접 함메이커 중에 시니어 개발자, 테크 리더가 그런 것들을 조율하고 일정을 만들어 냄프로덕트 기준으로는 극히 일부분 프로덕트 매니저프로젝트가 모여서 만드는 결과물제품을 만드는 자체에서 프로젝트 관리요소가 들어감경영진과 커뮤니케이션을 해서 싱크가 맞아야 됌고객을 찾아내서 고객들이 실제로 그런 고통을 가지고 있는지 무슨 생각을 하는지 어떤걸 필요로 하는지 찾아봐야 함실제 개발을 하고 운영을 시작운영을 하고 있는 중..
류가든
'협업' 카테고리의 글 목록