안녕하세요! 저희는 Culture & People 팀의 스더와 로아 입니다!
지난 12월 1일에 열렸던 개발자와 소통하며 가치를 만드는 사람들의 이야기 - Dev Chat에
참가하였는데요! Dev Chat을 통해 얻은 인사이트와 세미나 내용을 소개합니다!
지난 12월 1일에 열렸던 개발자와 소통하며 가치를 만드는 사람들의 이야기 - Dev Chat에
참가하였는데요! Dev Chat을 통해 얻은 인사이트와 세미나 내용을 소개합니다!INDEX
세미나 참여 소감
•
스더
◦
데브챗 세미나를 듣고 싶었던 이유는 HR 및 채용 브랜딩 담당자로서 우리 회사가 갖고 있는 문화적, 기술적인 장점은 어떤 방식으로 외부에 잘 알릴 수 있을까에 대한 고민이 있었기 때문입니다.
◦
연사분들은 개발자 출신뿐만 아니라 리쿠르터, 교육담당자, 콘텐츠 기획자 등 다른 직군에서 커리어를 시작하신 분들이 계셨습니다. 개발자 소통 문화를 위한 하나의 목적을 위해 다양한 배경의 분들의 다양한 방법론들을 들어볼 수 있어서 의미 있었고, 여러 시행착오와 노하우를 배울 수 있었습니다.
◦
HR을 담당하셨던 분께서 HR은 사람을 자원으로 바라보는 관점인데(Human Recource), Devrel의 경우 관계의 관점(Developer Relations)로 볼 수 있다는 것에서 가장 큰 차이가 있다는 말씀이 기억에 남고 앞으로도 되새길 것 같습니다!
•
로아
◦
HRer로써 DevRel, Developer Relation이 무엇인지 단순하게 궁금했습니다. DevOps와
유사한 건지, 인사팀과 구체적으로 어떻게 다른 건지 궁금증이 있었는데 이번 Devchat을 통해서 궁금증을 해소할 수 있었습니다.
◦
단순히 개발 지식이 있는 인사담당자 정도로 생각했는데, 개발자와의 관계를 중시하며 성장을 지원하며 “더 나은 개발 문화로 더 나은 기술의 탄생”을 고민하는 조직이라는 것을 느꼈습니다. 개발자가 아닌 다양한 경험을 갖고 계신 데브렐 분들의 이야기를 들으며, 누구보다 개발 조직과 문화를 사랑한다는 점이 느껴져서 좋았습니다. DevRel을 통해 계속 다니고 싶은 회사의 기술 문화를 만들 수 있겠다는 생각이 들었는데, 정말 가치 있고 멋진 일이라고 느껴졌습니다.
◦
헤렌에 적용하고 싶은 작은 인사이트
▪
네이버 부스트 캠프에서 진행하는 릴레이 프로그램이 인상 깊었습니다. 릴레이 형식을 통해 재미와 흥미를 부여 함으로써 구성원들의 참여도를 올릴 수 있다고 느꼈습니다. 구성원들과 서로 칭찬을 주고받는 사이트인 헤자박스나 기술 블로그 등을 릴레이 형식으로 다음 작성자를 지정한다면 재미와 함께 활성화에 도움이 될 것 같아요!
▪
Slido를 이용하여 실시간으로 Q&A를 진행하는 점이 인상 깊었습니다. 헤렌에서도 타운홀 미팅이나 추후 진행될 전사 교육 세션에서 적용해 보면 좋을 것 같습니다. 다양한 질문을 주고받는 과정에서 새로운 인사이트도 얻을 수 있을 것 같다는 생각이 들었습니다.
세미나 내용 요약
1부. 소통을 통한 가치 창출
기술 블로그 운영 기법 (SKT)
•
블로그 시작 목적 : 개발자 채용
•
‘18년 오픈소스로 발생된 문제점 해결을 위해 사내 개발자간 협업 및 해결 방안에 대해 내부 공유 기술 블로그 시작
→ 누적되는 블로그 콘텐츠, 활용할 방법이 없을까?
→ ’21년 6월 데보션 런칭 및 외부 공개
•
데보션 활용 방안
◦
대내외 개발자 소통/공유 (블로그 형식) : 매일매일 업데이트 시키는 형태
◦
데보션 전문가 프로그램 : SKT 내부 개발자간 유대 → SK 전체 그룹의 개발자 선발/운영/혜택 부여
◦
예비 대학생 멘토링
•
데보션의 성과 분석 방법
◦
◦
콘텐츠 효과성 : 공유횟수, 유용성
◦
소셜미디어 활동 : 팔로워, 공유/언급SNS → 최근 가입자 기반 레터에 집중
◦
검색 엔진 : 키워드 순위, 유기적 트래픽, 기술 관련 키워드(EKS, Docker 등등) 검색 시 전면에 뜨면 성공적이라고 판단
•
기술 블로그 콘텐츠 유도하기
(1) 쉽게 쓰게 하기 (책 : 개발자의 글쓰기) : 저술이 아닌, 편집자로, 단, 나만의 의견을 쓸 것
(2) 짧게 쓰게 하기 : 길어질 경우 연재 형식으로 작성하기
(3) 자주 얘기 하기 : 잡담에서 아이디어 기록하기
(4) 지금 하고 있는 일로 쓰게 하기 : 회고 → 성장
(5) 재미있게 만들어주기 : 블로그에 게이미피케이션 요소 적용하기, 포인트/랭킹 제도(상위 기고자, 절대평가 등등)
(6) 조직 활동과 연계하기 : 블로그를 쓰기 위해서가 아닌, 내가 하는 활동을 기록하는 형식으로
(7) 외부 행사와 연계하기 : 커뮤니티 행사
•
커뮤니티 활성화의 필요성
: 동아리 같은 보상이 없어도 자발적으로 참여할 수 있는 공간으로 만들기
◦
회사 - 협업 등의 사일로 이슈로 공유가 잘 안됨 → 친밀감에서 오는 힘을 이끌어 내기
◦
커뮤니티 팬덤을 만드는 법 : 관심을 유도하는 동기부여 플랫폼 (역량 플랫폼) + 동참 플랫폼
(Case : NVIDIA, CUDA를 쓰게 하기 위해 커뮤니티를 만듦)
•
컨퍼런스 가서 개발자 많이 만나기!
•
컨텐츠는 여러 사람이 만들기!
SWITCH 사무국의 일하는 방식
•
삼성 사내 소프트웨어 챌린지 : 주어진 업무 수행이 아닌, 본인만의 과제 기획 방법 제공 (현업 프로젝트 외 과제 코칭) (’21년~) → 영역을 넓혀가며, SW개발팀의 일하는 방식을 실험하고 발굴/코칭하는 조직
◦
전문역량 : 애자일 , 테크(아키텍처), 고객경험, 코칭
◦
기본역량 : 코칭, 퍼실리테이션, 티칭
•
SWITCH WAY : Sensing → Discovery → Journey → Commencement
(1) Sensing : 과제 발굴 (or 프로젝트를 못만들 경우 ideation 도움) / expert grade.. open space technology (과제 발굴 아이데이션) → 8시간만에 과제 3개 발굴 ⇒ 회의실에서 하지 않는 회의
(2) Discovery (포션을 많이 둠) : 프로젝트 주제 선정 및 실제 VOC 청취
Discovery (포션을 많이 둠) : 프로젝트 주제 선정 및 실제 VOC 청취•
Intensive camp (3 days)
◦
진행 내용 : 워크샵 (프로젝트를 위한 팀 빌딩, 비전&골 세팅, 아키텍처/퀄리티, CX쪽의 유저리서치 등)
◦
목표 : 개발자들이 목표와 방향성에 대해서 알도록
◦
실제 운영 : 워크샵 후 프로젝트 방향이 바뀌는 사람이 50% 이상
→ 왜? 대기업 특성상 기획팀(특정 부서)에서의 기획 및 Top-down 진행
→ 챌린지 특성 : 개발자 본인이 기획 (개발자 스스로 기획 경험이 없어, Sensing Workshop 간의 갭으로 방향이 바뀌게됨)
Workshop 간의 갭으로 방향이 바뀌게됨)→ 사용자 조사, 사용자 테스트 등 다양한 고객 경험 관점의 방법론에 SW 개발자가 직접 참여
→ 사용자 VOC 수집/분석 (전문성이 필요하여 전문기관에 의뢰하는 부분), 컨셉 검증을 통해 발굴한 인사이트를 개발에 적용
◦
그외 : 요구사항, 계획, 리뷰, 회고를 일정 주기로 점증/반복 → 타겟유저, MVP, team competency metrix (현 팀원의 역량과 필요 역량 체크, 핵심 역량이 있는 개발자가 없는데 이걸 하겠다고?), 누구와 협력합니까? (협력하는 사람 체크), 엘레베이터 미팅 (엘레베이터를 탄 30초안에 너가 팔고자 하는 상품/프로젝트를 설명해봐라)
•
과제를 점진적으로 개선/실행, 스크럼&칸반&XP 등 프레임워크 프랙티스 적용
(3) Journey : 일하는 습관 만들기 (Agile)
(4) Commencement : 과제 마무리, 도전/성장/기여 측면에서 개발 기간 동안 축적된 경험을 나누는 세레모니, 성공&실패 경험을 조직에 공유하고 전파 → 기간별 뭐했는지 리스트업, 도전/성장/기여한 부분 명확하게 작성&공유
⇒ 개발(Journey 단계)에만 신경쓰는 걸 전반적인 프로세스로 시야를 넓히고자!
•
실패로 배운 교훈
(1) 수단과 방법이 목적이 되어서는 안된다 : 합의된 비전과 골의 지속적인 싱크, 과감하게 바꿀 수 있는 유연함
(2) 한번에 큰 변화를 바라면 안된다 : 점진적이고 지속적인 변화, 속도보다는 방향
(3) 리더의 지시나 시스템에 의존하면 안된다
DevRel X HR = Beyond DevRel (롯데e커머스)
•
Upskilling & Reskilling → Career Integration Synergy
•
Issue
(1) 개발환경 및 문화 브랜딩 부재 : 들어와보니 좋은 회사(개발환경, 스택)인데, 대외적으로 모른다
(2) 개발자, 구직자 인지도 부족
(3) 대기업 특유의 수직적, 보수적 문화로 인식
•
Goal
(1) 적합 인재 채용 및 육성
(2) IT 인재 온보딩
(3) IT 인재 역량 육성
•
WorkFlow : 브랜딩 (개발) > 테크 리크루팅 > 온보딩 > 역량강화
(1) 브랜딩 : 기술적 강점 (회사/기술 블로그, 컨퍼런스/행사 참여), 문화적 강점
(2) 리크루팅 : 채용연계형, 외부 부트캠프 파트너십, 다이렉트 소싱
(3) 온보딩 : 온보딩 3단계
•
프리보딩 : 팀원 Ice Breaking
•
IT/UX 집중 온보딩 : 서버 통합 히스토리, 개발환경, IT 인재의 빌더스 프로그램
•
미션보딩 : 버디 매칭, 10가지 미션 수행
•
그외 : LBP (builders program)
(4) Empowerment : 직무 역량 과정 / 사내 세미나, 해외 테크 컨퍼런스
2부. DevRel의 성장과 다양성
육각형 DevRel (Line)
•
라인 DevRel의 2가지 활동
◦
Dev-Culture : 개발자가 성장하고 소통을 강화하는 문화
◦
Tech-Branding : 개발 조직의 강점을 브랜딩을 통해 커뮤니티 등 외부에 전파
•
DevRel로써의 역량 6가지
(1) 커뮤니케이션
◦
사내 커뮤니케이션 (ex. 사내 뉴스레터 : 어떤 개발 시스템 or 오픈소스를 공개했는지, 강의, 외부로 노출하고 있는 유튜브 콘텐츠 등등)
▪
개발 조직의 니즈 파악과 정보 공유를 위한 사내 뉴스 레터
LINE DEV NEWS 발행
◦
사외 커뮤니케이션
▪
라인의 이미지가 일관되게 전달될 수 있도록 실제 개발 언어 커뮤니티와 영상 제작 등을 통해 접점 다변화
(2) 협업 : (블로그 글 작성 시) Technical Writer - Developer - PR - Security - DevRel
개발 조직 - Technical Writing (컨퍼런스, 외부 텍스팅 확인) - PR/채용/HR - 각국 DevRel
(3) 개발/개발자에 대한 이해 + 개발자와 공감할 수 있는 센스
(4) 기획력
◦
타겟 개발자의 관심 유드
◦
개발자와의 교류 활성화
◦
라인개발실록 : 라인 개발실의 기술과 개발 문화를 알리는 유튜브 채널 운영중
(5) 호기심 : 개발, 개발자/팀에 대한 호기심
(6) 능동성 : 경계가 없음 -> 조직의 목표와 align된 활동, 액티비티 가능
1년차 꼬마 데브렐의 존재의의 탐색기 (LGU+)
•
3Q CTO 타운홀 미팅
◦
성장&도전&협업 키워드의 무게는 유지하면서 진부하지 않고 재미있게
◦
패널토크 : 시니어 & 주니어 2명씩 뽑아 진행
◦
성장 관련 질문을 밸런스 게임 형식으로 풀어냄
◦
지향점 : 1on1을 부담이 아닌 즐거운 시간으로 만들기
•
릴레이 기술 블로그
◦
동료의 성장과 이슈는 주변 동료가 더 잘 알것 (아이스버켓 챌린지처럼)
◦
다음 블로깅 대상자를 지목, 대상은 상관없음
3부. 케이스 스터디 - 함께 성장하기
다양한 구성원이 함께 성장하는 개발자 커뮤니티를 만들기 위한 노력 (네이버 커넥트)
•
양방향 커뮤니티로서의 부스트 캠프 : 커뮤니티의 속한 모두는 배움을 얻을 수 있다
•
릴레이 프로젝트
◦
커뮤니티 맴버의 초기 적응을 돕고 이해력을 높이기 위해 시작
◦
금요일마다 한 주를 마무리하는 퀘스트의 형태로 진행
▪
커뮤니티가 지향하는 바를 담은 책 읽
▪
참여자들은 책을 읽고 각자 퀘스트를 생성
▪
퀘스트를 릴레이로 참가자들이 수행
▪
퀘스트 : 책 내용을 기반으로 설명하고 행동하기
•
오프라인 오리엔테이션
◦
현업 마스터가 세션 진행
◦
현업 개발자가 이해하기 좋은 방식으로 소통
•
커뮤니티로써의 부스트 캠프가 나아가야 할 지향점 다섯 가지
◦
1) 모두가 공감하는 핵심 가치 : 구성원과의 합의가 필요
◦
2) 다함께 만들어 나가는 커뮤니티
▪
전사 설문조사, 인터뷰 진행
▪
구성원 스스로의 회고 시스템 구성
◦
3) 커뮤니티의 정체성 확립하기
◦
4) 구성원이 주체가 되는 환경 제공하기
◦
5) 계속해서 찾아오고 싶은 커뮤니티가 되기
▪
기획과 운영에 집중하며 구성원 한 명씩 세심한 케어 필요
개발팀에서의 시도, 이모저모 (네이버)
•
하우스 키핑 데이 : 지정된 날에 코드에 대한 깊은 이야기를 나누며 딥 다이브 하는 날
◦
팀원들과 교류 활성화의 목적으로 만듬
◦
문서정리, 코드/브랜치 청소, 이슈처리 등 다양한 활동 진행
•
피크 스탑 : 2주간 비즈니스를 멈추고 큰 단위의 기술 부채를 해결
◦
리팩토링, 프레임워크 업그레이드
◦
전반적인 기술 부채 해결 및 서비스 안정화를 위함
•
비동기 커뮤니케이션
◦
WHY? 불필요한 메세지가 너무 많음
◦
우선순위에 따른 커뮤니케이션 분리를 위해 사용
◦
슬랙 : 긴급 장애 대응 혹은 업무와 관련된 전달 및 문의 사항 소통으로 활용
◦
OSS : 하루 4번 지정된 시기에 일괄 확인
▪
결과적으로 하루종일 메세지에 집중하지 않고, 본인의 업무에 몰입할 수 있음
•
포커스 타임
◦
매주 금요일 3시부터 7시까지 한 주를 랩업함
•
3:59 데이
◦
전사 복치 차원에서 한 달에 한번 3시간 59분 근무
◦
자율 출퇴근제도
•
버티컬 서비스 비즈 데이
◦
조직원 소개 : 친목 및 친밀감 도모 , 심리적 안정감
◦
개발 상황 공유 : 장애 이슈 혹은 기술 공유
◦
조직 얼라인 : 성과 측정 방식 공유 후 질의응답 통한 얼라인