이 글은 1~3명 정도 되는 소규모 팀의 진행 계획표에 대한 이야기입니다. 대규모 팀에 속해 있더라도 본인의 개발 스케쥴을 관리하는 데는 도움이 될 지도 모릅니다.
이 글은 영상으로도 있습니다. 영상으로 보고 싶은 분들은 맨 아래로 내려가시면 됩니다.
프로젝트 금액 산정은 어떻게 할까요? 일하는 시간에 따라 받는 게 기본입니다.
그런데 작업 시간을 미리 알 수 있나요? 어렵죠. 별 수 없이 예측과 실제를 최대한 맞춰 가야 합니다. 프로젝트 계획표 작성은 이 점에서 큰 도움이 됩니다.
저는 구글 스프레드 시트에 항목을 기록하고, 진행 상황도 거기에서 파악합니다.
아래 이미지는 프로젝트 계획의 각 항목을 보여 줍니다. 예상 시간과 실제 시간을 적고 비교하는 게 특징입니다.
아래 이미지는 프로젝트 진행 상황을 보여 줍니다. 진행률을 시간 기준과 작업수 기준으로 각각 측정하는 것, 그리고 최초의 예상 시간을 기록해서 프로젝트가 끝난 후 예상이 얼마나 어긋났는지 비교해 보는 것이 특징입니다.
작업 하나를 끝낸 상황에서 현재 진행률은 대략 3-4%라고 표시돼 있습니다.
이미지 트레이닝
개발자들이 쉽게 빠지는 함정은 개발 일정을 산정할 때 핵심 로직을 중심으로 생각하는 것입니다.
예컨대 매일 아침 기사를 긁어 와서 이메일로 보내주는 시스템을 만든다고 생각해 봅시다. 핵심 로직 자체는 그렇게 어렵지 않습니다.
그런데 만약 어떤 페이지에서 기사를 긁어올지 입력을 받아야 한다면? 입력용 UI를 그려야 하고 이건 또 만만찮은 작업이 들어갑니다. UI는 실제로 그려 보면 또 자잘하게 신경써야 할 것들이 많이 나옵니다.
URL을 입력받는 순간 예외 발생 확률은 매우 높아집니다. 사이트가 모두 다르기 때문입니다.
기사를 긁어 오는 단순한 작업 또한 네트워크 작업인 만큼 온갖 예외가 있을 수 있습니다.
만약 이런 점들을 고려하지 않은 채로 핵심 로직 설계와 구현을 중심으로 일정을 잡으면 예상과 실제가 크게 어긋납니다.
모든 측면을 세세히 훑기
프로젝트를 진행하기 전에 모든 항목을 하나씩 살피며 계획을 세우면 이런 실수가 줄어듭니다. 일종의 이미지 트레이닝입니다.
이렇게 계획을 세우면 미처 생각 못했던 작업을 발견할 수 있습니다.
이런 일이 있었습니다. 데스크톱/모바일 인덱스 디자인을 보고 여느 때와 같이 10시간쯤 걸리면 구현이 되겠지 생각을 했습니다. 그런데 디자인 구석구석을 살피며 계획을 잡다 보니 모바일에서는 검색 버튼을 눌렀을 때 검색창을 레이어 팝업으로 띄워야 한다는 사실을 깨달았습니다. 1시간짜리 작업 하나를 찾아낸 것이죠.
개념적 모순을 미리 발견할 수도 있습니다. 디자인에는 상세 페이지에 페이지네이션이 그려져 있었습니다. 그런데 계획을 세우면서 구현 시간을 따지다 보니 상세 페이지에 페이지네이션이 들어가 있는 것이 실수라는 것을 알게 됐습니다. 구현 전에 디자인을 미리 수정할 수 있었습니다.
상세하게 상의하지 않았던 기획을 재확인할 수도 있습니다. 상세 페이지의 맨 위에는 시원한 이미지가 들어가 있었습니다. 이것은 모든 글에 똑같이 들어가는 이미지일까요, 글마다 사용자가 입력하게 하는 이미지일까요? 디자인만으로는 알 수 없는 부분이고 미리 기획을 확인해야 합니다. 이렇게 생각지도 못한 작업을 하게 되는 불상사를 피할 수 있습니다.
부분과 전체의 관계
전체를 세세히 훑는 것이 좋은 이유는 한 번 이렇게 전체 작업을 세세히 훑고 나면 부분을 작업할 때도 전체를 고려하면서 작업할 수 있게 된다는 점입니다.
개발자는 특정 기능을 구현할 때 불가피하게 그 작업에 집중하게 됩니다. 그 순간 개발자의 시야는 현재 구현중인 기능 수준으로 좁아집니다. 이런 상황에서 아직 충분히 살펴 보지도 않은 다른 부분들을 미리 신경쓰기란 힘든 일입니다.
그러나 만약 작업 시작 전에 이미 전체를 훑으며 계획을 세워 뒀다면, 어떤 작업에 집중해 시야가 좁아진 상태라 하더라도 전체와의 관계를 고려하는 관점으로 잠깐 빠져나오기가 좀더 수월합니다.
예컨대 CSS에서 “큐레이션 박스”라는 CSS 컴포넌트를 구현한다고 합시다.
그런데 나중에야 다른 페이지 작업을 하다 보니까 “큐레이션 박스”의 제목은 별도의 컴포넌트로 만드는 게 효율적이라는 사실을 알게 되는 거죠.
이런 문제를 금방 발견하면 재빨리 리팩토링을 하면 되는데요. 그렇지 않고 이미 기존 컴포넌트를 많이 사용한 상태라면 조금 난감합니다.
전체 프로젝트를 세세하게 살펴봤다면 이런 문제를 회피할 가능성이 늘어납니다. 좋은 일이죠.
잘게 나눠야 합니다
이 때 중요한 것이 있습니다. 큰 덩어리로 작업을 잡으면 이런 효과를 보기 어렵다는 것입니다. 적어도 30분~2시간 안쪽으로(가급적 1시간 안쪽으로) 처리할 수 있는 작업들로 세분화를 해서 계획을 세워야 합니다. 그러지 않으면 효과를 보기 어렵습니다.
예측 적중도를 높이기
계획표를 잘 작성하고 작업하면서 실제 시간을 채워 놨다면 작업 예측이 얼마나 실제에 가깝게 됐는지 따져 볼 수 있습니다. 이는 프로젝트 금액을 산정하는 데 중요합니다.
프로젝트 금액은 프로젝트가 완료되기 전에 정해집니다. 내가 작업을 과소평가하면 그만큼 적은 금액으로 많이 일하게 됩니다. 따라서 프로젝트 일정 산정은 내 작업 시간에 얼마의 가치가 매겨지는가 하는 것을 좌우할 수 있는 매우 중요한 작업입니다. 일정 예측 능력은 그래서 중요합니다.
다행히 예측을 잘 하는 일반적인 팁이 하나 존재합니다. 작업을 세분화하는 것입니다. 우리는 작은 작업일수록 들어가는 시간을 더 잘 예측합니다.
작업 세분화의 효과는 빠진 작업, 모순적인 작업, 기획이 부족한 작업을 발견하는 효과를 낸다고 위에서 설명했는데요. 이런 것들은 모두 작업 일정 예측을 빗나가게 하는 문제들입니다. 작업을 세분화하는 것은 이런 문제를 해결해 주는 동시에 작업 시간 예측도 비교적 정확히 할 수 있도록 해 주므로 훌륭한 일반 원칙입니다.
프로젝트 진행 상황 파악
이렇게 계획표를 채워 나가면 프로젝트 진행 상황을 파악하고 전체 일정을 재기 수월해집니다.
그러면 클라이언트에게 완료 일정을 비교적 정확하게 이야기해줄 수 있습니다.
계획표에 따라 작업하면서 매일 진척도를 체크한다면 일정 지연에 대해서도 미리 양해를 구할 수 있게 되고요.
신뢰라는 중요한 자산을 이렇게 쌓을 수 있는 것이죠.
도구: 스프레드 시트
그렇다면 어떤 도구를 사용하는 것이 좋을까요? 저는 구글 스프레드 시트를 사용합니다. 어디에서나 쉽게 접속할 수 있고, 여러 명이 공동으로 작업하기도 좋습니다. 작성괴 수정도 유연합니다. 서너명 정도의 작은 팀으로 작업할 때 구글 스프레드시트는 간편하고 효율적이었습니다.
여러분은 각자 목적에 맞게 가장 편한 툴을 사용하시면 될 것이고요. 도구가 목적을 방해하지 않는다면 어떤 도구든 사용하면 된다고 생각합니다.
실제 계획을 세우는 영상을 참고하세요
아래 영상은 제가 이 글에서 밝힌 내용을 설명하고, 실제로 제가 프로젝트 계획을 세우는 모습을 보여 주는 영상입니다.
계획을 세우는 데는 대략 40분 정도 걸렸습니다. 길고 지루할 수 있으니 실제 계획을 세우는 부분은 2배속으로 보시길 추천드립니다.
영상의 설명란에 보시면 위에서 보여 드린 구글 스프레드시트의 템플릿 링크, 제가 영상에서 계획을 세운 프로젝트의 디자인 파일을 다운받을 수 있습니다.
위 영상은 “프로젝트 중심 실전 CSS” 강의의 두번째 영상입니다. 프로젝트 기획안 설명을 보시려면 첫번째 영상을 보시면 됩니다.
댓글 남기기