리더십의 동의 얻기
개발자 포털 도입 제안을 하려면 리더십이 승인하도록 설득해야 해요. 이 섹션에서는 리더십이 어떤 이야기를 들으면 동의하게 되는지 살펴볼게요. 여러분이 Backstage로 회사에서 해결하고 싶은 문제를 이미 잘 알고 있다고 가정할게요. 아니라면 작게 시작하는 걸 권해요.
출처: 문서
본문
요약
이 섹션에서는 개발자 포털에 대한 제안에 리더십이 동의하도록 하기 위해 리더십이 듣고 싶어 하는 이야기를 살펴볼게요. 회사에서 Backstage가 해결해야 할 문제를 이미 잘 파악하고 있다고 가정할게요. 아직 아니라면 작게 시작하는 걸 추천해요. 함께 일하는 개발자들이 꾸준히 불편해하는 무언가를 찾아보세요(여러분 자신도 포함해서요). 사용자 인터뷰는 무엇을 개선해야 하는지 더 잘 이해하는 좋은 방법이에요. GitHub 저장소나 데이터베이스를 새로 만들 때 IT 부서가 막는 경우일 수도 있고, 조직 전체가 매주 5시간을 써야 하는 수작업일 수도 있어요. 새 서비스가 프로덕션에 나가기까지의 시간이 오래 걸리거나 테스트 환경 프로비저닝이 느린 경우일 수도 있죠. 회사마다 다를 거예요. 우리가 줄 수 있는 '만능 해답'은 없어요. 있다 해도 그것은 여러분의 리더십 팀에 딱 맞춰진 답이 아닐 거예요.
마일스톤
모든 Backstage 도입 여정에는 잘 알려진 마일스톤이 있어요.
- PoC를 구성한다.
- 사용자를 확보한다.
- 사용자 일부가 포털의 가치를 정말로 체감하고 뛰어든다. 직접 플러그인을 만들기도 하죠. 훌륭해요!
- 카탈로그 채택률이나 일일 활성 사용자가 정체되기 시작한다.
- 리더십이 지속적인 가치에 대해 궁금해지기 시작한다.
- 갈림길에 도달한다. 팀이 직접 무언가를 만들거나 다른 기성품을 선택하는 쪽을 고민하거나, 자리에 앉아 정체에서 벗어날 작업을 한다.
- 여기까지 왔다면 아마 카탈로그 항목에 대한 차단 검사(blocking check)가 생겼고, Backstage는 개발자들이 주간, 많게는 일일로 사용하는 포털이 됐을 거예요. 축하해요!
4번과 5번은 고통스러운 순간이에요. 성공적인 Backstage 도입도 순식간에 기세를 잃을 수 있어요. 이런 것들이 다 그런 법이죠. 흥분은 결국 식고 사람들은 자기 본업으로 돌아가요. 어떤 문제를 해결하고 있든, 또 하나의 YAML 파일이나 카탈로그 도구는 그저 부담(overhead)이고 추가 수고(toil)일 뿐이에요. Backstage의 가치에 대해 리더십과 같은 페이지에 서는 것이 매우 성공적인 도입 스토리의 첫걸음이에요.
권장 사항
- 리더십에게 실질적인 무엇인가를 가져가세요. 진짜 개념 증명(PoC)이거나 데모 사이트일 수 있어요.
- 올리거나 내리고 싶은 지표를 정의하세요. 새 엔지니어의 온보딩 시간, 새 서비스의 프로덕션 도달 시간, 인시던트 대응 시간 등이 될 수 있어요. 앞서 말했듯 이것이 바로 회사에 고유하면서 해결하면 진짜로 결정적인 차이를 만드는 '살찐 문제'예요.
- 채택의 장벽을 낮추세요. 많은 사람이 또 하나의 YAML 파일을 부담으로 봐요. 기존의 카탈로그 솔루션이 있다면 그것을 활용해 온보딩 과정을 단순화하세요. 없다면 그 작업을 진행할 좋은 기회일 수 있어요.
- 지식 사일로(knowledge silo)를 무너뜨리세요. 모든 팀은 일을 하는 방식에 선호가 있어요. 팀이 원하는 방식대로 계속 일할 수 있게 하면서 그 데이터를 단일 인터페이스로 중앙화하는 것은 강력한 목표이고, Backstage가 실현할 수 있는 일이에요.