싸움에서 지지 않는 개발자 되는 법

개발자는 혼자 일한다는 편견과 달리 다른 많은 직업들과 마찬가지로 협업이 중요시 되는 직업이다. 

특히 프론트엔드 개발자는 기획자, 디자이너, 백엔드 개발자 (그 외에 기타등등) 사이에서 일을 처리해야 할 경우가 있다.

커뮤니케이션 능력으로 모든 일을 좋게 해결하면 좋겠지만 완만하게 진행하는 것만이 능사는 아니며, 

좋은 프로덕트를 개발하거나 직업 윤리를 실천하는 것을 외면하고 오히려 당장의 편안함만을 추구하고 있는 것은 아닌지 돌아보아야 한다.

무엇이 옳은 일인지는 경험이 있어야 판가름 할 수 있지만

권리를 위해 투쟁해야 할 순간은 온다.

 

그럼 어떻게 해야 싸움에서 지지 않을 수 있을까? 

 

 

1. 싸움은 최대한 일찍 한다

소프트웨어의 수정 비용은 뒤로 갈 수록 기하급수적으로 증가한다. 

그러니 초반에 발견 가능한 의문점이 있다면 초반에 해결하지 않으면 안 된다.

나중에 싸우면 힘들다.

지금 안 싸우고 참고 넘어간다고 하면 당장은 편하지만 내가 이상하다고 생각한 건 결국 남들도 이상하다고 생각하게 되기 때문에

결국 수정을 해야 할 가능성이 높다.

 

2. 근거를 가지고 싸운다

기획서를 꼼꼼히 너무하지 않나 싶을 정도로 뜯어보고 싸움의 근거로 사용한다.

기획서가 너무 정해진 게 없으면 기획서에 제대로 정의할 것을 꼭 요청한다.

한국말은 끝까지 읽어야 하므로 디스크립션 문장 하나하나를 따져보자.

 

3. uiux적 의문이 생길 떄는 네이버, 구글 같은 사이트를 들어가본다.

우리보다 더 똑똑한 석박사들이 더 오랜 시간을 들여 만들었는데 이쪽을 따라한다.

여기서도 못 하는 건 우리도 못 하는 거라고 얘기해본다.

(그렇지만 네이버, 구글이 할 수 있다고 우리가 할 수 있는 건 아니라는 것도 염두해두자.)

 

4. 뭐라도 기록으로 남겨놔라.

메일, 메신저, 정 안 되면 녹음이라도 해서 근거를 남겨놓는다.

피그마 같은 디자인 툴의 경우 정기적으로 pdf로 내보내기를 해두는 게 좋다.

절대 구두로 뭘 정하고 개발하면 안 된다. 나중에 말 바꾸면 큰일난다.

 

5. 애매한 기획은 내가 원하는 쪽으로 유도하자.

무조건 기획이 틀렸단 건 아니지만 애매할 경우 먼저 원하는 방향으로 제안을 하는 것도 나쁘지 않다.

(이때 너무 고집을 부려서 개발자가 기획을 다 하려고 하면 안 된다. )

 

 

6. 상급자의 도움을 받는다.

잘 모르겠으면 나보다 높은 우리편 사람에게 물어본다. 

 

7. 화를 내지 않는다.

화를 낸다고 해결되는 것은 없으니 대화의 목적을 분명히 한다.