첫 개발자 설명을 회고하며

5월 11일 기획 세미나는 개발자들과 함께 했다. 개발자들에게 정의한 문제와 기획한 서비스를 발표하고 질의 응답 하는 시간을 가졌다.

진짜 문제를 찾고, 그 문제를 해결하는 서비스를 기획하고, 설득을 위한 원페이저를 작성하여, 기획문서와 함께 그것을 전달하는 일이 이제 낯설지는 않게되었지만, 개발자들에게 전달하는 것은 또 새로운 일이었다.

개발자로는 서버 부파트장 민지님, iOS 파도 하람님, 서버 파도 채린님이 함께 해주셨다.

세션은 1. 전 기획 파트가 기획해 온 서비스를 원페이저를 바탕으로 발표하고 2. 순서대로 개발자 분들에게 질문을 받고 3. 다시 자기 차례가 돌아오기전 받은 질문에 대한 답과 설명 자료를 준비하는 방식으로 이뤄졌다.

나는 첫 순서로 발표하여 기획 파트원들의 발표가 끝난 후 첫 순서로 질의를 받았다.

개발자로부터 첫 질의를 받았을 때 내 머릿속은 다음과 같았다.

개발자분들이 제시해주는 의문을 들으며, 개발자의 입장에서 생각한다는 것이 어떤 것인지 투박하지만 처음으로 알게 되었다. 새로운 느낌이었다. 기본적인 IT 요소에 대해 이해하고 있다고 해서 개발자의 방식으로 생각할 수 있는 것이 아니었다.

한 기능을 구현하기 위해서 생각보다 더 많은 조각으로 쪼개서 생각해야한다는 것을 알게 되었다.

개발자분들이 설명을 잘해주신다고 느꼈다. 그저 피드백을 해야해서 하는 것이 아닌 어떤 점이 왜 어려운지 스스로 제대로 이해하고 제시해준다고 느껴서 더 경청해서 듣게 되었다.

질의가 끝난 후에는 다시 내 차례가 돌아오기전까지 개발자들의 의문을 해결하고 설득할 자료를 준비 해야했다.

'개발자들이 어렵다고 하는 가장 큰 문제는 뭐지?'

'이 문제가 해결될 수 있다는 가능성을 어떻게 제시해야 하지?'

'몇 분안에 기술적인 해결책을 이해하고 제시하기는 무리가 있을 것 같다.'

'기능을 구현한 사례를 제시해야하나'

다양한 생각이 들었던 것 같다. 감이 잡히지 않아 제대로 답변을 하기 어려웠다.

개발자와 소통한다는 것은 이런 느낌이구나 하는 것을 처음으로 느낄 수 있었다. 좋은 시행착오였다고 생각한다.

이번 세션을 통해 알게 된 점은 크게 다음과 같다.

1. 적절한 양의 기능 수와 데이터

   : 기능을 최소화 했다고 생각했지만 '3주안에 구현하기에 기능과 데이터가 너무 많다'는 피드백을 듣고 다시 한번 적절한 양의 기능 수와 데이터에 대해 생각하게 되었다. 또 꼼꼼한 기획문서와 과한 기획문서는 다르다는 생각도 하게 되었다.

1. 개발자와 소통이 어려웠던 지점

   : 보통 요청하는 사항에 대해 조율할때

   상대가 'A는 어려워요 ~(B) 때문이에요' 라고 하면 B에 대해 질문하거나 이야기 하며 타협점을 찾아간다.( ex B 중에서도 어떤 점이 가장 어려운가요? 그럼 B를 이렇게 해보면 어떨까요?)

   개발자와 소통이 어려웠던 이유는 A가 B 때문에 어렵다는 것은 알겠으나 B가 기술적인 내용일 때 B를 어떻게 풀어나가야 할지 모르겠다는 것이었다. 이 부분에 대해서 개발자와의 소통을 어떻게 해나갈지 알아봐야겠다는 생각을 했다. 개발 경험을 가져봐야겠다는 생각도 했다.

1. 기능의 우선 순위를 확실하게 정하는 것이 중요하다.

   :개발자들의 질의를 들으며 기능의 우선 순위를 확실하게 정하는 것이 중요하다는 사실을 체감하게 되었다. 한정된 기간에서는 기획한 기능을 모두 구현하기 어려운 상황이 쉽게 발생할 수 있겠다는 생각을 했다. 기능의 우선순위가 명확하게 정해져야 개발자들의 입장에서도 개발의 방향성을 잡을 수 있겠다는 생각을 했다. 하는 일이 힘든데 중요한건지 안 중요한건지 알 수 없으면 동기가 많이 떨어질 것이라 생각한다.

그렇게 첫 개발자 설명을 마쳤다.

항상 처음은 초라한 것 같다. 하지만 돌아볼때마다 느끼는 것은 초라함을 느꼈던 순간들이 알고보면 가장 많이 배우고 있던 시기였다는 것이다. 또 새롭게 배워나갈 부분을 찾았으니 부지런히 배워 가야겠다!

개발자 친구들과 많이 소통해야겠다. 책한권이 스쳐 지나간다.