프로젝트를 하며...느낀점(추가수정)

 

 

 

프로젝트도 벌써 크고작은것 포함해서 3~4개정도 되는 것 같다. 

이번에 하는 프로젝트는 정말 너무 고되고 힘들고, 힘들면서도 인정은 못받는 그런 요새용어로 치면 ㅊㅎㅌㅊ 인듯.....

 

하는 동안 느낀점을 혹시 나중에 잊을까 해서 정리해 둔다.

 

 

1. 프로젝트는 시작부터 Clean 해야 한다.

: 프로젝트를 하는 필요성, 목적, 인원구성, 공수산정, 일정 도출, 범위, 성공의 정의 까지.... 규정대로 정확히 그리고 다소 여유롭고 Clean하게 구성되어야 한다.

 

2. 가급적 연초에 하는것이 좋다.

: 어차피 프로젝트를 한다고 해서 기존에 하던 일을 빼줄 경우는 거의 없을테니.... 가급적 연초에 시작해서 빨리 끝내는게 이롭다. 

  연말까지 이어지는 프로젝트를 하다보니... 고갱님들이 MBO성 IT 개선요청을 모아모아 던져주셔서 너무 힘들다.....

 

3. 프로젝트 팀 구성은 객관적으로, 그리고 제품을 쓸 수 있으면 쓰도록.

: 프로젝트를 할 때 솔루션 패키지를 구입해서 구축하는 경우도 많다. 나는 이것이 부정적이라고만은 생각하지 않는다. 

솔루션 패키지를 씀으로서 당분간은 해당 패키지에 대한 이해도를 높이기 위한 시간이 소요되겠지만, 그만큼 쌩바닥에 박치기 했을때 발생할 수 있는 많은 문제들이 

이미 고려되어 있기 때문에 그로 인한 시간적/인적 비용 절감도 무시 못한다..

기술이 되고 자신있으면 생짜 개발도 좋겠지만, 그럴 자신 없거나 짧은 개발 기간인 경우는 솔루션 도입이 효율적일 수 있다.

그리고 팀 구성을 할 때에도,(혹은 외주 개발자를 쓴다고 할 경우에도) 과연 역량이 있는 사람인지를 확실히 검증해서 투입한다.

누가누가 아는 사람이니 잘 하네.... 이런거 안된다....

 

4. 프로젝트 관리 툴은 반드시 필요, 그리고 항상 툴을 통한 업무 진행을 하라.

: 물론 대부분 툴을 하나정도는 (쉐어포인트나 뭐 그런거) 쓰겠지만... 소규모이거나 회사에 따라 또는 PM에 따라서 메일을 통한 진행을 하는 경우가 있다.

이러면...물론 PM이 정말 강인한 정신력의 소유자라서 모든걸 다 컨트롤 할 수 있으면 문제는 없지만, 대부분의 경우 파탄이 난다..

(일정관리는 별도 엑셀로 한다던지, 진행을 급한 순서대로 한다던지... 하다가 뭘 빼먹는다던지..)

정 안되면 Trello같은 간이 툴이라도 써서,.. 해야할 일과 중요한 일을 구분해서 진행해야 한다..
  - 2021년 추가 : 커뮤니케이션 툴 역시 필요.. MS Teams는 동기화때문에 비추. 이거보단 걍 공유폴더가 낫다. 코로나로 인한 화상회의에 필요한 메신저 그리고 화상/음성 장비 역시 필수. 좋은걸로 사자..

 

5. 테스트는 가능한 실제 시스템과 병렬로 되도록 많은 인원이 참가하도록..

: 테스트 기간은 가능한 길게 잡는다. 그리고 가능한 많은 인원을 참여 시키고, 가능하다면 고갱님의 회사 중 높은분(...)의 위엄을 빌어서 강제로 테스트를 시킨다.

실제 과거 운영하던 시스템이 있다면 병행해서 Open하여 동일한 프로세스로 진행해 보게 한다면 더욱 좋다.

별 문제 없겠지 하던 부분에서 까지 수 많은 생각지도 못한 오류가 쏟아져 나올 것이고, 그것만 다 잡는다고 해도 실제 오픈시 더이상 야근할 필요는 없을것이다.

 

6. 오픈 후 오류사항이 발생할 경우 전담 조직을 만든다.

: 작은 프로젝트나, 운영성 개발 프로젝트에서는 좀 힘든 일일수 있겠지만 반드시 필요하다. (내가 겪었던) 대부분의 프로젝트에서는 오픈하자마자 전화통에 불이 난다.

사용자가 많을수록, 그리고 그 사용자가 무기명 다수인 경우 더욱 그러하다. 심한 경우는...아침 9시부터 오후 6시까지 전화만 받고 대응하고 메일 회신 대응하다가 하루가

다 가버리는 경우도 있다. 이 경우 낮에는 응대, 저녁에 개발 보완 및 디플로이, 밤에 기존 업무 밀린거... 하는 형식이 되고.... (그리다 피로 누적되어 아프거나 퇴사하겠지)

그러니 오픈 전에 미리 그런 조직구성을 해서, 전화받을 애는 전화를 받아서 정리해서 QA로 넘겨 주고, QA에서는 로그뜨고 분석해서 개발에 보완 지시하고, 보완이 완료 되면

테스트 담당이 다시 한 번 테스트를 하고, 디플로이를 하는 형식으로 돌아가야 한다. 그리고 모든 내역은 Tool로 정리되어 PM이 확인 및 이후 추가 보완 대상을 추출할 수 

있어야 한다.

(근데 이런 프로젝트를 아직 본적이 없네.....ㅎㅎㅎㅎ 1개 빼고..)

  - 2021년추가 : 이슈와 리스크의 정의를 하고, 여기 해당되는 상황이 발생되면 보고하고 이슈화 하는 체계가 필요하다. 대충 뭉게고 있다가 골로간다....... 

 

7. 고갱님과 커뮤니케이션을 맡아줄 IT를 잘 아는 PI조직은 필수이다.

: 프로젝트의 범위, 구현 가능한 기능의 설명, 고객 요구사항의 적절한 커트, 테스트 독려, 문제점 리포트, 변화관리, 기존시스템과의 교체방법 검토 등등...

이 모든걸 PM이 다 하기엔 너무나 벅찬일이며, 한다 하더라도 결국 입장이 다르기 때문에 나중에 뒷소리가 나올 가능성이 높다...그러면 정말 잘 해놓고 또 욕듣는 상황이 되니..

가급적 IT를 잘 알고, 고객을 잘 컨트롤 할 수 있는 고객사의 PI조직이 있어야하며, 사전에 이러한 PI조직과 프로젝트 전반에 대한 논의와 검토가 충분히 진행 되어야 한다.

 

 

8. 기타의 팁(?일까...힘들게 살려면 아래와 반대로 해보면 되겠다)

   a. 남이 하던 프로젝트를 물려받는 것은 가급적 지양... 뭔일이 있을지도 모르고, 프로젝트 시작부터 어떤 비하인드 스토리가 있었는지도 모른다...
      고생은 고생대로 하고 성과는 없을 가능성이 다분.

   b. 사용자가 많고 사용자의 IT숙련도 이해도가 낮은 시스템일수록 개발도 힘들고 운영도 힘들다.

   c. 내가 처음 접하는 플래폼이나 언어로 개발되는 프로젝트에 참여하는순간...힘들다.(자기 개발은 된다..)

   d. 프로젝트 들어가기 전에 본인이 거기서 뭘 할건지? PL인지, 개발자인지, 테스터인지, 명확하게 PM과 업무의 영역을 정하고 들어가라. 

      그렇지 않은순간... 잡부가 되어 이거저거 시키는거 하다가 결국은...

   e. 추가 예정..

 

9. (2019년 추가) 업무는 다 떼놓고 와라!

: 옛날에는 그냥 당연히 그렇게 생각해서 안썼는지.... 요번에 느낀 것은 프로젝트시 기존 업무는 다 던져놓고 와야 한다는 것. 

운영하던 사람이 프로젝트에 들어가면서 기존 운영업무는 부사수에게 일정부분 주고 소위 반공수로 프로젝트 들어오는 경우가 많은데.... 이렇게 되면 이도 저도 집중하지 못하는 경우가 발생한다. 부사수는 아직 일이 서툴러 계속해서 문의메일과 전화를 해대고, 프로젝트 사이트에서 기존 업무를 하긴 눈치가 보이니 퇴근이후에 숙소에서 일을 하고.... 물론 이렇게라도 근무외시간에 처리를 해 왔지만 이제는 52시간 시대.. 프로젝트 시작전 부터 이런 기존에 맡은 업무는 모두 넘기고 프로젝트에 임해야 하겠다. 

(근데 그게 내 맘대로 안된다는게 문제지 ㅎㅎㅎ... 아직도 소위 0.5 공수가 존재하는 것 부터가......)

 

10. 장기 프로젝트일 경우 건강관리가 무엇보다 중요하다

: 서너달이 넘어가는 장기 프로젝트인 경우 건강이 얼마나 중요한지 느끼게 된다. 집떠나면 고생이라고 특히 타지 출장 프로젝트인 경우....

매번 사먹게 되는 식사(물론 기름기와 알코올은 덤) + 불편한 잠자리 + 불규칙한 퇴근 + 운동 부족(매일 사무실에...) 이 합쳐지면 소위 '골병'이 난다.

이런 부분은 프로젝트 처음 부터 식사에 대한 스스로의 그라운드룰(예를 들면 주에 최소 두세번은 샐러드등 채식을 먹는다던지..)을 세우고, 헬스라도 등록하거나 정 안되면 코스를 정해서 자전거나 걷기를 한다던지, 수면은 무슨일이 있어도 10시까지 잔다던지....를 의식적이라도 노력해야 한다.

잠자리의 경우 제일 좋은것은 사실 전/월세로 모든것이 다 갖춰진 오피스텔이나 원룸을 구하는 것인데, 회사가 그런 좋은 조건으로 구해 주지도 않을 뿐더러.....

사실 신기하게도 이런 직원의 복지를 생각해야할 회사의 담당 부서는 이러한 장기 출장의 어려움을 공감하지 못하는 경우가 대부분이다. 누구나 본인이 닥쳐보고 당해봐야 '아 그랬구나' 하는 것이라......(그래서 회사의 총무/HR부서 인원은 현업에서 오랫동안 운영도 해보고 프로젝트도 해 본 인력들로 채워져야 한다!!) 

어쨌든.. 이번 프로젝트를 그래도 만만히 생각하고 이런 저런 지원이 부실한 것을 감안하고 지원했건만.... 해보니 느낀 것은 '가능한 하지 않을수 있으면 하지말자' 다. 현재까지는 ㅎㅎㅎㅎㅎ

 

11. WBS를 짤때부터 연관된 모든 인원과 함께 시간을 들여 정확히 작성하자

 : 어차피 신이 아닌이상 WBS를  완전 정확하게 작성하긴 불가능.... 하지만 그렇다고 대충 WBS 내세요 해서 취합해서 한팩으로 만드는 것은 꼭 나중에 탈이 난다..... 반드시 시스템 또는 영역별로 WBS를 작성한 것을 가지고 PM과 동석하여 시간을 들여 인터뷰 하여 정합도 또는 생각지 못한 부분들을 가능한한 자세히 체크해야 한다.

그리고, WBS는 PM입장에서도 설명할수 있게 쉽게 써라.....영어로 유식하게 써봤자.. 시스템 담당자 밖에 모른다. 고객의 궁금증이 안생기도록 해야한다.

 

 

12. 사기 진작을 위한 여러 방안 생각 필요.

  : 장기간 서로 처음보는 확률이 높은 인원들이 한공간에서 하는 것이다 보니... 사기진작등이 필요하다. 작게는 프로젝트 룸에 놓아둘 과자 음료라던지, 정기적인 회식,  크게는 프로젝트 룸 자체(공간넓이, 위치, 회의공간, IT장비 등) 까지.... 프로젝트 원에 대한 대우에 신경쓸 필요가 있다.

본인들이 대우받고 있는지 아니면 그냥 몇 M/M의 공수로 취급당하는지에 따라서 프로젝트의 분위기 그리고 효율은 달라진다. 이는 회사의 경영관리팀 등은 '당연히'모르며(아니 근데 이걸 왜 당연히 모르지?????...) 이런 부분을 인정하려 들지 않는다(왜? 그건 결국은 다 돈이 드니까..ㅎㅎ)

PM은 이런 부분을 이해시키고, 회사 규정 내에서 혹은 규정 밖이라도 최대한 쾌적한 프로젝트가 될 수 있도록 노력할 책임이 있는 것이다...

 

 

13. 프로젝트가 끝나면 꼭 복기하라..

  : 대부분 프로젝트가 명목상이든 실제든 '성공'으로 끝나지만, 프로젝트 구성원들은 안다. 이게 성공인지 절반의 성공인지 실패인지.

이러한 프로젝트 인력중 외부인력(컨설턴트/외주개발자)은 그냥 프로젝트하고 나가면 끝이라고 생각하는 분도 대다수여서 이런 분들에게까지 레슨런드를 기대하긴 힘들다... 하지만 PM급으로 이 프로젝트에 관련된 내부인력들은, 프로젝트의 부족한점, 잘했던점 들을 복기하는 시간을 인위적이라도 가지고, 추후 다음 프로젝트에서는 개선할 수 있도록 해야 한다. 보통 이게 잘안된다....(프로젝트 끝나자마자 또 프로젝트 ㅎㅎㅎㅎㅎ 사람도 좀 쉬어야지 ㅅㅂㄹ 들아)

요새 추세는 프로젝트 끝나면 회사 내부 게시판에 '우리 이렇게 잘했답니다 홍홍' 하고 자랑하는거 같은데..... 뭐 굳이 부정적으로 생각하거나 하는건 아니지만 이 부분에 자랑뿐 아니라 부족헀던 점 위주로 적어서 공유해 주는것이 더 좋지 않을까 한다. 회사에서 하는 프로젝트는 돈을 벌어오는 일이지만 그래도 크게 보면, 회사 인력과 시간 금액을 투자하여 회사차원에서 큰 경험치를 먹는 일이며 이 부분은 구성원들에게도 공유가 되어야 한다. 

 

 

 

14. 구성원들이 해야할 일은 사전에 Planned되어야 한다

 : 보통의 프로젝트에서는 WBS를 초반에 만들고, 담당자들이 각자의 프로젝트를 진행하고 중간에 통합테스트 후 오픈준비, 컷오버 및 오픈을 하게 된다... 

그런데 프로젝트 전체적으로 보면 사전에 협의된 산출물(메뉴얼 포함) 및 고객이 시시때때로 요청하는 각종 자료들이 있다... 

이런것은 대부분 고객의 상위부서에 보고해야하는 용도가 많으며, 담당자들 입장에서는 이런것이 소중한 프로젝트 시간을 뺏는 가치없는 일로 느껴질 수가 있다.... 그리고 물론 이런 서류 작업 장표작성하다보면 힘이 빠지기 마련....

그러나 이런 서류 작업을 하지 않을순 없으니, 그나마 사전에 각종 작성할 자료들을 미리 (최소한 2주전) 알려주는 것이 서로를 위해 좋다. 

PM입장에서도 고객에게 사전에 이러한 부분이 필요함을 알려서, 최소한 오늘 메일보내고 오늘 퇴근전까지 ASAP으로 주세요하는 것은 없애려 노력해야 한다.

 

 

 

15. 각자의 Role은 정확하게, 담당자도 정확하게, 그리고 모든 역할을 공유해라.

  : 프로젝트 하다보면 여러가지 사유로 담당자가 갑자기 바뀌는 경우가 많다. 특히 골떄렸던 경우는 담당자의 퇴사(...)...

그런데 퇴사건 뭐 개인사정이건 간에, 담당자가 바뀌는 것은 그 담당자의 팀원이나 팀장은 이미 미리 알고 있는것이다...PM과 고객만 모를뿐 ㅡㅡ...

프로젝트 초기부터 각 시스템, 연관된 업무별로 Role을 정확히 매핑(절대 빈칸이 있으면 안된다)하고 당사자들까지 모두 해당 Rolebook을 공유해야 한다. 나중이 되어서 '어 저사실 이거 잘 모르고요..' 또는 '사람이 없어서 제가 잠시 지원해드리는거고요' 이런거 안된다....... 담당자 없으면 바로 이슈화 해서 담당자를 정하지 않으면 나중에 속 깨나 썩일 것이야 ㅎㅎㅎㅎ

 

 

16. Communication에 대한 Ground Rule은 필수

 : 성향이 다 다른 사람들이 모여 프로젝트를 하는 것이기에, 서로의 성향에 따라 커뮤니케이션 방식도 다 다르다....

어떤 분은 메일로만 보내고, 어떤분은 계속 직접 찾아와서 구두로 얘기하는걸 좋아한다. 어떤분은 카톡..(...)...

이런 부분에 대해 통일하여야 할 필요성이 있다. 특히 내부 인력에 해당되는 얘기로, 위에 나처럼 기존 업무를 떼지 못하고 프로젝트에 들어오는 경우... 마감기간이 되면 기존 업무가 우선이 된다.. 프로젝트 요청사항 메일을 읽을 시간이 부족하고 답변도 느려지게 된다...ㅠㅠ

프로젝트에선 내가 아니면 다음 타자도 기다리고 있다는 것을 항상 명심하고, 메일의 경우 몇시간내 회신하는 등의 그라운드룰을 꼭 정해야 한다. (안정해도 알아서 잘 돌아가는게 제일 이상적이긴 하다..)

 

 

 

17. 시스템별 특성을 잘 확인하라

: 예전과 달리 요즘은 내부 시스템이라도 Turnkey로 넘겨 운영되는 경우가 종종 있다. 즉 정규직은 인력관리만 하고, 시스템운영은 외주 직원이 통으로 하거나 외부 업체가 하는 경우.....

이런 시스템은 특히 요주의 시스템으로 지정하여 프로젝트에서 특별히 잘 관리해야 한다. 다 그런것은 아니지만 정규직의 경우 어떻게든 프로젝트에 맞춰 진행하려 하는 반면, 외주 직원이 운영하는 경우는 프로젝트에 대한 리소스 투입 자체의 우선순위가 없거나 아니면 일반 운영과 동급으로 생각하는 경우도 많다.. 그리고 외주 운영의 경우 시스템에 대한 의사결정권이 없기에 논의나 협의 역시 적극적일수 없어 시간이 지체되는 경우가 많다..

 

 

18. 각종 Template는 미리 정리되어야 한다.

 : 각종 산출물마다 정형화된 양식을 마련해 놓아야 한다. 물론 PM이 단독으로 정할수 있는것 외에, 고객과 연관되는 것은 고객의 협의를 거쳐 프로젝트 초기에 모든 양식을 미리 준비해 놓아야 한다. 추후에 담당자별로 자기만의 양식으로 작성하기 시작하면 글세.....그거 고쳐달라고 하면 좋아할까요?

아마 프로젝트 뒤로 가면 갈수록 고쳐달라 하지 못하고 결국 PM이 수정하고 있을 가능성이 높다.....

양식(폰트 포함) 은 반드시 중앙에서 미리 작성하여 배부할수 있어야 한다. 

 

 

19. 프로젝트 전반에 영향을 끼칠수 있는 시스템은 프로젝트 일정 단계에서 부터 별도 관리가 필요하다.

: 예를 들어 한 회사의 시스템 전반을 구축한다고 하자.. ERP며 비용시스템, MES, ITSM, EHS, HR, 등 많은 시스템이 있을것이다. 프로젝트 마다 다르겠지만 이 시스템 단위 중에서 타시스템과 연관성이 큰 시스템들은 처음 일정 구성때부터 별도로 관리가 필요하다. 

예를 들면 인사시스템과 이메일이다. 이런 시스템들은 나머지 시스템에 기준되는 데이터를 생성하여 내려주는 역할을 하는데, 이러한 시스템이 구축중에 중간에 뭔가 변수가 있어서 스펙이 바뀐다? 프로젝트 초반이면 다행이겠지만 막판가서 이러면 재앙이 따로없다...... 프로젝트 연기까지 고려해야 한다. 

시스템단위가 아닌 더 큰단위에서는 보안, 인프라(네트워크 서버 등)이 여기 속한다.. 특히 보안... 왠만하면 이러한 인프라 보안쪽이 모두 구축되고 난 이후에 어플리케이션 구축을 하도록 하자...WBS자체를 그렇게 잡자. 병행해서? 하는거 강력 비추한다.

 

 

20. 업체는 잘 고르자.

: 아마 이런 프로젝트 할 때 많은 업체를 고려해 볼것이다. 안전하게 다들 기존업체와 하려는 이유가 다 있다...사실...

그런데 만약 신생업체와 같이 해야 한다고 하면, 가능한한 모든 수단을 동원해서 Crosscheck하도록 하자. 컨설턴트들한테 물어보던 개발자한테 물어보던 아니면 너네 구매팀한테 알아보라 하던간에.....

이상한 업체는 생각보다 많다.....

 

 

 

21. 프로젝트 인력에게 인센티브는 필요하다.

  : 이건 다른 꼭지로 별도 작성

 

22. 프로젝트원들의 IT적인 준비 및 문제해결을 해줄 IT 코디네이터는 필수

: 왠만한 회사에는 이미 정형화된 많은 IT 거버넌스들이 존재한다.. 계정생성, 보안설정, 각종 프로그램 설치, DLP, EDR, 그리고 프린터 사용, 팩스 사용까지...... 

이 모든 것을 프로젝트를 하러 처음 이 사이트에 온 컨설턴트/개발자를 위해 준비하는 일 자체가 쉬운일이 아니다. 물론 이런 모든건 대부분 큰 기업에서는 별도의 담당 업체가 있기도 하지만...없다면?

당신은 그냥 프로젝트 초반 대부분을 이런 PC 봐주는 사람이 될수도 있다...