신기한 연구소

안녕하세요. 신기한 연구소입니다.

IT 프로젝트를 시작한 지 벌써 20년을 훌쩍 넘었네요.

처음 개발자의 길을 걷기 시작할 때는 그저 눈앞에 보이는 프로그램만

열심히 만들었던 기억이 있네요.

출퇴근하는 지하철에서도 소스를 분석하고 

밤에 집에서도 내일 할 일에 대해 미리 준비도 하고 검색도 하면서

밤을 하얗게 지새웠던 기억이 있습니다.

그렇게 정직원과 프리랜서를 넘나들면서

열심히 일을 하다가 어떤 회사를 입사하게 됩니다.

개발자로, PL로, PM으로 다양하게 SI 프로젝트도 SM도 진행을 했고

지금도 꾸역꾸역 다니고 있답니다.

최근 팀원으로 프로젝트를 진행하면서 PM과 PL들을 만나게 되었답니다.

그들의 일하는 모습을 보면서 많은 것을 깨닫게 되었는데요.

단순히 팀원으로 활동한 이번 프로젝트에서

오히려 3자의 위치가 되어 많은 것을 배우게 된 좋은 시간이 되었답니다.

지금까지 PM/PL 역할을 하면서 나름 기준을 정하고 

잘하고 있다고 생각을 했지만 팀원의 입장으로

그들을 만나니 내가 참 부족한 부분이 많았다는 생각을 했습니다.

그 부분에 대해 이번 포스팅에 다뤄볼 생각이고

현업에서 PM/PL 역할을 하는 분들이 조금이나마 도움이 되길 바라며

시작해보겠습니다.

1. 하지 말자.

무엇을 하지 말까요? 일은 해야겠지요. ㅎㅎ

우선 PM/PL은 팀의 리더이므로 간단히 리더라 통합해서 칭하겠습니다.

리더는 자기 자랑을 프로젝트 내에서 하면 안됩니다.

자기 자랑은 한다는 것은 착각에 빠져 있는 것이고

누군가 칭찬하거나 인정해 준다면

겸손한 마음으로 받아들이고 더 부족한 부분이 없는지 확인해봐야겠지요.

그리고,

팀원들의 험담을 하지 마세요.

사람이 모두 같지는 않습니다.

능력도 다르고 부족한 부분도 많지요.

물론 팀 업무에 차질을 주는 팀원도 있을 겁니다.

험담보다는 직접 가서 주의를 주는 것이 어떨까요?

2. 욕심은 버리고 성취감도 버리고 의욕도 버려라.

이건 또 무슨 말일까요?

욕심을 버리라는 말은 알겠는데

성취감과 의욕까지 버리라는 건 어떤 의미일까요?

자기 계발에 대한 욕심은 챙기는 것이 좋습니다.

하지만,

리더가 성취감에 빠지고 의욕이 넘쳐난다면

팀원들은 정말 힘든 시간이 됩니다.

리더는 팀을 이끄는 사람이고

팀원들이 좋은 환경에서 제 실력을 충분히 발휘할 수 있도록

도와주는 역할을 해야 합니다.

자기의 성취감에 빠져 산다면

고객의 무리한 요구사항과 일정을 받아서

내가 어려운 환경이지만 이루고 말겠다는 아집이 발생하고

오버된 업무를 받아주느라 늦은 시간까지 정리하고

진행을 맡기게 됩니다.

그렇다면 그 업무는 리더 혼자 하는 것인가요?

아닙니다.

리더는 팀원들의 능력을 활용해서 자신의 욕구를 충족시키는

불편한 상황이 발생하게 됩니다.

리더가 욕심부리고 일을 맡게 되면 야근과 주말근무를 하게 되고

팀원들 또한 눈치가 보여 퇴근길이 망설여지게 됩니다.

3. "당연"이라는 말은 삼가세요.

뭘 자꾸 하지 말라고 표현하게 되네요.

이 당연이라는 단어가 정말 무서운 말이 됩니다.

SI 프로젝트는 당연히...

오픈 시점엔 당연히...

주말에 나오는 건 당연히...

이런 말을 하는 리더는 자격이 없다고 봅니다.

그러기 전에

팀원들을 살펴야지요.

어쩔 수 없는 경우는

먼저 챙겨줘야 합니다.

주말에 나오는 것을 당연히? 그 정도는 희생해야?

이런 표현보다는

이런저런 사정이 있어서 주말에 불가피한 출근이 필요한데

도움을 주시면 감사하겠습니다.

당연히 주말 출근에 대한 보상으로 대체 휴무는 지원해 드립니다.

또한 식사와 간식 등도 제공해 드리니

불편하겠지만 여러분들께서 도와주시면 감사하겠습니다.

이렇게 표현을 하는 게 맞다고 생각됩니다.

당연히 나와야죠.

오픈인데 당연히 주말근무입니다.

그리고 누군가 주말 근무 보상에 대한 문의를 한다면

1. 당연히 대체 휴무와 식사 등 제공으로 보상해 드립니다.

2. 음..(머뭇거리기) 그건 PMO에 문의해보세요. 하지만 당연히 출근해야 합니다.

여러분이 혼자 하는 프로젝트가 아니라

팀원과 함께하는 프로젝트라면 1번처럼 답변해야 한다고 생각됩니다.

이번 프로젝트에서는 리더들이 보통 2번처럼 응대를 하길래

깜짝 놀랐던 기억이 있습니다.

처음부터 효율적으로 운영하고

현업의 무리한 요구와 일정은 리더가 잘 조정하고

팀원들이 최대한 효율적이고 즐거운 분위기에서

근무할 수 있게 도와주는 것이 리더의 역할이라 생각됩니다.

어쩔 수 없이 추가 요구를 받아야 한다.

일정은 그대로 갈 수밖에 없다.

그래서 야근과 주말 근무는 해야 한다.

이렇게 하는 건 누구나 할 수 있답니다. 리더님들..

혼자 똑똑하고 잘났다고 자랑한다고 일이 절대 잘 되지 않습니다.

리더는 팀원들을 이용하면 안 됩니다.

팀원들에게 일을 시키지 마시고

그들이 알아서 일을 하도록 환경을 만들어 주셔야 합니다.

그래야 팀원들에게 존중받는 리더의 자격이 생기는 겁니다.

결코 현실적으로 쉽지 않습니다.

하지만 같이 가야 한다면

같은 배를 탔다면

리더라면 그리 하도록 노력해야 됩니다.

이번 프로젝트는 서로 책임 회피와 비난이 남발하는 좀 힘든 프로젝트였지만

그런 부분에 대해서도 배울 수 있는 영역이 생긴다고 봅니다.

허세, 자만심 그리고 욕심이 

팀원들을 무시하고 이용하게 되면서

프로젝트에 어떤 영향을 끼치게 되는지

이번에 많은 것을 배우게 되었습니다.

다음에 리더로서 기회가 된다면

좀 더 발전된 모습의 리더가 되고 싶네요.

안녕하세요. 신기한 연구소입니다.

많은 크고 작은 프로젝트를 하면서
일정과 산출물로 고생했던 기억들이 많습니다.

특히 산출물은 추후 유지보수를 위해서는
제대로 잘 작성되면 좋습니다.

보통은 기존 프로젝트나
또는 다른 곳에서 사용했던 문서를
수정해서 사용하곤 하는데
엉터리인곳이 종종 있답니다.

산출물 자체를 전혀 활용하지 못하는 경우도 있어서
별도의 인수인계문서를 만들기도 합니다.

사실 개발자로, pl로 투입돼서
산출물 작업을 하면
이런 쓸데없는 문서를
왜 만드는지 이해가 안 되는 경우도 있었고요.

문서뿐일까요?
PM의 역할이 부족해서
프로젝트가 산으로 가는 경우도 본 적이 있답니다.

작거나 큰 프로젝트에
pl 또는 pm의 역할을 하신다면
나피엠, 문대현 님이 지은
프로젝트 관리자를 위한 PMBOK(PROJECT MANAGER BODY OF KNOWLEDGEMENT)를 추천해봅니다.

PMBOK는 사실 가이드입니다.

이 가이드를 참고로
프로젝트를 진행한다면
많은 도움을 받을 수 있겠더군요.

나피엠님과 문대현 님 두 분은
국내 다양한 크고 작은 프로젝트의
경험을 바탕으로
이 책을 썼기에
공감되는 부분이 많더군요

내용이 좀 딱딱한 부분이 있지만
소설책이 아닌지라
최소 5회 정도는 정독을 해야 할 듯합니다.

꼭 pm, pl이 아니더라도
프로젝트 개발자라면
읽어보시길 추천합니다.

권위적이고 강압적인 pm이 아닌
배려하고 공감대를 잘 형성하고
특히 다양한 참여자들 사이에서
의사소통을 잘해서
프로젝트가 성공적으로
끝날 수 있게 관리하는 게
pm이 아닐까 생각해봅니다.

지금 2 회독 중인데
최소 다섯 번은 읽을 계획입니다.

성공적인 프로젝트를 위해서

다들 열심히~~

아래 하트(공감) 버튼을 눌러서 더 다양한 글을 쓸 수 있게 응원 부탁드립니다. 감사합니다.