개발자든 연구자든, 일을 할 때 “확실하지만 시간을 들여야 하는 일” 도 있지만 “아예 어떻게 일정이 나올지도 모르겠는 불확실한 일” 도 해야 할 때가 있습니다. (후자의 일이 주 업무라면 정말 훌륭한 일을 하고 계시거나 매니저가 ***이거나… 여튼 그런 상황 아니겠습니까 ㅎ) 심지어는 가능 불가능의 여부가 나를 포함한 여러 관계 때문에 결정될 것 같을 때도 있죠.

오늘 글에선 이런 불확실한 상황에서 대처하는 “나쁘지 않은” 방법을 제시하고자 합니다. 즉, 최고의 방법일진 몰라도 제 경험상 특별한 경우가 아니면 이 방법이 제일 안정성과 속도에서 나쁘지 않았습니다.

0. 윗사람 or 경험자가 시키는 방법대로 “일단” 빠르게 해본다 (1): 글로 써라.

보통 매니저 입장에서 이런 일을 시킬 때는 1) 어떤 경우에도 뭐든 해낼 수 있을 것 같은 사람 or 2) 이 사람이 해내도 안해내도 상관 없는 사람 두 대상에게 시킵니다. 그리고 제가 매니징을 할 때는 웬만하면 2) 인 경우가 많았습니다. 1) 은 위기 상황에 가까운 상황에서 수퍼맨이 날 도와주길 바라는 것이고, 2) 의 경우에는 일단 각이라도 보고 싶은 경우에 해당하기 때문입니다.

이 글을 읽으시는 분들을 2) 라고 가정하고 얘길 진행하면, 이때 2) 의 역할은 이 업무에 대해 책임을 지는 역할이 아닌 경우가 많습니다. 말그대로 그냥 파보는 것이고, 선행 업무를 진행해서 후발대의 길을 잘 터놓는 게 역할인 것이죠. 그렇기 때문에 보통 이런 경우 매니저는 “한번 ~ 한 방식으로 해봐” 라는 얘길 합니다.

보통 2) 들은 연차가 낮아서 안그래도 겁이 많은데, 매니저가 준 방법이 개소리 같아 보여서 더 불안합니다. 보통 매니저가 이 일을 던질 때는 말그대로 그냥 던지는 것이기 때문에 깊히 생각을 안해봤을 확률이 높거든요.

이때 최악의 커뮤니케이션 방법은 매니저에게 “그 방법은 ~이기 때문에 못할 것 같습니다” 라고 얘기하는 겁니다. 님이 못할 것은 매니저도 알고 있을 가능성이 큽니다. 그냥 던져 본거고, 되면 이득이라고 생각하는거죠.

제가 제안하는 방법은, 일단 해보는겁니다. 다만, 하면서 이게 잘못된 방법이라고 생각이 들 수가 있습니다. 그렇기 때문에 일단 해보기 전에 “글로 문제를 서술해 보세요”.

정확히 어떤 문제를 풀려고 하는거고, 왜 풀려고 하는거고, 예상되는 결과가 뭐고, 어떤 부분이 확실한지, 어떤 부분이 불확실한지 적어보세요. 이 과정에서 내가 아는 것과 모르는 것이 파악 됩니다.

모르는 것에 대해서는 주변 경험자들에게 물어보세요. 아니면 매니저한테 물어보세요. 대략 키워드라도 얻어내면 그걸 갖고 일단 확실한 것들을 확보해 보세요.

글로 작성했다면, 추가로 계획을 짭시다. 언제까지 뭘 할 수 있을 것 같고, 언제까지 뭘 할 수 없을 것 같은지를 최대한 보수적으로 적어보세요. 그리고 매니저에게 그 문서를 던지면서 “파악해 봤는데 주신 업무 XX까지 해갈 수 있을 것 같습니다. 관련해서는 아래 자료 참고 부탁 드립니다.” 라고 얘기하는겁니다. 그리고 이제 매니저가 시킨대로 해봅시다.

여기서 매니저 입장에서 너무 기간이 촉박하거나 늘어진다면 일정에 대한 얘길 해줄겁니다. 그러면 일단 불확실한 ㅇㅋ를 날린 후 우린 우리의 일을 합시다.

——

근데 제가 갑자기 미팅이 잡혀서… 일하고 오겠습니다 ㅎ 다음 편에서 뵙죠.

평범한 사람이 불확실한 일을 해내는 나쁘지 않은 방법: Keep it simple, move fast! (1)