직장 부서에 어떤 상사가 있냐에 따라, 그 부서의 분위기가 좌우됩니다. 최근에 직장상사가 바뀌고 나서 재미있는 경험을 겪었는데요. 전임 상사는 하나의 팀은 항상 뭉쳐야 된다는 좌우명으로, 모두가 각자의 일이 끝날 때까지 사무실에 있어야 했습니다. 새로 온 상사는 "왜 불필요하게 그렇게 해야하지?"라면서 잔업을 처리하는 데 필요한 사람만 남고, 남는 사람을 당번으로 돌아가도록 하게 했습니다. 부서 구성원의 만족도는 높아졌고, 일은 똑같이 처리되었고 잉여 인력의 낭비는 없어졌습니다.
부서 특성 상 다양한 종류의 서류를 상신하게 되는데, 그 전까지는 완전히 구분된 업무 영역으로 일을 처리해서 각 일에 대한 전문성은 다소 높아졌지만, 담당자가 결근할 경우 고객이 자신의 요구사항을 충족하지 못하고 돌아가거나, 오래 기다리는 불편함이 있었습니다. 하지만 이번에는 서로 각자가 담당하고 있는 업무를 멘토링하면서 타인이 담당하고 있는 업무도 이해하고 유연성 있게 일을 처리할 수 있도록 되었습니다. 정보를 공유한 이후, 저도 상대방이 담당하고 있는 서류들을 '읽을' 수 있게 되기 때문에(그 전까지는 '볼' 수만 있었던) 요구사항이 불충분한 서류를 빨리 확인하고 효율적으로 업무를 진행하게 됩니다.
사무실에 인트라넷으로만 접근 가능한 위키나, 버전 관리 시스템 도입을 제안하고 싶은데 새 구성원들이 학습해야 하는 부담 때문에 걱정입니다. 그렇다고 비허가 소프트웨어를 설치해서 혼자 쓸 수도 없는 상황입니다. 문서를 작성하면서 실행취소(UNDO) 기능에 매번 감사하고 있습니다.
사무실은 점점 개선되고 있고, 우리는 충분히 더 나아질 여지가 있습니다.
아래는 추가로 생각해본 이야기들입니다.
문서를 완성하는 일, 프로그램을 완성하는 일. 제 생각에 닮은 점입니다.
처음 초안을 작성합니다.
초안을 작성한 후 문서의 오류(프로그램의 버그에 해당)를 찾습니다.
고객의 요구사항이 변경되면 다시 문서(프로그램)를 작성, 준비하거나 수정합니다.
특정한 여러 요구사항이 충족되면 문서는 완성됩니다.
(특정한 여러 요구사항의 행동명세를 수행하면 프로그램은 완성됩니다.)
가끔 오류가 있는 채로 인수가 되면, 다시 수정 작업(패치)을 합니다.
문서의 상태가 변경되고, 그 변경 기록을 문서화하여 유지하는 일이 중요합니다.
인수예정일까지 완성해야 한다는 부담이 있습니다.
닮지 않은 부분은, 문서 형식이 완전히 바뀌는 경우를 제외하고는, 일단 문서에는 이미 정해진, 또는 관례적인 형식이 존재해서 새로운 요구사항에 맞춰 특정 부분을 치환하면 됩니다.
