2022.01.30

프로젝트를 진행하면서 느낀 점과 당시의 생각을 기록하고자 작성되었습니다.
이 문서는 정보를 제공하지 않습니다.
생각나는대로 작성하였습니다.

---

🚀 일단 개발은

저번에 설명한 플랫폼 MVP개발은 (조금 미루어졌지만) 2월 내에 끝내기 위한 후반 절차를 밟고 있다.
무엇보다 개발팀원 간의 유대감과, 능숙한 Jira 및 Confluence를 통한 문서관리는 우리 팀이 따로 떨어져있어도 소통할 수 있는 좋은 수단이 되었다.

일정관리 툴이니 문서관리 툴이니 어쨌든 개발을 보조하기 위한 수단일 뿐, 이것으로 인해 개발에 차질이 생기면 안된다고 느꼈다.
우리는 Jira의 Story 개념을 과감히 배제했고, Task와 Study(공부) 추후 사용할 Bug만 이슈에서 사용하기로 했다.

MVP 3대 요구사항이었던 구독, 로그인, 결제 중 구독이 99% 완료되었고 (기획이 종종 바뀌어 100%를 찍기가 힘들다), 랜딩페이지가 완료되는대로 로그인과 결제 모듈을 사용할 수 있을 것 같다.

🚀 팀의 효율을 가장 높일 수 있는 방법은 무엇일까?

한가지 예시를 들어보고자 한다.

A가 팀에 합류할 때 "나는 PM에도 관심이 있다"라고 하였고, 팀의 리더는 이러한 답변을 해준 적 있다.

너가 우리 프로젝트를 함께 하면서 PM역할을 확실히 겪어보고, 너의 진로를 체험해보았으면 좋겠다.

같이 개발하는 팀에는 누군가 일정관리와 문서관리를 도맡아주니 순수히 개발에 집중할 수 있는 장점이 있고, A는 자기가 생각만 해보았던 PM의 역할을 직접 수행해보며 (물론 사수는 없지만) 포트폴리오 뿐 아니라 자신의 부족한 점, 자신이 생각하는 PM의 정의 등을 다시 세울 수 있는 장점을 생각하여 건네준 말이었다.

하지만 이미 기획은 어느정도 자리잡혀 있는 프로젝트여서, 정해져있는 기획을 바꾸기엔 무리가 있었다. 업무분배와 일정에 있어 기획을 일부 수정해야 할 때, 수정사항들을 모두 팀 리더나 대표에게 상의를 해야했다. 하지만 개발팀 이외의 디자인/마케팅 인원들은 매일 만나서 프로젝트를 진행하지도, 에자일 방식의 업무진행을 하고 있지도 않았다.
만약 설문조사와 관련된 일이 생긴다면 A를 통해서 업무가 공유되지 않고 담당자와 다이렉트로 대화하는 일이 있기도 했다. 더구나 웹의 업무가 많지 않을 것이라 생각하고 A가 같이 하기로 한 프론트엔드 영역은 우리의 판단과 다르게 업무가 생각보다 많았다.

이제 팀이 A에게 어떤 행동을 할 수 있을 지 간단하게 생각해보자.

1. A는 팀에 잘 적응하지 못하고 하는 일이 없으니 나가라.
2. A는 업무진행능력이 낮으니 PM과 프론트개발 둘 중 하나를 포기해라.
3. A가 PM역할과 프론트 개발을 잘 할 수 있게 환경을 맞춰준다.

물론 정답이 3번이 아닐 수도 있지만 나는 3번이 제일 좋은 선택이라 생각한다.

(보시는 분들 중 보기에 답이 없다면 답글로 알려주었으면 한다)

다만, 나의 관점에서 1번과 2번을 선택할 때 일어날 수 있는 문제점이나 단점들과, 3번을 선택하여야 하는 이유을 정리해보고자 한다.

1번을 선택하게 된다면, 이제 팀은 팀의 문제점을 전혀 알 수 없게 될 것이다.
새로운 팀원을 아무리 보충해도 보충인원들이 왜 짧은 시간 안에 그만두는지 그 이유를 알 수 없게 되는 것이다.
1번을 선택한 팀은 정확한 폭포수 모델이 적용되지 않는 이상, 와해될 팀이라 생각한다.

2번은 선택하게 된다면, 팀원의 신뢰도를 잃게 될 것이다.
프로젝트를 참여하는 팀원들은 각자 이유가 있겠지만, 어쨋든 각자에게 이득이 있어야 한다.
즉, 윈윈이어야 한다.
A는 개발경험과 PM경험 두 가지를 보고 프로젝트에 참여했다.
두 가지의 이유를 보장받고 시간과 노력을 투자한 A가 프로젝트에 참여할 이유가 사라진다면, 그 팀에 더 이상 자신을 투자할 수 없다.
2번을 선택한 팀은 당장은 문제를 해결한 것처럼 보이지만, 프로젝트가 잘 마무리되더라도 사람을 남길 수 없는 팀이다.

내가 생각하는 답은 3번이다.
예시부터 예를 들어보자.
예시에서의 문제 중

1. PM에게 정확히 인수인계되어지지 않은 기획
2. 팀원들간의 소통 부재

로 정리할 수 있을 것 같다.

위 두 가지 문제를 해결할 수 있다면, A는 PM역할과 개발역할을 충실히 할 수 있을 것이라 기대할 수 있다.
1번의 문제는 팀원 전체가 모여 프로젝트 기획과 방향성을 정확히 알고, 절대 수정하면 안될 내용을 알려주는 것으로 해결할 수 있다.
2번문제는 팀의 프로젝트 개발 방법을 바꾸어보는 것으로 해결할 수 있다. 팀의 대표는 A와 소통하는 것으로 업무를 부여하고 A가 적절히 팀원들에게 분배하는 것만으로, 지금까지의 업무환경보다 PM의 역할을 겪어보기 좋을 것이다. 모든 팀원이 스크럼을 진행하는 것으로 굳이 팀원 전체가 모이지 않아도 각 팀원들이 하는 일과 고충을 들을 수도 있다.

🚀 환경

팀원들이 환경을 맞춰주는 것이, 각 팀원들의 효율을 높히는 좋은 이유 중 하나이지 않을까 싶다.

팀원이 편안하다고 느끼는 환경이 아니라, 업무를 할 때 환경때문에 방해받지 않아야 한다는 것이다.

환경을 바꾸는 것은 팀원 모두가 신경을 써야하고, 환경을 체득하기 전까지 많은 노력이 필요하기도 하다.

하지만 자그마한 환경 개선만큼 팀의 능률을 크게 상승시킬 수 있는 방법도 많이 없을 것이다.

마무리

굉장히 보기 어렵고 난해하게 쓴 글이 탄생했는데,
어쨋든 요지는

서로가 만족할 수 있는 환경

을 만드는 것이 팀의 능률 효율을 크게 높일 수 있을 것 같다.

서로가 "팀"에 대한 불편함 없이 업무를 진행할 수 있도록 환경을 구축하고 개선하는 것이
팀 대표, 리더가 해야할 일이 아닐까 싶다.