오늘도 개발자가 안된다고 말했다 책 review, 후기

서비스를 기획하고 실행에 옮길 때 항상 부딪치는 문제

 

작업자와의 트러블

 

개발자가 안된다고 하는 이유는?

 

단순히 일이 늘어서, 요구사항을 들어주기 싫은걸까?

 

안된다는 말은 여러 의미 내포-> 해석 중요

 

여러 개발자 유형에서 부정형 개발자의 특징은 무엇이고 어떻게 대처해야 하는 걸까?

 

---

 

 

<개발자가 안된다고 말하는 3가지 이유>

 

 

1. 서비스 구조를 고려하지 않고 개발을 요청하는 경우

 

- 서비스 구조, 기능, 정책, 히스토리 같이 고려해야 한다.

 

-> 기본적으로 알고 있는 지식 필요하므로 적극적으로 질문해서 이유를 파악하고 빠르게 지식 습득

-> 가이드라인이 만들어지므로 개발의 경중 파악하여 무거운 개발 요청일수록 조심스럽게 접근하게 됨

 

 

2. 안정성에 영향을 주는 개발 건을 요청하는 경우

 

- 개발을 할 수 있는 시간은 한정, 모든 요구사항을 들어줄 수 없다.

 

-> 특히 시간이 없고 너무 많은 일이 쌓이면 시간에 쫓기고 쫓기듯이 개발을 하다 보면 서비스의 안정성이 떨어질 수 있다는 의미.

-> 기능 구현뿐만 아니라 테스트할 시간도 필요하다.

-> 서비스 운영의 관점에서 안정성, 사용성까지 고추 갖춰야 하고 충분한 시간 확보가 필요하다. 

 

- 서비스의 안정성이 우선이다.

 

-> 개발 업무 중에서 구조 자체를 뜯어고치는 일은 공수가 가장 많이 걸리고, 이전에 발생하지 않던 문제들이 일어날 가능성이 높기 대문이다. 

-> 즉, 서비스 성장 방법에 대한 사고방식이 다름. 

 

 

3. 쌓인 일이 많을 때 개발 요청 하는 경우

 

일이 쌓여 있지 않은 사람이 누가 있냐고 할 수 있다. 

 

하지만 기획>디자인>개발 순으로 진행되는 일에서 개발자가 개발을 진행하는 사이 기획, 디자인을 또 변경될 수 있고 개발 중간에 새로운 개발 요청하게 됨, 이런 상황이 반복되면 기획자는 일을 시키는 사람으로 받아들임.

 

-> 개발자는 기능을 만들고 개선하는 것 외에 서비스를 안정적으로 운영하기 위해 기능 장애를 처리하거나 유지보수를 하는 등 크고 작은 일이 반복되다보니 요청이 많아지면 부정적 액션을 취하게 됨

 

-> 이런 유형에는 지시로 느껴지지 않게 개발의 이유와 목적을 정확히 전달함으로써 목표를 공유하고 같은 방향을 향해 달리는 동지로 만드는 과정 필요 

 

---

 

큰 개선이 필요한 기능이더라도 서비스에 가져다 주는 가치가 높으면 설득 필요 

 

1) 개발자의 부담을 덜어주는 선에서 다른 개발 건의 우선순위를 조절해주거나

 

2) 단계별 개발이 가능하도록 넓은 개발 범위 세분화하여 요청하거나

 

3) 시간을 확보하는 등 대안을 함께 제시한다.

 

 

Point!

안된다는 말을 그대로 받아들이지 말고 이유를 빠르게 파악하여 함께 대안을 만들어나가는 분위기로 만들기

 

무엇보다 협업하는 자세가 중요하다.

 

기획자와 개발자 모두 회사의 성장을 위해 좋은 서비스를 만들겠다는 생각을 공유하면,

 

협업과정에서의 트러블은 더 좋은 서비스를 만들어가기 위한 과정

 

서로의 관점과 언어를 이해하고 좋은 파트너 관계로 발전하기!