개발 프로젝트 추진에 관한 단상 #1

프로젝트를 시간 내에 꼭 끝내고 싶다

만들고 싶었던 만큼, 원하는 시간 내에 만드는 것이 너무 어렵다. 만들고 싶은건 어마어마한데, 시간은 어떻게 잡아야 할까?

그동안 정말 가려웠던 부분인데, 멘토님이 나름 시원하게 긁어주신 것 같다.

나의 경우 : 프로젝트 일정 계획

전통적인 방법

• WBS
  • MECE 하게
• 기능분해도

하지만, 나의 경우에는 이번에 와이어프레임부터 바로 작성했다.

클라이언트나 다른 부서와의 커뮤니케이션을 위해서는, 실제 화면이 가늠이 가기 때문에, 와이어프레임이 있는게 소통에 큰 도움이 된다고 한다.

나 같은 경우에는, 와이어프레임을 그리면서 사용자 관점에서 우리 앱을 다시 생각해보게 되었다. 그래서 필요없는 기능을 삭제하고, 새로운 기능을 추가하기도 했다.

그 후에 Monday라는 툴을 이용해 WBS와 같은 것을 작성하였다.

팀으로 일하기 위해 고려해야 할 것들

일정 관리

• 참가중인 프로그램 혹은 팀 운영 일정
• 팀원 개인 일정
• 회의 일정

업무 관리

• 스터디 & 리서치
• 기획 및 설계
• 실험
• 개발
• 프로덕트 백로그
• 스프린트 백로그

현재 진행중인 프로젝트에는, ‘Monday’에서 위와 같이 항목을 나눠서 관리하고 있다.

프로젝트 성공을 위한 전략적인 일정 계획

어렵고 중요하고 먼저해야할 것들부터 해야한다. 그것부터 시간을 잡아야 한다.

Critical Path 일정을 줄일 수 없는 가장 중요하고 오래걸리는 일들을 말한다. 이 Path만 관리해도 된다.

계획을 세웠으면, 어떻게 시간 내에 하도록 추진할까?

책임감, responsibilty

response 응답. responsibility 응답성? 왜 응답의 가능성이 곧 책임감을 뜻할까?

멘토의 말씀에 따르면, 원래는 신이 부르면 응답하는 것을 뜻했다고 한다. 이처럼, 일을 해주는게 아니라 고객이 부르면 응답하는게 책임감이다.

이 일이 안될거 같은걸 데드라인 바로 전에 말하면 안된다. 미리 얘기해야한다. 그것이 응답성이고 책임감이다.

그렇다면, 지금 내 상태와 같이 기한 내에 일을 마칠 수 있을지에 대한 감이 없을때는 어떻게 해야할까? 계획 단계에서, 일의 양에 대해서 감이 없는데 될지 안될지 판단하고, 미리 말해줄 수 있을까?

항상 일을 받자마자 뜯어서 확인해본다

일하는 원칙은, 항상 뜯어볼 수 있을 때 뜯어봐야한다. 막상 일을 시작하게 되면 훨씬 오래걸릴 수 있다. 또는, 사실은 혼자 못하는 일 일수도 있다.

다 하는게 아니라 바로 일을 뜯어보고 감을 잡아야한다. 예상작업시간을 쓰려면 일을 한번 훑어봐야한다.

책임감의 핵심은 상대방과 협업을 하는데 있어서, 일이 잘 진행되게 반응을 잘해주는 것, 그 전체가 책임감이다.

팀원의 역할은 책임감이다

나의 문제를 직시하고 인정해야한다 프로젝트를 하게 되면 우리의 문제와 나의 문제를 구분해야한다. 내일까지 못할 거 같으면 팀원들에게 얘기를 해야한다.

리더의 역할은 점검이다

leading을 하는 사람은 점검을 하는 것이다.

일의 추진 관점에서 프로젝트를 바라보는 것이다. 실행 관점이 아닌, 추진 관점이 리더이다.

실행관점 : 어떻게 하면 할 수 있지? 추진관점 : 어떻게 하면 일이 진행되지?

따라서 전체 팀 회의를 할 때, 추진 관점의 회의를 해야한다. 일을 관리하는 매니저가 아니다. 더 큰 추진 관점에서 봐야한다. (물론 멋진 리더들은 어마어마하게 까칠한 매니저들이다.)

일을 추진한다는 것은 일의 품질을 결정하기도 한다

기획서 작성할때도 통과될 거 같다? 그럼 멈춰야해. 할일은 많으니까.

나의 경우 : 일정 계획의 방법

계획은 뒤에서부터 만든다

계획은 항상 뒤에서부터 만드는것이다. 그래야지 진짜 마감일이 나온다.

마지막 평가 기한이 ~~이다. 그럼 –는 –까지 되어있어야 한다. ~> 지금 하고 있는 일은 —까지 끝내야겠다.

뒤에서 시작해서 빠르게 한번 정리하고, 다시 앞에서부터 보면서 일정을 현실적으로 조정하는 것이다. 이와 같이 뒤에서 오고, 앞에서 가고 반복하면서 일정이 다듬어지는 것이다.

뒤에서 오면 일정을 안전하게 잡게 되고, 왠지 비현실적으로 보인다. 근데 또 앞에서 시작하면 일정을 넉넉하게 잡게 되고, 기한내에 끝낼 수가 없다. 원래 다 이런 것이다.

프로젝트 도메인의 전문가라면 기획 단계에서 일정이 쫙 그려졌을 것이다. 우리가 학생이고, 처음 해보는 것이기 때문에 한번에 나올 수가 없는 것이다.

프로젝트를 성공하기 위해 버릴건 버려야 한다

전략은 주어진 목표를, 정해진 기한과 환경 내에서 완수하기 위해 계획을 최적화하는 것이다.

• 주어진 목표
• 정해진 기한
• 정해진 환경
• 계획 최적화

또한 최적화라는 것은 버릴걸 버릴 줄 알아야 한다는 것이다. 뭐가 덜 중요한지 알아야함

하지만 학습을 위한 프로젝트라면 약간 다를 수 있다. 만약 출시를 해야하는 프로덕트라면, 기능을 줄여서 출시를 하는게 맞다. 학습을 위해서 였다면, 성장을 위해 그 경험을 포기하지 않는 것도 중요하다.

기한 내에 프로젝트를 성공하지 못할 것 같다

현행화의 방법으로는,

1. 더 똑똑한 사람과 토의해서 묘안을 찾던가
2. 덜 중요한 목표를 포기하거나 (+ 또는 잠을 안자겠다고 각오를 하거나)

MVP : Minimum Viable Product

Viable 생존 가능한 최소 기능 제품? X MVP라는 것은 기능 그리고 성능, 두 가지 모두를 담아야 한다. 고객에게 보여줘도 생존할 수 있는 제품이어야 한다.

예를 들어 간편 송금 서비스의 MVP는 무엇을 만족해야 할까? 해당 MVP의 기능으로는, 로그인, 계좌 조회, 간편 인증 등이 있을 것이다. 하지만, 송금을 하는데 30분이 걸린다면?

MVP가 생존하려면, 송금이 되는게 중요한게 아니라 진짜 편한지 성능이 받쳐줘야 한다.

MVP는 설계가 끝날 때 이미 만들어져 있어야 한다

이거 만큼은 만들어야 하는 것이 MVP이다. 최종 시연을 할때 보여줘야 할 핵심 시나리오를 만족해야 한다.

우리가 기획한 제품을 완성하지 못했더라도, 정안되면 MVP라도 보여줘야하니까. 그래서 첫번재 MVP의 목표는 최종시나리오가 되어야 한다.

실험 계획의 필요성

우리 프로젝트에서 기술적인 부분이 얼마나 가능할까 먼저 검증해보는 것이다.

예를 들어, 만약에 강아지 자세인식이 안된다면? 우리 제품은 불가능한 제품 아닐까?

특히나 딥러닝과 같은 알고리즘이 들어간 경우에는 실험을 해봐야한다. 실컷 다 만들어 놓고 엎어야할 수 있다.

실험 뿐만 아니라 늘 조심해야 하는 것

일을 위해서 일을 만들지는 말자. 간결한 방법을 만들어야한다. 필요없거나, 괜히 크게 만들지 말자. 어떤 것은 개발을 해나가면서 하면 된다. 개발 시작하기 전에 검증해야하는것만 실험하면 된다.

무조건 중요도로 정렬하고, 중요한 것부터 집중한다

자유란? 꼭 해야하는 것들, 또는 절대 해야하면 안되는 것들을 걸러내고 남는 것들이 바로 자유이다.

형식적인 것이 아닌 ‘진짜’ 계획

X : ‘Flutter 학습’ 학습할 부분을 명시해놓아야한다. 그래야 계획을 세울 수 있다. Flutter로 작업할 준비를 하는 것이 목표가 되어야한다.

회사라면 학습은 적지 않는다. 어떤 것을 학습을 해서 어떤 준비가 될 것이다. 이 준비로 어떤 작업을 해낼 것이다를 보여줘야 한다.