단기 프로젝트 회고_KPT 방법론

작년 12월, 정말 급하게 웹사이트 프로젝트를 진행하게 되었다.

 

어느정도의 기획은 있었으나 프로젝트를 관리해줄 사람이 없어 내가 얼떨결에 프로젝트를 맡게 되었다. 기간은 총 2주였으며, 투입 인력은 기획 1명, 디자인 1명, 개발 1명 등 총 3명이었다. 이렇게 단기간에 프로젝트를 진행했던 경험이 없어 어려움도 있었지만 나름의 좋았던 점도 있어 회고하고자 한다. 

 

이번 회고에는 'KPT 회고' 라는 방법론을 통해 진행했다. 먼저, KPT는 Keep, Problem, Try의 약자이다.

Keep(kaizen) : 좋았던 것, 다음에도 사용할 수 있는 것

Problem : 문제, 고충

Try : Problem을 고치기 위한 개선 방법

 

Chat GPT "KPT"

 

내 관점(PM 관점)에서 느낀 KPT

Keep(Kaizen)

빠른 문제 공유와 해결

짧은 기간동안 프로젝트가 진행되다 보니 문제, 이슈가 생기면 실무자끼리 고민없이 바로 이슈라이징을 했다. 혼자 고민하고, 리서치할 시간이 없기 때문에 서로가 머리를 맞대어 집단 지성의 힘을 빌리는 것이 더 낫기 때문이다.

 

이번 프로젝트는 연말에 갑자기 진행되어 마음대로 예산을 쓸 수 없는 상태였다. 하지만, 우리는 트위터 API를 사용해야 했고, 작년부터 트위터 API가 유료화되면서 막대한 금액을 집행해야 되는 상황을 맞이했었다. 실제로, 트위터 API 엔터프라이즈용은 월 4만 2천달로 한화 약 5천만원에 달한다. 2주 안에 그 정도의 금액을 승인 받기는 매우 어려웠고 연말이기 때문에 많은 사람들이 휴가를 가있는 상태였다. 

 

이 문제가 이슈라이징 되자마자 개발자분한테는 해당 기능을 제외한 다른 기능을 선 개발할 수 있도록 안내했고 나는 급하게 트위터 API를 우회할 수 있는 방법을 조사했다. 작년부터 트위터가 API를 우회하는 방법들을 열심히 차단하고 있어 쉽지 않았지만 우여곡절 끝에 사용자 경험을 조금 상이하지만 트윗, 좋아요, 리트윗, 임베드 정도는 트위터 유료 API 사용 없이 구현 가능한 것을 확인했다. (참고 : 링크) 

 

구현 가능성을 확인한 후, 빠르게 UX 관점으로 문제가 없는지 확인하고 개발에 바로 적용했다. 덕분에, 트위터 API 문제로 개발이 지연되는 것을 막았다. 빠른 문제 공유로 병렬적으로 일처리를 할 수 있는 환경을 구성하고 결론적으로 일정에 차질없게 만든 문제 처리는 프로젝트의 단합력을 고취시켰고 개인적으로, 트위터 정책, API 이해도를 높힌 기회이기도 했다. 

 

 

Problem

정석대로 작성된 문서

빠르게 진행되는 프로젝트이기 때문에 길고 완벽한 고민이 덜된 상태에서 디자인, 개발이 진행되었다. 디자인을 하면서, 개발을 하면서 간단한 수정사항들이 쏟아져 나왔다. 하지만, 나는 `문서만큼은 정석을 고집했기 때문에 엑셀 형식의 IA, 기능명세서, 와이어프레임 등 총 3개의 문서를 작성한 상태였다. 고작 웹페이지 하나였지만 버전 관리를 해야할 문서를 3개나 작성한 것이었다. 

 

따라서, 당연히 버전관리는 되지 않았다. 디자인에서 급하게 수정한 것은 와이어프레임에서 수정했고, 개발에서 급하게 수정했던 것은 엑셀 형식의 IA에서 수정하다보니 곳곳에서 버전이 병렬적으로 바뀌었다. 프로젝트 중후반부터는 엑셀 형식의 IA를 중심으로 수정사항을 반영했지만 그 전에 와이어프레임, 기능명세서를 작성한 시간, 수정한 시간은 분명 시간 낭비였다. 필요 없는 문서에 시간을 투자하는 것보다 논리적 오류가 없는지 고민하는 것이 100배 더 나았다. 

 

 

 

Try

프로젝트의 규모를 고려하고 문서를 작성하자

여러 명이 투입되는 프로젝트는 당연히 잘 정돈된 문서와 통일된 양식, 모두가 이해할 수 있는 배려감 넘치는 디테일들이 필요하다. 하지만, 이번 프로젝트처럼 구현되는 기능들이 적고 팀원이 4~5명이내로 구성되었을 경우에는 문서적 배려심은 오히려 방해가 된다는 것을 느꼈다. 빠른 속도를 요구하는 프로젝트였기 때문에 빠르게 바뀔 문서 하나면 충분했다. 기능 명세서나 와이어프레임을 작성할 정도로 실무자들에게 어려운 로직을 갖추지도 않고 누구나 쉽게 이해할 수 있는 서비스였다. 

 

따라서, 2주 ~ 4주내에 끝나는 웹서비스라면 엑셜 형식의 IA정도면 충분한 것 같다. 결국, 한 페이지이기 때문에 정상적인 성인이라면 참고할만한 시각화 이미지는 필요 없다. 그냥 규칙을 잘 지킨 기획서면 충분하다. 단기 프로젝트에서는 이전 글에서 언급한 엑셀 형식의 IA만 작성하자. 

 

 

글을 마치면서

'프로젝트에 맞게 유연성을 갖추자, 사람에 맞게 융퉁성을 갖추자.' 라는 말은 내가 직장에서 지키는 신념과 같은 말들이다. 하지만, 이번 프로젝트에서는 내가 지키고자 하는 신념보다는 정리하고 싶은 나의 본성이 앞서버렸다. 1분, 5분이라도 문서를 작성하기 전에 깊이감 있는 고민을 계속 시도해야겠다.