프로그래밍을 떠나 협업에 있어 가장 중요한 요소는 커뮤니케이션이라고 생각합니다.
그러기때문에 많은 회사에서 자체로 협업툴을 직접 개발하기도 하고,
그 협업툴을 상용화 시키기도 합니다.
전 그렇게 나온 협업툴 중 트렐로를 사용하였었습니다.
기획단계부터 잦은 혼선. 팀원간의 업무 이해도 부족으로 일정의 딜레이. 서로의 업무에 대해 알지 못하는 상황에서 서비스 배포에 따른 버그발생 등.
생각해보면 참 힘들었던 시간들이었습니다.
그 시간들을 겪으면서 꾸준히 커뮤니케이션 툴을 제안을 해왔고. 시범적으로 적용한 결과를 적어볼까 합니다.
(트렐로의 사용법에 대해서는 많은 사람들이 안내해주고 있으니 따로이 적지 않겟습니다.)
사용했던 방식은 팀단위로
아이디어단계 ( 아직 실체가 없고 구상중인 것 들에 대한 리스트 )
해야하는 업무 ( 실체가 나와 업무로 진행해야 하는 업무 리스트 )
진행중인 업무 ( 진행을 시작한 업무 리스트 )
완료된 업무 ( 진행중인 업무가 완료되어 보고가 마무리 된 업무 리스트이며 각자의 판단으로 리스트에서 제거 )
이렇게 나누었습니다.
트렐로를 정식으로 제안하여 회의를 하였을 때 팀의 반응은 3가지였습니다.
1. 필자와 같은 생각을 하는 청사진만 바라보는 경우.
2. 트렐로에 업무를 작성할 시간에 코드를 한 줄 더 작성하는게 더 업무에 효율이 있다고 생각하는 경우.
3. 업무 감시용으로 모니터링으로 바라보는 경우.
반응 3가지 중 1번의 경우에 대해서는 적극적인 자세가 가능했고 그에 따라 장점은 아래와 같은 경우가 나왔습니다.
1. 팀원끼리 하고 있는 업무에 대해 이해를 할 수 있으므로 처음 접하는, 다른 동료이 작성한 코드에 대해 누가 업무를 했었는지 확인이 가능하고 굳이 비즈니스로직까지 살펴볼 필요없이 구두로 코드리뷰를 요청하여 짧은 시간에 코드이해가 가능.
2. 해야하는 업무 리스트중에 하고 싶은 업무에 대해 주도적인 자세가 가능해집니다.
3. 다른 동료에게 자신이 알고 있는 지식을 전달해줄 수 있습니다.
4. 눈에 보이는 업무들로 인하여 스스로 일정을 구상할 수 있습니다.
5. 업무에 대해 스스로 체크리스트나 코멘트를 달 수 있음으로, 업무를 진행하면서 더욱 상세하게 업무에 대해 기록을 할 수 있습니다. ( 이건 자칫 트렐로의 업무 카드가 지저분해질 수 있습니다. )
6. 업무 중 다른 이벤트 등으로 인하여 일정이 딜레이되게 된다면 그것을 업무 카드에 작성하여 일정의 딜레이에 대한 소명자료가 됩니다.
7. 여러 업무들을 동시에 진행하게 될 경우에, 놓칠 수 있던 업무를 수행할 수 있습니다.
8. 잠시 쉬면서 앞으로 해야하는 업무들이나 아이디어단계의 업무들에 대해 생각해 볼 수 있는 여지가 생깁니다.
그리고 단점은 아래와 같은 경우가 나왔습니다.
1. 업무의 멤버로 등록되어있지 않더라도 혹시 본인의 업무인지 재차 확인하는 경우가 발생하며, 소외감을 느끼는 경우가 발생합니다.
2. 업무 모니터링으로 생각하는 경우가 발생합니다.
3. 업무의 멤버로 등록되어있지 않음으로 관심을 가지지 않는 경우가 발생합니다.
4. 자신의 업무를 팀 전체에게 보여주어야 하다보니, 트렐로 자체에 대한 스트레스를 받는 경우가 발생합니다.
사실 장점만 가지고 요구를 한다는 것은 무척 개인적인 생각일 수 있습니다.
단점을 바라보고 그것을 어떻게 개선할 수 있을지 고민해야합니다.
이번에 트렐로를 오랜 시간 설득하여 적용하고 시범적으로 사용하기까지 여러 생각을 했었습니다.
일 자체만 보고 있다면 트렐로는 분명 좋은 협업툴이라고 생각합니다.
그러나 팀원, 개개인의 성향을 이해하고 팀 전체를 생각하는 입장이라면 과연 좋은 협업툴인지 고민할 필요가 있습니다.