(Case Study) JIRA를 사용하여 개발 프로젝트를 고객에게 직접 연결한 mgm 기술 파트너

mgm 기술 파트너 정보

mgm은 클라이언트 비즈니스의 성공에 기여하는 것을 자사의 성공 기준으로 정의한 중간 규모의 소프트웨어 솔루션 기업입니다. 1994년에 설립된 mgm은 뮌헨에 본사가 있으며 유럽 전역에 약 300명의 직원이 근무합니다.
Alexander Weiss는 회사가 Bugzilla에서 JIRA로 마이그레이션한 2005년부터 계속 근무했으며, 고객 사이트에서 JIRA를 사용한 후부터 내부적으로 JIRA 채택을 옹호해 왔습니다. mgm 기술 파트너는 JIRA, JIRA Agile, Confluence를 사용하고 최근에는 FishEye를 도입했습니다. JIRA를 버그 추적이 아닌 다른 프로젝트에서 사용하는 방법을 집중적으로 다룬 Alexander의 2부작 블로그 시리즈(I부II부)를 읽은 후 그와 연락해서 Atlassian 도구를 사용해본 mgm의 경험에 대해 들어보았습니다.

설정

mgm은 프로젝트의 여러 측면에서 고객과 긴밀하게 협력합니다. mgm 비즈니스의 독특한 측면 중 하나는 Atlassian 제품으로 고객이 프로젝트의 거의 모든 단계와 의사 결정 프로세스에 관여한다는 점입니다. 모든 사람이 JIRA에 로그인할 수 있습니다. JIRA는 토론을 위한 보다 직접적이고 중앙 집중적인 도구로 기능하고 기록 정보를 쉽게 찾게 해주기 때문에 프로젝트 커뮤니케이션 측면에서 이메일을 대체합니다. mgm은 현재 약 70개의 프로젝트를 단일한 JIRA 인스턴스(사이트)로 실행 중이며 약 800명의 JIRA 사용자가 적극적으로 사용하고 있습니다(직원과 고객 포함). 프로젝트는 소수의 인원만 필요한 2개월간의 작업부터 JIRA의 내부와 고객 포함 모두 몇십 명이 관여하는 수년간의 긴 작업까지 다양합니다.
프로젝트 리더는 프로젝트별 JIRA 대시보드를 설정하므로 고객은 다른 사람의 업데이트를 기다릴 필요 없이 자기 프로젝트에 대한 최신 정보를 볼 수 있습니다.

백로그의 점진적인 증가 방지

mgm 개발 팀은 JIRA Agile을 사용하여 프로젝트 작업을 설정하고 우선 순위를 정합니다. 개발 팀은 DevOps 팀에서 사용한 방식이 유용하다는 점을 알게 되었습니다. 프로젝트가 진전됨에 따라 우선 순위가 정해진 프로젝트 백로그를 고객에게 표시하여 기대치를 현실적으로 유지할 수 있습니다.
경험에 따르면 소프트웨어 개발과 향상 프로젝트, 특히 대규모 프로젝트에서 고객이 JIRA 프로세스로부터 배제되지 않는 경우 관련된 모든 사람에게 오버헤드가 덜 발생하고 혜택은 높아집니다. 더욱이 고객이 현재 진행 중인 모든 활동을 확인할 수 있고 프로젝트 상태를 직접 생성할 수 있으면 '자신'의 프로젝트에 대해 기존과는 완전히 다른 애착심을 가지게 됩니다. 우리는 고객이 프로세스 투명성의 성과를 전부 경험하면 만족감이 훨씬 높아지고, 자신에게 할당된 수명 주기에 대해 책임감이 높아진다는 것을 깨달았습니다. 또한 "단순한" 요청 하나를 추가한 행위가 어떤 결과를 가져오는지 깨닫게 되면 간섭이 될 수 있는 요소에 대해 더 민감해지고 '증가하는 요구 사항'을 자제하기 시작합니다. 물론 예외도 있긴 하지만요.

같은 정보 공유와 상황 파악

고객과 개발자는 상세 정보와 기대치에 대해 미리 평가해야 하고, 따라서 요구 사항은 명확하게 전달되고 검색 가능한 중앙 위치에 저장되어져야 합니다. mgm은 JIRA를 사용하면 요구 사항이 일관되고 관련성 있는 방식으로 명시되어 개발자가 작업을 시작할 때 필요한 모든 것을 알 수 있습니다.
요구 사항을 구두로 표현할 책임은 일반적으로 계속 우리에게 있습니다. 하지만 고객은 언제든지 상세 정보를 기여하는 데 참여할 수 있고 정교화 단계에서 활발하게 참여하며, 해당 티켓에 대한 의견을 통해 조언과 전문 지식을 제공할 수 있으며 그러는 것이 바람직합니다.
요구 사항 관리에서 또 하나 매우 중요한 점은 사용하는 용어입니다. 항상 고객의 분야에서 사용하는 말과 글을 사용하는 것이 매우 중요합니다. 고객이 이해할 수 있는 용어만 사용하세요! 우리는 모든 영역별 단어와 용어를 고객과 함께 공유하고 유지하는 것이 매우 유용하다는 것을 발견했습니다.

고객의 참여 유도

프로젝트가 진행되기 시작하면 고객은 요구 사항, 변경 요청, 버그에 대한 새로운 문제를 생성할 수 있지만, 이것에 그치지 않습니다. 고객이 버그 수정을 승인하거나 선택한 설명서 테스트를 실행하게 하면 고객의 깊이 있는 참여가 가능해지기 때문에 고객에게 자부심과 함께 프로젝트 참여 의식을 심어줄 수 있습니다. 이것이 수많은 mgm 프로젝트의 성공 비결입니다.
경험적으로 봤을 때 JIRA에 고객을 직접 참여시켜서 얻는 이점은 단점(예: JIRA 구성을 위해 할 작업이 늘어남)보다 큽니다. 충분한 정보를 받고 프로젝트에 직접 참여한 고객은 문제가 생기거나 프로젝트 진행에 어려움이 생겨도 많이 불안해하지 않습니다. 투명성은 마법의 키워드입니다.

마지막 생각

Alexander는 몇 해 동안 조직 전체에 걸친 프로젝트를 관리하기 위하여 JIRA를 사용함으로써 배운 교훈과 훌륭한 사례를 제시합니다. 소프트웨어를 판매하거나 인도하거나 내부 운영을 위해 제공하거나에 관계없이 다른 팀과 연결하고 최종 사용자를 높은 수준에서 프로젝트에 관여시키면 적절한 기대치를 설정하고 모두 같은 페이지를 보도록 만드는 데 도움이 됩니다. 사람들이 소프트웨어를 만듭니다. 더 나은 소프트웨어는 관련된 모든 사람들의 연결 관계가 튼튼할 때 탄생하는 것입니다.

댓글

이 블로그의 인기 게시물

Confluence 내의 스프레드 시트 기능이 필요하시다면 애드온을 활용해 보십시요

시스템에 숨어있는 "윤초" 버그에 대해 준비하십시요

Confluence 페이지의 분류와 관련된 잘 몰랐던 기능 3가지를 확인해 보십시요