건축현장의 복잡한 정보를 정리해보자
포스트잇을 통해 진행해본 건축현장 관리 플랫폼 기획 사례
포스트잇을 통한 정보정리가 쓸모없다고 생각하는 사람들도 많다. 하지만 내 경우는 생각이 좀 다르다. 혼자서 업무를 처리할거라면 몰라도, 팀 작업에 있어서 포스트잇은 상당히 좋은 도구가 된다. 다양한 정보를 모아 각 정보의 연관성을 정리하는 정리법인데, 좀 어려운 말로 어피니티 다이어그램 (Affinity Diagram) 이라고도 부른다. 최근 새로운 신입 기획자를 교육하면서 진행해본 어피니티 다이어그램의 사례를 소개한다.
-
포스트잇 기반의 정보정리가 효과적인 경우는 다음과 같다.
- 서비스나, 대상에 대해 연관된 정보가 너무 많아서, 한눈에 보기 어려운 경우
- 너무 다양한 단계를 거쳐서 하나의 기능 (Function)이 진행되는 경우
- 해당 정보들을 '다른 협조자나, 팀원 등과 함께' 정리하고싶은 경우
그림으로 정리하기 어려운 경우, 포스트잇을 쓴다.기존에 다른 글에서도 소개했지만, 내 경우는 복잡한 flow일수록 그림을 그려서 정리를 하는 편이다. 하지만 정리해야할 내용이 너무 많거나, 정보의 우선순위를 정하기가 어려운 경우는 상황이 다르다. 해당 정보가 익숙하지 않은 정보라면, 각 정보를 나열하고 연결해보는 과정을 거치곤한다. 마치 퍼즐을 맞추듯이, 내가 알고있는 내용과 빠져있는 내용들을 검증하는 것이다. 이번에 진행한 건축현장 관련 케이스가 바로 이런 사례였다.
건축현장에서 일어나는 작업들은, 실제 현장에 나가보지 않으면 상황파악이 쉽지 않다. 건축현장에서 어떤 사용자 타입들이 있는지. 각자가 무슨 역할을 하는지. 또 어떤 지점에서 다른 사용자와 협동을 하게되는지. 이런 지점들을 설명하기가 쉽지 않았다. 그래서 내가 선택한 것은 '건축현장이 만들어지기까지의 과정'을 정리하는 방법이었다.
-
건축현장에서 공사가 진행되는 과정
1. 클라이언트가 특정 공사에 대한 공고를 낸다.
2. 다른 업체들이 제안서를 작성해, 공사권을 따내기 위해 입찰을 진행한다.
3. 클라이언트는 각 업체별로 계획한 내용과, 금액, 진행방식 등을 검토하고, 가장 우수한 업체를 선정한다.
4. 공사권을 따낸 업체 (원청)은 공사 계획서를 만들고, 추가로 필요한 외부 협력사를 찾아 견적을 문의한다.
5. 각 외부 협력사들은 공사 계획서에 맞게, 각자 견적서를 작성한다.
6. 공사권을 따낸 업체 (원청)은 적당한 가격에 맞춰 외부협력사의 견적을 수락한다.
7. 원청에서 만든 업무 계획서에 따라 실제 공사가 진행된다.
8. 공사 과정에는 각 업체와 전문가와 외부인력 등이 함께 투입된다. 또한 매일 출퇴근 증명서를 작성한다.
9. 공사 과정이 끝나면, 원청은 출퇴근 기록을 바탕으로 협력사들에게 비용을 지불한다.
10. 클라이언트도 원청에게 공사완료에 따른 보수를 지급한다.
공사권을 따낸 업체가 다시 다른 전문업체를 찾는과정. (원청과 하청의 관계)공사현장에서는 이런 하청계약이 흔하게 일어난다. 또한 각자 업무의 주체가 다르고, 건축이 진행됨에 따라 일하는 곳이나, 작업내용이 달라지기도한다. 심지어 사고나, 컨디션 난조로 인해 기존 업무자가 대체되는 경우도 많다. 이런 환경에서 계약진행조차 문서에 글씨를 써서 진행되는 형식이니. 작업 난이도가 계속해서 올라갈 수 밖에 없다. 그래서 이런 계약 과정이나, 업무위치 배정, 주의사항 전달 등을 앱으로 처리하려는게 이번 작업의 목표였다. 다만 이 과정에서 몇가지 문제가 있었다.
1. 소속업체와 계약관계에 따라 달라지는 급여 / 정산 정보
- 일반적인 서비스에서는 사용자 타입이 상당히 제한적이다. 하지만 공사현장에서는 들어가는 업체의 수도 다양하고, 각자가 계약된 작업내용이나, 기간이 다르다. 작업하는 사람이 그날 얼마나 일했는지에 따라 일 급여비용도 매일 달라진다. 심지어 그 사람이 어디 소속인지, 그 소속 업체가 얼마나 되는 수수료로 하청계약을 했는지에 따라 금액계산에 요율 (%) 을 주어야한다.
2. 시시각각 바뀔 수 있는 작업자 / 업무체계
- 기존에 나왔던 작업자가, 내부 사정에 따라 다른 사람으로 변경될 수 있다. 심지어 파견업체가 다른 업체로 변경되기도 한다. 함께 일하던 담당자나 팀장이 변할 수도 있고, 업무체계나 보고 대상이 바뀔 수도 있다. 게다가 현장에서 타 업체와 협업해야하는 경우, 누가 어떤 역할을 하는지도 알기가 어려울 수 있다.
3. 업무 계획이 제대로 이뤄지는지 체크하기 쉽지 않은 구조
- 건축현장은 날씨나, 자재 전달, 안전사고 등으로 업무계획이 변경되는 경우가 많다. 그렇다보니 현장소장이 매번 각 작업이 잘 진행되고있는지를 확인하게된다. 그러나 - 현실적으로 감독관이 모든 작업내용을 확인하는건 불가능하다. 게다가 각 업체별로 보고체계가 다르다보니, 변경된 계획을 전달하는것도 쉽지 않다.
건축현장의 가장 큰 문제는, 환경이나 사람의 영향을 쉽게 받는다는 지점이다.내가 이번 정보정리에서 가장 핵심적으로 다룬 것은 '대부분의 정보가 바뀔 수 있다는' 점이었다. 작업자도 바뀔 수 있고, 업체도 바뀔 수 있고, 작업 계획이나, 위치도 바뀔 수 있다. 그러니 한번 계획을 짜고 다른 사람에게 일괄 전달하는 방식은 사용할 수 없었다. 현장에서 자주 수정할 수 있어야하고, 개별 업체의 팀장이나, 팀원들이 직접 정보를 등록해야했다. 예를 들어 오늘 작업할 곳이 1층이었다해도, 상황에 따라서는 2층이나 3층으로 작업위치가 달라질수도 있다는 거다. 심지어 관리자의 분류도 업체별로 여러명이고, 이들에 대한 추가, 수정이 일어날 수도 있었다.
팀원분과 함께 진행해본 서비스 정보정리 결국 내가 선택한 방식은 사용자 타입 레벨이 아닌, '업체' 레벨의 구분이었다. 공사를 따낸 원청과, 다시 하청 계약으로 묶인 협력사들로 큰 틀을 나눴다. 이후 인력 소개소에서 들어온 작업자들과, 개별 팀장과 이야기를 나누어 팀원이 된 작업자를 나누기 시작했다. 그리고 각 작업자들이 업무 계약을 위해 필요한 정보들이 무엇인지 정리하기 시작했다.
1. 건축 현장에 연결된 정보들
- 건축현장 이름
- 건축 설계도
- 일별 / 주별 / 월별 작업계획서
- 도면 기준 개별섹션 구분 명칭 / 층수
- 작업계획 WBS / 실제 진척도
- 계약을 따낸 원청 회사
- 원청과 계약한 하청 회사 (협력사)
- 건축현장에서 사용할 중장비 목록
- 건축현장의 프로세스별 업무 목록
2. 건축현장에서 작업자 등록을 위해 필요한 것들
- 본인을 증명할 수 있는 신분증
- 건축현장 안전교육 이수증
- 국가기관에서 발행한 기술자격 인증서
- 안전화와 작업복
3. 각 작업자에 연결된 정보들
- 업체 소속 정보
- 계약 기간
- 작업분야와 숙련공 / 조공 등급
- 작업분야별 일별 비용 / 계약에 따른 요율(%)
- 일별 작업할 위치 / 작업할 내용
- 비상연락망 / 팀장
- 기존 작업이력 / 일별 작업공수 / 추가공수
- 작업위치별 안전교육 정보 등
4. 업체별로 연결된 정보들
- 업체명
- 업체분류 / 업무분야
- 관리자 및 작업자 목록
- 주소록 / 비상연락망
- 월별 정산 합계 / 지급현황 등
업무를 관리하고, 그 안에 들어가있는 사람과, 급여까지 처리하는 ERP 시스템정보들을 정리해보고나니, 왜 이렇게 내용이 복잡했던 건지 알게됐다. 단순히 현장관리를 하는게 아니라, 신규인원을 추가하거나, 수정할 수 있는 ERP 플랫폼을 만들어야했기 때문이었다. ERP 플랫폼은 비즈니스 분야에 따라 조금씩 다르지만, 설계 난이도가 높은 것들 중 하나다. 일반적으로 ERP는 각각의 사람과 그들의 개인정보, 개별 부서와 그룹 전체의 정보에 대해서 다룬다. 한개의 회사만 다뤄도 밀도가 상당히 높아지는데, 여러 업체를 다루니 자연스럽게 정보가 복잡해질 수 밖에 없었다.
어찌보면 이번 정리과정에서 내가 포스트잇을 꺼내들게된건, 매우 당연한 결과였다. 머릿속으로 암산을 하는 수준으로는 도저히 정리가 불가능했기 때문이었다. 정리해야할 내용이 많으니, 개별 기능 (function) 별로 정리가 되어야하는 지점은 건드리지도 못한채. 한시간이 지나갔다. 조금 더 시간이 있었다면 기능별로 어떤 단계를 거치는지. 어떤 사람들이 무슨 일을 하게되는지를 정리했을 것 같다. 결과적으로 빠져있던 지점이나, 주체가되는 업체 / 사용자타입을 정리하는데에는 성공했다. 단지 깊이가 충분하지 못했던 것이 아쉬울 따름이다.
-
작업이 진행된 이후 팀원분과 이 작업을 왜 진행해야했는지. 그리고 어떤 방식으로 정보정리를 했는지, 잠시 되돌아보는 시간을 가졌다. 그리고 이 과정에서 다른 사람들이 생각하는 포스트잇 기반의 정보정리 (어피니티 다이어그램)에 대한 자료를 조금 더 찾아보게됐다. 누군가는 이런 방식이 '유용하다' 하고, 다른 누군가는 이 방식이 '무의미하다'고 말한다. 하지만 나는 이 부분에 대해서 '복잡한 서비스일수록' 포스트잇 기반의 정리가 유용하다고 본다. 특히 각각의 정보의 상관관계를 정리하기 어려울 때, 포스트잇 기반의 정리는 빛을 발한다.
어피니티 다이어그램은 정리할 정보가 많을수록 효과가 강력해진다사람은 정보를 '시각 중심'으로 바라본다. 그렇기에 단순히 텍스트를 말하거나, 글로 적는것만으로는 정리하기가 쉽지 않다. '글이 담긴 덩어리를 떼어 붙이고, 재배치하는 과정'을 거치는 과정에서 그 연관관계를 파악하게된다. 결과적으로 어려운 내용도 좀 더 쉬운 방식으로 이해할 수 있게 돕는 것이다. 이미 남들이 다 알고있는 것들이라면 별로 필요가 없을지도 모른다. 하지만 새로운 정보, 복합적인 연관정보를 정리해야할 때는 상당히 좋은 도구가 된다. 심지어 이 부분이 좀더 발전하면 데이터베이스의 구조를 만들거나, API를 설계할때에도 사용될 수 있다.
물론 포스트잇 기반 정리가 만능은 아니다. 기반 정보를 전혀 알지 못하거나. 비어있는 칸의 정보를 채울만한 지식기반이 없는 상태라면, 무슨 방식을 써도 의미가 없다. 실제 포스트잇 기반의 어피니티 다이어그램은, 수많은 정보들을 그룹화하고, 중요도가 낮은 정보와 높은 그룹을 제거하는 과정이기도 하다. 그러니 '양이 많고 복잡한 정보' 일수록 효과가 커지는 것도 이런 이유다.
본인이 기획공부를 하고있고, 정보정리를 해야할 내용이 너무 많다면. 이런 포스트잇 기반의 작업을 추천해본다. 정보를 묶는 '사용자 타입'과 '플랫폼' 기준으로 바라본다면, 아마도 손쉽게 정리가 가능할 것이다. 나 역시도 이 방법을 좀더 훈련해보면서, 다른 정보정리 작업에서도 사용해볼 예정이다.
-
추후에 참여형 수업을 진행한다하더라도, 이런 포스트잇 기반의 정보정리 사례는 한번 꼭 적용해보게 될 것 같다.
