[좋은글] 개발자와 소통할 때, DO/DON’T

개발자와 소통하는 것이 어려운 분들이 있습니다. 개발자는 워낙 이런 저런 많은 일을 소화하기 벅차지만 그 전에 알고 있는 배경지식이 다르기 때문인데요, 그래서 비개발자분들께서는 개발의 용어를 명확히 알 수 없을 뿐만 아니라 기획적인 부분의 커뮤니케이션에도 이해관계가 다르기 때문에 서로의 입장 파악을 하기 어려운 부분이 맞습니다. 

아래에는 제가 읽어본 글 중 좋은 글이 있어 가져와보게 되었습니다. 글 하단에 댓글을 작성하는 부분이 없어 제가 따로 허락은 받지 않았지만, 개발자랑 소통하면서 이런 부분이 있으면 좋겠다라는 생각을 많이 하게 되는 글이었습니다. 

링크는 아래에 있습니다!

https://www.saeyoonjeong.com/blog/product-communication-do-dont

개발자와 소통할 때, Do/don’t — 보통의 언어

 

---

DEC 2 

WRITTEN BY SAEYOON JEONG

이 글은 52g(GS Open Innovation) Studio에서 일하며 IT 백그라운드가 없는 현업 크루와 개발자가 원활하게 소통하기 위한 제언을 정리한 글입니다. 52g의 조직적 특수성에서 기인하는 내용을 제외하고 개발자와 일하는 누구나에게 해당하는 내용만 남겨 정리해봤습니다.

DO

• 무엇을 원하는지, 글이든 그림이든 정리해서 주면 좋아요.
  • 소위 말하는 ‘와이어프레임’을 기깔나고 멋지게 그릴 필요는 없어요. 개발자와 디자이너 모두 작업을 시작하기 위한 초기 설계 도면이 필요한 것 뿐이에요. 어떤 요소가 들어가야 하고, 그 요소가 어떤 의도를 가지고 어떻게 동작해야 하는지 알고 싶어요. 손으로 그린 그림이어도 좋아요.
• “왜”에 대해 잘 설명해 주세요.
  • 목표까지 도달하는 최적의 방법을 찾아내고 싶어도, 이 기능과 이 화면을 왜 만들어야 하는지 잘 모르면 최적의 방법을 찾아낼 수 없어요. “왜”를 명확하게 설명하고 공유해주면 동기부여도 더 명확하게 되기 때문에, 더 멋진 결과물을 낼 수 있어요.
  • 문제 해결의 관점에서 발견한 문제가 무엇인지, 어떤 것을 실행해야 하는지, 개발자의 관점에서 좋은 대안이 있는지, 개발을 진행하는 데 문제는 없는지 등 먼저 의견을 물어보는 형태로 접근하고 도움을 요청하는 형태의 대화를 시도하는 것이 좋다. - <오늘도 개발자가 안 된다고 했다>, 215p
  • 이를테면 이런 내용을 문서든, 구두 커뮤니케이션이든, 넣어주면 좋아요. “이 화면은 (어떤 사용자가) (이렇게 조작해서) (이런 결과를 얻었으면 한다.)”
• 필요한 Due date가 있다면 명확히 말해 주세요.
  • 변동이 없어야 한다는 이야기는 아니에요. 일정은 프로젝트를 진행하면서 얼마든지 바뀔 수 있지만, 반드시 지켜야 하는 due date가 있는 경우엔 미리 얘기해 주실수록 이에 맞추어 개발프로세스를 진행할 수 있어요.
  • “금방”, “오래”, “빨리” 같은 주관적인 시간산정에 대한 단어보다는 몇 시간, 며칠, 몇 주 등의 객관적인 단위로 소통할수록 좋아요.
• 개발 삽을 뜨기 전까지 최대한 명확하게 원하는 산출물에 대해 합의해요.
  • 한 번 개발을 시작하면 디자인~노코드로 만들 때보다 더 많은 리소스가 들 뿐더러, 개발 중간에 목표하는 산출물이나 목표가 바뀐다면 이른바 “컨텍스트 스위칭”이 일어나면서 많은 리소스를 낭비하게 돼요.

DON’T

• 구조에 대한 고려가 없는 요청은 힘들어요.
  • 개발은 건물을 쌓아올리는 작업과 비슷해요. 삽을 뜨기 전 결정한 큰 틀의 구조와 뼈대는 쉽게 바꾸기 힘들어요. 다 지은 건물을 옆으로 1m만 옮겨달라는 요청은 불가능한 것처럼, 이미 설계된 개발 구조를 고려하지 않은 요청은 반영하기 힘들어요.
  • 만든 프로덕트를 어떤 기술적 환경에서 어떤 사용자가 사용하느냐는 구조를 설계할 때 매우 중요한 정보이기 때문에, 이 정보는 최대한 변동 없이 미리 공유하면 좋아요.
• “어떻게든 빨리”
  • “어떻게든 빨리 일단 되게 해주세요”와 같은 요청은
  • 기간산정 없이
  • 최소한의 기술적인 안정성을 담보할 수 없고
  • 보안 이슈를 체크하기 어려운 상태로 프로덕트를 만들 수밖에 없어
  • 오류의 원인이 되기 쉽고, 현업에 이관하는 등 정보를 공유해야 할 때 매우 번거로워질 수 있어요.
• 테스트를 거치며 추가 요구사항이 생긴다면 바로 반영하기 힘들어요.
  • 우리는 여러 번의 이터레이션을 통해 만들고자 했던 것이 잘 만들어졌는지 확인하는 데에 집중해요. 추가 요구사항이 계속해서 늘어난다면 프로젝트 마무리를 짓기 힘들고, 모두가 “끝없이 늘어나는 프로젝트의 굴레”에 빠지게 됩니다.
  • 만약 이번 프로젝트, 혹은 프로토타입의 범위를 벗어나는 더 좋은 아이디어가 생각났다면 백로그로 정리해서 다음 페이즈에 실천해요.