프로젝트 관리 - UX 기획 서요한

# 프로젝트 관리 어떤 서비스를 만들어야 한다고 생각해봅시다. 아니 좀 더 포괄적으로, 어떤 프로젝트를 진행한다고 생각해볼게요. 그러면, 가장 중요하게 생각해야 하는 것은 무엇일까요? 완성도, 편의성, 심미성 등 다양한 기준이 있겠습니다만, 기획자는 무엇보다도 시간을 가장 중요하게 생각해야 합니다. 디자이너에게 작업을 의뢰하거나, 개발자에게 기능 수정이나 추가를 요청할 때, 혹은 외주를 맡길 때도 이 물음은 빠지지 않습니다: "언제까지 가능하신가요?" 그러면 그에 대한 답은 보통 "언제까지 드리면 될까요?"가 되죠. 제가 기획을 처음 접할 때, 가장 많이 듣던 말 또한 그와 비슷합니다. "일정관리 확실하게 해라." 아무리 일을 잘 진행해도 일정이 초과되면 그 사람은 무능하다고 볼 수 있습니다. 반대로, 조금 부족함이 있어도 일정 내에 오픈이 가능할 정도로 진행했다면 유능하다는 평을 듣게 됩니다. 그래서 오늘은, 제가 지금까지 사용해봤던 일정관리 도구를 소개해보려 합니다. 사실, 학부시절 저는 "너 공부 더럽게 안한다"라는 말을 듣기도 했습니다. 하지만, "왜 자꾸 약속 어기고 늦고 그러니"라는 말을 듣지는 않았죠. 구글 캘린더 덕분에 가능했습니다. ## 구글 캘린더 ![[Pasted image 20250207201621.png]] 제가 학부생 시절 사용하던 캘린더와 Todo 기능입니다. 캘린더 자체는 처음 스마트폰을 사용했던 시기까지 거슬러 올라가니까... 2010년 12월 정도라고 볼 수 있겠네요. 실제로 제가 처음 등록한 일정 또한 2010년 12월이었습니다. 아마 옵티머스Q로 작성한 것으로 기억합니다. 일정관리에 있어 캘린더는 기본 중 기본입니다. 캘린더 기능을 사용하지 않는 기획자라도, 책상 위에 달력 하나 정도는 있기 마련이니까요. 캘린더를 사용하면 내 일정을 다른 사람에게 공유해줄 수 있고, 특정 시간이 되면 메일이나 문자 등으로 알림이 오도록 만들 수도 있습니다. 일정이 등록된 시간대에는 바쁘다는 표시를 나타낼 수 있어, 해당 시간을 피해서 업무 연락을 주고받는 일 또한 가능하죠. 그래서 캘린더의 역사는 스마트폰 이전에 PDA 시절까지 거슬러 올라갑니다. 하지만 솔직히, 캘린더만으로는 일정관리가 어려운 편이에요. 국내에서는 캘린더를 사용하지 않는 사람이 더 많고, 캘린더를 이용해서 일정관리를 수행하는 경우도 별로 없었습니다. 게다가 스크린샷 오른쪽에 있는 Todo List 또한 [표준 API](https://ko.wikipedia.org/wiki/%EC%95%84%EC%9D%B4%EC%BA%98%EB%A6%B0%EB%8D%94)가 아니기 때문에 다른 플랫폼(아이폰, 블랙베리, 리눅스 등)에서 네이티브 동기화가 어렵고, 그래서 브라우저 사용이 강제되기도 했죠. 결국, 프로젝트 일정 관리는 조금 다른 측면에서 접근해야합니다. ## Google Sheets ![[Pasted image 20250207201638.png]] ![[Pasted image 20250207201703.png]] 그런데, 이번에도 구글입니다. 보통 프로젝트를 진행하기 전이나 진행 도중 WBS(Work Breakdown Structure, 업무 분업 구조)를 엑셀 파일로 많이 작성하게됩니다. WBS는, 큰 프로젝트를 해야 할 일과 세부 업무로 구분하고, 각 항목별로 언제부터 언제까지 진행하면 프로젝트가 완료될 수 있는지 기록한 형태입니다. 그리고 이 문서에서 맨먼스를 산정해서 전체 프로젝트의 기간과 비용(혹은 맨먼스)을 산정할 수 있게 되죠. 그런데 이를 구글 문서도구(이전에는 Google Docs, 구글독스)를 사용하면, 작업중인 문서를 실시간 공유가 가능해집니다. 할 일을 정하고 이를 TodoList 형태로 제작하고, 실시간으로 진행현황을 업데이트 할 수 있게 되죠. 게다가 성능 이슈도 거의 없어서, **그냥 쓰면 되는** 도구가 됩니다. 조금 기능이 부족하기는 하지만, 엑셀의 사용자 경험을 그대로 가져올 수 있기 때문입니다. 하지만 구글 문서도구 또한 한계가 존재합니다. 다른 사람이 관리하는 문서를 그대로 쓰기는 좋은데, 협업 환경을 처음부터 구축하기는 생각보다 엄청나게 번거로운 작업이 됩니다. 댓글이나 내용을 마음대로(하다못해 실수로라도) 추가/수정/삭제하는 경우도 많고, 이러한 실수 여럿이 겹치면 문서 전체가 망가지는 일 또한 비일비재합니다. 그게 겁나서 오히려 건드리지 못하는 사람도 많죠. 그래서 저는, 용도별로 다른 도구를 사용하는 방식을 권장합니다. ## Github ![[Pasted image 20250207201723.png]][Github Project](https://github.com/features/project-management/) 스크린샷 그리고 사실, 개인적으로 최근에 관심가진 툴은 바로 Github Project 라는 기능입니다. 사실 깃헙 자체는 옛날에개발자 부트캠프 과정에서 그냥 소스 저장소 개념으로만 사용했죠. 그런데 최근에 이것저것 눌러보다가 확인해보니, 이 기능이 매우 쓸만해보였습니다. 이슈나 Pull Request 등이 발생할 경우 새로운 할 일에 자동으로 등록되는 등, 꽤 다양한 기능을 쓸 수 있습니다...만, 사실 저는 개발자가 아니기 때문에 쓸 일은 그리 많지 않아서 아쉬워하는 중입니다. 그래서 아쉬움을 뒤로하고 사용하기 시작한 도구가 바로 노션이기도 하죠. ## Notion 사실, 노션 자체는 저도 최근부터 사용하기 시작한 도구입니다. 노션이 처음 등장했던 시기에는 원노트나 에버노트, 하다못해 구글킵에 비해서도 그다지 큰 우위를 보이지 못했습니다. 하지만 지금은 출시 후 3년이 다돼가고, 이제서야 좀 쓸만해졌다는 생각이 드네요. 노션이 프로젝트 관리에 어떻게 도움을 주는지 이야기하기 전에, 프로젝트 관리를 간단히 요약하자면 아래와 같습니다. - 일정한 기간 내에 - 각 담당자가 - 특정한 작업 목록을 처리한다 생각보다 간단해 보입니다. 하지만 문제는, 기간은 생각보다 짧고, 담당자는 복잡하게 얽혀있으며, 작업 또한 깔끔한 배분이 어렵습니다. 그래서 각 담당자에 맞게 작업을 배분하는 사람의 역할이 매우 중요하죠. 그래서 사용하는 방법이 바로 Gantt 차트와 간반(Kanban) 시스템입니다. [그리고 이 둘 모두 노션에서 활용이 가능해요.](https://www.notion.so/211b3dbd10844e1bafd27619d2dcddc0?pvs=21) 위 링크는 노션에서 기본으로 제공하는 템플릿입니다. 들어가보셨으면 아시겠지만, 생각보다 매우 편리한 구조로 되어있죠. 상태/작업자별(간반), 기간별(캘린더) 등으로 사용이 가능합니다. 게다가 캘린더 구조를 살짝만 바꾸면, 타임라인 보기(Gantt) 형식으로 바꿀 수도 있습니다. 지금은 제 개인적인 읽기자료를 노션에 저장하고, 특정 기간 내로 읽도록 일정을 정리하는데 꽤 편리하게 이용하고 있어요. ![[Pasted image 20250207201751.png]] ![[Pasted image 20250207201835.png]] 이런 기능 이외에도 표를 DB처럼 사용할 수 있게 한다든지, 트리 구조로 콘텐츠를 관리한다든지 할 수 있다는 다양한 장점이 있지만... 이 부분은 다른 사람들도 많이 언급하는 내용이기 때문에 생략하겠습니다. ## ASANA 결론부터 이야기하자면, ASANA 자체는 그냥 Todo List라고 봐도 무방합니다. 그 안에 댓글을 작성하거나 콘텐츠 링크를 삽입하는 것 또한 가능하지만, 가장 큰 목적은 "할 일 관리"라고 보는 편이 좋습니다. 결국, 특정 기간 내에 특정 업무를 처리하도록 만들 뿐이죠. ![[Pasted image 20250207201901.png]] 스크린샷에서 보면 화면 가장 왼쪽에서 프로젝트(또는 팀)별로 나누고, 중앙에서는 프로젝트 내에서 카테고리(홈페이지, 앱 부분 등)를 구분하고, 그 안에서 다양한 서브태스크를 지정합니다. 그리고 서브태스크 상세보기 화면에서 담당자와 마감일을 지정하는 형태가 되죠. 처음 빈 화면을 보면 어색하고 막막하지만, 사용하다보면 매우 단순하게 이용이 가능합니다. 그런데 ASANA에서 일정관리 측면을 강조해서 Gantt 차트로 만들어주는 서비스가 있어요. ## Instagantt 이제부터, 진짜배기 일정관리에 들어갑니다. 아래 스크린샷은 프로젝트 일정관리 화면이며, 이 화면에 이해관계자 각각이 접속해서 업무 진행현황을 업데이트 할 수 있기 때문이죠. PM은 이렇게 업데이트 된 사항을 메일이나 Push 등으로 전달받을 수 있습니다. ![[Pasted image 20250206210823.png]] 저는 보통 주요 작업과 1차 서브태스크까지는 ASANA에서 작업합니다. 그래서 주요 업무를 정의하고, 그에 따라 필요한 설명내용을 그 안에 담아두죠. 종종 댓글 형태로 등록하기도 합니다. 그리고 서브태스크 아래에 상세 Todo는 Instagantt에서 정의합니다. ![[Pasted image 20250207201955.png]] 이 때, 업무별로 담당자를 배정하고, 진행률을 업데이트해달라고 요청합니다. 이렇게 각각의 진행률이 모이면, 프로젝트 전체의 진행률 계산이 가능해지기 때문이죠. 물론 왼쪽 그래프는 그다지 정확하다고 하기 어렵겠지만, 그래도 없으면 아쉬운 기능임은 분명합니다. ## Jira 이번에는 조금 용도가 다른 서비스를 가져왔습니다. 사실 얘도 간반 구조로 사용할 수 있고, 담당자/카테고리별 보기 또한 가능합니다. 하지만 Jira는 무엇보다도, QA(Quality Assurance, 품질 보증)에서 빛을 발합니다. ![[Pasted image 20250207202004.png]] QA 진행 중 이슈를 보고할 때, 저는 아래와 같은 형식으로 이슈를 등록합니다. > 테스트 환경, 재현 경로, 기대 동작, 실제 동작, 스크린샷 Jira는 게시물을 작성할 때 마크다운 위지윅 에디터를 지원하며, 복사 붙여넣기 방식으로 스크린샷을 첨부할 수 있습니다. 즉, 위에 있는 형식을 모두 등록할 수 있다는 뜻이죠. 게다가 댓글 등으로 진행상황 추적이 가능하고, 담당자나 보고자, 진행상태 등이 변경돼도 이력관리가 가능하다는 장점이 있습니다. 물론 이슈리스트를 작성할 때 MantisBT 같은 툴을 사용하기도 합니다만... 가볍고 내부서버에 설치 가능하다는 것 말고는 장점을 잘 모르겠어서 아직 주력으로 사용하지는 않는 편입니다. ![[Pasted image 20250207202015.png]] [MantisBT](https://mantisbt.org/blog/archives/mantisbt/489) 스크린샷 --- ## **Contact** GitHub : [https://github.com/john33fiao](https://github.com/john33fiao) Email : [[email protected]](mailto:[email protected])