일의 완료 기준을 구체적으로 적으면 얻게 되는 이득
보고 듣고 배워 지금 써먹기
회사에서 OKR을 채택한 후 협업 시스템인 두레이에 반영하여 써 온지 꽤 긴 시간이 흘렀습니다.
완료란 무엇인가? Definition of Done
두레이가 아니더라도 작업에 대해 기록을 남기는 시스템을 쓰다 보면 완료에 대해 어떻게 기술하느냐로 작업자의 성숙도를 확인할 수 있습니다. 어떤 이들은 이를 '일머리'로 볼 수도 있겠다는 생각이 들지만, 저는 명시적인 방식을 더 선호합니다. 보고 배울 수 있는 문화를 만들기 때문입니다.
아무튼, 가장 초보적인 단계에서는 업무를 정의할 때 '완료' 기준 자체를 정의하지 않습니다. 이 단계를 레벨 0이라고 부르면, 레벨 1은 완료 기준을 명시하는 일입니다. 생각보다 한 단계를 올라가는 일을 습관화하는 데에 시간이 오래 걸리는 분들의 비중이 많습니다.
아무튼 아래 동료의 기록은 레벨 1로 분류할 수 있습니다. 저는 다음 단계가 있다고 느껴서 조언을 하려고 합니다.
자기화한 구상 계획
일단, 결론부터 말하면 다음과 같이 피드백했습니다. 영업을 하는 동료인데, 영업이 애초에 관계 지향적이라 내가 할 일 위주로 일의 정의하기가 꽤 까다롭습니다.
컨설팅 회사에 다닐 때 그래도 10년 정도 영업을 해 보아서 저 역시 그 어려움을 압니다. 그럼에도 불구하고 아니 그럴수록 꼭 해야 한다고 생각합니다. 세 가지 이유를 들 수 있습니다. 하나는 내 역량을 확인하기 위함입니다. 무슨 일을 해야 하는지 글로 써 보면 내가 도대체 일을 어느 정도 세밀하게 볼 수 있는 지를 확인할 수 있습니다. 대체로 형편없는 수준인 경우가 많습니다. 형편없다는 말은 사실 내 기대치가 실제 내가 쓸 수 있는 내용보다 큰 경우가 많았다는 뜻입니다.[1]
여기까지 글을 쓰고 잠시 뿌듯했습니다. 유튜브 영상을 보고 쓴 <자기화 메모와 전략적 삶을 이끄는 메모> 덕분에 머릿속에서 '자기화'와 '구상 계획'이라는 단어가 떠오르는 일 때문이었습니다. 그래서, 첫 번째 완료 기준 정의의 효용성을 '자기화한 구상 계획'이 가능하다고 설명하겠습니다.
외부에 의존하면 내 시간을 낭비할 수 있다
두 번째 이유는 바운더리 인식 때문입니다. 바운더리에 대한 이해는 <나의 바운더리를 튼튼하게 하는 이분법>을 참조하실 수 있습니다.
또한, 최근에 쓴 <관계는 나로 인해 생겨나지만 내 것은 아니다>편은 바운더리 인식에 대한 효용성을 설명해 줄 수도 있습니다.
관계의 문제나 일의 성사 자체는 외부에 의존하는 일을 막을 수 없습니다. 너무나도 당연한 일이죠. 하지만, 지금 나에게 주어진 시간과 내 감정 상태는 내 것입니다. 내가 의존하는 상대가 연락을 해 올 때까지는 나는 자유롭습니다. 자유로워지려면 상대 연락과 무관하게 내가 할 수 있는 정의 할수록 자유를 어떻게 활용할지 명확해집니다.
깨어 있고, 예상 못한 변화를 받아들이고, 잘 차리자
마지막 이유는 XP 그리고 옛 선인들의 문헌을 통해 전해 오는 오랜 지혜를 받아들이는 일입니다. 지극히 스스로 정성을 다 해야 주변이 바뀔 수 있습니다.
조금 더 구체적으로 설명하면, XP에서 eXtreme 이라는 단어가 쓰인 이유를 말씀드려 보겠습니다. 안전지대가 있다는 믿음을 지우라는 것입니다. 예를 들면, 부모님, 경제 사정, 시장 상황, 회사, 상사, 동료 등등으로 우리가 남에게 의존할 때 내면에 찾아오는 것이 안전지대입니다. 부자 아빠 시리즈 6편에서 부자 아빠는 그런 안전지대에 정착하려는 마음을 '안정'이라고 부르고 이는 미신이라고 말합니다.
우리에게 주어진 시간은 지금 밖에 없습니다. 무슨 소리냐 100세 시대인데라고 할 분들이 있겠지만, 미래의 시간도 항상 지금(The Present)의 형태로 옵니다. 결국 기다리느라 버려지는 시간에 나를 위한 일을 할수록 더 잘(?) 사는 일이라 할 수 있습니다.
대뇌 피질이 편도체를 이길 수 있도록 말을 잘 전달하기
마지막으로 나의 피드백은 어떠했는지 다시 돌아볼 필요가 있습니다. 최근에 <대뇌 피질이 편도체를 이길 수 있도록 말을 잘 전달하기>를 쓴 효과가 있네요. 서로 오래 만나왔고 화법이 익숙해져서 안전(?)하다고 생각하는데 이를 동료에게 물어보기로 합니다. 그리고, '토킹스틱'을 떠올리면서 양자 대화가 아니라 다자 대화 형태로 피드백이 되도록 발전시켜 봅니다.
주석
[1] 저는 이런 노하우를 TDD를 개발이 아닌 분야에 적용하면서 익혔습니다.
