4주차 Info (2025.01.27~2025.01.31)
[이번주에 한 실습]
1) KPI 분석 피드백 및 마무리
2) 피드백 정리
과정 평가 및 혜택
1️⃣과정 평가 개요
1. 평가 내용
내용 | 비율 |
지금까지 작성한 아티클 분석, 실습, WIL (1~5주차) | 30% |
KPI 분석, 페르소나 별 제안서 실습 (4~5주차) | 50% |
참여도/성실도 (1~5주차) | 20% |
2. 평가 기준
<아티클 분석/실습/WIL>
유형 | 세부 기준 |
(1) 논리성 | 문제 정의부터 결론 도출 과정이 논리적인가? |
(2) 이해도 | 에듀테크 산업 및 부트캠프 시스템에 대한 이해도가 적절하게 갖추어졌는가? |
(3) 참신성 | 문제의 본질을 해결할 수 있는 새로운 기획을 도출했는가? |
<참여도/성실도>
유형 | 세부 기준 |
(1) 일정 준수 | 기한 내에 완성했는가? |
(2) 목표 지향 | 기한 내 완성하지 못했어도 시간을 할애해서 완성했는가? 기한 내 완성했다면 피드백을 반영하여 추가로 보완을 했는가? |
(3) 참여도 | 질문, 세션 중 답변, 캠 켜고 참여 등 |
2️⃣과정 혜택
- 수료생 전원 : 서류 면제
- 우수 수료생 : 서류 면제 + 우선 면접권 부여
지금까지 우수하다고 생각되는 인원은 4명 (늘수도 줄어들 수도 있음)
4주차 FeedBack (2025.01.27~2025.01.31)
피드백 주제 : KPI 분석
1️⃣chatGPT (생성형 AI)의 활용
- 데이터의 전체적인 틀을 보거나 개요를 짤 때는 사용하는 것이 좋다.(현상 분석) -> 교육 운영 PM도 GPT를 사용하긴 한다.
- 그렇지만 결론이나 해답을 GPT가 주어진 그대로 넣는 것은 좋지 않다. -> 하지만 교육 운영 PM도 GPT로 결론을 내지는 않는다.
- 문제 정의, 솔루션은 GPT보다 사람이 더 잘한다.
2️⃣과제의 핵심 - 문제 정의
- 현상을 나열하는 것은 문제 정의를 잘 하는 것이 아니다.
- 문제 정의를 잘 한다는 것은 1) 현상을 파악하고 2) 그 현상이 일어난 진짜 문제를 파악하는 것이다.
Ex) 문제 정의 - 가설 - 문제 해결 방안 도출 예시
만족도가 낮아져서 알아보니 팀빌딩에서 문제가 있다는 것을 파악했다. 팀빌딩의 어느 부분이 문제인지 찾기 위해 아래와 같이 생각했다.
1. 사소한 갈등이 있는 사람들이 있었다. 그 사람들에 대한 정보가 이미 있었음에도 팀으로 묶었다. 그 결과 프로젝트를 하는 동안 갈등이 심화가 되어 그 팀들에 대해 만족도가 낮아진건 아닐까?
2. 팀 내에서 실력 격차가 너무 크게 있어서 잘하는 사람과 못하는 사람 둘 다 얻어갈 수 있는게 없는 프로젝트여서 만족도가 낮아진 것이 아닐까?
정성적 데이터 VoC를 보니 1번이 문제여서 다음 팀 빌딩을 할 때는 갈등이 있는 사람을 사전에 파악하여 분리하고 팀빌딩에 신경을 쓴다면 만족도가 30% 오를 것이다라는 가설을 세웠다.
문제 해결 방안으로는 가설을 기반으로 팀프로젝트 팀빌딩 전 직전 상호 평가와 교육생과의 관계를 조사하여 팀빌딩 과정의 우선순위를 둘 것이다.
case 1. 이탈률 분석 (이탈률 개선 방안)
- 통제할 수 있는 변수인지 아닌지 파악 후 통제 가능한 영역에 집중
- 가설을 시각적으로 보여줄 수 있으면 더 좋겠다!
통제할 수 없는 변수 : 건강, 생계, 가정 문제 (지극히 개인사 문제)
학습 로드맵을 주고 개인 프로젝트를 할 수 있도록 해줘도 애초에 12시간동안 부트캠프에 몰입할 수 있는 상태가 아니므로 억지로 이탈하지 않도록 끌고 오기는 어렵다. -> 통제가 불가능한 변수
이런 경우, "통제가 불가능한 변수는 이 정도 있었고 통제가 가능한 영역은 이 정도 있었으면 나는 통제가 가능한 영역에 집중을 하려고 한다는 느낌으로 가면 된다."
case 2. 만족도 분석 (성공요인 강화 문제)
- 어떤 Action에 대해 만족한다보다 그 Action을 통해 어떤 needs가 채워졌는지 파악할 것
- 성공 요인 강화 전략을 설명할 때 팀프로젝트, 학습 부문을 왔다갔다 하면서 생각해보면 더 잘 설명할 수 있을 것
팀빌딩 때문에 만족했다면 그 중에서도 어떤 부분 때문에 만족이 되었는지, 아니면 어떤 부분이 특히 해결이 되어서 전체적으로 만족하게 된 건지 정확하게 정의해야 한다.
case 3. 만족도 추이 분석 (그래프에서 특이점을 찾고 분석해야 하는 문제)
- 우상향하고 있는 그래프에서 전체적인 추세를 깨고 왜 15주차만 NPS가 떨어지게 되었는지 문제정의를 정확하게 할 것
4주차 Q&A (2025.01.27~2025.01.31)
1. 이탈률을 줄이기 위해 지원을 받을 때 수강생을 선별하여 받아야 하는 것이 좋은 것인지? vs 아니면 이들에게 지속적으로 학습의지를 부여하여 이탈을 하지 않도록 하는 것이 좋은 것인지?
(Ex. 국비과정으로 수강료가 0원이라 학습의지가 약해보이는 수강생)
- 가치관 차이이다.
- 어떤 부트캠프는 교육과정을 잘 해나갈 수 있는 사람을 선발하여 그 사람들을 잘 교육하여 내보내는 것이 옳은 교육이라고 생각하는 사람도 있다.
- 모두가 처음부터 기초 실력을 가지고 있는 것이 아니다. 그런 사람들을 잘 교육시켜서 본인이 원하는 방향으로 갈 수 있도록 하는 것이 옳은 방향이라고 생각하는 사람도 있다. -> 팀스파르타가 추구하는 방식 ("누구나 큰 일을 낼 수 있다.")
Ex) 이탈률을 줄이기 위해 수강생을 선별해서 받는 것은 옳은가?
유료 서비스의 경우 : 과정을 안정적으로 진행할 수 있도록 비슷한 사람들을 모아서 집중적으로 관리를 해주어야 한다. 이런 경우에는 사전에 선별이 필요함
무료 서비스의 경우(국비교육) : 어떤 학생은 취업률에 도움이 될 것 같으니까 선별하고 누구는 받지 않는다면 적절한 방향은 아니다.
2. 이탈이 중반이나 후반에 있는 것이 초반에 이탈하는 것보다 회사에 이익인지?
- 최대한 늦게 나가는 것이 회사에 이익은 맞다.
- 왜냐하면 그 학생이 남아 있는 기간동안 회사도 훈련비를 책정 받는다.
- 전체 과정의 80%를 이수하고 조기 수료도 가능하다. 이런 경우 이탈률로 집계가 되지 않는다.
3. 실무에서는 KPI설정 단계에서 목표지향적인(다소 성과에 욕심을 반영한) KPI와 현실적으로 달성 가능한 KPI의 간극을 어떻게 조절하는 지 궁금합니다.
- KPI = 핵심 성과 지표 = 목표지향적일 수밖에 없다. KPI를 달성했을 때 성과가 나도록 설정
- 교육운영 KPI 구성 요소 = 만족도, NPS, 이탈률, 실력지표(상위권 비율)
- 가드레일 지표 = 이 이상은 적어도 달성해야 한다.
4. 실제 KPI 달성률이 높은 편인가요? KPI 달성 실패가 치명적으로 여겨지는 지 궁금합니다.
- 팀스파르타의 KPI 달성률은 60% 정도
- 해야 할 일을 기한 내에 완수했는데도 실패 했다면 그 실패에 대한 책임은 교육운영파트장이 진다. 왜냐하면 팀장이나 파트장이 전체적인 큰 방향의 틀을 정해주기 때문
- 중요한 것은 KPI 지표가 우수하게 나왔는데 왜 우수하게 나왔는지 모르는 것과 KPI 지표가 낮게 나왔는데 왜 낮게 나왔는지 모르는 것이 최악이다.
5. KPI를 지속적으로 모니터링 해야한다는 말이 아티클에 있었는데, 회사나 프로젝트 진행에 이슈가 생겨서 당해 KPI를 달성하자 못할 것 같을때, 이를 수정하기도 하나요?
- 수정하기도 한다.
6. 실력 성과 KPI에서 과제 완성도, 과제 제출율, 시험 등을 통해 '상', '중,' 하'로 나눌 수 있을 것 같습니다. 이를 지표화하는 과정에서 학생의 실력을 제외하고도 시험 난이도가 높거나 원래 어려운 이론 부분을 다루는 경우 '중' 이나 '하' 로 갈 가능성이 높아진다고 생각합니다. 실무에서 이런 변수도 고려하시는지 궁금합니다.
- 고려를 하긴 하지만 보정을 하지는 않는다. 왜냐하면 객관적인 판단이 어려워지기 때문이다.
6-1. 과정 1기라서 비교할 수 있는 실력 성과 지표가 없는 경우 어떻게 판단하시는지 그 기준이 궁금합니다.
- 비슷한 코호트끼리 비교를 해본다. (Ex. react 1기 과정이라면 node.js 에서 문법 과정에서 똑같이 javascript를 배우니까 지표를 비교해본다.)
- 전혀 레퍼런스가 되는 코호트가 없는 경우 외부의 자료(외부 비슷한 프로젝트를 한 사례 등)를 찾아본다. (Ex. UI/UX 1기 과정)
- 1기 과정에서는 평가 지표를 세분화해서 보려고 노력한다.
7. 실력 성과 KPI에서 최종프로젝트의 퀄리티 평가한다고 하셨는데, 우수한 프로젝트를 평가할 때 주관적 요소도 들어갈 수 있을 것 같습니다. 그래서 어떻게 객관적으로 평가할 수 있는지 궁금합니다.
NPS 점수의 경우 상대적인 지표로 분석해야 될 것 같은데 KDT 사업의 IT 교육의 경우 보통 평균적인 NPS 점수가 어느 정도 되는지 궁금합니다.
- 기준이 있어서 점수로 평가를 해달라고 해준다.
- 그리고 정성적인 부분도 적어달라고 한다.
- 평면적으로 판단하는 것이 아니라 다각적으로 판단하는 이유? 개발자, 기획자, 디자이너의 실력을 아주 객관적으로 판단하는 것은 어렵다. 회사에서도 개개인에게 원하는 역량도 조금씩 다르기 때문이다. (디자이너여도 UX적인 부분을 더 중요하게 보는 회사도 있고 UI적인 부분을 더 중요하게 보는 회사도 있다.)
8. 한 트랙에 NPS가 높게 나왔을 때 수강생들이 실제로 추천을 했는지 알 수 있는 방법이 있는가? (NPS가 높게 나온 것은 좋지만 실제로 추천해야 의미가 있다고 생각한다.)
- 팀스파르타에서는 지인추천 이벤트를 할 때가 있다. 그런데 NPS를 높게 준 교육생이 지인추천 이벤트에도 참여를 해서 추천하신 분들이 팀스파르타 과정에 들어 왔는지를 체크해보진 못했다. 그래서 이 부분을 분석해보면 좋을 것 같다.
9. NPS 점수의 경우 상대적인 지표로 분석해야 될 것 같은데 KDT 사업의 IT 교육의 경우 평균적인 NPS 점수는?
- 팀스파르타 B2B, B2C, B2G 와 비교를 했을 때는 B2G가 제일 높다.
10. 최하방인원으로 분류되는 기준?
- 웹 개발 : CRUD + 로그인/회원가입 구현
- 최하방 = "이것도 못하면 안된다."
- 최하방 인원들은 최하방의 요건을 구현할 때까지 시킨다.
11. 데이터리터러시 실습과 같이 최하방인원이 8명이라면, 팀빌딩을 할 때 최하방은 다른 수강생과 섞여 팀을 만들게 되는지 아니면 최하방끼리 따로 팀을 빌딩하게 되는지 궁금합니다.
- 여러가지 시도를 한 결과 최하방은 최하방끼리 묶어주는 것이 좋았다. (최하방 인원도, 상위권 인원도 만족)
- 최하방 인원 = 실력에 대한 자존감이 떨어진 사람 = 다른 사람들이랑 묶으면 어떤 역할도 주도적으로 하겠다고 하지 못한다. = 왜 못하는지 다른 사람들이 공감해주지 못하므로 자꾸 위축되고 문서 정리, PPT만 하는 경우가 있다. (그리고 잘 하는 사람들과 기본적으로 상호작용 소통 자체가 불가능하다.)
- 최하방 인원끼리 묶으면 아주 작은 것이라도 본인이 만들어보며 시행착오를 겪을 수 있고 이야기하면서 공감대 형성도 잘 된다.
- 단, 하방은 CRUD를 할 수 있는 상태이므로 기본적으로 1인분은 할 수 있다. 이런 인원은 섞어서 팀을 매칭한다. 못하는 것은 소통하면서 배울 수 있다.
12. 현상을 바탕으로 문제점을 발견하여 그것을 데이터로 검증하는 것이 가장 이상적이고 빠른 방법이라고 생각합니다. 하지만, 현상에서 문제점을 발견할 수 없는 특수한 경우에는 어떻게 해야 할까요? 인터뷰를 제외하고 비용적, 시간적 측면을 고려했을 때 현업에서 가장 효율적이라고 생각하시는 방법이나 사례가 있으신지 궁금합니다.
- 좀 더 엄밀하게 이야기하면, 데이터를 통해서 추세/현상을 보고 그 현상에서 문제를 발견하고 문제를 정의하는 것이다.
- 문제를 정의하는 과정에서는 효율적인 방법을 생각하면 안된다.
- 과정을 개강하기 전까지를 담당하는 전환 파트의 경우 가설이나 감을 가지고 실험을 해도 된다. (대상이 잠재고객이기 때문, 고객이 된 사람이 아님)
- 하지만 교육운영의 경우 문제 정의를 안하고 가설만으로 실험을 하면 교육 진정성에 좋지 않은 행동 (왜냐하면 간절한 마음을 가지고 온 교육생도 있을 것인데, 이 교육생을 대상으로 실험을 한 것이므로)
- NPS가 많이 떨어졌는데 현상을 찾으려고 데이터를 봤더니 특별한 내용이 없어보일 때는 인터뷰가 좋은 해결책
👍좋았던 점
🔥실습과 과제에 대한 피드백을 통해 체계를 잡다.
피드백, 체계
연휴가 좋은 타이밍에 있었던 것 같다. 그동안 피드백들을 정리하고 문제점을 개선할 수 있었다.
특히 예전에는 문제 정의의 중요성을 모르고 문제 현상만 바라보고 이 것을 해결하기만 급급했는데 과제를 진행하면서 아래와 같은 프로세스 체계를 만들어서 했다는 점에서 칭찬하고 싶다.
1️⃣ 데이터를 바탕으로 카테고라이징 -> 현상 파악
- 정량 데이터
- 평균, 중앙값 분석
- 상관관계 분석
- 추세 파악
- 데이터 시각화를 통해 경향성/특이점 파악
- 정성 데이터
- 자주 빈출되는 키워드 정리
- 인터뷰
- 🌟 정량 데이터와 정성 데이터를 교차 검증
2️⃣현상을 바탕으로 문제를 발견하고 문제 정의
- 계속 "왜?" 를 거치면서 진짜 문제를 정의
- 어떤 하나의 문제가 다른 연쇄적인 문제로 이어진다면 문제 정의 Good
- 따로따로 1,2,3,4,5 나열식으로 문제 현상이 나온다면 조금 더 고민해보기
3️⃣문제 정의를 바탕으로 가설 수립
- ~한다면 ~할 것이다. (Action + 기대 효과)
4️⃣실행 방안
- 정의한 문제를 해결할 수 있는 세부적으로 실행 방안을 작성
🔥미스터리쇼핑을 진행하다.
팀스파르타가 궁금했다.
팀스파르타는 최근에 미미미누, 김계란, 면접왕 이형님까지 대형급 유튜버들을 광고 모델로 섭외하였다.
궁금해서 더 찾아보다가 내일배움캠프에서 제공하는 취업 고민 상담 이벤트가 있었다.
팀스파르타 현직자와 대화해보고 수요자 입장에서 체험도 할 수 있으며 취업 고민 상담도 진짜 할 수 있는 1석 3조의 기회였다.
당장 신청해서 진행했는데, 자세한 내용은 다음 포스팅에 작성하겠지만 꼭 해보시길 바란다. 실질적으로 도움이 되었을 뿐만이 아니라 긍정적인 에너지도 얻을 수 있다. 이거 기획한 사람은 상 줘야 한다고 생각한다.
여기서 팀스파르타에 대해 이것 저것 묻기도 했는데 무려 1시간 47분동안 통화를 해주셨다. 팀스파르타에 대한 궁금증도 해소되었고, 교육과정에 진심이라는 것을 다시 느낄 수 있었다.
어떤 서비스에 대해 알고 싶으면 내가 소비자가 되는 것이 가장 빠른 길이라고 생각했다. 앞으로도 실제로 내가 소비자가 되어 실제로 사용해보는 경험을 많이 해보고 더 통찰도 해야겠다.
아쉬운 점 / 생각해볼 점 / 개선이 필요한 점
🔥아티클을 보고 "교육PM"에 어떻게 적용할 수 있을지를 생각하면 더 좋겠다.
1월 7일부터 모든 피드백을 봤다. 말씀 주신 피드백 덕분에 많은 부분이 개선이 되었다.
하지만, 아티클을 읽고 어떻게 적용하면 좋을지에 대한 부분을 "교육PM" 관점에서 조금 더 생각해보면 아티클을 읽는 것이 더 의미있는 시간이 될 것 같다.
31일 아티클부터는 내가 진짜 교육운영PM 이라면 어떤 부분을 적용하고 싶은지와 기대 효과를 같이 적용하여 작성해야겠다.
🔥Python이 아니라 Zapier으로 slack 자동 메시지를 보낼 수 있다고?!
4주차 피드백 세션때 잠깐 언급하고 지나갔던 부분인데 Zapier으로 slack 자동 메시지를 보낼 수 있는 것이 있다고 하셨다.
평소 python 코드로 구현해서 slack 자동 모니터링 프로그램을 만들었던 나에게는 신선한 충격이었다.
Zapier가 python으로 코드 작성하는 것보다 유지보수가 편한지, 더 생산성이 좋은지 한 번 사용해봐야겠다. (현업에서도 사용하고 있을 정도면 이미 검증이 되었겠지만..)
🔥Flutter 강의를 수강하기로 결심했는데 아직 수강하지 못했다.
교육과정 논외의 이야기지만 스파르타코딩클럽의 Flutter 강의를 수강하고 실제로 서비스를 운영해봐야겠다. MVP 까지 만들어진 서비스가 있는데 PM 시간에 배웠던 분석 방법을 내가 만든 MVP 서비스에도 적용하여 설문을 해보고 사용자의 요구사항을 파악한 후 Flutter을 학습하여 앱으로 출시하고 싶었다.
그리고 설문 조사 문항은 어떻게 짜야 하는지도 배우고 싶다.
일단 task를 쪼개서 1) 스파르타코딩클럽의 Flutter 강의 수강 -> 2) 사용자 요구사항 설문 조사 -> 3) 팀빌딩 및 제작 중 1단계를 2주 안에 완수해야겠다.