Final_Project_Restropect

Good experience

• 🤴 리더십 역량을 기르기 좋았다

• 👩‍💻 css, html, stypedcomponent 툴과 수많은 대화, 피드백을 통해 프론트 엔드로써 디자인 경험과 연습을 많이 쌓을 수 있었다.

• 👩‍💻 git 사용을 좀 더 심화된 버전으로 공부함.

• 📚 공부할 내용이 늘었다

  • typescript, angular, react, redux, typeorm, 새로운 모듈 등

• 📌 목표가 생겼다.

  • 아쉬운 게 많은 첫번째 프로젝트를 tech별로 개념 정리, 리펙토링 local에서 시도! 기록하기

  • 팀원들과 계속해서 뻔뻔하게 연락하기!

  • 취업 코칭님께 피드백 자주 드리기 징징대기

  • 코딩테스트는 일단 코드스테이츠 걸로 연습. 녹화하면서 스스로 피드백하기.

  • 노션 익숙해지기..

---

Regrets

👫 인간 관계 고찰

모든 것을 함께 한다는 게 좋은 것인가?

• • 팀 룰 내에 에러 핸들링은 다같이 한다는 룰이 암시적으로 있었다. 주로 나 때문이긴 하지만 실제로 함께 핸들링해서 requirements 세팅, 컴포넌트 디자인, framework, 디렉토리 세팅등이 빠르게 진행되었다.
• • 팀원 중 한 명이 프론트 엔드인 본인의 범위를 벗어난 (프론트와 백엔드 밖에 없었으므로) 영역에 대해 간섭을 했었다. DB 테이블 명에 대한 이견이였고, client 서버측에서 토큰 및 DB를 받아서 쓰는 상황이여서 변수명의 혼란은 납득할 만한 주제였다. 때문에 일주일정도 백엔드 측과 계속해서 대화를 했다. 나 또한 그자리에 있었기에 충분히 합의가 되었다고 판단이 된 상황. 하지만 백엔드에서 요청한 대로 계속해서 DB 변수명을 수정했으나 또다시 얘기가 나왔다. 본인이 의도한 것은 그게 아니라고 했지만, 계속해서 변수명을 길게, 디테일하게 바꾸는게 의미가 있는 것인가 라는 생각이 들었음. DB 구조는 안정화 되어있는 상황이였다. 다대다 형식으로 잘 구성되어있음에도, 배포가 제대로 되지 않고, 데이터가 제대로 전달되지 않는 등의 백엔드 내에서도 다른 중요한 버그들이 많았기 때문. 때문에 마지막 합의했던 상황 그대로 가자고 합의를 했다. 그럼에도 불구하고 본인의 생각과는 맞지않는다며 화를 냈다. 왜 계속 말을 바꾸지 라는 생각이 들었음. 나도 들었던 게 있었기에.
• • 화내는 사람의 의견대로 프로젝트는 흐르게 되었다. 나는 발언권 및 의견 전달 기준을 기여도로 생각하고 있었는데, 태스크 분배를 따졌을때에도, 따지고 보면 그 분이 제일 많이 도맡아서 하고 있긴했다. 그분은 첫 프로젝트때 백엔드를 했었기 때문에, 실제 파이널떄에는 풀스택처럼 프론트 대다수와 백엔드의 조언을 주고 있던 상황이였다. 하지만 옳았을까.

🤴 리더십

누구에게나 좋은 사람일 수 없다.

• • 팀장으로서 어떻게 해야했을까? 내가 그 분만큼 뛰어나거나, 직접 나서서 서포트를 할 수 있는 입장이 아니다보니, 쌓인게 많다는게 느껴졌다. 하지만 다른 팀원들이 이로 인에 부차적인 고생을 했고, 그리고 본인들의 의견들이 단 한 명으로 인해 많이 묵살되었다는 부분이 눈에 보였다.
• • 급한대로 개인 dm을 보내 지쳐있을 팀원들을 확인했다. 다들 별거 아닌것 처럼 굴어서.. 나도 가볍게 공감하고 편하게 텐션을 풀어주었던 것 같다. 하지만 제일 상처 받은건 나였던 것 같다. 그분이 화내실때 나의 퍼포먼스 지적도 같이 하셨기에 ㅎㅎ. 또 불안 했던 것 같다. 내 기분은 둘째치고 혹시라도 이탈을 하면 어쩌지?
• • 그분께는 담담한 사과와 함께 장문의 하소연을 보냈다. 읽어 보셨을 꺼라 생각은 됐지만 이후 답장은 주시지 않았다. 프로젝트 볼륨은 줄이고 마무리 하는 걸로 합의가 되었다. 다음날부터 의욕을 잃으신 모습이 종종 보이긴 했지만.. 디자인 욕심은 끝까지 부리셨던 것 같다. 나한테 더이상 코드를 만들거나 수정할 기회를 주시지 않기도 하셨고.

🔊 대화 기법에 대한 고찰

나도 그건 할 수 있어. 내 의견도 존중해줘.

• • 결과물이 중요했던 나로썬, 갈등 및 조정에 드는 소모적인 에너지 보단 회피해 최대한 상대방에게 조율하는 행동을 선택한 것 같다. 만약 이를 공공연하게 부딪쳐서 컨트롤 했다면 결과가 달랐을까?
• • 상황에 따른 대화법이 중요한 듯 하다. 너무 중도와 화합만 중요시 했던 것 같다. 때문에 나의 목표나, 나의 의견 전달이 불확실했음. 이 때문에 다른 이들이 거의 나의 결과물의 처음부터 끝까지 모든것을 컨트롤 당한 것에 대해 반대하지 않은게 아쉬움. 내 나름대로 내 파트에 대해 욕심은 좀 부릴 수 있었다고 생각한다.
    ex) 발표 대본 수정 , 푸터 디자인 수정, 랜딩 페이지 디자인 수정등..

👩‍🎓 진로 고민

표시판 조차 없는 개미굴, 혹시 잘 못 들어 온걸까?

• • 피드백 대부분이 코드를 다시 공부해보라, 공부를 좀 더 해라 였다. 팀원들보다 난 두배로, 8개월 간 공부를 했다.
• • 초창기부터 잘하는 팀원이 기본적인 기능구현을 본인이 다 해버리고선, 나보고 다른 것을 던져버렸다. 나도 충분히 할 수 있는 부분을 다 가져가 버려서, 솔직히 어이가 없긴 했다. 하지만 생각해보면 손 빠르고 코드 이해가 빠른, 게다가 팀룰을 어겨가며 밤늦게까지 하는 본인이 하는게 프로젝트를 위한 판단이였다는 생각 또한 들었음.
• • 다른 팀원 따라가느라 나 스스로 돌아보고, 모자란 부분을 공부할 여유는 전혀 없었다는 판단이 든다.
• • 위와 같은 일로 나도 멘탈이 나가서, 종종 개발자 못하겠다고 하소연을 한 거 같다. 생각해보면 불안하다 보니 좀 유치해진 것 같기도 하고. 경영학 전공으로 매몰비용 생각 하면 안되는데, 매몰시간은 아까웠다. 그래서 끝까지 가자 하며 이 악물고 버텼는데. 프로젝트 동안 새벽에 깨거나, 우울증에 시달렸다.
• • 나의 최종 목표는 DBA이다. 파이썬을 공부하며 데이터 분석하는게 재미가 있어서 1차로 선택한 길이고 이후 경제적으로 안정이 되면 대학원을 갈 생각이였으나.. 수료후에 오히려 더 고민하고 있다.

---

Solution

👫 팀플시 Maximum Avg 정하기

• 처음 SR때로 돌아간다면, brain storming 후 maximum limit을 각자 얘기해 보라고 할 것 같다. 난 결과론적인 사람이라, 아마 typescript를 쓰기로 한 시점에서 minimum 한 수준이 내 목표이고 희망사항이라고 얘기했을것이다. 다만 이후에 파악해보니 다른 팀원들도 다 기대치가 달랐기 때문에 각자의 욕망을 털어놓는 시간을 가져도 좋았을 거라는 판단. 이후 공동된 level을 정하고 시작했으면 훨씬 병목현상이 적었을 거라는 결론이다.

👫 🎨 공동 디자인하기

• .. 그렇게 멋진 디자인이라는 생각은 솔직히 들지 않는다. 우리팀은 디자이너가 한명뿐인가 ..할 정도로 한명이 다 끌고 가버렸지만. 그래서 공동 디자인을 합의해야한다는 경험을 얻었다. Prototype과 UI 디자인때 내가 맡고자 하는 파트는 꼭 의견제시, 먼저 디자인해서 수정 할 부분은 합의할 것!

🤴 의견 제시하기

• 내 의견을 제시했으니 내 limit 도 얘기할 것이다. 앞으로는 negative 정책을 쓰되, 허용되지 않는 상한선을 제시할 것 같다. 안된다고 싸우며 조율하는 건 내 성향과도 안맞고 감정 에너지 쓰는게 세상 힘들다..

🪠 사공이 많으면 산으로..아니.. Bug로..

• 태스크가 정해지면 더이상 개인의 역량에 맡겨야 한다고 생각함. 앞으로는 이부분을 중요시 할 것 같다. 실제 각자 파트를 맡은 경우는 오히려 bug가 적었고 갈등도 적었다. 혼자 에러 핸들링이 밤새 수정해 PR 가능한 경우의 얘기다. 하지만 내가 팀원중 퍼포먼스 적으로 약했기 때문에, 개발자로서 미진했기에, 다른 이들이 걱정이 되서 이것 저것 함께 처리를 도와줬던 것이다. 하지만 이들의 의견을 반영하느라 결과물이 계속 나오지 않던 상황. 그 때문에 병목 현상이 터졌다고 생각함. 그 와중에 로컬에 에러가 생겨 프로젝트 도중 내 개인 레파지토리만 삭제했어야 했다. 또 발표를 맡겨놓고서, PPT 디자인이 마음에 안든다고 고치거나.. 갑자기 당일 수정된 대본을 해야하는 등의 예상치 못한 문제가 발생. 그냥 좀 맡겨줬으면 했다.

⏳ TIME LIMIT은 필요하다

• 유일하게 우리 git issue에 없는게 time이다. 위와 같은 상황이 있다 보니 complete/expect time을 제대로 기록하지 않았다. 이부분은 앞으로 꼭 필요한 부분이라고 생각이 들어 주의할 예정. 특히 에러핸들링에 정해진 시간내에 혼자서 충분히 try, 숙고한 후에 팀원들에게 공유하는게 천배 만배 낫다는 생각. 다른 이의 코드를 읽느니 다 삭제하자 주의였으니..