AI (227) 썸네일형 리스트형 메타인지 in 트루먼쇼 메타인지를 하고 있다고 생각하는 행동이 영화 트루먼쇼 안에서의 메타인지 라는 걸 시간이 지나서 깨달을 때가 있다. 내가 억지로 설명을 위해 억지로 만든 용어지만, '메타인지 in 트루먼쇼' 란 단어를 생각하고 트루먼쇼를 벗어나기 바란다. (내 자신에게 하는 말)--팬택과 아이리버의 사례를 보면서..혁신 in 트루먼쇼 인가.. 싶다. 슬램 알람 봇 - 1 (python bolt) 우리 서비스의 현황을 알려주는 봇을 만들어볼려고 한다.아침 9시마다 전날의 현황인 아래 두가지를 알려주는 봇이다.- 어제 회원가입 한 수- 어제 이용한 건 수 원래는 백엔드에서 배치로 작업을 했지만,백엔드 개발자가 서비스를 위한 배치가 아닌 배치를 또 Task로 잡고 만드는 건 아닌 것 같고, 프론트 개발자가 이미만들어논 API가 있어서 PM인 내가 Slack workflow 에 GET요청 코드를 넣어서 만들어보려고 한다. 슬랙에 있는 Workflow Builder 기능을 사용합니다. 이렇게 하려고하는데, 워크플로에 붙일려면 '커넥터' 항목에 등록된 앱이거나 '맞춤형'으로 직접 만들어야하는 것 같다.커넥터에는 outgoing webhook이 등록되있지 않다. 심지어 outgoing webhook(발신 웹.. firebase studio firebase studio가 어제 런칭되어서 써봤다.그냥 이제 코딩이 agent가 다 해준다.. 어떤 방향으로 앞으로 흘러갈지 마일스톤이 되지않을까 싶다. IT 프로덕트를 만들때, ;한국인 특'을 생각해야한다. 게시판만 딸랑 만들어 놓고 커뮤니티 라고 하면 아무도 안쓴다. 프로필에서 자기소개 칸을 만들어 놓으면 아무도 안쓴다. 한국인은 잘 논다. 하지만 어떻게 노는지를 알려줘야 잘논다. 가이드가 필요하고 마중물이 필요하다. 커뮤니티는 운영자가 콘텐츠 발행을 해주고 어떻게 반응하는지 계속해서 마중물을 넣어줘야하고프로필에서는 자기소개 칸을 앱에서 누르면 bottom sheet가 올라와서 그냥여러 예시중 하나를 클릭하던가 거기서 만족못하면 + 직접작성하기가 있어야한다. 이건 국내에서 IT프로덕트를 만들 때 꼭 알고있어야하는거다.프로덕트 매니저가 [2024년 12월 연말] 개발의 미래 https://github.com/stackblitz/bolt.new GitHub - stackblitz/bolt.new: Prompt, run, edit, and deploy full-stack web applicationsPrompt, run, edit, and deploy full-stack web applications - stackblitz/bolt.newgithub.com 브라우저에서 Prompt로 개발하고, 코드짜고, 배포까지한다.https://github.blog/changelog/2024-12-18-announcing-github-copilot-free/ Announcing GitHub Copilot Free · GitHub ChangelogAnnouncing GitHub Copilot.. PM 내가 기획작성 순서 & 기획을 전달하는 순서 디자이너와 개발자의 숙련도와 연차에 따라서 달라집니다.[앱개발]정책문서 작성기획문서 작성기획문서를 1. 디자이너한테 전달 초안 요청 -> (반박자늦게) 백엔드 개발자와 기획내용 협의 통과하면 일정협의 WBS등.. 2. 앱개발자 마지막으로 전달 마지막: 전체공유 다시 한번 더 [웹개발]정책문서 작성기획문서 작성기획문서를 가지고 1. 프론트개발자와 이야기 2.디자이너와 위와같은 과정 . 3. 백엔드 개발자와 획내용 협의 통과하면 일정협의 WBS등.. 4. 프론트 개발자한테 픽스전달 마지막: 전체공유 다시 한번 더중요한건.. 백엔드 개발자와 이야기할 때는 PM으로서 하나의 기능과 정책에 대해서 해왔던 Context 를 공유해야한다. 그래야 일정을 측정할 수 있다. 디자이너는 경력이 있으면 좋다. 정책문서과 기획문서 차이 난 이렇게 함 개발로 치면 정책문서는 interface고 기획문서는 class임정책 문서에 포함될 경우:"동일한 쿠폰의 중복 발급 방지: 관리자는 동일한 쿠폰을 특정 사용자에게 중복 발급할 수 없으며, 시스템은 중복 발급 시 경고 메시지를 표시합니다."안되는걸 명시해서 쫌 더 느슨하게 작성해야하는 것 같기도?기획 문서에 포함될 경우:"관리자 페이지에서 동일한 쿠폰을 특정 사용자에게 발급할 경우, 중복 발급을 차단하는 로직을 추가합니다. 중복 발급 시 경고 메시지를 표시합니다."사용자는 어떤 기능을 어떻게~를 할 수 있다. 할수있다를 명시하면 편함 이건 대학교 때 배웠던 것 같은데, 아니면 사회초년생때 배웠거나 헷갈리네관리자는 ~를 할 수 있다. 정책 문서는 "왜" 중복 발급을 방지해야 하는지와 "무엇".. PM과 하인리히 법칙 (매니저와 구성원) https://namu.wiki/w/%ED%95%98%EC%9D%B8%EB%A6%AC%ED%9E%88%EC%9D%98%20%EB%B2%95%EC%B9%99 하인리히의 법칙큰 실수는 굵은 밧줄처럼 여러 겹의 섬유로 만들어진다. Les fortes sottises sont souventnamu.wiki늦게 퇴근 + 피곤 빠르게 짧게 요약해서 대충 적겠다. 매니저는 힘들다. 혼자 프로젝트의 '재난' 이 발생하지 않게 노력하는 존재다. (위에 나무위키 참고)혼자 리스크를 부담한다. --- 리더 탓, 무능력한 리더가 고생시킨다.병사가 아닌 장교에게 책임을 물어라 --> 이것 정말 맞는말이고, 내가 좋아하는 말이다. 장교는 구성원들을 적재적소에 배치해야하는 책임이 있고,구성원들에게 비전을 제시해야한다. 근데.. 이전 1 2 3 4 ··· 29 다음
