실력있는 개발자를 움직이고 싶다면.
개발자와 잘 지내고 싶은 모든 분들을 위해.
1. 모든 것이 다 중요하다고 하지 않는다.
'미움받을 용기'란 책이 한 때 매우 유행했는데, 혹시라도 개발자들로부터 미움을 받고 싶다면 아래와 같이 하면 된다.
- 해야하는 일을 한꺼번에 여러개 말한다.
- 모두 다 중요하다고 한다.
- 모두 다 ASAP라고 한다.
문과생인 당신은 동시에 여러가지 업무를 하는 것이 익숙하다. 전화를 받다가 장표준비를 하기도 하고, 팀장님이 부르면 갑자기 회의에 참석하기도 하고, 시도 때도 없이 새로운 업무지시가 내려오는 것에도 익숙하다. 가장 중요한 업무, 가장 먼저 해야 하는 업무의 개념이 당신에게는 생각보다 중요하지 않을 수도 있다. 어쩌면 그것은 이상적인 이야기고, 현실 직장생활에서는 접어두어야 한다고 생각할 수도 있다.
그러나 개발자는 다르다.
개발자는 큰 문제를 작게 조각을 낸 후, 각각의 조각을 어떻게 혹은 어떤 순서로 해결해나갈 것인가에 매우 익숙한 사람들이다. '우선순위'는 개발자에게 매우 중요하다. 먼저 한 가지의 문제를 풀고, 그 다음에 다른 문제를 풀어나간다. 이 때 주로 고려하는 것은 각 조각의 중요도, 시급성, 그리고 인과관계이다.
문과생인 당신은 오른손으로 동그라미를 그리고 왼손으로 세모를 그릴 수 있을 지 모르지만, 개발자는 보통 하나의 코드를 완성한 후 다음 코드로 넘어간다. 어떤 코드를 먼저 짜야할 지에 대한 단서가 주어지지 않는다면 개발자는 스스로 판단을 해서 우선순위를 정한다. 당연한 이야기이겠지만, 그 순서는 당신이 생각하는 순서와는 매우 많이 다를 것이다.
만약 당신이 모든 것이 다 중요하다고 말하는 대신 개발자가 어떤 순서로 일을 할 지 스스로 판단할 수 있을 만큼 충분한 단서를 제공한다면 많은 개발자들이 당신을 좋아할 것이다.
(주의점: 개발자에게 어떤 업무부터 하라고 말하라는 것이 아니다. 개발자가 어떤 업무부터 작업하는 것이 좋을 지 스스로 판단할 수 있을 만큼의 충분한 정보를 주라는 것이다. 이 둘의 차이는 매우 크다.)
2. 일의 의미와 배경을 설명한다.
당연한 이야기인데, 개발자도 사람이다.
의문을 품지않는 기계와는 다르게, 사람은 누구나 자신이 하는 업무의 의미에 대해서 관심을 갖는다. 특히, 실력있는 개발자일 수록 더욱 그렇다.
물론, 모든 업무에 있어 의미와 배경을 일일히 설명하는 것은 어려울 수 있다. 그러나 최소한 일정 수준 이상의 리소스를 들여야 하는 업무에 대해서는,
- 그 업무의 의미는 무엇인지
- 누가 그 업무를 하자고 했는지
- 업무의 결과는 어떤 것들을 예상하는지
- 회사 전체의 방향에서 이 업무는 어떤 역할을 담당하게 되는지
이런 것들에 대해서 충분히 설명하는 것이 필요하다. 반대로 절대 피해야 하는 말들은 아래와 같다.
- 저도 잘 몰라요.
- 그냥 위에서 하래요.
- 설명할 시간 없어요.
- 그냥 해주시면 안되요?
음... 이렇게 이야기하면 개발자는 화를 내고, 당신을 싫어할 수도 있지만, 사실 그것보다 더 안 좋은 행동을 한다. 그것은 바로,
당신이 요청한 그대로 개발한다.
이것이 왜 문제가 되는지는 스스로 생각해 보는 것이 좋다. 아멘.
3. 하나를 추가하면 하나를 빼주거나 일정을 조정한다.
개발팀과 업무 리스트와 우선순위에 합의한 후 한창 해당 프로젝트들이 진행되고 있는데, 경영진이 당신에게 새로운 업무 지시를 했다고 가정해보자(경영진은 늘 이렇게 한다). 이 때 당신이 가진 옵션은 두 가지다.
1) 경영진의 지시사항을 그대로 개발팀에 들고간다.
2) 경영진이 요청한 배경을 이해하고, 해당 업무가 추가되었을 때 기존 업무에 미치는 영향을 고려한 후 개발팀과 상의한다.
전자는 '아몰라' 타입이라고 할 수 있고, 후자는 개발팀과 상의한 후 필요하다면 경영진에 자신의 의견을 이야기할 수 있는 '조정자' 타입이라고 할 수 있다.
아몰라 타입을 좋아하는 개발자는 없다. 애초에 개발자는 계획대로, 합의된 일정대로 하는 것을 훨씬 더 선호하는 사람들이다. 중간에 요청사항이 치고 들어오면 미리 생각해둔 계획이 깨진다. 그 상황에서 새롭게 추가된 업무를 하는 것도 딱히 기분이 좋지 않지만, 더 큰 문제는 추가 리소스를 투자해서(가령 야근을 해서) 그 업무를 했을 때 발생한다.
뭐야, 가능하잖아.
이렇게 경영진 혹은 아몰라 타입이 생각하게 되면 앞으로의 업무가 험난해진다. 물론 회사 업무 상 늘 계획된 대로만 업무를 진행할 수는 없다. 사업적 니즈와 시장 변화에 따라서 기존에 합의된 업무와 일정을 조정해야 하는 상황은 늘 발생한다. 그러나 이러한 상황에서 개발팀의 리소스를 블랙박스 혹은 고무줄로 생각하는 것은 정말로 피해야 한다.
아래는 새로운 업무지시가 주어졌을 때 할 수 있는 예시답안이다.
- 개발팀은 최선을 다해 일하고 있다고 생각한다.
- 새로운 요청을 해야할 경우, 변경이 발생한 배경과 의미를 먼저 설명한 후,
- 그 요청이 기존 일정에 영향을 줄 크기의 업무인지 아닌지에 대해 개발팀의 자문을 먼저 구한다.
- 만약 기존에 합의된 일정에 영향을 줄 업무라는 것이 확인되면, 새로운 업무를 진행하기에 앞서 기존 업무과 새로운 업무 간의 우선순위와 일정을 조정한다.
- 변경된 우선순위, 일정이 회사에 큰 영향을 준다고 생각되는 경우, 반드시 경영진에 보고한 후 합의를 받는다.
4. 개발자가 이해할 수 있는 질문을 한다.
개발자는 당신이 물은 질문에 답한다.
물론, 당신이 왜 그 질문을 했는지, 어떤 의도를 가지고 있는지, 당신의 마음 상태는 어떤지에 대해서도 궁금해하고 그에 따라 답변하는 개발자도 있겠다. 그러나, 많은 개발자들은 당신이 물은 바로 그 질문에 답한다.
유명한 짤이 있다.
와이프: 여보, 마트가서 우유사고 만약에 아보카도 있으면 6개 사와.
개발자: 우유 6통을 사고, 마트에 '아보카도가 있었다'고 와이프에게 답해준다.
(내용 이해 안되시는 분은 혼자 생각해보시길).
물론 위 내용은 다소 과장된 부분이 없지 않지만, 개발자가 문과생의 질문을 받아들이는 방식을 엿볼 수 있도록 도와준다. 그렇다면 어떻게 하는 것이 좋을까?
1) 개발자에게 질문을 하기 전에 스스로 확인하고 싶은 것이 무엇인지를 분명히 한다. (가끔 본인이 무엇을 묻고 싶은지 모르는 경우가 많은데, 문과생끼리는 그래도 될 지 모르나 개발자에게 이런 고난의 시간을 주지 말자. 사실 회사에서는 문과생 끼리도 이러면 안된다)
2) 개발자에게 묻고 싶은 것을 질문한다.
3) 개발자의 답이 본인이 생각한 것과 다르다면, 어디에서 핀트가 빗나갔는지를 확인하고 다시 질문을 한다. 좀더 정확하게는 질문을 좁혀나간다.
4) (이 부분이 굉장히 중요한데) 만약 그 개발자가 굉장히 실력있는 개발자임에도 끝끝내 당신의 질문을 이해하지 못했다면, 당신이 질문을 잘못 하고 있는 거라고 스스로 생각한다.
개발자가 질문을 이해하지 못했다면, 그것은 당신 책임이다.
5. 뻘짓을 없애준다.
개발자의 마음을 얻는 필살기다.
모든 회사에서는 개발자가 원치 않는 업무들이 있다. 회사에 꼭 필요한데 하고 싶지는 않는 그런 업무들이 아니라, 실제로 할 필요가 없는 업무들이 꽤 많다. (왜 이런 업무들이 생기고, 사라지지 않는가는 굉장히 슬픈 이야기니 여기서는 생략)
평소에 개발자에게 미리미리 물어두자. 리소스는 많이 드는데 뻘짓인 것 같은 업무가 무엇이냐고.
그런 업무들을 찾으면 셜록홈즈가 되어 왜 개발자가 그런 업무를 하게 되었는지 탐정처럼 조사하자. 단순히 조사만 하고 그치는 것은 모두에게 민폐이나, 실제로 그 중에서 해결할 수 있는(없애버릴 수 있거나 효율화할 수 있는) 업무들을 찾아서 적극적으로 날려버린다면 이야기가 다르다. 필요하다면 경영진에 보고해서 공개적으로 없애버리자.
당신이 개발팀의 뻘짓을 없애줄수록 당신은 그들의 마음을 살 것이다.
다시 말하지만 개발자도 사람이다. 사업에 대한 이해가 아무리 부족한 개발자라 하더라도, 개발하는 과정에서 어느 정도 눈치를 챈다. 자신이 뻘짓을 하고 있는지, 아닌지 하는 것을.
그럼에도 불구하고 개발자가 뻘짓을 하고 있다면, 그것은 개발자가 그것이 뻘짓임을 몰라서가 아니라 그 뻘짓을 없애기 위해 (개발자가 도저히 이해하기 어려운) 더한 뻘짓을 하기 싫기 때문이다. 당신이 개발팀을 위해 그 뻘짓들을 없애준다면, 당신이 하자고 말하는 업무에 더욱 귀를 귀울이게 될 것이다.
당연하지 않은가. 뻘짓을 없애준 사람이 새로운 뻘짓을 가져올리가.
6. 만든 것은 팔아온다.
정말로 많은 회사에서 일어나는 일이다.
개발만 해주면 서비스가 엄청나게 개선되고, 세일즈가 엄청 잘 되고 어쩌고 저쩌고... 그런데 일단 개발을 해 놓으니, 잘 쓰지 않는다.
원래 원했던 대로 안 되었다느니, 시장이 변했다느니, 원래 자신이 요청했던 것이 아니라거나, (제일 안 좋은 것은) 자기도 원래 잘 될 거라고 생각하지 않았다고 하는 사람들이 너무나 많다.
직장을 다니면서 개발팀과 일할 때의 철칙이 있다.
만든 것은 반드시 팔아온다. 특히, 리소스를 많이 투여한 업무는 무슨 짓을 해서라도 팔아온다.
만들었는데 못 팔아온 경우도 거의 없지만, 설령 그런 일이 발생하더라도 모든 사람들이 납득할 수 있을 때까지 최선을 다해 판다. 만들어준 개발팀이 이제 되었다고, 그만 떠나보내자고 할 때에도 그럴 수 없다고 팔아온다. 스스로 납득할 때까지는 반드시 팔려고 한다.
저 사람은 요청한 것은 반드시 팔아온다.
이런 믿음이 생기면, 설령 왜 그 요청을 하는지 이해가 잘 안되는 경우라도 그 사람을 믿고 리소스를 투여하게 된다. 반대로, 요청만 하고 개발해놓으면 어디론가 없어지는 사람의 경우라면? 어떻게든 그 사람이 하자고 하는 프로젝트에 끼지 않으려고 노력하는 것이 당연하지 않겠는가?
만약 당신이 하자고 하는 업무를 개발팀이 계속해서 반대하고 참여하고 싶어하지 않는다면 스스로를 돌아보자. 과거에 당신이 요청한 프로젝트의 결과가 어땠는지를.
7. 숫자가 달라지는 것을 보여준다.
다녔던 회사에서 대체로 개발팀과 잘 지냈던 가장 큰 이유는, '숫자가 달라지는 것'을 눈으로 보여주었기 때문이었다.
당연한 이야기겠지만, 성과가 나오면 일이 즐거워진다. 설령 그로 인해 직접적인 보상이 이루어지지 않는다 해도, 자신이 개발한 것이 자신이 다니는 회사의 성장에 어떻게 기여하고 있는지, 얼마나 큰 영향을 주었는지에 관심을 갖지 않는 개발자는 없다. 특히 실력있는 개발자라면 더욱 그렇다.
개발을 마치고 숫자가 변화하는 것과, 개발을 마쳤는데 도대체 어떤 변화가 있는건지 알 수 없는 것의 차이는 엄청나게 크다. 아무리 많은 보상을 주더라도 의미없는 개발에 매진할 실력있는 개발자는 많지 않다.
투여한 리소스와 그로 인해 발생하는 Impact은 반드시 '정'의 상관관계를 가져야 한다.
개발팀에 정말로 큰 리소스를 요청할 때는 반드시 숫자를 움직이겠다는 마음을 잃지 말자. 그러면 개발팀은 당신이 하는 이야기에 더 관심을 갖고, 더 많은 질문을 하고, 그리고 무엇보다 당신이 진행하는 프로젝트에 참여하고 싶어할 것이다.
