개발자는 항상 컴퓨터만 보고 있다고 생각한다면. 그건 큰 오산이다. 하루에도 몇 시간씩 회의를 진행하곤 한다. 회의에서는 수많은 이야기가 오간다. "OO님 이건 어떻게 생각하세요?" "ㅇㅅㅇ" 속으로 '앗 난 별생각이 없다' 그래서 나는 "그냥 그렇게 진행해도 되겠는데요."라고 대답한다. 좋은 생각이 있더라도 어떻게 말해야 할지 모르겠기에 횡설수설하다가 끝나는 경우도 있다. 그리고 무엇보다 개발자, 기획자, 디자이너의 관점이 모두 다르다. 그렇기에 내 의견을 설득력 있게 말하기 위해서는 명확해야 한다. 설득력 있게 말하여 회의에서 살아남을 수 있는 방법 3가지를 정리해 보았다.
첫째 용어를 정리하라! 기획서를 받으면 먼저 해야 하는 건 기획서에서 처음 보는 용어들을 정리하는 것 이다. 종종 GNB, LNB, 소켓 등등 처음 들어보는 용어들이 나온다. 조금이라도 모르는 용어라면 정리해야 한다. 그래야 소통이 된다. 디자이너가 GNB는 이렇게 저렇되어야 하느냐고 말했는데.. GNB가 어디인지 모른다면 우리는 그저 끄덕하는 방법 말고는 없다. 기획서를 보고 모르는 용어를 정리하라.
둘째 비슷한 기능을 가진 플랫폼을 찾아봐라! 대부분의 기능은 상용화 되어있다. 비슷한 플랫폼을 찾아봐라. 채팅 기능이 수정된다면, 다른 플랫폼들은 어떻게 채팅 기능을 제공하고 있는지 미리 써보고 좋은 점과 나쁜점을 정리해 보라. 그리고 수정 기능이라면 기존에 사용하고 있는 기능에 어떤 문제가 있는지 찾아보고, 개선할 점을 발견해 보라. 절대로 기획서가 정답이 아니다. 우리는 더 좋은 기능 더 좋은 제안을 할 수 있어야 한다.
셋째 단순히 개발에만 집중하지 말아라! 그렇다 우리는 개발자다. 개발자인 우리의 속마음은 대부분 '어떻게 쉽게 할 수 있는 개발은 무엇일까? '사용성보다도 우리가 쉽게 개발할 수 있는 것. 재사용 가능한 코드를 사용하여 개발하는 것이다. 그래서 우리 개발자들은 재사용에 목숨을 걸 정도로 열심히 설계하고 만든다. 우리는 회의에서 쉽게 개발하는 방향으로 주장하는 것도 좋지만, 거기에 빠지면 다른 중요한 것들 놓치게 된다.
그렇다. 개발자가 회의에서 살아남기란 쉽지 않다. 글에서 말한 내용은 시작이다. 우리는 말할 수 있어야 한다. 우리가 생각하는 바를 정확하고 쉽게 설명해야 한다. 쉽게 설명하기 위해서는 정리한 용어를 가지고, 다른 플랫폼이랑 비교하여 더 나은 점들을 근거로 이야기해야 한다. 처음부터 요구분석 회의를 잘하려고 하지 말자. 한 번 더 모여서 회의하자고 하는 것도 좋은 방법이니까~
