주제 2.2 — 업무 우선순위 설정

한 문장으로: 우선순위 설정은 트리아지를 통과한 업무를 — 가치, 긴급성, 위험, 노력을 한정된 역량에 견주어 균형 잡으면서 — 의도적이고 투명하게 순서 짓는 일로서, 조직이 어느 순간에나 할 수 있는 가장 가치 있는 일을 하고 있고 그 이유를 설명할 수 있게 한다.

보건·돌봄에서 이것이 중요한 이유#

우선순위 설정은 전략이 현실이 되는 곳이다. 조직의 진짜 전략은 공표된 계획이 아니라 실제로 일을 하는 순서이며, 보건·돌봄에서 그 순서는 안전, 형평성, 공적 자금의 결과를 낳는다. 상호운용성 작업의 우선순위를 낮추면 공유 진료 기록이 멈춘다. 기술 부채의 우선순위를 낮추면 공휴일 새벽 2시에 시스템이 고장 난다. 접근성 수정의 우선순위를 낮추면 서비스가 가장 필요한 사람들을 배제한다.

압박은 구조적이다. 수요는 늘 역량을 넘고, 그 수요의 상당 부분은 정당하다. 따라서 리더에게는 마지막 이메일이 이기거나 모든 프로젝트가 "최우선"인 프로세스가 아니라 상충 관계를 명시적이고 방어 가능하게 만드는 방법이 필요하다. 투명한 우선순위 설정은 정치적 분위기도 바꾼다. 이해관계자가 기준과 순서를 볼 수 있으면 협상은 로비에서 가치와 지연 비용에 대한 공유된 대화로 옮겨 간다. 이 주제는 접수(주제 2.0)와 트리아지(주제 2.1)를 잇는다. 이미 순서를 매길 눈에 보이고 평가된 백로그가 있다고 가정하며, 딜리버리 수명주기(주제 3.4–8)와 포트폴리오 관리(주제 5.3 — 전사 프로젝트 포트폴리오 관리(EPPM))에 투입된다.

핵심 개념#

**우선순위 설정(prioritisation)**은 백로그나 포트폴리오의 순서를 정한다. 각 항목을 따로 평가하고 보낸 트리아지와는 구별된다. 우선순위 설정은 한정된 역량을 두고 항목들을 서로 비교하며, 현실이 바뀜에 따라 그 비교를 다시 한다.

**지연 비용(Cost of Delay)**은 최고의 방법들 밑에 깔린 경제적 렌즈다. 이것이 행해지지 않는 매주마다 가치, 해악, 또는 돈으로 얼마의 비용이 드는가? 지연 비용을 명시하면 우선순위 설정이 "무엇이 가장 중요한가?"(모든 것)에서 "무엇을 지연하는 것이 가장 비싼가?"(순위를 매길 수 있는 질문)로 재구성된다.

일반적인 프레임워크는 각각 적합한 쓰임이 있다.

• WSJF (Weighted Shortest Job First), Scaled Agile Framework(SAFe)에서: 지연 비용(사용자/비즈니스 가치 + 시간 결정성 + 위험 감소/기회 실현)을 점수화하고 작업 규모로 나눈다. WSJF가 가장 높은 것을 먼저 한다. 작고, 가치가 높고, 시간이 결정적인 업무를 자연스럽게 선호하며 매몰 비용을 무시한다.
• RICE (Reach × Impact × Confidence ÷ Effort, Intercom이 대중화): 열의를 확신(Confidence) 요인으로 누그러뜨리는 제품 관리 점수.
• MoSCoW (Must / Should / Could / Won't-this-time), DSDM에서: 분류 방식으로, 릴리스나 고정 일자 프로그램의 범위를 정하는 데는 탁월하지만 세밀한 순서 매기기에는 약하다.
• 가치 대 노력(2×2): 빠른 성과와 돈 먹는 구덩이를 찾아내는 빠른 시각 도구로, 거칠지만 빠르다.
• Kano 모형: 기능을 기본(필수), 성능, 감동 요소로 분류하며, 기본 요건과 차별화 요소의 균형을 잡는 데 유용하다.

어떤 프레임워크도 "정답"은 아니다. 각각이 가치의 다른 정의를 담고 있으며, 함께 점수를 매기는 행위가 숫자 자체보다 더 가치 있는 경우가 많다.

운영 대 변경은 포트폴리오 수준의 균형이다. "불을 켜 두는" 운영 업무(run)와 새 역량(change)이다. 우선순위 설정은 둘을 모두 아울러야 한다. 그렇지 않으면 **기술 부채**와 안전/보안 시정을 포함한 보이지 않는 운영 업무가 번쩍이는 새 기능과의 모든 경쟁에서 지다가 결국 파국적으로 실패한다.

역량 기반 대 일자 기반 우선순위 설정: 역량 기반 순서는 알려진 한정된 처리량(지속 가능한 속도)을 채운다. 일자 기반 순서는 움직일 수 없는 기한(규제 가동)에서 거꾸로 일하며 MoSCoW로 범위를 유연하게 한다. 대부분의 포트폴리오에는 서로 다른 항목에 적용되는 둘 다 필요하다.

모범 사례#

1. 하나의 주 프레임워크를 고르고 일관되게 적용하라. 업무에 맞는 방법을 고르라. 실제 시간 결정성이 있는 혼합 변경 포트폴리오에는 WSJF, 제품 기능 백로그에는 RICE, 고정 일자 릴리스에는 MoSCoW다. 그리고 점수가 비교 가능하도록 일관되게 사용하라. 항목마다 프레임워크를 바꾸면 백로그가 비교 불가능해지고 조작을 부른다.

2. 특히 안전과 법정 업무에 지연 비용을 명시하라. 각 항목에 물으라. "한 달의 지연은 얼마의 비용인가?" 안전 수정이나 규제 기한의 경우 답은 심각하고 비선형인 경우가 많으며, 바로 그 때문에 가정이 아니라 점수화되어야 한다. 지연 비용은 준수 기한과 사용자 경험 개선을 정직하게 비교하게 해 주는 공통 통화다.

3. 운영, 기술 부채, 안전을 위한 명시적 역량을 확보하라. 불을 켜 두는 업무, 기술 부채, 보안/안전 시정이 기능별로 새 역량과 경쟁하게 두지 말라. 무언가 고장 날 때까지 질 것이다. 이 업무를 위해 역량의 상시 비율(경험칙으로는 의미 있고 보호되는 몫)을 별도로 확보하고 타협할 수 없는 것으로 다루라.

4. 요청자의 직급이 아니라 성과와 가치로 우선순위를 정하라. 누가 요청했는지가 아니라 조직의 명시된 성과와 우선순위(이상적으로는 OKR — 주제 10.0 참조)에 대해 점수를 매기라. 고위 이해관계자의 항목이 낮게 점수를 받는다면, 그것은 시스템이 작동하는 것이다. 프레임워크는 그 대화를 나눌 공정하고 비인격적인 근거를 준다.

5. 방법을 제약에 맞추라: 역량인가 일자인가. 지속 가능한 변경 흐름에는 가치로 순서를 정하고 알려진 역량에 맞춰 업무를 끌어오라. 움직일 수 없는 일자에는 거꾸로 일하며 MoSCoW로 "Must"를 보호하고 "Could"를 유연하게 하라. 둘을 혼동하는 것 — 고정된 범위를 고정된 시간과 고정된 역량에 맞추려는 것 — 이 실패한 프로그램으로 가는 고전적 길이다.

6. 투명하게 우선순위를 정하고 공개적으로 협상하라. 순위가 매겨진 백로그와 그 뒤의 점수를 공표하라. 투명성은 우선순위 설정을 일련의 사적 거래에서 상충 관계가 보이는 공유된 협상으로 바꾼다. 내 항목을 올리려면 다른 무언가가 내려가야 하고 모두가 그 비용을 볼 수 있다. 이것이 딜리버리 리더가 쓸 수 있는 가장 강력한 탈정치화 수단이다.

7. 정기적인 주기로 — 오직 그때만 — 우선순위를 재조정하라. 우선순위를 새로운 증거에 비추어 다시 검토하는 리듬(예를 들어 월간 또는 분기 포트폴리오 검토와 그 사이의 더 가벼운 백로그 정제)을 정하라. 검토 사이에는 선을 지켜 팀에게 안정적인 활주로를 주라. 끊임없는 재조정은 한 번도 재조정하지 않는 것만큼 해롭다. 흐름을 파괴하고 아무것도 끝내지 못한다.

8. 조작과 거짓 정밀함을 경계하라. 상대 점수(피보나치, 티셔츠 사이즈)는 진리가 아니라 추정이다. WSJF 8.3이 7.9보다 의미 있게 낫지는 않다. 숫자를 순위가 매겨진 대화에 정보를 주는 데 쓰고, 부풀려진 입력을 경계하며, 경험 있는 판단이 명백히 비뚤어진 점수를 뒤집게 하되 이유를 기록하라.

팀과 논의할 질문#

1. 우리가 계속 미루고 있는 업무에 대해 "한 달의 지연이 실제로 얼마의 비용인가?"라는 질문의 정직한 답은 무엇인가? 지연 비용은 준수 기한과 사용자 경험 손질을 정직하게 비교하게 하는 공통 통화지만, 대부분의 조직은 이를 명시하지 않아 기본적으로 "모든 것이 중요하다"에 머무르며, 이는 순위를 매길 수 있는 진술이 아니다. 이는 일부 업무를 지연하는 비용이 심각하고 비선형이므로 보건·돌봄에서 특히 중요하다. 미뤄 둔 안전 수정이나 상호운용성 의존성은 몇 달 동안 무해하게 앉아 있다가 파국적으로 실패할 수 있는 반면, 미뤄 둔 편의 기능은 거의 아무 비용이 들지 않는다. 팀은 가장 논쟁적인 항목들의 지연 비용을 실제로 설명할 수 있는지 토론하고, 인기 있는 프로젝트에는 정직한 답이 "거의 없음"이고 보이지 않는 프로젝트에는 "잠재적으로 중대한 사건"인 불편한 사례와 마주해야 한다. 구체적 각도는 이렇다. 현재 백로그 중간에 걸려 있는 항목 세 개를 골라 각각에 지연 비용 한 문장을 강제로 쓰게 하라. 기술 부채와 안전 시정이 지연 비용으로 점수화된 적이 있기는 한지, 아니면 아예 들어가지 않음으로써 모든 경쟁에서 지는지 물으라. 좋은 답은 지연 비용이 대략 선형인 항목과 기한이나 고장 지점에서 급등하는 항목을 구별하고, 그 형태를 순서의 정당화에 쓴다. 부정직한 버전은 "모두 우선순위다" 뒤에 숨는데, 이는 이 질문이 드러내려는 우선순위 설정의 부재 그 자체다.

2. 운영, 기술 부채, 안전을 위해 얼마의 역량을 별도로 확보할 의향이 있으며 — 번쩍이는 새 제안이 올 때 그것을 지킬 것인가? 이것은 가장 확실히 잘못되는 상충 관계다. 불을 켜 두는 업무, 기술 부채, 보안 또는 안전 시정은 보이지 않아서 공휴일 새벽 2시에 무언가 고장 날 때까지 기능별로 새 역량에 진다. 논쟁은 일부 역량을 보호할지 여부가 아니라(원칙적으로 거의 모두 동의한다) 구체적인 비율이며, 훨씬 어렵게는 고위 후원자의 흥미로운 프로젝트가 처음으로 그 별도 확보분을 털어 가려 할 때 리더십이 실제로 그 선을 지킬 것인가이다. 보건·돌봄에서는 환자 안전과 임상의가 의존하는 시스템의 신뢰성이 걸려 있으므로, 그 몫을 타협할 수 없는 것으로 다루는 것은 단순한 좋은 위생이 아니라 안전 자세다. 구체적 각도는 이렇다. 마지막 주요 인시던트나 아차 사고를 돌아보며 우선순위 경쟁에서 이긴 적이 없는 미뤄 둔 운영이나 부채 업무로 거슬러 올라가는지 물으라. 보호된 역량을 터는 것을 거부할 권한이 있는 사람을 명명하고 그가 정말 그럴지 시험하라. 강한 답은 구체적이고 보호되는 몫을 약속하고, 결정적으로 선의를 믿는 대신 압박 속에서도 그것을 보호하는 거버넌스를 설명한다. 정직한 버전은 별도 확보가 방 안의 가장 강력한 이해관계자와 맞닥뜨려 살아남아야만 실재함을 인정한다.

3. 고위 이해관계자의 항목이 낮은 점수를 받을 때, 순위가 유지되도록 할 투명성과 배짱이 있는가? 요청자의 직급이 아니라 성과로 우선순위를 정하는 것은 자명하게 들리지만, HiPPO 효과, 곧 가장 높은 보수를 받는 사람의 의견이 점수를 조용히 뒤집는 것은 위계적인 NHS와 정부 환경에서 기본적인 실패이며, 바로 조용하기 때문에 부식적이다. 긴장은 낮은 점수의 고위 항목이 종종 시스템이 올바로 작동하는 것인데, 공표된 투명한 순위와 점수 근거가 없으면 딜리버리 리더가 그 대화를 나눌 비인격적 근거가 없어 대개 굴복한다는 점이다. 팀은 백로그와 점수가 요청 조직에 진정으로 보이는지 토론해야 한다. 공개적인 상충 관계 협상 — "당신 것을 올리려면 점수가 더 높은 어느 항목이 내려가야 하며, 그 지연의 비용을 받아들일 수 있는가?" — 이 쓸 수 있는 가장 강력한 탈정치화 수단이고, 그것은 공개적일 때만 작동한다. 구체적 각도는 이렇다. 고위 요청이 대기열을 새치기한 마지막 때를 떠올리고 순위가 공개되어 있었다면 무슨 일이 일어났을지 물으라. 점수 근거를 이사회, ICB, 감사관에게 보여 줄 수 있는 거버넌스 기록으로 보존하는 것을 고려하라. 좋은 답은 투명성(순서와 점수를 공표)을 뒤집기 대화를 위한 연습된 비인격적 대본과 짝지우고, 그것을 쥘 지위가 있는 사람을 식별한다. 회피하는 답은 이를 가정으로 취급하지만, 현실에서는 거의 매주 일어나며 계획은 그것을 견뎌야 한다.

4. 우리는 실제로 하나의 우선순위 프레임워크에 전념했는가, 아니면 각 항목을 그것에 유리한 방법으로 조용히 채점하고 있는가? 하나의 주 프레임워크를 고르고 일관되게 적용하는 것이 백로그를 비교 가능하게 만든다. 한 제안에는 WSJF, 다른 제안에는 가치 대 노력의 직감, 세 번째에는 "이사님이 정말 원하신다"를 쓰는 순간 순서는 의미를 잃고 조작이 스며든다. 긴장은 어떤 단일 프레임워크도 모든 종류의 업무에 맞지 않는다는 점이다. WSJF는 혼합 변경 포트폴리오에, RICE는 제품 기능 백로그에, MoSCoW는 고정 일자 릴리스에 맞는다. 그래서 정직한 토론은 무엇이 주 방법이고 어디서 두 번째가 편리한 탈출구가 아니라 정당하게 허용되는지다. 이는 보건·돌봄에서 중요하다. 준수 기한, 임상의가 요청한 기능, 데이터베이스 업그레이드가 같은 저울에서 따져져야 하고, 일관된 방법만이 법정 항목과 편의 항목을 특별한 변론 없이 서로 순위를 매기게 하기 때문이다. 구체적 각도는 이렇다. 최근 열두 개의 우선순위 결정을 감사해 같은 방법이 진정으로 적용되었는지, 아니면 미리 정해진 답을 정당화하려고 방법이 바뀌었는지 확인하라. 정교한 점수가 아무도 그에 따라 행동하지 않는 숫자를 낳는 "프레임워크 연극"을 경계하라. 좋은 답은 주 프레임워크를 명명하고, 다른 것이 쓰이는 좁고 원칙 있는 경우를 설명하며, 점수를 진리가 아니라 순위가 매겨진 대화에 정보를 주는 것으로 다룬다. 약한 답은 모든 요청자가 자신의 수학을 가져오게 두는데, 이는 방법이 없는 것과 구별되지 않는다.

5. 어떤 업무가 역량에 묶이고 어떤 것이 일자에 묶이는지 정직한가 — 아니면 범위, 일자, 역량을 한꺼번에 고정하려 하고 있는가? 우선순위 설정은 제약에 맞아야 한다. 지속 가능한 변경 흐름은 가치로 순서를 정하고 알려진 역량에 맞춰 끌어오며, 움직일 수 없는 규제 가동은 일자에서 거꾸로 일하고 MoSCoW가 "Must"를 보호하고 "Could"를 유연하게 한다. 실패한 프로그램으로 가는 고전적 길은 둘을 혼동하여 범위, 일자, 역량을 동시에 잠그는 것이며, 법정 기한이 타협할 수 없다고 느껴지고 이해관계자가 전체 범위도 똑같이 타협할 수 없다고 가정하는 보건·돌봄에서 특히 유혹적이다. 팀은 주요 업무 각각이 정말 역량에 묶이는지 일자에 묶이는지 항목별로 토론해야 한다. 일자 주도의 프로그램을 시간이 탄력적인 것처럼, 또는 일상 운영 흐름을 하드 데드라인이 있는 것처럼 다루면 하류의 모든 것의 우선순위가 잘못 매겨지기 때문이다. 구체적 각도는 이렇다. 움직일 수 없는 가동 하나를 들어, 어느 요구사항이 법적 최소를 위한 진정한 "Must"이고 어느 것이 필수 집합에 몰래 들어온 "Should"나 "Could"인지 물으라. 세 제약이 조용히 모두 고정된 프로그램을 찾아 현실이 닥칠 때 실제로 무엇이 굽혀질지 명명하라. 좋은 답은 업무를 구속 제약에 따라 분류하고 맞는 방법을 의도적으로 적용하며, 역량 기반 흐름과 일자 기반 딜리버리를 별개의 규율로 유지한다. 비현실적인 답은 고정된 일자에, 고정된 역량 안에서, 전체 범위를 약속하고 희망한다.

6. 우리의 재조정 주기는 무엇이며, 검토 사이에 순서를 안정적으로 유지할 규율이 있는가? 우선순위는 새로운 증거에 비추어 다시 검토되어야 하지만 리듬에 맞춰야 한다. 월간 또는 분기 포트폴리오 검토와 그 사이의 더 가벼운 정제다. 끊임없는 재조정은 한 번도 재조정하지 않는 것만큼 해롭기 때문이다. 흐름을 파괴하고 아무것도 끝내지 못한다. 긴장은 실재한다. 현실은 진정으로 바뀌고, 새로운 안전 신호나 재원의 변화가 재배열을 정당화할 수 있지만, 진행 중의 모든 재편은 팀의 활주로를 앗아 가고 반쯤 만든 업무를 남겨 둔다. 딜리버리 팀이 빠듯하고 의존성이 여러 조직에 걸치는 보건·돌봄에서는 혼란이 비싸고 사기를 깎으므로, 검토 사이의 안정적인 활주로는 딜리버리의 문제만큼 생산성과 유지의 문제다. 구체적 각도는 이렇다. 지난 분기에 정해진 검토 밖에서 백로그 맨 위가 몇 번 바뀌었고 그 결과 무엇이 출시되었는지 확인하라. 주기를 깨는 것을 정당화하는 좁은 기준 — 목소리 큰 이해관계자가 아닌 진정한 비상 — 에 미리 합의하라. 좋은 답은 명시적 주기를 정하고, 검토 사이의 활주로를 지키며, 순서가 유지되었기에 실제로 끝난 업무를 가리킬 수 있다. 실패하는 답은 마지막 이메일이 도착할 때마다 재조정하여, 아무것도 결승선을 넘지 못하는 동안 움직임을 응답성으로 착각한다.

실제 사례: 보건·돌봄 예시#

한 ICB 디지털 포트폴리오 팀이 경쟁하는 열두 개의 제안과 아마 다섯 개를 감당할 역량에 직면했다. 역사적으로 순서는 조직 내 직급을 따랐고 기술 부채는 아예 등장하지 않았다. 이들은 변경 업무에 WSJF를 채택하고 운영, 기술 부채, 안전을 위한 고정된 몫의 역량을 별도로 확보했다.

각 제안은 딜리버리, 임상, 재무의 목소리가 함께한 한 번의 세션에서 비즈니스 가치, 시간 결정성, 위험 감소/기회 실현, 작업 규모로 함께 점수가 매겨졌다. 법정 데이터 제출 기한은 시간 결정성에서 매우 높은 점수를 받았고 규모가 적당해 WSJF에서 맨 위로 올랐다. 크고 인기 있는 분석 플랫폼은 가치에서 높은 점수를 받았지만 규모가 순서를 아래로 밀어 냈다. 직급 기반 순위 아래에서는 생각할 수 없었을 결과였고, 프레임워크가 이를 방어 가능하게 만들었다. 오랫동안 미뤄졌고 이전에는 보이지 않던 데이터베이스 업그레이드는 고장 나기 전에 별도 확보된 운영 몫에서 재원을 얻었다.

결정적으로, 순위가 매겨진 백로그와 점수는 모든 요청 조직과 공유되었다. 한 트러스트가 자신의 제안을 새치기시키려 밀어붙였을 때 대화는 "누구를 아시나요?"가 아니라 "점수가 더 높은 이 항목들 중 어느 것이 내려가야 하며, 그 지연의 비용을 받아들일 수 있습니까?"였다. 협상은 공개적으로 이루어졌고, ICB는 이사회에 순서가 정치가 아니라 가치와 지연 비용을 반영했음을 증거로 보일 수 있었다.

부문별 관점#

스타트업#

재원이 제한된 디지털 보건 스타트업은 무엇보다 런웨이에 맞춰 우선순위를 정하므로, 순서 방법은 가볍고 가치 주도여야 한다. 가치 대 노력 2×2나 단순한 RICE 점수면 보통 충분하고, 서른 개 항목의 백로그에 정교한 WSJF 장치는 과하다. 지배적인 지연 비용은 존재적이다. NICE 평가나 핵심 고객이 필요로 하는 증거를 놓치면 회사가 끝날 수 있고, 이는 있으면 좋은 기능보다 훨씬 높은 순위다. 가장 어려운 규율은 매주가 다음 매출 기능을 외치는 때에 기술 부채와 안전 시정을 위한 역량을 얼마라도 확보하는 것이지만, 이를 아예 건너뛰는 것이 젊은 제품이 규모를 키우는 바로 그때 멈춰 서는 원인이다. 재조정은 잦고 창업자 주도이므로 위험은 혼란이다. 해독제는 무언가 실제로 출시되도록 적어도 짧은 스프린트 동안 안정된 순서를 유지하는 것이다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 단일 사업장 클리닉 — 는 여유가 거의 없이 우선순위를 정한다. 같은 소수가 서비스와 모든 변경 업무를 운영하므로 순서는 철저히 단순해야 하고, 팀의 누구나 읽을 수 있는 가치 대 노력 2×2가 아무도 유지할 시간이 없는 점수 모형보다 값지다. 지배적인 지연 비용은 보통 법정 또는 안전 주도이며 — 데이터 보안 툴킷 기한, 임상 안전 수정, 국가 공급업체의 의무적 시스템 업그레이드 — 이는 맨 위에 있어야 한다. 소규모 제공자는 대형 트러스트와 같은 의무를 지면서 실패를 흡수할 자원은 없기 때문이다. 재량적 개선은 서비스 운영과 진정으로 경쟁하므로, 정직한 규율은 환자 접점 수요에 매주 지게 두는 대신 타협할 수 없는 운영 및 시정 업무를 위한 작고 규칙적인 시간 몫을 보호하는 것이다. 전담 IT 역량이 얇거나 없어서 "어떻게"의 상당 부분은 공급업체와 프레임워크 계약이 정하므로, 우선순위 설정은 흔히 공급업체 주도의 변경과 진료소가 통제할 수 있는 몇 가지를 순서 짓고, 바쁜 한 주와 다음 주 사이에 무언가 끝나도록 충분히 오래 안정된 순서를 유지하는 일이다.

대기업#

NHS 트러스트나 ICS는 진정한 시간 결정성과 무거운 운영 의무를 가진 혼합 변경 포트폴리오를 운영하며, 이것이 바로 WSJF와 별도 확보된 운영/기술 부채/안전 몫이 설계된 형태다. 진짜 과제는 정치다. 여러 후원 조직, HiPPO 압력, 연공서열이 순서를 정한다는 레거시 기대가 있으므로, 순위가 매겨진 백로그와 점수의 투명성이 대기업의 주된 탈정치화 도구다. 여기서 우선순위 설정은 포트폴리오 사무국에 걸쳐 있으며, 일상 변경을 위한 역량 기반 흐름과 움직일 수 없는 규제 가동에서 거꾸로 일하며 MoSCoW로 범위를 유연하게 하는 일자 기반 프로그램을 조화시켜야 한다. 트러스트는 이사회, ICB, 감사관에게 비용 대비 가치를 입증해야 하므로, 점수 근거는 결정이 내려진 뒤 버려지지 않고 거버넌스 기록으로 보존된다.

정부#

NHS England, DHSC, 지방분권 정부에서 우선순위 설정은 국가 규모의 포트폴리오 관리이며, Management of Portfolios(MoP)와 재무부 5개 케이스 모델을 통해 공식화되고, 지연 비용은 인구 건강, 법정 준수, 수십억 파운드로 측정된다. 포트폴리오의 상당 부분은 재량이 아니다. 의무적 제출, 법적 기한, 장관의 약속이므로, 방법은 할지 말지가 아니라 의무화된 업무의 어떻게와 언제의 순위를 매겨야 하고 움직일 수 없는 일자의 프로그램이 지배한다. 위험 감수 성향은 낮고 감시는 대립적이다. National Audit Office와 Public Accounts Committee는 순서가 가치와 지연 비용을 반영했는지 단지 정치적 편의를 반영했는지 시험할 것이므로, 명시적이고 공표된 우선순위 설정 근거는 관리 도구만큼이나 방어다. 형평성은 가치의 법정 차원이므로, 정부의 점수 모형은 총편익뿐 아니라 가장 덜 서비스받는 인구에 대한 영향에 가중치를 두어야 한다. 그렇지 않으면 이미 잘 서비스받는 이들을 체계적으로 선호할 것이다.

흔한 실패 양상#

• 모든 것이 최우선이다. 실제 순서가 없어서 가장 큰 목소리나 가장 가까운 기한이 좌우한다. 해결: 엄격한 순위를 강제하라; 맨 위에서 동점은 허용되지 않는다.
• 운영과 기술 부채가 항상 진다. 보이지 않는 운영 및 시정 업무가 고장 날 때까지 굶는다. 해결: 별도 확보되고 보호되는 역량.
• HiPPO 뒤집기. 가장 높은 보수를 받는 사람의 의견이 점수를 매번 조용히 뒤집는다. 해결: 투명한 점수와 공개적인 상충 관계 협상.
• 프레임워크 연극. 정교한 점수가 아무도 그에 따라 행동하지 않는 숫자를 낳는다. 해결: 점수가 실제로 실행되는 순위 순서에 정보를 주게 하라.
• 고정된 범위 + 고정된 일자 + 고정된 역량. 세 제약이 모두 잠겨 실패가 보장된다. 해결: MoSCoW로 범위를, 또는 역량이나 일자를 유연하게 하라.
• 혼란. 우선순위가 매주 바뀌어 아무것도 끝나지 않는다. 해결: 정해진 재조정 주기와 그 사이의 안정적인 활주로.

성숙도 모델#

체크리스트#

• 하나의 주 우선순위 프레임워크가 선택되어 일관되게 적용된다.
• 특히 안전과 법정 업무에 지연 비용이 명시된다.
• 운영, 기술 부채, 안전/보안 업무를 위해 역량이 별도 확보된다.
• 항목이 요청자의 직급이 아니라 성과/OKR에 대해 점수화된다.
• 역량 기반 방법과 일자 기반 방법이 알맞은 항목에 쓰인다.
• 순위가 매겨진 백로그와 점수가 이해관계자에게 공표된다.
• 상충 관계가 공개적으로 협상된다: 하나를 올리려면 다른 하나가 내려간다.
• 재조정이 정해진 주기로 이루어지며 그 사이에 안정적인 활주로가 있다.
• 점수는 추정으로 다루어지며 조작과 거짓 정밀함을 경계한다.
• 현재 순서를 이사회에 설명하고 방어할 수 있다.

주요 출처#

• Scaled Agile Framework (SAFe) — Weighted Shortest Job First (WSJF)와 지연 비용.
• Reinertsen, D. — The Principles of Product Development Flow (지연 비용, 대기열 경제학).
• Intercom — RICE 점수 모형(Reach, Impact, Confidence, Effort).
• DSDM / Agile Business Consortium — MoSCoW 우선순위 설정.
• Kano, N. — 고객 만족의 Kano 모형.
• Cabinet Office / AXELOS — Management of Portfolios (MoP) — 포트폴리오 우선순위 설정과 균형.
• NHS Digital Service Standard & GOV.UK Service Manual — 가장 중요한 사용자 필요를 우선하기; 성과 정렬을 위한 OKR (Doerr, Measure What Matters).

참고문헌#

1. Prioritization — Wikipedia — https://en.wikipedia.org/wiki/Prioritization
2. Cost of delay — Wikipedia — https://en.wikipedia.org/wiki/Cost_of_delay
3. Scaled agile framework — Wikipedia — https://en.wikipedia.org/wiki/Scaled_agile_framework
4. MoSCoW method — Wikipedia — https://en.wikipedia.org/wiki/MoSCoW_method
5. Dynamic systems development method — Wikipedia — https://en.wikipedia.org/wiki/Dynamic_systems_development_method
6. Kano model — Wikipedia — https://en.wikipedia.org/wiki/Kano_model
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Objectives and key results — Wikipedia — https://en.wikipedia.org/wiki/Objectives_and_key_results
9. Weighted Shortest Job First (WSJF) and Cost of Delay — Scaled Agile Framework (SAFe) — https://framework.scaledagile.com/wsjf
10. Reinertsen, D. — The Principles of Product Development Flow — Celeritas Publishing — https://www.celeritas.com/
11. The RICE scoring model (Reach, Impact, Confidence, Effort) — Intercom — https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/
12. MoSCoW prioritisation — DSDM / Agile Business Consortium — https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html
13. Management of Portfolios (MoP) — AXELOS / Cabinet Office — https://www.axelos.com/
14. Doerr, J. — Measure What Matters (OKRs) — Portfolio/Penguin — https://www.whatmatters.com/
15. The Green Book: appraisal and evaluation in central government (five-case model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-government