프로젝트 관리자(PM)를 위한프로젝트 관리 이야기

프로젝트 관리자(PM)를 위한프로젝트 관리 이야기

저자: 신진현

출판사: 한빛미디어

---

개발자가 회사생활하면서 겪을 일들을 저자가 직접 경험한 내용을 재미있는 에피소드로 잘 정리해주신 책입니다.

보면서 중요하다고 느껴지거나, 기억하고 싶은 부분을 형광펜으로 색칠하면서 읽었는데요.

그 부분을 글로 정리하려고 합니다.

아래 내용은 책에서 발췌한 내용입니다!

---

다행스러운건, 근래 들어 개발자의 가치가 올라가고 있다는 점이다.

이 책은 개발자를 위해 썼다.

초급: 신기술에 대한 강한 욕심이 있고, 자기가 만든 결과물에 대해서는 큰 자존심을 갖고 있으며, 책임감을 똘똘 뭉쳐있다.

중급: 다른 개발자의 설계를 이해할 수 있어야 한다.

개발자가 개발에 전념할 수 있는 환경

사용자는 요구사항을 기르는 토지다. 씨를 뿌리고 길러서 수확하는 것은 프로젝트 팀의 몫이다. - 소프트웨어 프로젝트 생존 전략 (스티브 멕코넬, 인사이트)

[ISO 9126] - 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성

사람관리, 위험관리, 의사소통

팀원을 잘 관찰해 팀원의 능력을 파악해야 한다.

팀원에게 팀의 비전을 제시하고 개인의 비전을 갖도록 해야한다.

위험을 인식하고 준비해서 위험에 대한 영향을 최소화하는 것이다.

팀과의 의사소통에서 실수를 하게 되면 팀 간의 협력이 깨지고 대립하는 상황이 발생하기도 한다.

의사소통 문제가 있다면 프로젝트 진행으로도 힘든 상황에 정치적으로도 어려운 상황을 맞을 수 있다.

서로 존중하고 이해햐려는 마음을 가져야 하고 의사소통에 있어 모호한 부분을 명확히 함으로써 오해의 소지가 없도록 해야한다.

80%, 90% 완성은 결국 미완성이다.

이전 업무 50%, 신규 프로젝트 50%를 담당한다.

개발자는 비중이 적은 어느 하나는 하지 말라는 것...

개발자에게 퇴사를 바란다면 2개의 프로젝트에 투입시켜보라. 원하는 것을 이룰 수 있을 것이다.

이전에 성공했던 프로젝트를 참고

관리자가 프로젝트를 성공하기 위해서 가져야 할 중요한 것들이 있는데 바로 리더십, 권한 이양, 실수의 인정, 동기부여 등이다.

관리자는 팀원들의 역량을 파악해 적당한 업무를 주고 그 업무가 잘 진행되는지 관리한다.

실수를 말하는 것은 너무나 고마운 일 아닌가? 실수한 부분을 고치고 바로잡으면 된다. 그러면서 한 가지 배우는 것이다. 

실수를 말할 수 없고 인정하지 않는 분위기를 만든다면 그것은 큰 짐을 지고 마라톤을 하는 것과 같다.

설계, 개발, 테스트, 운영

무엇을 개발하는지 분석한다.

설계는 분석에서 도출한 프로세스를 기반으로 각각의 프로세스를 가능한 상세화한다.

서버의 구성, 네트워크, 보안

개발하고 테스트하고 통합한다. (통합테스트로 묶어서 진행)

별도의 유지보수 조직이나 소수의 인원만 남아서 유지보수를 하게 된다.

팀 - 프로젝트의 성공이라는 목표를 가지고 모인 사람들

일반적으로 팀은 적게는 3~5명, 많게는 6~8명 정도로 구성한다.

성취감과 팀에서 배우고 성장하고 있다고 느끼는 것이 중요하다.

비전을 다가갈 수 있도록 작지만 성취감을 가질 수 있는 업무를 주어야 한다.

지식을 주고받은 사람들은 서로를 조금씩 더 믿고 읮할 수 있다.

업무를 즐기면서 할 수 있는 환경을 만들어 주면 생산성은 자연스럽게 올라간다.

첫째 고객이 무슨 말을 하는지 정확히 파악하라.

둘째 설계에 승부를 걸어라.

셋째 위험을 관리하라.

넷째 범위를 선정하라. - 고객과 요구사항에 없는 기능으로 치장하려는 개발자를 경계하라.

완벽함이란 더 이상 무언가를 더할 것이 없을 때가 아니라 더 이상 뺄 것이 없을 때 완성되는 것이다. - 생텍쥐페리

단계적 인력 투입으로 비용을 절감하라.

단계적 납품으로 위험을 줄여라.

미리 개발해서 납품하고 추가적인 기능에 대해서는 단계적으로 개발해 납품하는 것이다.

유지보수 업무가 발생할 수 있다는 점을 참고해야 한다.

고객에게 큰 만족감을 준다.

범위관리 계획

해야 할 업무를 정의하는 것이다.

상세한 개발 목록을 도출한다.

분할과 정복 & 스토리 텔링

분할과 정복(DIvide and Conquer)

복잡하거나 커다란 부분을 분할해서 단순하거나 작은 부분으로 나누고 한 부분씩 해결해 결국 전체 결과를 얻어내는 개념이다. 개발 범위를 구할 때 매우 유용하다.

동일한 시스템이 있는지 꼭 확인하자. 시스템을 재구축하는 것인지 아니면 정말 신규로 만드는 프로젝트인지 확인해야 한다.

재구축할 때 중요한 것은 현재 운영되는 시스템에 대한 데이터 마이그레이션이다.

개발 범위에 포함시켜야 한다.

신규로 구축하는 시스템의 구조를 모두 알고고 있어야 한다.

신규 시스템에서 정상적으로 동작해야 한다.

반드시 할 것과 할 수 없는 것을 구별하여 할 수 없는 것에 대해서는 반드시 할 수 없다고 해야 한다.

의사소통의 채널은 한 곳으로 하는 것이 좋다.

가장 중요한 것은 제일 먼저 한다. 쉽다고 혹은 재미있다고 먼저 하는 것이 아니다.

중요한 것이 보통 제일 복잡하기도 하고 제일 많이 사용되기도 한다. 제일 중요한 문제가 해결되면 그 이후 작업들은 훨씬 쉽게 진행된다.

위험 관리

주기적으로 관리

정밀하게 관리

완료일을 기입한다.

현재 위험과 해결된 위험을 기입한다.

개발 기간 산정이라는 것이 즉, 답할 수 있는 성격이 아니다. 즉 답을 피하고 확인 후 알려준다고 해야 한다. 

기간을 산정할 때 반드시 해야 할 것이 바로 변경으로 인한 영향을 파악하는 것이다.

내가 잘하면서 남들도 잘한다고 하는 것을 해라.

빠른 의사결정이 다른 누군가가 결정해 주기를 기다리면서 일을 뭉개고 있는 것보다 낫다. 보통 팀은 다른 누구보다 무엇이 대안인지 훨씬 더 잘 알고 있다.

최악의 경우도 아무것도 하지 않는 것보다 낫다. - 스크럼 (켄 슈와버/마이크 비들, 인사이트)

쪼개고 카테고리화하고, 필요없는 부분은 덜어내야 한다!

일정 계획에서는 항상 회의적인 시선을 가져야 한다.

요구사항 변경과 추가가 기다리고 있다.

완료일을 기준으로 여유가 남도록 해야 한다.

너무나 작게 생각하는 경향이 있기 때문이다.

프로젝트의 규모가 크면 클수록 테스트 기간은 길어야 한다.

예측 가능한 프로젝트를 하기 위해서 예측 가능한 일정이 나와야 하는 것이 맞지만 

정확한 일정을 잡기 위해서 완벽한 업무 범위와 변경 없는 완벽한 요구사항을 설정하기란 현실적으로 불가능하다.

일정 계획은 빠른 기간 내에 프로젝트를 완성할 수 있도록 작업의 순서를 최적화하는 일이다.

한 단계의 마무리가 진행될 정도에 다음 단계의 진행이 시작되어야 한다.

누락된 작업 없도록 여러 번 많이 생각하기

만약 분석과 설계를 한 단계로 진행한다면 지금의 인력 요청은 필요 없을 것이다.

그들과 유대관꼐에도 신경을 써야 한다. 그런 개발자들은 자신의 의지로 신규 프로젝트를 선택하기도 하기 때문이다.

불가능한 계획은 본인 스스로 세우지 말자.

설계를 위해서 요청한 인원이라면 어느 정도 신뢰를 가지고 있거나 능력을 인정받는 사람이다.

믿고 맡긴다는 생각으로 해야 한다.

프로젝트에 여유가 있다면 가능한 한 브레인스토밍을 권장한다.

데이터들의 관계를 정의하는 것

두 나열하고 그룹핑한다.

그룹핑된 자료와의 관계를 정의한다.

같은 종류의 데이터를 한곳에 모으면 데이터를 읽거나 쓸 때 같은 종류의 데이터들은 동시에 사용되는 경우가 많기 때문에 성능이 더 우수하다.

초기 설계부터 검색에 용이한 구조를 생각해야 한다.

빈번하게 조회되는 데이터만 딸 ㅗ모아 별도의 데이터 구조를 생성하고 유사한 데이터는 그룹핑해서 읽고 쓸때 보다 향상된 결과가 나오도록 해야 한다.

삽입, 삭제, 갱신 등의 과정에서 발생할 수 있는 이상(Anomaly) 현상을 방지함에 있다.

적절한 인덱스를 정의하여 검색의 성능을 높여주자!

검색의 성능을 고려햐여 인덱스를 활용하는데, 역정규화 기법을 통해서 검색의 효율을 높일 수 있다.

빈번히 변경될 가능성이 있는 데이터를 역정규화 할 경우가 바로 정규화에서 말하는 이상(Anomaly)현상이다.

변경이 일어나지 않는 데이터에 한해서 역정규화를 진행하는 것이 좋다.

역정규화는 반드시 정규화가 끝난 다음 필요에 따라 진행한다.

검색 구문을 쉽게 사용하기 위한 역정규화는 절대 하지 않는다.

실현 가능한 기능 현실적인 일정이 필요하다.

아무리 좋은 설계라도 기간 내에 완료할 수 없다면 프로젝트는 실패하게 된다.

일정과 인력이 부족하다고 생각된다면 추가적인 일정과 인력을 요구해야 한다.

중요한 것을 먼저 해야 한다.

가장 복잡하고 시간과 인원이 많이 드는 순서대로 인력과 시간을 집중해야 한다.

협업이 필요한 부분은 더욱 중요하다.

가시적으로 확인 가능한 단위로 일정을 나눈다.

상세한 작업 진행 상황을 알 수 있다.

새로운 시스템을 오픈할 때, 구 시스템보다 우수할 것이라는 사용자의 기대감과 구 시스템의 데이터에 관한 마이그레이션에 대한 부담이 크게 작용한다.

고객의 접속률이 늘어날수록, 데이터가 많아질수록 하나둘 문제가 발생한다.

변경을 해야 한다면 필요한 일정과 인력을 요청해야 한다. 개발 완료 이후에 추가적인 인력은 투입하기 어렵다. 일정을 늘려서 개발 가능성을 높일 수 밖에 없다.

오류만 처리하는 조직으로 전락해서는 안 된다. 개발팀에서도 기능상이나 편의상의 개선사항을 제안할 수 있어야 하고 불편함을 듣고 개선하는 적극적인 활동을 해야 한다.

내게 나무 벨 시간으로 여덟 시간이 주어진다면 그 중 여섯 시삭ㄴ은 도끼를 가는 데 쓰겠다. - 에이브러햄 링컨

링컨은 누군가와 이야기하기 전에 많은 시간을 그 사람과 무슨 말을 할지 생각하는 데 소비한다고 한다. 

프로젝트에서 분석, 설계가 개발만큼 어쩌면 그보다 더 중요하다는 것을 말해주는 매우 적절한 비유가 아닌가 싶다.

---

책에 나온 이야기를 두서 없이 정리 했는데요.

나중에 시간날때 따로 다시 복기해보면서 정리해 볼 예졍입니다.

이 책은 저에게 있어서 많은 것을 배우게 해준, 좋은 책이었습니다!

감사합니다. :)