pmjigu

🧭 지난 이야기지난 글에서는 “왜 자동화를 하게 됐는지”, 그리고 “어떤 문제를 발견했고 어떤 흐름으로 바꿨는지”에 집중했어요. 이번 글은 예고했던 대로 그 연장선에서, 제가 실제로 적용한 노션 자동화 설정 방법을 최대한 짧고 따라하기 쉽게 정리한 실전편입니다. 처음 보시는 분이라면 아래 글을 먼저 보면 “왜 이 설정이 필요한지” 맥락이 더 또렷해져요.👉 [Notion] 같은 일을 두 번 하던 협업 프로세스, 노션 자동화로 한 번에 끝내기결론부터 말하면, 설정 자체는 생각보다 복잡하지 않아요. 이미 우리가 겪는 문제가 무엇인지, 어떤 방식으로 해결할지 흐름은 먼저 정리해뒀잖아요. 그리고 “이벤트(조건) 발생 → 슬랙 메시지 전송(액션)” 이 한 문장만 이해하면, 아래 과정은 거의 클릭 가이드에 가깝습..

📝 협업 요청/완료 프로세스를 노션×슬랙 자동화로 운영 가능하게 만든 작은 기록입니다저희 팀은 디자인 요청을 할 때마다 노션에 등록하고, 이메일로 “요청드립니다” 보내고, 작업이 끝나면 디자이너는 노션 상태를 바꾸고, 다시 이메일로 “완료됐어요” 보내고…근데 이상했어요. 이렇게 번거롭게 두 번씩 하는데도 확인은 직관적이지 않았고, 누락은 생겼거든요. 결국 우리 팀의 메신저인 슬랙에서 “혹시 메일 확인하셨을까요?”를 또 물었습니다. 저는 '아, 이건 문제다.개선이 필요하다'고 생각이 들기 시작했습니다.우리가 겪고 있던 ‘협업 비용’은 이런 형태였다우리 팀은 디자인팀과 협업이 많아서 제작물 요청이 자주 발생해요. 개발팀은 Jira를 활용하고 있어서 이런 문제가 덜했는데, 디자인팀은 Jira를 쓰지 않았기에..

🧭 앞선 이야기 : 왜 자동화를 하게 됐는지 궁금하다면이번 글은 ‘실제 설정 방법’에 집중한 실전편입니다.왜 자동화를 시도하게 됐는지, 어떤 흐름을 만들고자 했는지는 아래 글에서 자세히 다뤘어요.👉 [Notion] “왜 안 봐요?” 대신, '자동화' 적용으로 자연스럽게 바꿨습니다🔧 어떤 자동화를 만들었나요?기능보다 ‘흐름’을 만드는 게 더 중요하다고 생각했어요이번에 설정한 자동화는 아래 두 가지 간단한 흐름이었습니다프로젝트가 신규 등록되면 → 슬랙 채널에 알림프로젝트 상태가 ‘완료’로 변경되면 → 슬랙 채널에 알림물론, 더 정교한 조건이나 수식을 걸어 만들 수도 있었지만처음부터 복잡하게 가는 건 오히려 실행을 늦출 수 있다고 생각했어요.작게라도 빠르게 시도해보고, 반응을 본 뒤 점진적으로 개선해나가..

🛠️ 도입보다 더 어려운 것 : ‘잘 쓰이게 만드는 일’ PM으로 일하다 보면, 팀에 어떤 툴을 ‘도입’하는 것보다그 툴을 ‘잘 쓰이게 만드는 것’이 훨씬 더 어렵다는 걸 실감하게 됩니다.예전 포스팅에서도 한 번 이야기했듯,우리 팀은 원래 노션을 전혀 쓰지 않던 팀이었습니다.https://fejigu.tistory.com/5(혹시 그 과정을 아직 못 보셨다면, 위 포스팅을 참고하셔도 좋아요.노션 도입을 고민하시는 분들께 도움이 될 수 있을 거예요.)업무 대부분이 말로, 혹은 개인 간 메신저를 통해 이뤄졌고‘기록’이라는 습관은 익숙하지 않았습니다.그런 팀에 노션을 도입하고, 루틴화한 것도 분명 쉽진 않았지만사실 진짜 고민은 그 이후부터 시작됐어요.“어떻게 하면 팀원들이 노션을 더 자연스럽게,그리고 놓치지..

저는 이전 직장에서 프론트엔드 개발과 기획을 동시에 맡다가PM으로 이직한 첫 주, 팀 분위기를 파악하려고 조심스럽게 살폈습니다.팀원들은 모두 이곳이 첫 직장이었고, 2~3년 이상 함께해온 멤버들이었죠.일하는 방식도, 사용하는 툴도 각자에게 익숙한 루틴이 자리 잡고 있었습니다.그런데 이상하게도, 누가 어떤 프로젝트를 하고 있는지 알 수 없었고,업무 내용은 대부분 사람 머릿속이나 개인 메모장에만 있었습니다.회의는 끝나면 잊혔고, 담당자가 없으면 업무도 멈췄죠.변화가 필요하다고 느꼈고, 저는 조용히 노션을 꺼내 들었습니다.🧭 그래서 저는 노션을 꺼냈습니다팀 안에서 반복되는 혼란을 보며,문서화되지 않은 정보, 공유되지 않는 업무, 끊기는 커뮤니케이션을 정리할 방법이 필요하다고 느꼈어요.그때 자연스럽게 떠오른 ..