# [책갈피] 항목은 책을 읽으면서 기억에 남는, 기억하고 싶은 부분을 메모한 페이지입니다.
04. 성공을 이끄는 프로젝트 리드
"현업에서 PM이라는 용어를 많이 쓰는데요. PM에는 두 가지 뜻이 있습니다."
"프로젝트 매니저와 프로덕트 매니저입니다."
"프로덕트 매니저를 프로덕트 오너(PO)라고도 부릅니다."
"단적으로 이야기하면 PO는 제품만 신경 쓰고 PM은 개발해서 출시하는 전체 일정과 리소스를 관리합니다."
"지금부터 다룰 프로젝트 리드는 PO 역할도 하지만 전반적으로는 PM 쪽에 더 집중하는 역할이라고 보면 됩니다."
"프로젝트 리드는 기술을 제외한 모든 것을 챙겨야 합니다."
"다양한 역할의 사람과 소통하며 교통리를 하면서도 중요하지 않은 일에 시간을 쓰지 않도록 시간 관리에 신경을 써야 합니다."
"이제 이런 개발 과정에서 벌어지는, 그래서 프로젝트 리드가 챙겨야 하는 일들을 살펴봅시다."
개발 계획 세우기:
"개발 주기는 요구사항을 분석하고 시스템 구조를 설계하고, 개발하고 테스트와 출시하고, 피드백을 받아서 업데이트하는 전체 과정입니다."
"계획 안에서 실행해야 리소스가 관리됩니다."
"PM은 전체 과정을 이해하고 목표를 이해하고 리소스를 관리해야 합니다."
"PO를 포함한 사람들이 그림 안에서 소통할 수 있도록 도움을 줘야 하고 스스로도 소통을 해야 합니다."
"계획을 세우는 것도 중요하지만 준수하는 것도 중요합니다."
"계획을 세우는 이유는 완벽하게 준수하기 위해서가 아닙니다. 성공을 위해 세우는 겁니다."
"그러므로 계획을 세워두고 상황에 맞게 수정하고 대비해야 합니다."
"작심삼일이면 어떻습니까? 3일마다 계획을 세워 3일 동안 실행하면 되지 않습니까?"
"PM은 계획을 세워서 전체 그림을 정리하고 시장, 개발, 제품에 맞춰서 계획을 업데이트해야 합니다."
"하지만 일반적인 서비스라면 품질과 시간 사이에서 밸런스를 잡아야 합니다."
"결국 우선순위 정하기가 절반, 시간을 효율적으로 관리하기가 절반입니다."
"이걸 잘 섞고 조율해야 프로젝트 관리를 잘해서 성공적으로 제품을 출시할 수 있습니다."
역할 나누기:
"역할을 맡은 사람이 일을 잘할 수 있게 코디네이션 하려면, PM은 사람들이 적절히 부딪히며 일할 수 있게 역할을 정의해야 합니다."
"완벽히 격리된 역할을 주면 의욕이 떨어지고, 역할 이기주의에 빠질 수 있습니다."
"모든 사람에게 기본 역할을 정리해주되, 약간은 자기 범위 밖에 나와서 일할 수 있도록 자유를 제공해야 합니다."
"앞부분에서 이야기했던 투명성, 예측 가능성 같은 것을 발현하여, 사람들이 자연스럽게 자기 밖으로 나와서 이야기하고, 생산적인 충돌이 일어나도록 해야 합니다."
시간 아끼기:
"시간을 아끼는 최고의 방법은 낭비를 없애는 겁니다."
"시간을 잡아먹는 요인으로는 필요 없는 코드, 개발 과정에서 기다림(다음 과정이 준비되지 않았기 때문에), 불명확한 요구사항, 내부 정치, 느린 내부 소통 이렇게 다섯 가지가 있습니다.
"지금 이 순간에도 도처에서 시간이 버려집니다."
"성공적으로 프로젝트를 완료하고 싶다면 낭비를 막아야 합니다."
"해결책은 단순합니다."
"계획을 세워서 명확한 요구사항을 만들고, 관리자가 큰 틀에서 목표와 비전을 가지고 정리해 내부 소통을 개선해서 내부 정치를 사라지게 하면 됩니다."
"따라서 요구사항을 명확히 정의하고 기술 구조를 초기에 제대로 잡아둬야 합니다."
"거창한 이벤트보다는 일상에서 꾸준히 하나씩 낭비를 줄이는 방식이 낭비가 낭비를 만들지 않는 방법입니다."
"낭비를 줄이면 업무 효율이 올라갑니다."
"당연히 생산성도 높아지게 됩니다."
"생산성을 올리는 방법은 모두를 바쁘게 하는 것이 아니고 낭비를 없애는 겁니다."
"모두가 바쁘고 진척이 안 된다면 사실상 낭비하고 있을 가능성이 높습니다."
문제 해결 6단계:
"프로젝트를 진행하다 보면 문제가 계속 발생합니다."
"일이란 문제를 잘 정리하고 계산하고 해결하는 행위입니다."
"문제가 재발되지 않게 해결하는 게 중요합니다."
"고로 문제 자체를 싫어하면 안 됩니다."
"그래서 위기관리를 하면 위기가 안 오고, 위기관리를 안 하면 위기가 옵니다."
"문제는 필연적으로 계속 발생하므로 문제 해결 시스템을 갖추면 시간 낭비를 줄일 수 있습니다."
*문제 해결 단계*
문제 해결 단계 | 해결 방안 |
1단계 | 문제 고르기 |
2단계 | 고른 문제를 정의하기 |
3단계 | 문제 분석하기 |
4단계 | 해결책을 찾고 그중에서 최선의 해결책 선택하기 |
5단계 | 선택한 해결책을 실행해도 되는지 결정권자에게 승인받기 |
6단계 | 문제가 해결되었는지 확인하기 |
"해결책은 여러 가지여야 합니다."
"해결책이 하나만 있어서는 안 됩니다."
"저는 해결책이 단 하나일 때는 그 해결책을 적용하지 않는 편입니다."
"문제 하나에 여러 해결책을 고안한 뒤 제일 좋은 해결책을 골라야 합니다."
"이것이 문제 해결의 핵심입니다."
"참고로 문제 해결뿐 아니라 모든 일에서 목표(goal), 계획(plan), 실행(action), 측정(measure) 이 네 가지는 중요합니다."
선별해 문제 풀기:
"제한된 시간을 효과적으로 사용하려면 산적한 문제를 효과적으로 분류하고 대응해야 합니다."
"따라서 문제를 발견했다면 경중과 해결 가능성을 따져야 합니다."
"이처럼 중요도가 낮거나 해결할 수도 없는 일이라면 (리소스 때문이든 능력 때문이든) 머릿속에서 지워버리는 것도 방법입니다."
"그렇지 않으면 낭비로 연결되기 때문입니다."
"할 수 있는 일, 중요한 일, 해결할 수 있는 문제에 집중합시다."
"재발하지 않도록 해결책을 만듭시다."
"그래야 시간을 효율적으로 쓰면서 프로젝트를 제대로 리드했다고 말할 수 있습니다.
우선순위 정하기:
"우선순위대로 일하고, 문제를 해결하고, 낭비를 없애고, 사람들의 역할을 연결해야 합니다."
"중요한 일을 해야지 급한 일의 늪에 빠져서는 안 됩니다."
"할 일을 고를 때 급한가 급하지 않은가를 따지지 말고, 한 발 물러서서 '중요한가 중요하지 않은가'를 먼저 생각해야 합니다."
"업무 요청을 전부 즉시 처리하는 게 아니라 마감일을 정하거나, 거부하거나, 위임해서 관리해야 합니다."
"프로젝트 리드는 역할, 낭비, 문제, 우선순위 이 모든 것을 총체적으로 관리해야 합니다."
"그래야 큰 그림 안에서 안정적으로 일할 수 있습니다."
# To-Be..
05. 기술 주도 테크니컬 리드
'Book' 카테고리의 다른 글
[책갈피] 개발자로 살아남기 - 06 (0) | 2022.08.07 |
---|---|
[책갈피] 개발자로 살아남기 - 05 (0) | 2022.08.06 |
[책갈피] 개발자로 살아남기 - 03 (0) | 2022.07.30 |
[책갈피] 개발자로 살아남기 - 02 (0) | 2022.07.28 |
[책갈피] 개발자로 살아남기 - 01 (0) | 2022.07.28 |