Low-Code로 디지털 고객 온보딩 프로세스를 구축하는 방법 | Mendix

메인 컨텐츠로 가기

Low-Code로 디지털 고객 온보딩 프로세스를 구축하는 방법

오늘날의 직장에서는 개발자들이 끊임없이 앱을 쏟아내는 행렬이 있는 듯합니다. 거의 매일 우리가 아는 직장 생활을 혁신할 새로운 앱이 개발 중이라는 소식을 듣게 되죠, 맞죠? 맞죠…

모바일 및 웹 애플리케이션에 대한 모든 화려함 속에서 당신은 다음 사실을 알게 되어 놀랄 수도 있습니다. 2020년에는 모든 소프트웨어 프로젝트의 66-70%가 실패했습니다..

일부에게는 혼란스러울 수 있지만, 저는 전문적인 로우코드 개발자로서, 때로는 수십억 달러 규모의 회사가 지원하는 프로젝트가 종종 실패한다는 사실에 개인적으로 공감할 수 있습니다. 출시되지 않거나, 지연에 시달리거나, 출시되더라도(최악의 경우) 사용자에게 필요한 것이 아닙니다. 실패의 원인은 개발 방법에 있습니다.

우리는 왜 실패하는가?

오늘날의 웹에서 우리는 우리보다 먼저 온 사람들의 어깨 위에 서서 그들이 이룬 것을 바탕으로 일을 진행합니다.

실패는 그것을 인식하지 못하는 데서 비롯됩니다.

회사의 IT 부서에 들어가게 된다면 DevOps 층으로 가보세요. 인력이 부족한 개발자 팀이 헤드폰을 끼고 화면을 응시하다 눈이 충혈된 채로 여러분을 맞이할 것입니다. 그들은 너무 집중해서 질문을 받아도 대답하지 않을 가능성이 큽니다.

왜 그들은 그렇게 열정적이고 눈이 침침할까? 저는 전통적인 개발자들이 처음부터 앱을 빌드하고 스스로 하는 데 자부심을 느끼는 것을 경험했습니다. 스스로 하고 처음부터 빌드하는 것을 선호하는 것은 충분한 시간과 리소스가 있다면 놀라울 수 있지만, 자금이 제한된 소규모 프로젝트의 경우 종종 프로젝트의 몰락이 됩니다. 로우코드와 같은 도구가 등장하면 전통적인 개발자들은 코를 찡그리는 경향이 있습니다. 도전은 어디에 있습니까!

처음부터 만든 앱은 영원히 걸리는 것 같습니다. 다른 사람의 작업에 의존할 수 없으면 간단한 빌드가 불필요하게 복잡해질 수 있습니다. 아이러니한 점은 오늘날 Node.js나 Java에서 미리 빌드된 라이브러리에 의존하지 않는 실제 애플리케이션이 없다는 것입니다.

로우코드 플랫폼을 사용하면 Mendix, 이를 통해 마켓플레이스에서 소싱할 수 있습니다. Mendix- 그리고 커뮤니티에서 구축한 모듈은 사전 구축된 Node.js 라이브러리와 동일한 개념입니다. 빌드에서 불필요한 복잡성을 제거하고 최종 결과를 전달하기만 하면 됩니다.

때로는 활용할 수 있는 것이 이미 존재하지 않습니다. 그때는 광범위하고 복잡한 코딩을 해야 하며, 그런 경우 회사의 나머지 사람들이 이를 재사용할 수 있기를 원합니다. 이 시나리오에서 대부분의 회사는 재사용 가능한 구성 요소를 만드는 데 여전히 시간을 투자할 것이고, Mendix 이 과정을 한층 더 간소화하려고 노력했으며, 모든 사용자 정의 확장 프로그램을 호스팅할 수 있는 내부 회사 마켓플레이스를 만들고, 회사는 지적 재산이 보호된다는 사실을 알고 안전하게 회사 웹사이트와 앱 간에 기능을 만들고 공유합니다.

전통적 코드 대 로우코드: 실제 사례

차이점을 설명하기 위해 디지털 고객 온보딩 프로세스를 만드는 아이디어를 살펴보겠습니다.

한 회사에서 고객 온보딩에 사용할 앱 개발을 개발팀에 요청했습니다.

앱에는 다음과 같은 기능이 있어야 합니다.

  • Dropbox와 통합하여 고객 데이터와 문서를 저장합니다.
  • 고객 주소에 대한 주소 조회
  • 중요한 문서를 스캔하고 그로부터 정보를 추출하는 기능
  • 문서에 디지털 서명하고 검토할 수 있는 능력.

이를 참고로 회사의 비즈니스 분석가는 DevOps 팀이 실행할 수 있는 4개의 사용자 스토리를 작성합니다.

1) 사용자로서 고객의 문서를 클라우드에 저장할 수 있도록 Dropbox와 통합하고 싶습니다.

2) 사용자로서 고객의 주소를 쉽게 찾을 수 있도록 자동 주소 조회 기능을 갖고 싶습니다.

3) 사용자 입장에서는 기기의 카메라를 사용해 중요한 문서를 스캔할 수 있는 기능이 있었으면 좋겠습니다.

4) 사용자로서 문서를 디지털로 검토하고 서명할 수 있는 기능이 필요합니다.

해당 부서에는 두 팀이 있으며, 진행 중인 새로운 프로젝트가 없기 때문에, 회사에서는 두 팀 모두 앱을 만들고 내부 해커톤에서 경쟁하도록 결정했습니다.

팀 1은 주로 로우코드를 사용하는 팀입니다. Mendix 앱을 빌드하고 호스팅합니다. 팀은 매우 숙련된 개발자 한 명, 여가 시간에 코딩을 배우는 재무 부서의 회계사, 웹사이트와 앱 스타일링에 재능이 있는 마케팅 부서의 디자이너로 구성되어 있습니다.

팀 2는 Java 개발자, C# 개발자, Node.js 개발자 등 세 명의 전통적인 개발자로 구성되어 있습니다. 두 시나리오 모두에서 팀은 QA 및 비즈니스 분석가와 같은 더 큰 전통적인 스크럼 이해 관계자에게도 접근할 수 있습니다.

1주 후 두 팀은 이해 관계자에게 앱을 발표하고, 각자가 앱이 챌린지에 제시된 사용자 스토리를 어떻게 충족하는지 차례로 보여줍니다. 그리고 명확한 승자는 팀 XNUMX입니다.

제출물을 살펴보면서 심사위원들은 각 사용자 스토리에 대해 평가했습니다. 그들이 본 것을 풀어보죠.

1) 사용자로서 고객의 문서를 클라우드에 저장할 수 있도록 Dropbox와 통합하고 싶습니다.

팀 1은 즉시 사전 빌드된 모듈이 사용 가능하다는 것을 인식했습니다. Mendix  Marketplace. 이를 기반으로 작업을 진행한 그들은 곧 이를 설정하고 사용자 인터페이스와 코드 문서화에 시간을 집중했으며, 이를 비디오에서 수행했습니다.

2팀은 대부분의 시간을 Dropbox의 문서 페이지를 이해하는 데 보냈고, 작동하는 통합 기능을 만들어냈지만 사용자 인터페이스가 거칠고 불편했습니다.

2) 사용자로서 고객의 주소를 쉽게 찾을 수 있도록 자동 주소 조회 기능을 갖고 싶습니다.

팀 1은 다시 한번 다운로드할 수 있는 모듈을 확보하여 기능을 완성하고 문서화하는 데 집중하여 빠르게 연결할 수 있었습니다.

팀 2는 어떤 주소 검색 서비스를 사용해야 할지 결정하는 데 어려움을 겪었습니다. 그들은 모두 어느 것이 가장 좋을지 선호했고 결정하는 데 시간을 낭비했습니다. 결국 그들은 Google을 사용하여 작동하도록 만들었지만 다시 한 번 팀 1에게는 상대가 되지 못했습니다.

3) 사용자로서 기기의 카메라를 사용하여 중요한 문서를 스캔할 수 있는 기능이 필요합니다.

이 시점에서 팀 2는 자신들이 뒤처졌다는 것을 알고 있었고, 도움을 받기 위해 해당 분야의 전문가를 찾았습니다. 소프트웨어 프로젝트 관리 분야에서 일한 적이 있다면 여기서 문제를 느낄 수 있을 것입니다. 소프트웨어 개발에서 유명한 법률은 브룩스 법칙으로, "늦은 소프트웨어 프로젝트에 인력을 추가하면 프로젝트가 더 늦어진다"고 명시되어 있습니다. OCR 기능을 빌드하기 위해 새로운 팀원을 데려오면 새로운 멤버는 프로젝트를 따라잡을 시간이 필요하고, 그러면 현재 코드베이스를 이해할 시간도 필요합니다. 항상 그렇듯이 이는 사실로 판명되었고 프로젝트는 더욱 뒤처졌습니다.

팀 1은 개발 속도를 유지할 수 있었습니다. 그들은—맞춰보셨죠—그들에게 사용 가능한 모듈을 사용했습니다. Mendix그리고 이미지 인식에 대한 경험이 없는 로코더들은 가장 기술적인 멤버에게 의지하여 작업을 신속하게 처리했습니다.

4) 사용자로서 문서를 디지털로 검토하고 서명할 수 있는 기능을 원합니다.

두 팀 모두 이 사용자 스토리에 대해 비슷한 결과를 냈지만, 로우코드 팀은 비밀 무기(현재 시스템에서 따르는 올바른 프로세스를 아는 회계사)를 활용할 수 있었기 때문에 복잡한 사용자 흐름에서 실수를 피할 수 있었습니다. 그들은 시간이 많이 남았기 때문에 이에 대한 비디오도 만들 수 있었습니다. 팀 B는 그렇지 않았습니다.

Mendix 팀 A에게 기존 스프레드시트를 업로드하여 앱 도메인 모델을 자동으로 모델링하는 옵션을 제공했으며, 이는 앱 도메인 모델에서 자동으로 읽히고 다시 생성됩니다. 마지막으로 팀 A는 Mendix모든 필수 데이터에 대한 일반적인 개요를 생성할 수 있는 능력이 있었고, 이를 통해 앱의 모든 중요한 통합에 집중할 수 있었습니다.

의사 결정 시간

심사위원들은 쉽게 팀 1을 우승자로 선정했습니다. 하지만 왜 그럴까요?

근본적으로 두 팀은 모두 동일한 요구 사항을 모두 충족했습니다. 이는 동일한 기술이며 동일한 공급자가 처리하지만 팀 1은 절반의 시간에 완료하고 나머지는 제품을 반복하고 개선하는 데 사용했습니다. 그들이 만들 수 있었던 것은 다음과 같습니다.

또한 팀은 사용한 모듈의 향후 변경 사항에 대한 모든 재작업을 완화했습니다. 예를 들어, DocuSign 라이브러리에 변경 사항이 필요한 경우 모듈의 Marketplace 작성자가 처리하고, 애자일 팀은 모듈을 업데이트한 후 중단 변경 사항이 있는 경우에만 코드를 리팩토링해야 하며, 이는 커넥터 작성자가 처리해야 했습니다.

다른 사람의 작업에 의존하는 것은 괜찮습니다. 그것은 진보입니다. 이러한 모듈과 코드 라이브러리를 구축한 사람과 조직은 여러분이 이를 사용하기를 원합니다. 그들은 여러분이 겪은 골치 아픈 일을 덜어주고, 여러분이 더 큰 문제를 해결하는 데 집중할 수 있도록 하기를 원합니다. 장점은 이를 사용하여 고객 경험을 개선하고 디지털 고객 온보딩 프로세스를 구축할 수 있다는 것입니다. 또는 이를 활용하여 이전에는 불가능했던 속도로 수많은 시스템과 앱을 혁신하고 현대화할 수 있습니다.

언어를 선택하세요