프로젝트 시 하지 말아야 할 말들(Feat. IT)

 

 

대부분 직장을 다니는 직장인들이라면 반드시 IT 직군이 아니더라도 혼자서 업무를 진행하는 경우보다는 일반적으로는 타 부서와의 협업을 통해 회사에서 목표하는 방향성에 맞게 프로젝트를 정하고 진행하면서 최고의 결과를 도출해야 하는 경우가 더 많다고 생각합니다.

문제는 타 부서와 협업을 하다 보면 각 파트(직군)에 대한 이익이나 상호관계에 따라서 같은 목표임에도 불구하고 의견이 충돌하는 경우가 발생하게 되는데 이때 원하든 원치 않았든 한쪽의 파트에서는 원활한 프로젝트의 진행을 위해서 손해를 감수하고 업무를 진행해야 하는 경우가 발생하게 됩니다. 

이때 상대방을 배려하지 않는 몇몇의 사람들로 인해 업무적 스트레스 보다 더 힘들게 스트레스를 받아들이는 경우도 발생합니다. 그렇기에 우리는 프로젝트를 진행할 때 서로를 조금은 더 배려하는 태도를 가져야 합니다. 협업은 혼자의 뛰어난 역량보다는 여러 직군의 사람들 역량이 모여서 큰 힘이 발휘될 때 프로젝트 역시 좋은 결과로 이어지게 되기 때문입니다.

같이 협업해서 같이 일하는 사람들끼리 웃으면서 일해요. 우리는 모두 성인이잖아요.

1. "제가 하는거 아닌데요? 그거 못해요"

부서의 색깔과 업무롤이 대기업처럼 명확하지 않은 이상(대기업이라고 모두 업무가 명확하게 나누어져 있다고 생각하는 건 정말 오해) 일반적으로 업무를 진행하다보면 자신의 부서와 타 부서랑 하는 일에 교집합이 생기기 마련입니다. 

누가 보아도 명확한 업무분장 업무는 상관없지만 그 경계선이 불분명한 그레이 존 업무는 서로 자신의 업무가 아니라고 하기 대부분입니다. 누구는 귀찮아서 또 누군가는 정말 본인의 업무가 아니라고 생각하기 때문일 수도 있습니다. 

 

협업을 진행하면서 해당 업무가 큰 건이 아니고 자신의 영역에서 해결 가능한 부분이라면 가급적 업무에 경계선을 나누지 않고 작업을 하면 어떨가 생각합니다. 
프로젝트는 언제나 시간의 싸움이고 일정의 압박속에서 업무에 치이다 보면 자신도 모르게 날카로워지고 업무가 가중되는 것을 막기 위해 자기 방어 차원에서 커트를 하는 것은 머리로 충분히 이해가 되지만 어느 정도 자신과도 관계있는 내 일이 아니라고 선을 긋고 행동한다면 그런 행동은 남들이 보기에도 좋지않고 내가 한 행동으로 인해서 정말 내가 도움이 필요할 때 아무런 도움도 못 받게 되는 경우가 발생하게 됩니다. 

가끔은 그레이 존 업무가 아닌 스스로 처리하지 못하는 업무 요청이 들어오는 경우가 있는데 대부분의 이유는 질문을 하는 담당자가 정확히 어느 파트의 업무롤인지 파악이 안 되어 발생하는 경우가 많습니다.  그렇기 때문에“그거 못해요. ○○○파트 업무예요.”라고 말하기보단 “확인해 봤는데 그 부분은 ○○○문제와 이슈가 있어서 ○○○파트에서 처리하는 게 좋을 것 같습니다.”라고 정확히 어떤 이유 때문에 자신이 처리를 못하는지 말해주는 게 좋습니다. 

모든 프로젝트는 절대로 혼자의 힘만으로는 무수히 많은 난관을 헤쳐나갈 수 없습니다. 스스로 남에게 선의를 배풀면 다른 사람들의 도움을 언젠가는 도움을 받게 됩니다.

혼자 가면 그 순간은 빨리 갈 수 있을지 모르지만 여럿이 가야 오래 멀리 갈 수 있습니다. 프로젝트는 마라톤과 같습니다.

2. "○○○은 되던 데 우린 안 돼요?"

연예를 하면서, 또 부모님들에게서 자식들이 가장 상처가 되는 말이 있는데 그게 바로 남과의 비교입니다.

흔히들 말하는 "엄친아"라는 신조어도 어찌 보면 부모님들에게 보내는 자식들의 조롱에서 파생된 말일지도 모른다고 생각합니다.

현실 속에 있지도 않는 사람을 우리 엄마는 자꾸 자신과 비교하니까 자식 입장에서는 화가 날 수밖에 없는 것이죠.  사람의 성장하고 자라온 환경이 다르고 처해져 있는 조건이 다른데 처음부터 비교가 될 수 있을까 하는 의문이 생깁니다.

프로젝트를 하면서 ○○○는 되니 당연히 우리 서비스에도 그 기능은 되겠죠? 라고 묻는다면

질문자는 우선적으로 해당 질문을 하기 전에 스스로 먼저 점검해야 할 부분이 있습니다. 

• 현재 진행하는 프로젝트와 타 사이트가 비슷한 UI/UX 구조인가?
• 업무 환경 및 투입인원, 프로젝트 기간등 프로젝트 조건이 비슷한 환경인가?
• 해당 기능과 서비스가 우리가 추구하는 방향성과 맞는가? (단순히 멋있어 보이고 이뻐 보여서 해당 기능을 넣어주세요....라는 말은 제발 하지 말아 주세요.)

물론 충분히 구현 가능하고 프로젝트에 반드시 필요한 기능을 못한다고 한다면 그건 분명히 문제가 있지 위에 조건 중 어느 하나라도 다르다면 이야기는 달라지지만 맨먼스(Man/Month)와 업무 일정을 무시하고 무조건 내가 요구하는 건 무엇이든 만들어 내어라라는 말은 조금은 지양했으면 좋겠습니다.

3. "그거 꼭 해야 돼요?"

네. 네 고객님. 방금 질문하신 질문에 대한 대답은 "꼭 해야 됩니다!"입니다.

프로젝트 협업을 하면서 타 부서에 업무 요청을 부탁할 경우 스스로 판단하여 중요하지도 않은 거 왜 시켜? 라는 생각으로 저렇게 말씀하시는 분들이 계십니다.

하지만 조금만 생각해보면 같이 협업하는 사람들이 아무 이유 없이 업무를 부탁하지 않을 것이고 더욱이 자신의 파트에 대한 업무가 아닐 때 타 파트의 업무에 관해서는 중요도를 쉽게 판단하면 안 됩니다. 자신이 판단하기에는 별일이 아니어도 타 파트에서 해당 업무를 담당하는 사람에게는 굉장히 크고 중요한 일 일수도 있기 때문입니다. 

한 예로 IT에서 프로젝트르 할 때 디자이너가 버튼에 음영을 추가하거나 라인을 추가, 삭제하는 이슈,  버튼의 위치가 현재 위치에서 몇 픽셀(px) 떨어지거나 처음 디자인한 위치에서 이동하는 문제는 디자이너가 받아들이기에는 굉장히 중요한 문제일 수 있습니다.
하지만 디자인을 전달받아 작업하는 UI작업자는 "그게 그렇게 중요한가. 그것 때문에 작업한 거 다시 해야 돼?"라고 말하는 경우가 있는데 그건 스스로 판단하면 굉장히 위험합니다. 

어떤 프로젝트를 진행하더라도 각 파트마다 중요하게 생각하는 부분은 늘 존재하고 실제로 그 업무의 중요도를 해당 파트가 아니면 정확이 파악할 수 없기에 각 파트에서 작업 결과물에 수정이나 변경을 요구했을 때 스스로 판단하지 말고 서로를 존중하고 이해해주었으면 좋겠습니다. 작업하면서 짜증 내지 않는 건 덤입니다.(우선 저부터 반성하겠습니다.)

어느 파트이건 본인도 작업을 하다 보면 스스로가 신이 아닌 이상 실수나 추가 요청을 할 때가 발생하고 타 부서에게 수정 또는 요청사항을 요구할 때가 생기게 됩니다. 그러니 우리 너무 퍽퍽하게 굴지 말아요. 목막힙니다. 

4. "이건 간단하니까 쉬울 거예요."

타 파트에서 협업을 요청할 때 업무를 요청하면서 업무를 요청하는 사람이 스스로 판단하고 업무의 난이도를 판가름하여 "이건 간단하고 쉬울 테니 금방 할 것에요."라는 말은 굉장히 위험한 발언이라고 생각합니다. 

작업의 난이도나 작업 기간은 해당 업무를 담당하는 작업자가 체감하고 판단하는 게 맞지 업무를 전달하는 사람이 판단하는게 아니기 때문입니다.  같은 업무라 하여도 해당 작업자의 경력의 차이 및 경험 유무에 따라 부담감 및 업무의 난이도, 작업 속도는 당연히 차이가 있을 수밖에 없습니다.

경력 10년 차 셰프가 음식을 손질하고 만드는 속도와 경력 1년 된 셰프가 음식을 손질하고 만드는 속도가 같을 수 있을까?라는 질문에 대해 스스로 조금만 생각해 본다면 답은 이미 마음속에 그려질 거라 생각합니다. 

개인적인 생각으로는

“제 생각에는 ○일 소요될 것 같은데 조금 더 시간이 필요한 작업인가요?”라고 자신의 생각을 이야기 한 뒤 상대방의 의견을 들어서 시간을 조율하는 것이 서로를 배려하는 자세라고 생각합니다.

5. "그거 금방 되죠?"

음... 가끔씩 이런 말을 들으면 저도 뭐라 답을 드려야 할지 조금은 난감합니다. 

아주 금방 끝날 거라고 생각한 업무가 하루 종일 머리를 붙잡고 쥐가 나게 하는 경우도 있고 업무를 전달받고 고생하겠다고 생각한 업무가 몇 시간도 안 걸려서 깔끔하게 해결되는 경우도 있습니다. 

업무가 대략적으로 어느 정도 시간이 소요될지 예상은 가능하지만 예상은 예상일 뿐… 늘 현실은 날 비웃으며 나에게 고난과 시련을 던져주고 농락합니다.  그래서 저도 저런 질문을 받으면 마음속에선 '나도 해봐야 아는데..... '라는 답이 메아리칠 때가 있습니다. 

업무라는 게 사람이 하는 거고 사람과 사람과의 관계에서 가장 쉽게 신뢰를 쌓는 건 말이라고 생각합니다.
협업을 하는 쪽에서 따뜻한 말 한마디, 업무에 관련된 빠른 피드백을 해준다면 작업자 역시 작업에 몰두해서 아마 평소보다 높은 품질의 작업물을 받아볼 수 있을 거라 생각합니다. 

물론 빠른 작업 속도는 덤입니다. 

6. "그건 제가 좀 아는데

어느 유명하신 분께서 자주 하셨던 말씀이셨다고 합니다. (누군가 특정 인물이 생각난다면 그건 단순한 기분 탓입니다.)

 

"그거 내가 해봐서 아는데..."

저 말을 하는 대부분의 사람들 유형은 이론은 어딘가에서 들었는데 그 내용이 완벽한 지식이 아닌 경우가 많습니다. 본인이 업무를 담당할 예정이고 본인이 책임을 지는 위치라면 상관없지만 자신과 관계가 없거나 타 부서의 업무를 본인이 저렇게 판단해서 말을 한다는 것은 잘못되었다고 생각합니다. 

 

프로젝트를 하다 보면 때론 기술적으로는 충분히 할 수 있지만 해당 작업을 추가할 경우 프로젝트 일정기간에 차질이 생기거나 프로젝트의 성격과 맞지 않는 상황이라 판단할 경우 해당 작업자는 요청이 들어온 일을 거절하게 됩니다.
그때 불쑥 상황을 지켜보던 타 부서의 사람이 “그건 제가 좀 아는데..”라며 그 말을 던지고 사라지면 그 뒤에 다가올 엄청난 태풍은 생각하기도 무섭습니다.

본인이 책임질 수 없는 말은 안 하는 게 서로에게 좋다.

7. "그거 무조건 해줘요."

프로젝트를 진행하면서 앞, 뒤 사정 전혀 고려하지 않고 기존에 전혀 이야기되지 않았던 새로운 프로젝트 유형을 가지고 와서 추가해 달라는 경우가 간혹 발생합니다.  이때 일정은 촉박하고 업무의 진척도는 크게 진전이 없을 경우 참으로 난감한 상황이 됩니다. 

 

그럼에도 피할 수 없는 수순이라면 우선 이 프로젝트에서 새로운 프로젝트가 필요한 부분인지를 우선적으로 파악해야 합니다. 

그리고 해당 프로젝트를 진행할 경우 발생할 수 있는 모든 이슈를 반드시 기록을 남겨야 합니다. 

예로 특정 UI/UX가 맘에 들거나 좋아 보여서 신규 프로젝트를 요청할 경우 현재 진행하는 프로젝트와 추구하려는 "톤 앤 매너(Tone & Manner)"가 맞는지 확인하고 최종 담당자에게 “○○○를 추가할 경우 업무 일정이 늘어나고 전체적인 디자인과도 맞지 않습니다. 괜찮은가요?" 또는 "해당 기능을 추가하면 ○○○이슈가 있는데 괜찮은가요?”라고 물어봐서 조율을 하여야 합니다.

8.  그 외

프로젝트를 진행하다 보면 너무나도 다양한 이슈들이 발생합니다. 그래서 저는 업무에 있어서 가장 중요하게 생각하는 건 업무에 대한 히스토리 관리와 이슈 해결입니다. 업무 히스토리를 스스로 관리하면 추후 업무에 문제가 발생 시 또는 GUI 변경이나 기능의 추가, 삭제 시 자신이 적어두었던 히스토리는 큰 힘을 발휘하게 됩니다. 

어떠한 이유로 이렇게 진행을 했다는 히스토리는 인력이 교체되고 신규 투입되는 사람은 알지 못하고 자신의 업무 역할이 종료될 경우 다음 사람에게 업무에 대한 인수인계를 진행할 때에도 많은 도움이 됩니다. 

또한 프로젝트를 진행하면 서 이슈가 발생 시해당 프로젝트의 총책임자에게 반드시 이슈사항을 전달하고 공유해야 야만 나중에 생기는 문제에 대해서 본인이 감당해야 할 피해를 최소화하고 문제를 해결할 수 있습니다. 큰 프로젝트일수록 누가, 언제, 왜 그것을 진행하게 되었는지 굉장히 중요시 여깁니다. 반드시 메일을 통해 기록을 남겨놓는 게 좋습니다. 

 

모든 업무에 대한 기록은 스스로 업무를 돌이켜보게 되고 업무에 대한 이슈 상황에서도 유연하게 대처가 가능합니다. 오늘부터 간단히 하루에 대한 업무일지를 기록하는 것은 어떨까요?

 

긴 글 읽어주셔서 감사합니다.