팀 프로젝트에서 어떤 사람이 가장 중요한지 적어봤는데요.

https://letspl.me/quest/1055

아무래도 너무 추상적인것 같네요. 그래서 아예 사례별로 조금 풀어서 정리해보도록 하겠습니다.

0. PM은 일정을 어긋나면 안됩니다.

PM은 사람들과 프로젝트의 전체일정을 관리하는 사람입니다.

나부터가 일정이 어긋나면 정당성이 떨어지게 됩니다.

나는 뭐가 됬든 , 더 빨리 더 많이 해서, 일정을 무조건 지켜야합니다.

그리고나서, 역할을 수행할 수 있습니다.

1. 2달 이내의 목표 설정 및 계획 수립

프로젝트의 마일스톤별 목표와 기간을 정의하고, 각자가 언제까지 어떠한 일정으로 진행할지 결정해줘야 합니다.

아마 처음에 시작할때 여러가지 아이디어가 산재할 거예요. 만들고 싶어하는것들이 각기 다양할 거예요.

그렇기 때문에 프로젝트내 최종 결정할 사람을 정해야합니다. PM이 하는게 좋습니다.

기한내에 방향이나 목표를 과감히 결정할 수 있어야 합니다.

A도, B도, C도 만들어야지, 우리가 정한 최종 서비스가 된다고 하면, PM는 가장 처음에 만들 모양을 정해야 합니다.

MVP라고 하기도 하죠. 그 기간은 두달이내로 잡아주는 것이 좋습니다.

1) 기획이 2주정도 작업할 수 있는 볼륨

2) 디자인이 2주정도

3)개발/테스트가 한달정도 시간을 쓰면 , 두달내에 끝날 수 있습니다.

우리는 서로를 잘 몰라요. 어떤 스타일인지 속도가 빠른지/아닌지

이렇게 한번 돌리면, 감을 잡을 수 있습니다. 그러면 다음 계획도 이 속도에 기반해서 잘 세울 수 있습니다.

2. 막힌 부분(보틀넥) 풀어주기

프로젝트에 참여중인 사람이 어떤 상황인지 확인해야 합니다.

그냥 믿고 기다리는 것만이 답은 아니예요. 늦어지고 있다면 두가지 상황일 가능성이 큽니다.

1) 개인적인 일이 생겨서 집중할 시간이 부족할 경우

→ 다른 사람들과 논의해서, 이 일을 어느정도 가져갈 수 있게 해야합니다.

→ 아니면 해당 일의 범위를 상당히 축소해서, 일정안에 끝낼 수 있게 조정해야 합니다.

2) 해당 일이 상당히 어려워서 어디서부터 손을 대야 할지 모르는 경우

→ 같이 논의해서 일의 범위를 줄이거나, 어려워하는 부분을 대신 결정내려야 합니다.

그러나, 팀프로젝트에서 리소스가 엄청 많지 않기 때문에

1)번의 경우는, 범위를 상당히 축소해야합니다.(디자인을 텍스트로 때우거나, 개발을 외부 솔루션을 바꾸거나)

2)번의 경우 이런 사이트를 그대로 베끼자 하는 등으로 눈 딱깜고 결정해야 합니다.

아니면 PM이 가져와서 임시적으로 결정을 내리고 다시 워야 합니다.

하나의 작업이 한달이 넘어가지 않게 하자.

한달동안 똑같은 수정작업하면 사람 미칩니다.

한달이 넘어가거나 그에 상응하는 기간이 도달하게 되면, 과감하게 정리해줘야 합니다.

그게 넘어가면 한없이 늘어집니다 한달이내로 끊어버리고 다른작업을 할 수있도록 정리해줘야 합니다.

3. 새로운 기술은 위험해

프로젝트 진행 중 발생할 수 있는 다양한 위험 요소를 사전에 예측하고, 이를 예방하거나 발생 시 신속하게 대응할 수 있는 계획을 수립합니다.

아마 프로젝트를 하시다보면, 참여자들이 새로운 기술을 도입하고 싶다는 이야기를 많이 하실 겁니다.

전체 개발을 새로운 기술이나 솔루션, 프로그램을 쓰고 싶으실텐데요.

1) 어느정도 내부타협을 해야합니다. 코어의 경우는 했던것 중심으로 구성하되, 주변시스템을 새로운 시스템을 쓴다거나 등

2) 아니면 선검증을 할 수 있는 시간을 주고 ,가능할지 판단해야 합니다.

→ 아마 기획시간이나 디자인 시간에 어느정도 시간이 남을텐데 그때 검증을 할 수 있도록 배려하는게 좋습니다.

4. 공유하는 분위기 만들기

회의록을 지배하는자가 프로젝트를 지배합니다.

회의록 자체가 의사결정의 의도가 어느정도 담긴 문서이기 때문에 , 회의 주제와 회의록의 내용을 잘 관리해야 됩니다.

문서를 잘 정리하는 것이 좋겠죠. 그러나 이경우는 회의에 참석했을 때에 도움되는 겁니다.

그러나 다들 바쁘다보면 회의에 참석하지 못하는 사람이 발생하기도 합니다.

이러면 이 사람 때문에 회의를 조정하기 보다는 , 과감하게 빼고 진행해야 합니다.

빠진 사람이 빠지지 않고 참석하도록 페널티를 주는 것도 중요합니다.

그러나 결정된 사항은, 별도로 공유해줘야 합니다.

문서로도 좋지만 대면/비대면 미팅을 별도로 하는 것이 좋습니다.

기획내용은 여러번 공유해도 지나치지 않다.

기획 후 디자인으로 넘어갈때가 가장 위험합니다. 디자인이 잘못나오면, 개발도 잘못되게 됩니다.

여러번 설명해주고, 여러번 이해시켜줘야 합니다.

실제 문서만 딱 던져주는 경우도 있는데, 여러 번씩 공유될 수 있도록 기회를 제공해야 합니다.

나중에 실제 디자인→ 개발에서 엄청난 시간이 잡아먹을 수가 있으니까요

뭘하고 있는지 서로 공유하기

이번주와 저번주가 동일해도됩니다. 누가 뭘 하고 있는지 전체가 아는 것이 중요합니다.

물론 PM이 잘 기억해야하지만, 주기적으로 공유해줘서 팀 전체적으로 잘 가고 있다는 안정감을 줘야 됩니다.

PM이 정보를 독점하는 게 아니라, 정보를 관리하는 사람일 뿐이예요.

정보가 잘 흐를 수 있도록 분위기를 조성해야 합니다.

5. 모든 사람의 참여를 통한 품질 관리

모두가 참여할 수 있는 테스트 환경의 마련이 필요합니다.

팀프로젝트에서는 전문 테스터를 모집하기 힘듭니다.

하다보면 , 실제 테스트가 개발자가 책임지고 진행되는 경우가 많습니다. 물론 단위테스트는 그것이 맞지만, 실제 통합테스트, UIT등은 , PM이 테스트 역할까지 배분할 수 있어야 합니다.

참여자가 모두 참여할 수 있는 테스트 환경 및 역할을 제공해줘야 합니다.

다들 기기도 다르고, 실제 테스트해보니 기획한 의도가 다를 수 있습니다.

내가 왜라고 생각하시는 분들도 가끔씩 있습니다. 프로젝트의 끝은 테스트입니다.

시작때부터 해당 테스트를 할 수 있는 시간을 마련하고, 누군가 해야 한다면, 이사람의 공적을 인정할 수 있는 분위기를 마련해야합니다.

테스트를 한 사람에게 미안함이나 고마움을 느낄 수 있도록 팀 분위기를 조성해줘야되요.

6. 팀원의 심리상담가

사실상 구성원의 사기진작도 해야합니다.

아쟈아쟈를 할 수 있는 분위기를 해주고 그게 회식일 수도 있고, 간단한 커피일수도 있고, 1:1 티타임일수도 있어요.

누가 싸울 분위기가 나온다면,

1) A는 양측의 의견을 충분히 듣고, 합리적인 중재안을 제시하여 문제를 해결하거나

2) 누가 결정을 하는게 맞는지 결정해줘야 합니다.

3) 그게 아니라면 PM이 결정해서, 욕은 내가 다 먹을 수 있도록 합니다.

너무 일정을 푸시하면 뿌러진다.

다들 직장인이거나, 뭔가 하고 있다면 시간내기 어려울 것입니다.

사람을 미워하면 프로젝트는 끝납니다.

사람을 미워하지 말고, 여기에는 합당한 이유가 있다는 마인드가 필요합니다.

일정 관리가 가장 중요하지만, 어느정도 어긋나는 것도 인정할 수 있는 너그러움을 가져야 해요.

너무 푸시하면 그 사람이 의지를 잃거나 더 안하고 싶을 수도 있습니다.