아쉬운 점
번아웃 관리
이번 프로젝트는 팀원들이 번아웃 오는 것을 막진 못했습니다. 마지막쯤 되니까 점차 새로운 일을 벌이기 싫어하고 뭔가 대충하려는 양상이 나왔고, 저도 어느정도 눈감아줄 수 밖에 없었습니다.
하지만 덕분에 번아웃이 오는 이유에 대해 곰곰이 생각해볼 기회도 있었는데요. 제가 뽑은 번아웃이 온 이유는 아래와 같습니다.
1. 모르는 영역에 대한 논의
패션과 관련된 주제를 잡고 프로젝트를 시작했지만, 애석하게도 팀원 중에 옷잘알은 없었습니다. 그러다보니 모르는 영역에 대한 논의를 자주 갖게 됩니다.
모르는 영역에 대한 논의는 배트맨 vs 슈퍼맨 같은 겁니다. 누가 이길건지 이런 저런 예를 들며 승리를 예측하지만 사실 아무도 정답을 알 수는 없습니다. 끝없는 소모전만 계속 됩니다. 이 소모전은 다시 주제에 대한 흥미 감소로 이어집니다.
배트맨이 이길지 슈퍼맨이 이길지 알아보는 가장 확실한 방법은 둘이 싸우게 해보는겁니다. 즉, 유저에게 써보게하고 유저의 판단에 따르는거죠. 그 전까지 예측은 시간 낭비, 체력 낭비 입니다.
애석하게도 모르는 영역임을 알지 못하고 논의가 길어지는 일을 막진 못했네요. 그래서 개발도 느려지고 번아웃도 오지 않았나 싶습니다. 다음부턴 불확실한 것에 대해선 출시 하고 생각하려고 합니다.
2. 휴식시간 부족
그리고 물리적인 시간도 부족했습니다. 주로 개발하는 시간은 학교가 끝나고 8시 ~ 12시가 됐는데, 워라벨이 많이 깨지긴 했습니다. 워라벨이 깨진 만큼 피로도가 누적된 것도 문제가 됐던 것 같습니다.
3. 러닝 커브
이것도 실수한 영역이라고 생각하는데, 플러터를 선택한 것도 피로도에 영향을 주었다고 봅니다. 리액트를 사용하는 팀원이 있는데 리액트 네이티브를 놔두고 플러터를 선택한게 dart 공부 + flutter 공부로 공부량만 늘어난 꼴이지 않을까 합니다. 하지만 플러터를 선택한걸 후회하진 않습니다. 실무도 아니고 학생 팀프로젝트니까 이 정도 도전은 할 수 있다고 생각해요. 다만 피로도에 영향은 주었다~~
반쪽짜리 애자일
애자일하게 팀을 운영하고 다 좋았지만, 고객 참여를 충분히 못시킨 것 같아 아쉽습니다. 물론 개발자도 쓸 수 있는 앱이라 개밥먹기도 했고, 지인들에게 "함 무 바라" 해서 사용 경험을 들어보기도 했지만 더 다양한 유저 참여가 있다면 더 좋았을텐데 참 아쉽습니다. 유저로부터 반영할 만한 사항을 많이 못 끌어낸 것도 그렇구요.
그 외
데이터를 쌓아서 유저한테 제공하는게 아니라 유저가 데이터를 쌓거나 데이터가 필요 없게 서비스를 기획하는게 편합니다. 저작권 때문에 한참 토론을 했는데 이것도 아쉬운 점이네요.
그리고 수익 구조가 없는 서비스라는 것도 조금 아쉽습니다. 수익성이 있다면 팀에 강한 동기 부여가 됐을텐데 말이죠.
앱스토어 등록도 염두해 두고 크로스 플랫폼으로 플러터를 선택했는데, 앱스토어는 등록을 못했네요. 맥OS를 못구했습니다. 허허...
이런 저런 생각들
페어 프로그래밍에 대한 고찰
이번 프로젝트에선 머지할 때 충돌이 나는 일이 잦았고, 이를 해결하기 위해 같은 영역을 짜는 팀원들끼리는 페어 프로그래밍을 시도했는데, 결과는 영 좋지 않았습니다. 그만큼 생산성이 줄어들었고, 팀원은 같이 프로그래밍하는 일에 피로감을 호소했습니다.
음...이상했습니다. 저는 페어 프로그래밍을 한 경험이 꽤 좋았거든요. "이번엔 왜 다를까" 라고 생각해봤습니다.
나의 결론
제 생각엔 다양성 부족의 문제이지 않았나 싶습니다. 페어 프로그래밍은 같은 기능, 같은 코드에 대해서도 다양한 통찰을 주기 때문에 강력하고 효과적이라고 생각합니다. 그런데 이번에 페어 프로그래밍을 한 팀원들은 비슷한 부류의 개발자였고, 페어 프로그래밍에서 얻을 수 있는 부분이 적지 않았나 싶습니다.
아무한테나 좋은게 아니었네요. 다음번엔 충분히 다른 종류의 개발자인지 생각해보고 페어 프로그래밍을 도입해야 겠습니다.
마치며
다음 포스트에선 플러터를 선택한 이유, 그리고 사용 경험에 대해 말해보겠습니다.
