GA(일반 공개) 준비하기
이 시점에서 함께 일하는 개발자들이 Backstage 배포에 관한 골든 패스를 읽었기를 바라요. Backstage 인스턴스는 전체 회사 출시와 함께 오는 규모에 대비되어 있어야 해요. 이 글에서는 성공적인 GA 출시를 위한 공지 방법과 출시 후 기대할 점, 지속적으로 개선하는 방법을 설명드릴게요.
출처: 문서
본문
이 시점에서 함께 일하는 개발자들이 Backstage 배포에 관한 골든 패스를 읽었기를 바라요. Backstage 인스턴스는 전체 회사 출시와 함께 오는 규모에 대비되어 있어야 해요.
출시 공지
소식을 널리 알리는 것은 성공적인 GA 출시의 가장 중요한 부분 중 하나예요. 좋은 공지는 두 가지 역할을 해요. 개발자에게 Backstage가 사용 가능하다는 것을 알려주고, 왜 신경 써야 하는지 알려주는 거예요.
내부 커뮤니케이션 채널 활용하기
개발자들이 이미 사용하는 채널에서 시작해요. 엔지니어링 전반에 닿는 Slack이나 Teams 채널에 게시하고, 회사 뉴스레터나 엔지니어링 블로그에 짧은 글을 공유하며, 메시지를 하위 직원에게 전달할 수 있는 팀 리더에게 타깃 이메일을 보내요. 각 채널에 맞게 메시지를 다듬어요. Slack 공지가 작성된 글이나 블로그 글보다 짧고 대화체일 수 있어요.
개발자를 위해 Backstage가 해결하는 문제로 시작하고, 기능 목록으로 시작하지 마세요. 개발자들은 "다섯 가지 다른 도구에서 소유권 정보를 쫓아다닐 필요가 없어졌습니다"라는 말이 "소프트웨어 카탈로그를 출시했습니다"보다 훨씬 잘 먹혀요.
내부 밋업이나 데모 개최하기
라이브 데모는 작성된 공지가 할 수 없는 방식으로 신뢰를 쌓아요. 개발자들은 제품이 실제로 동작하는 모습을 보고, 질문을 하고, Backstage가 일상 업무에 어떻게 맞는지에 대한 구체적인 인상을 가지고 떠날 수 있어요.
데모는 짧고 집중적으로 유지해요. 가치가 높은 워크플로 한두 가지를 보여주되, 이상적으로는 이해관계자 피드백 세션에서 식별한 고통 지점을 다루는 것이 좋아요. 질문할 시간을 남겨두세요. 세션이 녹화되었다면 커뮤니케이션 채널에 녹화물을 공유해서 참석하지 못한 개발자들이 따라잡을 수 있게 해요.
서로 다른 시간대나 팀에 닿기 위해 여러 세션을 운영하는 것을 고려해 보세요. 특정 팀을 위한 더 작고 타겟팅된 데모가 단일 대규모 올핸즈(all-hands)보다 더 효과적일 수 있어요.
개념 증명(PoC)에 참여한 팀의 개발자를 초대해서 공동 발표하게 해보세요. 동료의 지지는 플랫폼 팀이 자기 제품을 이야기하는 것보다 더 큰 무게가 실려요.
앞으로 몇 달간 기대할 점
GA 직후의 기간은 종종 예상보다 더딜 수 있어요. 이것은 정상이에요. 개발자들은 바쁘고, 습관을 바꾸기는 어려우며, 채택은 모멘텀을 쌓는 데 시간이 걸려요. 이른 시기의 목표는 채택을 강제하는 것이 아니라 그것을 막는 마찰을 제거하는 거예요.
피드백을 일찍, 자주 듣기
첫날부터 명확한 피드백 채널을 만들어요. 전용 Slack 채널, 양식, 또는 정기 오피스 아워 세션이 될 수 있어요. 출시 공지에서 보이도록 해서 개발자들이 어디로 가야 하는지 알게 해요. 처음 몇 주간 받는 피드백은 앞으로 받을 것 중 가장 가치 있는 것들 중 하나예요. 실제 첫 사용자 경험을 반영하기 때문이에요.
개발자들이 어려워하는 것에 주목하세요. 기능 요청뿐만 아니라요. 어려움은 문서화의 공백, 혼란스러운 워크플로, 또는 채택을 막는 누락된 통합을 가리켜요.
의사 결정을 안내하는 데 분석 사용하기
Backstage는 기본적으로 사용 분석을 함께 제공하지 않지만, 플러그인 생태계를 통해 분석 프로바이더를 통합할 수 있어요. 이에 대한 자세한 내용은 Backstage 문서의 Analytics 섹션에서 확인할 수 있어요. 개발자들이 Backstage의 어떤 부분을 실제로 사용하는지 추적하면 시간을 어디에 투자할지 정보에 기반해 결정하는 데 도움이 돼요.
패턴을 찾아보세요: 개발자들이 카탈로그에 도달하지만 엔티티 페이지로 파고들지 않나요? 검색 기능이 저조하게 사용되나요? 소프트웨어 템플릿이 트리거되지만 완료되지 않나요? 이런 신호들은 경험이 어디서 무너지고 어디서 잘 작동하는지 알려줘요.
사용자와 직접 이야기하기
분석은 무슨 일이 일어나고 있는지 알려주고, 대화는 왜 그런지 알려줘요. 서로 다른 팀의 개발자들, 특히 초기 채택자였던 사람들과 정기적인 체크인을 잡아요. 무엇을 사용하는지, 무엇을 피하는지, 무엇이 일상 업무에서 Backstage를 더 유용하게 만들지 물어보세요.
짧고 비공식적인 대화가 공식 설문조사보다 더 많이 드러내는 경우가 많아요. Backstage를 거의 열지 않는 개발자와의 5분 대화가 한 달치 대시보드보다 더 실행 가능한 통찰을 줄 수 있어요.
계속 반복하는 방법
GA는 결승선이 아니에요. 가장 성공적인 Backstage 인스턴스는 피드백을 받아 변화로 바꾸는 명확한 과정에 힘입어 출시 후에도 계속 개선하는 것들이에요.
피드백에 기반한 결정 내리기
만드는 것이 흥미로워 보이는 작업보다 실제 개발자 고통 지점을 해결하는 작업에 우선순위를 두세요. 같은 문제에 대한 반복적인 피드백을 받으면 강력한 신호로 취급하세요. 피드백이 혼합되거나 불분명하면 사용자에게 돌아가 방향을 정하기 전에 더 깊이 파고들어요.
내린 결정과 그 근거를 문서화해요. 이것은 팀이 정렬을 유지하는 데 도움이 되고, 과거 선택을 다시 검토할 때 참조할 기록을 남겨줘요.
개선할 수 있는 프로세스를 찾기
Backstage가 조직에서 성숙해짐에 따라 개발자들이 그것과 상호작용하는 방식의 패턴을 알아차리기 시작할 거예요. 그런 패턴 중 일부는 Backstage가 자동화할 수 있는 수동 단계나, Backstage 밖에 존재하지만 끌어들이면 이로울 워크플로를 드러낼 거예요.
카탈로그를 정기적으로 검토해요. 엔티티가 오래되나요? 소유권 정보가 낡아가나요? 이것들은 제품 자체가 아니라 Backstage 주변의 프로세스가 주의를 필요로 한다는 신호예요. 팀과 함께 데이터를 정확히 유지하는 습관과 자동화를 만들어요.
이해관계자에게 정보 제공하기
여러분의 리더십과 핵심 이해관계자는 이 투자를 지지했어요. Backstage의 영향력을 그들이 신경 쓰는 결과(개발자 생산성, 작업량 감소, 더 빠른 온보딩, 개선된 시스템 안정성)와 연결하는 정기 진행 보고서로 그들에게 정보를 유지하세요.
성과를 공유하되, 무엇이 작동하지 않는지와 그것에 대해 무엇을 계획하고 있는지도 투명하게 알려주세요. 여러분의 판단을 신뢰하는 이해관계자는 시간이 지나도 플랫폼에 계속 투자할 가능성이 더 높아요.