brunch

You can make anything
by writing

C.S.Lewis

by 안영회 습작 Aug 02. 2021

복잡한 업무규칙 논의를 촉진하는 상태도

실전 시스템 수준 리팩토링 사례 8회

지난 글에 드러난 기부상태에 대한 다른 인식에 대해 팀 모두가 공감한 상태로 함께 모여 쟁점을 논하는 자리가 마련되었습니다. 상태도는 각자 다른 해석을 하기 쉬운 자연어를 UML이라는 시각화 하는 동시에 형식화(formalization) 하는 탓에 쟁점이 잘 드러납니다. 여러 차례 말씀드렸지만, 상태도는 의사소을 돕는 도구입니다. 이 연재가 그 도구를 어떻게 쓰는 보여주는 본보기가 되겠죠.

매장기부와 택배기부에서 서로 다른 접수 양상

첫 번째 쟁점은 매장 접수와 택배 접수가 매우 다르다는 점입니다. 기부자가 매장에 기부물품을 직접 들고 오는 매장 기부의 경우 접수라는 행위를 모두가 인지합니다. 기부하는 분이나 매장 매니저(책임자)나 명확하죠. 반면에 택배로 보내는 경우에는 접수라는 행위 자체가 모호해집니다.

한자어인 접수(接受)의 受자는 '받을 수'자 입니다. 그런데, 기부자가 기부물품을 아름다운가게로 접수해야 하지만, 편의점에 물건을 건내고 택배를 통해서 아름다운가게 물류센터로 기부물품이 도착합니다. 아름다운가게 입장에서 보면 물류센터로 택배가 도달하고, 물건을 확인했을 때 접수가 잘 된 것으로 볼 수 있습니다. 반면, 접수자 입장에서는 편의점에서 택배를 맡긴 후에는 접수라는 행위가 있을 수 없습니다.

기부가액 산정 프로세스 표준화

두 번째 쟁점으로 기부자가 원할 경우 기부 영수증을 발급해주기 때문에 기부 금액을 산정하는 일이 있습니다. 그런데, 택배 기부의 경우 편의점에서 택배로 기부를 할 수 있다는 최소 기능을 빠르게 릴리즈하는 린스타트업의 MVP(Minimum Viable Product)를 채택한 탓에 기부가액을 바꾸는 부분은 아직 구현되어 있지 않습니다. 그런데, 매장 기부는 받는 즉시 가격산정을 해두어야 종이에 기록하고 나중에 시스템에 등록하는 번거로움이 줄기 때문에 기부가액 산정하는 기능이 만들어져 있었습니다.

그래서, 이를 양쪽 경우 모두에 통일성 있게 반영할 수 있는 프로세스 정비에 대해 의견을 나눴습니다.

아래 화이트보드 내용은 회의를 중재하며 제가 메모한 사항입니다. 정말 다양한 생각들을 들을 수 있습니다. 기획자, 개발자, 운영자 등의 입장에 따라 입장이 다름은 물론이고, 다양한 질문과 제안속에서 최초의 쟁점은 더욱 좁은 범위의 쟁점들로 바뀌는 과정을 경험할 수 있습니다.

풍부한 기록을 생산하는 비대면 디지털 논의

하지만, 대면 논의 직후에는 아직 정리가 덜 된 쟁점들이 서로의 머리속에 서로 다른 말로 기억될 뿐입니다. 많은 사람들이 생산적인 회의였다고 만족감을 표했지만, 결실은 그 다음에 만들어집니다. 지식은 구현 가능한 수준으로 구체적으로 정리되어야 합니다. 이를 위해 디지털 공간에 기록을 쌓는 일은 매우 생산적입니다. 다행히 아름다운가게 모바일사업부는 작년 8월부터 두레이를 이용한 비대면 디지털 소통에 익숙해져 있었습니다.

쟁점을 좁혀 논의를 구체화 하기 위해 질문을 잘 던지는 것이 중요합니다.