리더십 승인 받기
이 섹션에서는 개발자 포털을 위한 피치에 리더십이 승인하도록 하기 위해 무엇을 들려줘야 하는지 살펴볼게요. Backstage가 회사에서 풀어주길 원하는 문제에 대한 좋은 아이디어가 있다고 가정할게요. 그렇지 않다면 작게 시작하는 것을 권장해요. 함께 일하는 개발자들(여러분 자신도 포함)을 지속적으로 좌절시키는 무언가를 찾아보세요. 사용자 인터뷰는 무엇이 개선되어야 하는지 더 잘 이해하는 훌륭한 방법이에요.
출처: 문서
본문
요약
이 섹션에서는 개발자 포털을 위한 피치에 리더십이 승인하도록 하기 위해 무엇을 들려줘야 하는지 살펴볼게요. Backstage가 회사에서 풀어주길 원하는 문제에 대한 좋은 아이디어가 있다고 가정할게요. 그렇지 않다면 작게 시작하는 것을 권장해요. 함께 일하는 개발자들(여러분 자신도 포함)을 지속적으로 좌절시키는 무언가를 찾아보세요. 사용자 인터뷰는 무엇이 개선되어야 하는지 더 잘 이해하는 훌륭한 방법이에요. 새 GitHub 저장소나 데이터베이스 생성을 차단하는 IT일 수도 있어요. 조직 전체가 해야 하는 주당 5시간의 수동 작업일 수도 있어요. 새 서비스의 프로덕션 도달 시간이 느리거나 테스트 환경 프로비저닝이 느릴 수도 있어요. 모든 회사가 다르기 때문에 우리가 줄 수 있는 정답은 없어요. 정답을 줄 수 있다 하더라도, 그것은 여러분의 리더십 팀에 잘 맞춰진 것이 아닐 거예요.
이정표
모든 Backstage 채택 여정에는 잘 알려진 이정표가 있어요.
-
PoC를 설정해요.
-
사용자를 확보해요.
-
한 무리의 사용자들이 포털의 가치를 실제로 깨닫고 뛰어들어요. 심지어 자체 플러그인을 만들 수도 있어요. 훌륭해요!
-
카탈로그 채택이나 일일 활성 사용자 수가 정체되기 시작해요.
-
리더십이 지속적인 가치에 대해 캐물어 보기 시작해요.
-
갈림길에 도달해요. 팀이 직접 무언가를 만들거나 다른 기성품 옵션을 선택하는 것을 고려하거나, 앉아서 정체에서 벗어나기 위한 작업을 해요.
-
조직이 여기까지 왔다면, 이제 카탈로그 항목에 대한 차단 검사가 있을 가능성이 높고, Backstage는 개발자들에게 주간이 아니라면 일일 포털이 되었을 거예요. 축하합니다!
4번과 5번 단계는 고통스러운 순간이에요. 성공적인 Backstage 채택이라도 순식간에 기세를 잃을 수 있어요. 그것이 이런 것들의 본질이에요. 흥분은 결국 사라지고 사람들은 일상 업무로 돌아가게 돼요. 또 다른 YAML 파일이나 카탈로그 도구는, 풀고 있는 문제와 무관하게 그저 오버헤드이자 추가 작업량이에요. Backstage의 가치에 대해 리더십과 같은 입장이 되는 것은 아주 성공적인 채택 스토리의 첫걸음이에요.
권장 사항
-
리더십 팀에게 진짜 무언가를 가져가요. 진정한 개념 증명이거나 데모 사이트일 수 있어요.
-
올리거나 내리려는 항목 주위로 메트릭을 정의해요. 새 엔지니어 온보딩 시간, 새 서비스의 프로덕션 도달 시간, 인시던트 완화 시간 등이 될 수 있어요. 위에서 말했듯이, 이것이 해결하면 정말로 수치를 움직일 수 있는 회사 고유의 핵심 문제예요.
-
채택 장벽을 낮춰요. 많은 사람들이 또 다른 YAML 파일을 오버헤드로 봐요. 기존 카탈로그 솔루션이 있다면 그것을 사용해서 온보딩 과정을 단순화해요. 없다면 그 작업을 할 좋은 기회일 수 있어요.
-
지식 사일로. 모든 팀은 일하는 방식에 선호가 있어요. 팀이 원하는 방식대로 계속 일하게 두면서 그 데이터를 단일 인터페이스로 중앙화하는 것은 강력한 목표이고, Backstage가 실현할 수 있는 일이에요.