포스트

마음가짐 - 프로젝트

마음가짐 - 프로젝트

🗿 말머리


조금은 딱딱한 이야기.

무엇을 만든다는 것에 있어서,
역할을 가지고, 그 역할이 가지는 책임을 진다는 것에 있어서,

🗿 시작


프로젝트를 시작하기 전에, 정말 내가 좋아하고 잘 할 수 있는 역할인지 생각해보자. 하기 싫거나 어려움에도 불구하고 프로젝트를 강행하는 것은 스스로에게 있어서 (팀 프로젝트라면 팀원에게 있어서도) 힘든 일이다.

이런 상황에 있다면, 프로젝트 시작을 다시 한 번 고민해라.

🪨 이미 다른 프로젝트를 하고 있을 때

  • 다작은 하지 않는 것이 좋다.

  • 사람은 멀티태스킹이 불가능하다.
    • 신경씀에 있어서
    • 자원 (시간과 에너지)에 있어서
      • 자원을 낭비하면, 뒤늦게 찾아오는 기회를 놓칠 수 있다.
    • 하나의 프로젝트에 자원을 쏟자.
    • 자원을 나눠 쓰면, 그만큼 퀄리티도 낮아진다.
    • “더”의 기회가 없어진다. (딱 요구사항 만큼 만든다는 이야기다.)
  • 특히 혼자 진행하는 사이드 프로젝트
    • 자원 (시간과 에너지)의 여유가 있고, 중요한 프로젝트가 있는 것이 아니라면
    • 그때 비로소 고민해보자.

🪨 누가봐도 재미 없거나, 힘든 프로젝트

  • 스스로 함정에 걸어들어가진 말자.
    • 더 많은 보람을 느낄 수 있는 프로젝트가 많다.
  • 거절할 줄 알아야 한다.
    • 유혹이 있어도 (내가 좋아하는 팀원이 있다던지), 그만큼 프로젝트가 재미없고 힘들다면 의미없다.
  • 나만 할 수 있는 일이여도, 굳이 내가 힘들어질 이유는 없다.
    • 이건 상황에 맞게

🪨 이제 막 여유가 생겼을 때

  • 제발. 그냥 쉬어라.
  • 절대 일을 막 만들지 마라

  • 재충전, 재점검, 다지기의 시간을 가져라.

🪨 그래서

정말 내가 좋아하고, 재밌을 것 같은 프로젝트를 하자.

좋아하는 일을 업으로 삼으면 평생 동안 단 하루도 일하지 않아도 된다. ㅡ 공자

🗿 역할과 책임


누구도 당신을 ‘가르치지’ 않는다. 배우는 건 스스로의 몫이다.

그렇게 프로젝트를 시작했으면, 맡은 역할에 대한 책임을 다하자.

내가 맡은 역할은, 내가 책임져야 하는 것이다. 다른 누군가에게 도움을 받을 수 있을진 몰라도, 그 사람에게 책임이 전가되어서는 안된다.

🗿 코드, 프로그램 검증에 대한 책임


개발자의 일은 자기가 만든 것을 자기 손으로 테스트하는 것 까지. 테스트 코드를 실행해보는 것과는 별개로, 직접 떠먹어 보는 것 까지가 일. 기획자도 마찬가지.

내가 만든 코드, 프로그램에 대한 책임은 내가 직접 테스트해야 한다. 정말 개발 중간에 빌드 한 번 돌려서 간단하게 돌려보면 나오는 문제들, 최소한 그런 것들은 내 선에서 처음되고 해결이 된 상태여야 한다. 이게 테스트 빌드, 릴리즈 빌드에서 발견되어서는 안된다.

🪨 버그 하나로 인한 자원 낭비

(문제를 버그라고 표현하겠다.)

내가 내 역할에 대한 책임을 다하지 않았다는 것, 버그가 방치되었다는 것 자체도 문제지만, 더 큰 문제는 그 사소한 버그로 인해 자원 낭비가 발생한다는 것이다.

아래와 같은 상황에서 자원 낭비가 발생한다.

버그를 발견하는 과정

  • 내가 버그를 찾지 않았다면, 이 버그는 다른 사람이 찾아낸 상황일 것이다.
  • 그러니까 다시말해, 다른 사람이 해당 버그를 자원을 써서 발견해야만 한다.

버그 상황을 전달하는 과정

  • 그 버그는 결국 내가 만든 코드, 프로그램에서 비롯된 것이고 내가 해결해야 한다.

  • 때문에 다른 사람이 버그를 발견하면, 해당 사실을 나에게 알려줘야 한다.
    • 보통 버그 조건 등을 자세히 적어주시려고 하고, 또 최대한 기분나쁘지 않게 신경써서 전달해주려 하시는데, 이게 또 자원 낭비다.
  • 그리고 내가 그 사실을 전달 받는다. 그리고 생각한다.
    • 일단 먼저 팀과 팀원에게 미안한 마음이 들고..
    • 스스로 자책 타임을 가지고..
    • 내가 더 자원을 써야한다는 사실에 힘들어진다.

이 과정에서 나와 팀원 둘 다 특히 감정에 있어서 힘들어진다.

버그를 해결하는 과정

  • 내 입장에서도 처음 만들 때 한 번 작업하면 되는 것을, 두 번, 세 번 작업해야 하고

  • 일단 버그가 생겼으니, 테스트든, 릴리즈든, 다른 파트 작업 요청이든, 딜레이가 된다.

    • 이것이 무엇보다 큰 자원 낭비이자 문제.

🪨 코드, 프로그램 검증 - 이렇게 하자

  • 테스트 케이스 작성
    • 기획 단계에서
  • 빌드 때 마다 영상 녹화 후 공유
    • 자연스럽게 코드, 프로그램의 전체적으로 테스트하게 된다.

🪨 코드, 프로그램 검증 - 그래서

어쨌든 그래서, 정말 당연한 말이다.
내가 만든 코드, 프로그램에 대한 책임은 내가 직접 테스트해야 한다.

🗿 개발


코드, 프로그램을 만들면서 신경써야 할 것들.

  • 수정이 필요하다면
    • 해당 수정이 다른 부분에 영향을 미치는지
    • 해당 수정이 다른 부분에도 적용이 필요한지

🗿 프로젝트


🪨 프로젝트-읽을거리

🪨 협업-읽을거리

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.