Search

반응형

'프로젝트'에 해당되는 글 4건

  1. 2021.09.26 [심리]자신의 능력을 다스리는 기술
  2. 2021.01.04 [서평]PM필독서, 프로젝트 관리자를 위한 PMBOK 활용, 나피엠, 문대현 지음, 비팬북스
반응형

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

최근 원치 않은 통보성 프로젝트에 참여하게 되었습니다.

상황 판단을 빨리 하고 할 일에 대해 적극적으로 대처하다 보니

한달동안 지연 된 이슈들이 일주일 내로 하나씩 정리가 되고 있는 상황입니다.

일을 하면서 느끼는 점은 

정말 사람들이 적극적으로 진행하지 않는다는 부분입니다.

이 적극적이라는 표현이 정말 쉽게 되는 부분이 아니라는 것을 이번에 절실히 느끼게 되었답니다.

 

신입사원과 같이 일하게 되었습니다.

역시나 회사에서 들은 부분과 다른 점이 있더군요.

어떻게 같은 직원한테까지 뻥튀기를 하는지 ㅎㅎㅎ

입사한지 1년이 넘었지만 정말 아는 것이 거의 없고

기초도 없는 그런 친구였습니다.

하~

그래도 직원이라 같이 진행을 해야겠지요?

그래서 몇가지 조언도 해주고

주말에 공부도 하라고 했습니다.

정말 이쪽 방면으로 잘 되고 싶었다면

이런 좋은 기회를 잘 잡아서 주말이든 추석 연휴든 열심히 공부를 했어야 하지만...

그러지 않더군요.

기회가 항상 오지 않는다고 그렇게 얘기 했는데...

잘하고 싶고 성공하고 싶다면..

기회를 놓치지 말고 항상 적극적으로 준비를 하고 있어야 합니다.

놀거 다 놀면서 어떤 발전이 있기를 바라는건지 이해가 안되더군요.

이렇게 신입 사원만의 문제는 아닙니다.

일전 프로젝트에서 프론트엔드와 백엔트의 구분 없이

개발자들에게 메뉴 단위로 업무를 분장하고 일정 관리를 하고 있었습니다.

당연히 개발 진행이 지연이 발생할 수 밖에 없는 구조였지만

PL은 예전 방식만 생각하고 그저 밀어 붙이기만 하고 있더군요.

그래서 제안을 했습니다.

프론트엔드, 백엔드 자체를 이해를 못하는 상황인듯 해서

그냥 화면단과 비즈니스단을 한명이 하지 말고 분담해서 하면 

개발 속도만 봐도 많이 좋아질거라고 조언을 했지만

모두들 시큰둥 하더군요.

지금 생각해보면 그런 전문성에 대해 전혀 아는 상황이 아닌

주먹구구식 개발과 일정 진행에 길들여져있던 상황이었던거 같았답니다.

 

그래도 혼자라도 그렇게 해보면서 보여주고 싶었기에

프론트엔트와 백엔드를 구분해서 직원 한 명과 같이 작업을 했습니다.

 

결과는 우리 둘은 일정내 미리 정리가 되고 심지어 다른 개발자들의 지연건까지 지원하게 되었고

당연히 야근 없이 잘 진행하게 되었습니다.

메뉴 단위로 풀 진행을 하는 개발자들은 매일 야근에 일정도 못맞추면서 지연되고 있었구요.

이번 프로젝트에서도 또 어처구니 없는 상황이 발생하게 되었답니다.

잘 알지도 못하면서 휩쓸려 다니면서

말도 안되는 일정과 통보성 진행에 또 마찰이 발생하게 되었답니다.

 

원활한 프로젝트 진행을 위해서는 충분히 준비해서 

각 팀원들의 능력이 최대치가 될 수 있도록

해야하지 않을까 싶네요.

 

완벽한 사람은 없습니다.

하지만 적극적으로 자신의 일에 대한 준비를 한다면

실수가 최소화 되고 일의 흐름이 매끄럽게 진행되는데

왜 고지식한 생각과 쓸데없는 고집과 아집으로

다른 팀원들에게 피해를 주고

프로젝트 전체에 문제를 만드는지..

그게 결국 회사에 큰 피해를 준다는 생각은 안하는지

모르겠네요.

그렇게 사고 치고는 결국 남탓으로 돌리면서

쏙~ 빠져나가는 관리자들은

정말 퇴출되어야하지 않을까 생각됩니다.

꼰대, 노땅이 괜히 나오는 표현이 아니랍니다.

신입이든 관리자든

다들 자신의 자리에 제대로 된 역할을 하기 원한다면

적극적이고 최선을 다하는 자세가 필요해 보입니다.

 

 

 

반응형
반응형

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

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

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

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

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

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

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

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

 

 

PMBOK는 사실 가이드입니다.


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

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

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

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

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

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

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

다들 열심히~~

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

 

반응형