Тема 5.0 — Работа, ведомая продуктом

В одном предложении: Работа, ведомая продуктом, финансирует устойчивые, наделённые полномочиями команды, чтобы они владели услугой на протяжении всей её жизни и отвечали за измеримые результаты, а не за поставку фиксированного списка функций.

Почему это важно в здравоохранении и уходе#

Большая часть того, чем управляют организации цифрового здравоохранения и ухода, — не разовая поставка, а живая услуга. NHS App, электронная медицинская карта, общая запись ухода, путь электронного направления, система ведения дел социального ухода: ничто из этого не «закончено». Их нужно непрерывно улучшать по мере изменения клинических руководств, появления инцидентов безопасности, смещения спроса и развития окружающего хозяйства.

Когда вы управляете живой услугой как серией разрозненных проектов, получается предсказуемый провал: поставщик строит по спецификации, деньги кончаются, команда распускается, и услугу оставляют гнить до следующей капитальной заявки. Клиницисты обходят пробелы, риски безопасности пациентов накапливаются, а страдает равенство, потому что люди, меньше всех способные терпеть неуклюжую услугу, — те, у кого самая большая потребность. Работа, ведомая продуктом, существует, чтобы разорвать этот цикл. Она держит стабильную команду рядом с пользователями и результатами, так что услуга со временем становится безопаснее, удобнее и справедливее, а не деградирует между раундами финансирования.

Ставки также финансовые и законные. Общественные деньги лучше защищены командой, непрерывно проверяющей, действительно ли услуга улучшает уход, чем проектом, измеряющим успех как «поставлено в срок и в бюджет» независимо от того, получил ли кто-нибудь пользу. Эта тема стоит рядом с темой 5.1 — Работа, ведомая проектами, и темой 5.2 — Работа, ведомая программами; три — взаимодополняющие инструменты, а не соперники, а тема 5.3 — Управление корпоративным портфелем и проектами (EPPM) объясняет, как держать их вместе.

Ключевые понятия#

Устойчивая продуктовая команда. Кросс-функциональная долгоживущая команда, владеющая продуктом или услугой на протяжении всего жизненного цикла. Команда сохраняется; работа течёт к ней. Это атомарная единица продуктовой операционной модели, описанной Marty Cagan и Silicon Valley Product Group (SVPG): стабильная группа из менеджера по продукту, продуктового дизайнера и инженеров, поддерживаемая клинической экспертизой и экспертизой по данным в контексте здравоохранения.

Наделённая полномочиями команда. Cagan проводит резкую границу между «командой функций» (feature team), которой вручают дорожную карту того, что нужно построить, и «наделённой полномочиями командой» (empowered team), которой вручают проблемы для решения и результаты для достижения и которой доверяют найти лучшее решение. Наделение полномочиями — не лицензия делать что угодно; это подотчётность за результаты в рамках ясной стратегической рамки.

Результаты вместо выходных продуктов. Выход — то, что вы поставляете: функция, релиз, экран. Результат — изменение в мире, которое из этого следует: меньше пропущенных приёмов, быстрее выписка, меньше ошибок с лекарствами, более справедливый охват. Работа, ведомая продуктом, измеряет команды по результатам, потому что поставка функции, которой никто не пользуется или от которой никто не безопаснее, — расточительство, наряженное прогрессом.

Менеджер по продукту. Руководитель управления продуктом, отвечающий за ценность и жизнеспособность продукта: стоит ли это строить, будут ли люди использовать, согласуется ли это со стратегией, регуляторикой и финансами организации? В здравоохранении и уходе эта роль должна тесно сотрудничать с руководителями по клинической безопасности и управлению информацией, а не стоять над ними.

Продуктовая операционная модель. SVPG явно подчёркивает, что это модель, а не методология или жёсткая рамка: набор принципов о том, как компания строит и эксплуатирует технологические продукты, — наделённые полномочиями команды, подотчётность за результат, непрерывное исследование (discovery) и продуктовая стратегия, — а не предписанный процесс, который устанавливают.

Жизненный цикл продукта. Исследование (есть ли реальная проблема, достойная решения?), поставка (построить безопасно и хорошо), рост и оптимизация (улучшить принятие и результаты) и, наконец, вывод (изящно закрыть или заменить). Продуктовые команды владеют всем этим, поэтому могут принимать разумные компромиссы на весь срок жизни, недоступные проектной команде.

Лучшие практики#

1. Финансируйте команду, а не проект. Переносите деньги из ограниченных по времени проектных бюджетов в постоянные продуктовые бюджеты, привязанные к потоку создания ценности, как доказывает Mik Kersten в Project to Product. Финансируйте постоянную команду для достижения результатов в последовательных циклах планирования и пересматривайте финансирование по продемонстрированным результатам, а не по плану вех, согласованному годами ранее.

2. Давайте командам проблемы и результаты, а не списки функций. Формулируйте мандат как «снизить долю неявок в амбулаторных приёмах» или «сократить время, которое клиницист тратит на поиск результата», затем позвольте наделённой полномочиями команде открыть лучшее решение. Дорожная карта обязательных функций, спущенная сверху, воссоздаёт антипаттерн команды функций, от которого предостерегает Cagan.

3. Делайте меры результатов явными и клинически значимыми. Заранее согласуйте небольшой набор метрик результатов, в идеале как цели и ключевые результаты (OKR; см. тему 7.3). Сопровождайте каждую метрику эффективности метрикой безопасности и метрикой равенства, чтобы команда никогда не вознаграждалась за скорость ценой вреда или расширения неравенства.

4. Держите команду рядом с реальными пользователями. Встройте непрерывное исследование: регулярный контакт с клиницистами, работниками ухода, администраторами и пациентами. NHS Service Manual и GOV.UK Service Manual делают исследование пользователей постоянной дисциплиной, а не разовой фазой. Устойчивая команда делает это доступным, потому что отношения сохраняются.

5. Стройте многопрофильные команды с клинической безопасностью внутри. Цифровой продуктовой команде здравоохранения нужны, наряду с продуктом/дизайном/инженерией, офицер клинической безопасности (DCB0129/DCB0160), управление информацией и экспертиза по данным. Безопасность и управление — проектные входы, которыми владеют внутри команды, а не шлюзы, приделанные в конце.

6. Оснащайте продукт измерениями и действуйте на основе данных. Устойчивые команды могут вкладываться в телеметрию, так что решения основаны на реальном использовании и реальных результатах, а не на мнениях. Следите за принятием по когортам, чтобы рано заметить цифровое исключение.

7. Владейте всем жизненным циклом, включая вывод. Наделённые полномочиями команды планируют изящное закрытие и миграцию, а не только запуск. Решение не продолжать строить и консолидироваться на стратегической платформе — законное и ценное продуктовое решение.

8. Согласуйте команды через стратегию, а не микроменеджмент. Автономия без согласованности порождает локальную оптимизацию и хаос. Ясные продуктовая видение и стратегия — а в масштабе портфельная и программная рамка (темы 5.2 и 5.3) — позволяют безопасно наделять команды полномочиями.

Вопросы для обсуждения с командой#

1. Какие из услуг, которыми мы управляем сегодня, действительно живые услуги, заслуживающие устойчивой финансируемой продуктовой команды, а какие — конечная работа, которой мы только притворяемся, что она нужна? Это основополагающий вопрос сортировки, и ошибка в любую сторону дорога. В организации цифрового здравоохранения и ухода хозяйство смешанное: общая запись ухода или приложение для пациентов — живая услуга, но разовый вывод из ЦОДа или обновление оборудования — действительно конечная работа, и честный ответ требует назвать каждую значимую систему и обосновать её случай, а не применять одну модель финансирования везде. Напряжение в том, что механизм финансов и управления обычно толкает всё к ограниченным по времени капитальным заявкам, так что называть что-то «продуктом» может казаться особым пледированием, тогда как называть живую услугу «проектом» тихо гарантирует распад по схеме «построил и бросил», описанный выше в теме. Подумайте о стоимости полного жизненного цикла, скорости, с которой меняются клинические руководства и спрос вокруг услуги, и накапливается ли риск безопасности пациентов, когда никто не владеет непрерывным улучшением. Хороший ответ называет две-три услуги, где устойчивая команда явно оправдана, откровенен о пограничных и явно откладывает конечную работу для темы 5.1, а не защищает общее правило.

2. Какие две-три метрики результатов мы действительно поставили бы под финансирование команды и как мы сопровождаем каждую мерой безопасности и равенства, чтобы никогда не вознаграждать скорость ценой вреда? «Результаты вместо выходов» легко сказать и трудно операционализировать, потому что в момент, когда метрика управляет деньгами, она начинает искажать поведение. Цифровая команда здравоохранения, которой сказали «снизить долю неявок», может достичь числа, подталкивая наиболее цифрово уверенных пациентов и тихо расширяя разрыв для пожилых или более неблагополучных когорт: поэтому спор должен выявить, какую единственную метрику эффективности каждая команда может переоптимизировать и что на самом деле измеряет сопутствующий барьер безопасности и равенства. Принесите на стол конкретных кандидатов (меньше ошибок с лекарствами, быстрее выписка, охват по местности или прокси цифрового доступа) и проверьте на прочность, клинически ли они значимы или просто легко измеряются. Подумайте, кому принадлежит каждая метрика, какова базовая линия и как часто она пересматривается, потому что бесхозный или без базовой линии результат — декорация. Честный ответ принимает, что некоторые результаты, которые нам важны, медленны или трудны для измерения, сопротивляется тяге к тщеславным числам принятия и обязуется публиковать меру равенства рядом с мерой эффективности, чтобы компромисс оставался видимым.

3. Сколько реальной власти мы готовы дать наделённой полномочиями команде менять направление и какая стратегическая рамка не даёт этой автономии раздробиться в локальную оптимизацию? Наделение полномочиями — суть продуктовой операционной модели и одновременно её самая частая подделка, потому что организации переименовывают команды в «продуктовые», по-прежнему спуская фиксированную дорожную карту и измеряя поставку. Подлинный вопрос — где проходит граница: может ли команда перейти от функции, спонсируемой советом, к другому решению, когда исследование показывает, что оно лучше реализует результат, или клиническое управление, управление информацией и существующие контракты с поставщиками наложат на это вето на практике? Напряжение в том, что автономия без согласованности порождает дублирование и дрейф по ICS, а согласованность, навязанная как микроменеджмент, воссоздаёт фабрику функций, поэтому ответ лежит в явной продуктовой видении и стратегии, а в масштабе — в портфельной рамке, ограничивающей, не диктуя. Подумайте о недавнем решении, когда команда хотела сменить курс, и честно спросите, позволила ли это система. Хороший ответ определяет решения, которые команда может принимать сама, против тех, что требуют эскалации, называет стратегический документ, дающий рамку, и откровенен о том, где организация сейчас путает контроль с согласованностью.

4. Как мы финансируем и защищаем устойчивую команду в годовом бюджетном цикле и что мы на самом деле сделаем, когда финансы попросят оправдать «продукт» без фиксированной даты окончания? Работа, ведомая продуктом, держится или падает на деньгах, а механизм финансов NHS и государственного сектора построен для ограниченных по времени капитальных заявок, а не для скользящего текущего финансирования, привязанного к потоку создания ценности, — так что этот вопрос вынуждает к неудобным операционным деталям за словами «финансируйте команду, а не проект». Напряжение в том, что устойчивой команде нужна многолетняя стабильность, чтобы удерживать дефицитных клинических, продуктовых и инженерных людей, но урегулирование, от которого она зависит, ежегодно переборется против капитальных схем, показывающих аккуратные начало и конец. Принесите реальные числа: каков постоянный расход команды, какому потоку ценности она соответствует и какие доказательства продемонстрированных результатов оправдали бы повторное разрешение против плана вех, согласованного годами ранее. Подумайте, как правила учёта капитальных и текущих расходов, закупочные циклы и контракты с поставщиками помогают модели или борются с ней в вашей организации. Честный ответ называет, кто подписывает скользящий бюджет, что происходит с командой в плохой год урегулирования и готова ли организация превратить подлинную услугу в продуктовую линию, а не тихо вернуть её по умолчанию к проектным заявкам.

5. Когда работа, ведомая продуктом, встречается с нашими обязанностями по клинической безопасности и управлению информацией, действительно ли безопасность и управление находятся внутри команды как проектные входы или они всё ещё шлюзы, к которым команда мчится и которые обходит торгами? Устойчивая, наделённая полномочиями команда, поставляющая непрерывно, меняет картину риска, потому что каждая итерация — потенциальное событие клинической безопасности и защиты данных, а не единая подпись в конце проекта, так что работа по опасностям DCB0129/DCB0160 и DPIA должна жить внутри ритма команды, а не пристраиваться на шлюзе релиза. Напряжение реально: встроить офицера клинической безопасности и руководителя по управлению информацией в каждую продуктовую команду дорого, а эти навыки дефицитны, так что организации соблазняются делить их тонко или считать гарантии одобрением, которого команда ищет поздно. Именно этот соблазн воссоздаёт провал «построил и бросил» для безопасности, потому что команда, оптимизирующая метрику результата под давлением поставки, без внутреннего голоса безопасности обнаружит вред только после того, как он достигнет пациентов. Подумайте, как дело безопасности поддерживается живым по многим малым релизам, кто владеет журналом опасностей и есть ли у коллег по управлению реальное влияние на исследование и приоритизацию или только вето в конце. Хороший ответ откровенен о том, где безопасность сейчас шлюз, а не проектный вход, и обязуется предоставить кадры и ритм, делающие непрерывные гарантии доступными.

6. Как мы удержим устойчивую команду по-настоящему близкой к недообслуженным пользователям, чтобы непрерывное улучшение сужало, а не расширяло цифровое исключение? Работа, ведомая продуктом, обещает равенство как первоклассный результат, но стабильная команда, оснащающая измерениями собственный продукт, естественно услышит громче всех тех пользователей, которые уже взаимодействуют, — цифрово уверенных, подключённых, тех, кто виден в телеметрии, — так что близость к пользователям может тихо стать близостью к лёгким пользователям. Напряжение в том, что когорты, наиболее подверженные исключению (пожилые пациенты, люди в неблагополучных местностях, с низким цифровым доступом или языковыми барьерами), труднее и дороже всего достичь через непрерывное исследование, но именно им служба общественного здравоохранения и существует. Принесите на стол конкретную практику: какие когорты сознательно привлекаются в исследования, как отслеживается принятие по местности и прокси цифрового доступа и какой нецифровой резерв существует, когда цифровой путь оставляет кого-то позади. Подумайте, меняет ли метрика равенства команды решения или просто отчитывается. Честный ответ признаёт, где текущий пул исследования смещён к легкодоступным, называет недообслуженные группы, которых команда ещё не слышит, и описывает конкретные вложения — выход к людям, помощь в цифровом доступе, телефонный резерв, — не дающие улучшению накапливать преимущество.

На практике: пример из здравоохранения и ухода#

Интегрированная система ухода (ICS) ведёт приложение для пациентов по управлению приёмами, используемое в нескольких трастах. Исторически каждое улучшение было отдельным проектом: поставщика нанимали «добавить SMS-напоминания», он поставлял и уходил. Через шесть месяцев напоминания срабатывали неверно, исправление никому не принадлежало, а для повторного открытия контракта требовалась капитальная заявка.

ICS переходит к продуктовой модели. Она создаёт устойчивую продуктовую команду — менеджер по продукту, дизайнер, четыре инженера, офицер клинической безопасности и руководитель по управлению информацией, — финансируемую на скользящей основе и получившую мандат с результатом, а не со списком функций: снизить долю неявок (DNA) и улучшить равенство доступа по всему населению.

Команда ведёт непрерывное исследование с пациентами и планировщиками амбулаторных приёмов. Она узнаёт, что напоминания помогают, но более сильный драйвер неявок в одной неблагополучной местности в том, что пациенты не могут легко перезаписаться и просто пропускают слот. Поскольку команда владеет результатом, а не спецификацией, она переносит инвестиции с эффектной функции уведомлений на простой процесс самостоятельной перезаписи и оснащает измерениями принятие по местности и по прокси цифрового доступа.

За три цикла планирования доля неявок падает, и — принципиально — команда отслеживает метрику равенства и замечает, что принятие отстаёт среди пожилых пациентов, что побуждает создать телефонный резервный путь, чтобы цифровой путь не расширял неравенство. Финансирование продолжается, потому что результаты демонстрируемы. Ни одна функция никогда не была «подписана и брошена»; услуга просто продолжает улучшаться. Когда позднее национальная платформа предлагает ту же возможность, та же команда ведёт миграцию и закрывает собственный компонент — решение на весь срок жизни, на которое проектная команда никогда не была бы поставлена.

Секторные линзы#

Стартап#

В небольшой цифровой компании здравоохранения работа, ведомая продуктом, — режим по умолчанию, часто единственный: одна наделённая полномочиями команда, иногда вся компания, владеет продуктом от начала до конца. Ограничивающий фактор — финансирование, потому что запас хода от инвесторов или гранты означают, что команда должна показать тягу по результатам (принятие, удержание, ранний клинический сигнал) достаточно быстро, чтобы оправдать следующий раунд, так что непрерывное исследование и измерения — инструменты выживания, а не роскошь. Аппетит к риску высок, а подотчётность идёт к основателям и инвесторам, а не к совету или обществу, так что команда может менять курс за дни. Ловушка — считать клиническую безопасность и управление информацией (DCB0129, DPIA) корпоративными накладными расходами, которые можно отложить: в здравоохранении эта дисциплина необсуждаема даже на посевной стадии, а покупатели NHS потребуют доказательств DTAC, прежде чем подпустят вас к данным пациентов.

Малый бизнес#

Для устоявшегося малого поставщика — общей практики, общинной аптеки, дома ухода или агентства ухода на дому, клиники на одной площадке или небольшого поставщика технологий здравоохранения, перешагнувшего стадию стартапа, — работа, ведомая продуктом, редко означает создание выделенной кросс-функциональной команды, потому что нет свободного менеджера по продукту, дизайнера или инженера, которого можно финансировать. Здесь «устойчивая команда» часто — управляющий практикой или зарегистрированный менеджер плюс доверенный поставщик, поэтому важная дисциплина — спрашивать с того, кто настраивает и поддерживает систему, за результаты — меньше пропущенных приёмов, безопаснее сверка лекарств, лучший доступ для самых немощных жильцов, — а не за разовую установку. Деньги ограничены и текущие, а не ограничены запасом хода, поэтому разумный ход — вкладываться в продукты, которые поддерживают другие (дорожная карта хорошо управляемого поставщика, общая запись ухода, платформа ICS), а не заказывать индивидуальные сборки, которые никто не будет поддерживать. Клиническая безопасность и управление информацией действуют в полной мере — те же обязанности внедрения DCB0160 и обязательства DPIA, что у крупного траста, — но без внутренней возможности, что делает выбор поставщиков, владеющих своим делом безопасности, подлинным продуктовым решением. Аспект равенства близок: малый поставщик часто обслуживает именно тех пожилых или более неблагополучных пациентов, которые больше всех подвержены цифровому исключению, так что сохранение нецифрового резерва — не прихоть, а необходимость.

Предприятие#

В крупном трасте NHS, интегрированной системе ухода (ICS) или фирме технологий здравоохранения модель устойчивой команды сталкивается с годовым капитальным бюджетированием и проектно-ориентированной финансовой машиной. Основная работа — преобразование постоянных услуг — команды оптимизации EPR, команды общей записи ухода — из стоп-стартовых проектов в финансируемые продуктовые команды со скользящими бюджетами, привязанными к потокам ценности, что является финансовым и управленческим изменением не меньше, чем оргсхемой. Подотчётность многослойна: клиническое управление, управление информацией, гарантии совета и контракты с поставщиками, так что наделение полномочиями должно сочетаться с явной продуктовой стратегией и портфельной согласованностью (см. тему 5.3 — Управление корпоративным портфелем и проектами), чтобы десятки автономных команд не оптимизировали локально. Масштаб — враг близости к пользователям, поэтому целенаправленные инвестиции во встроенное исследование удерживают команды крупной организации честными.

Правительство#

В национальном масштабе — NHS England, DHSC, UKHSA — работа, ведомая продуктом, финансирует долгоживущие платформы (NHS App, NHS login, национальные API интероперабельности) как продукты, а не программы, оцениваемые по Service Standard GDS и NHS и их оценкам услуг. Финансирование идёт через урегулирования Spending Review и бизнес-кейсы, так что трудная часть — сохранять стабильные команды через финансовые годы и политические циклы, когда окружающий механизм построен для ограниченных по времени проектов. Подотчётность — перед министрами, парламентом и обществом через National Audit Office, а обязанность равенства законодательная, так что метрики результатов должны сопровождаться опубликованными мерами равенства на уровне населения. Приз — охват: одно улучшение продукта может затронуть десятки миллионов пользователей сразу, что поднимает и выгоду, и цену ошибки.

Типичные виды отказов#

• Ведомое продуктом только по названию («фабрика функций»). Организация переименовывает проектные команды в «продуктовые», но по-прежнему спускает им фиксированную дорожную карту и измеряет по поставке. Исправление: меняйте мандат и метрики, а не только названия должностей.
• Результаты без барьера безопасности или равенства. Оптимизация единственной метрики эффективности может скрыть вред или расширить исключение. Исправление: каждая метрика результата сопровождается мерой безопасности и мерой равенства.
• «Наделение полномочиями» без стратегии. Команды, оставленные изобретать собственное направление, дрейфуют и дублируют. Исправление: сильная продуктовая видение и стратегия и согласованность на уровне портфеля (тема 5.3).
• Применение продуктового подхода к подлинно конечной работе. Разовая миграция ЦОДа или развёртывание оборудования не нуждаются в вечной команде. Исправление: используйте работу, ведомую проектами (тема 5.1), где объём действительно фиксирован.
• Финансирование, возвращающееся к годовым проектным заявкам. Устойчивая команда на стоп-стартовом бюджете не может планировать и удерживать людей. Исправление: скользящее, пересматриваемое по результатам финансирование потока ценности.
• Менеджер по продукту как писатель тикетов. Сведение роли к администрированию бэклога тратит её впустую. Исправление: спрашивайте с менеджера по продукту за ценность, жизнеспособность и результаты.

Модель зрелости#

Контрольный список#

• Это действительно постоянная услуга (не конечная работа), подходящая для устойчивой команды?
• Стабильная кросс-функциональная команда владеет продуктом на протяжении всего жизненного цикла?
• Команде дан мандат с проблемами и результатами, а не фиксированным списком функций?
• Метрики результатов согласованы, и каждая сопровождается мерой безопасности и равенства?
• Клиническая безопасность (DCB0129/DCB0160) и управление информацией находятся внутри команды?
• Команда финансируется на скользящей основе и повторно разрешается по продемонстрированным результатам?
• Непрерывное исследование пользователей — постоянная практика?
• Продукт оснащён измерениями, а принятие отслеживается по когортам для выявления исключения?
• Есть ясная продуктовая стратегия, согласующая автономию с целями организации?
• Изящный вывод/миграция запланированы как явная стадия жизненного цикла?

Ключевые источники#

• Silicon Valley Product Group (SVPG), Marty Cagan — The Product Operating Model: An Introduction и Empowered Product Teams (svpg.com); книги Inspired, Empowered и Transformed.
• Mik Kersten — Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework (IT Revolution, 2018).
• NHS England — NHS Service Manual и NHS Digital Service Standard.
• GOV.UK — Government Digital Service (GDS) Service Manual и Service Standard.
• Стандарты клинической безопасности NHS Digital DCB0129 (производство) и DCB0160 (внедрение) ИТ-систем здравоохранения.
• John Doerr — Measure What Matters (OKR) для постановки целей на основе результатов.

Литература#

1. Product management — Wikipedia — https://en.wikipedia.org/wiki/Product_management
2. Product lifecycle — Wikipedia — https://en.wikipedia.org/wiki/Product_lifecycle
3. Cross-functional team — Wikipedia — https://en.wikipedia.org/wiki/Cross-functional_team
4. Value stream — Wikipedia — https://en.wikipedia.org/wiki/Value_stream
5. Objectives and key results (OKR) — Wikipedia — https://en.wikipedia.org/wiki/OKR
6. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
7. NHS App — Wikipedia — https://en.wikipedia.org/wiki/NHS_App
8. Digital divide — Wikipedia — https://en.wikipedia.org/wiki/Digital_divide
9. The Product Operating Model / Inspired, Empowered, Transformed — Marty Cagan, Silicon Valley Product Group — https://www.svpg.com/
10. Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework — Mik Kersten, IT Revolution (2018) — https://itrevolution.com/product/project-to-product/
11. NHS service manual and NHS Digital Service Standard — NHS England — https://service-manual.nhs.uk/
12. GOV.UK Service Manual and Service Standard — Government Digital Service — https://www.gov.uk/service-manual
13. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety
14. Measure What Matters — John Doerr — https://www.whatmatters.com/