비즈니스와 DevOps를 연결하는 멋진 방법을 찾은 방법

개발이 소프트웨어 유지 관리와 결합되면 DevOps 철학은 누구도 놀라지 않을 것입니다. DevOps 2.0 또는 BizDevOps라는 새로운 추세가 탄력을 받고 있습니다. 비즈니스, 개발 및 지원이라는 세 가지 구성 요소를 하나의 전체로 결합합니다. DevOps에서와 마찬가지로 엔지니어링 방식은 개발과 지원 간의 연결 기반을 형성하며, 비즈니스 개발에서 분석은 개발과 비즈니스를 통합하는 "접착제" 역할을 합니다.

저는 바로 인정하고 싶습니다. 우리는 똑똑한 책을 읽은 후에야 진정한 비즈니스 개발이 가능하다는 사실을 알게 되었습니다. 직원들의 주도성과 개선을 향한 억누를 수 없는 열정 덕분에 이 모든 것이 하나로 합쳐졌습니다. 분석은 이제 개발 생산 프로세스의 일부로서 피드백 루프를 크게 줄이고 정기적으로 통찰력을 제공합니다. 모든 것이 우리에게 어떻게 작동하는지 자세히 알려 드리겠습니다.

클래식 DevOps의 단점

새로운 고객 제품이 구상되면 기업은 이상적인 고객 행동 모델을 만들고 좋은 전환을 기대하며 이를 기반으로 비즈니스 목표와 결과를 구축합니다. 개발팀은 매우 좋은 고품질 코드를 만들기 위해 노력하고 있습니다. 지원은 프로세스의 완전한 자동화, 신제품 유지 관리의 용이성과 편의성을 희망합니다.

현실은 클라이언트가 다소 복잡한 프로세스를 받고, 비즈니스가 낮은 전환율로 정체되고, 개발 팀이 수정 후 수정 사항을 릴리스하고, 클라이언트의 요청 흐름에 지원이 빠져버리는 방식으로 발전하는 경우가 가장 많습니다. 익숙한 것 같나요?

여기서 문제의 근원은 프로세스에 내장된 길고 빈약한 피드백 루프에 있습니다. 기업과 개발자는 스프린트 중에 요구 사항을 수집하고 피드백을 받을 때 제품의 운명에 큰 영향을 미치는 제한된 수의 고객과 소통합니다. 종종 한 사람에게 중요한 것이 전체 대상 청중에게는 전혀 일반적이지 않습니다.
제품이 올바른 방향으로 움직이고 있는지 여부는 출시 후 몇 달 후에 재무 보고서와 시장 조사 결과를 통해 알 수 있습니다. 그리고 제한된 표본 크기로 인해 다수의 클라이언트에 대한 가설을 테스트할 기회를 제공하지 않습니다. 일반적으로 이는 길고 부정확하며 효과적이지 않은 것으로 나타났습니다.

트로피 도구

우리는 이 상황에서 벗어날 수 있는 좋은 방법을 찾았습니다. 이전에는 마케팅 담당자에게만 도움이 되었던 도구가 이제 기업과 개발자의 손에 들어가게 되었습니다. 우리는 지금 여기에서 프로세스를 실시간으로 살펴보고 무슨 일이 일어나고 있는지 이해하기 위해 웹 분석을 적극적으로 사용하기 시작했습니다. 이를 바탕으로 제품 자체를 기획하고 다수의 클라이언트에게 출시합니다.
일종의 제품 개선을 계획하고 있다면 어떤 측정항목과 관련되어 있는지, 이러한 측정항목이 비즈니스에 중요한 판매 및 특성에 어떤 영향을 미치는지 즉시 확인할 수 있습니다. 이렇게 하면 효과가 낮은 가설을 즉시 제거할 수 있습니다. 또는 예를 들어 통계적으로 상당한 수의 사용자에게 새로운 기능을 출시하고 지표를 실시간으로 모니터링하여 모든 것이 의도한 대로 작동하는지 이해할 수 있습니다. 요청이나 보고 형태의 피드백을 기다리지 말고 제품 제작 과정을 직접 모니터링하고 신속하게 조정하세요. 우리는 새로운 기능을 출시하고, 통계적으로 정확한 데이터를 XNUMX일 안에 수집하고, 또 XNUMX일 안에 변경 사항을 적용할 수 있으며, 일주일 안에 훌륭한 새 제품이 준비됩니다.

전체 퍼널, 신제품을 접한 모든 고객을 추적하고 퍼널이 급격히 좁아진 지점을 감지하고 그 이유를 이해할 수 있습니다. 이제 개발자와 기업 모두 일상 업무의 일부로 이를 모니터링합니다. 그들은 동일한 고객 여정을 보고 함께 개선을 위한 아이디어와 가설을 생성할 수 있습니다.

분석과 함께 비즈니스와 개발을 통합하면 지속적으로 제품을 만들고, 지속적으로 최적화하고, 병목 현상을 검색하고 확인하는 것은 물론 전체 프로세스를 전체적으로 볼 수 있습니다.

모든 것은 복잡성에 관한 것입니다

새로운 제품을 만들 때 처음부터 시작하는 것이 아니라 기존 서비스 웹에 통합합니다. 신제품을 시험해 볼 때 고객은 여러 부서에 연락하는 경우가 가장 많습니다. 그는 연락 센터 직원, 사무실 관리자와 소통하거나 지원팀에 문의하거나 온라인 채팅을 통해 소통할 수 있습니다. 예를 들어 메트릭을 사용하면 연락 센터의 로드가 얼마나 되는지, 들어오는 요청을 가장 잘 처리하는 방법 등을 확인할 수 있습니다. 우리는 사무실에 얼마나 많은 사람이 방문하는지 파악하고 고객에게 추가 조언을 제공하는 방법을 제안할 수 있습니다.

정보시스템도 마찬가지다. 우리 은행은 20년 넘게 존재해 왔으며 그 동안 대규모의 이기종 시스템이 생성되어 여전히 작동하고 있습니다. 백엔드 시스템 간의 상호 작용은 때때로 예측할 수 없을 수 있습니다. 예를 들어, 일부 고대 시스템에서는 특정 필드의 문자 수에 제한이 있으며 이로 인해 새 서비스가 중단되는 경우가 있습니다. 표준 방법을 사용하여 버그를 추적하는 것은 상당히 어렵지만 웹 분석을 사용하면 쉽습니다.

우리는 관련된 모든 시스템에서 클라이언트에게 표시되는 오류 텍스트를 수집하고 분석하기 시작한 지점에 도달했습니다. 그들 중 다수는 구식이라는 것이 밝혀졌고 그들이 우리 프로세스에 어떻게 든 관여하고 있다고 상상조차 할 수 없었습니다.

분석 작업

웹 분석가와 SCRUM 개발 팀이 같은 방에 있습니다. 그들은 끊임없이 서로 상호 작용합니다. 필요한 경우 전문가가 측정항목을 설정하거나 데이터를 다운로드하는 데 도움을 주지만 대부분 팀 구성원이 직접 분석 서비스를 사용하므로 복잡한 것은 없습니다.

예를 들어 제한된 유형의 클라이언트 또는 소스에 대해 일부 종속성 또는 추가 필터가 필요한 경우 도움이 필요합니다. 그러나 현재 아키텍처에서는 이런 일이 거의 발생하지 않습니다.

흥미롭게도 분석을 구현하기 위해 새로운 IT 시스템을 설치할 필요가 없었습니다. 우리는 마케팅 담당자가 이전에 사용했던 것과 동일한 소프트웨어를 사용합니다. 사용에 동의하고 비즈니스 및 개발에 구현하기만 하면 되었습니다. 물론 우리는 마케팅이 가지고 있는 것을 그대로 받아들일 수는 없었고 모든 것을 새롭게 재구성하고 마케팅이 우리와 동일한 정보 분야에 있을 수 있도록 새로운 환경에 대한 액세스 권한을 부여해야 했습니다.

앞으로 우리는 점점 늘어나는 처리 세션량에 대처할 수 있는 개선된 버전의 웹 분석 소프트웨어를 구입할 계획입니다.

우리는 또한 CRM 및 회계 시스템의 웹 분석과 내부 데이터베이스를 통합하는 과정에도 적극적으로 참여하고 있습니다. 데이터를 결합함으로써 우리는 소스, 클라이언트 유형, 제품 등 필요한 모든 측면에서 클라이언트에 대한 완전한 그림을 얻습니다. 데이터 시각화를 돕는 BI 서비스는 곧 모든 부서에서 제공될 예정입니다.

우리는 결국 무엇을 얻었습니까? 실제로 우리는 이에 대한 분석과 의사결정을 생산 과정의 일부로 삼았는데, 이는 가시적인 효과를 가져왔습니다.

분석: 갈퀴를 밟지 마세요

그리고 마지막으로 사업 개발 사업을 구축하는 과정에서 문제를 피하는 데 도움이 되는 몇 가지 팁을 공유하고 싶습니다.

1. 분석을 신속하게 수행할 수 없다면 잘못된 분석을 수행하고 있는 것입니다. 한 제품에서 간단한 경로를 따른 다음 확장해야 합니다.
2. 미래의 분석 아키텍처를 잘 이해하고 있는 팀이나 사람이 있어야 합니다. 분석을 확장하고 이를 다른 시스템에 통합하고 데이터를 재사용하는 방법을 현장에서 결정해야 합니다.
3. 불필요한 데이터를 생성하지 마세요. 웹 통계는 유용한 정보일 뿐만 아니라 품질이 낮고 불필요한 데이터가 가득한 거대한 쓰레기장이기도 합니다. 그리고 이러한 쓰레기는 명확한 목표가 없으면 의사결정과 평가를 방해하게 됩니다.
4. 분석을 위한 분석을 수행하지 마십시오. 첫째, 목표, 도구 선택, 그리고 효과가 있는 경우에만 분석합니다.

해당 자료는 체보타르 올가(Chebotar Olga)와 공동으로 준비했습니다.olga_cebotari).

출처 : habr.com