الموضوع 5.0 — العمل المُوجَّه بالمنتج

بإيجاز: يُموِّل العمل المُوجَّه بالمنتج فرقًا دائمة ومُمكَّنة لتملك خدمة طوال حياتها، تُحمِّلها المسؤولية عن نتائج قابلة للقياس بدلًا من تسليم قائمة ميزات ثابتة.

لماذا يهم هذا في الصحة والرعاية#

معظم ما تُشغِّله مؤسسات الصحة والرعاية الرقمية ليس تسليمًا لمرة واحدة — إنها خدمة حية. تطبيق NHS، سجل صحي إلكتروني، سجل رعاية مشترك، مسار إحالة إلكتروني، نظام إدارة حالات رعاية اجتماعية: لا شيء من هذا "منتهٍ". يجب تحسينها باستمرار مع تغير الإرشاد السريري، ظهور حوادث سلامة، تحول الطلب، وتطور الأصول حولها.

عندما تُدير خدمة حية كسلسلة من مشاريع مُنفصِلة، تحصل على فشل متوقع: يبني مورد لمواصفة، ينفد المال، يُحَل الفريق، وتُترَك الخدمة لتتعفن حتى عرض رأسمالي تالٍ. يعمل الأطباء حول الفجوات، تتراكم مخاطر سلامة المريض، ويُعاني الإنصاف لأن الناس الأقل قدرة على تحمل خدمة أخرقة هم من أعظم حاجة. يوجد العمل المُوجَّه بالمنتج لكسر تلك الدورة. يحفظ فريقًا مستقرًا قريبًا من المستخدمين والنتائج، بحيث تُصبح الخدمة أكثر أمانًا، قابلية للاستخدام، وإنصافًا بمرور الوقت بدلًا من التدهور بين جولات التمويل.

المخاطر أيضًا مالية وقانونية. يُحمَى المال العام بشكل أفضل بواسطة فريق يُتحقَّق باستمرار مما إذا كانت خدمة تُحسِّن الرعاية فعليًا من مشروع يقيس النجاح كـ"سُلِّم في الوقت وضمن الميزانية" بغض النظر عن ما إذا استفاد أحد. يجلس هذا الموضوع جنبًا إلى جنب مع الموضوع 5.1 — العمل المُوجَّه بالمشروع والموضوع 5.2 — العمل المُوجَّه بالبرنامج؛ الثلاثة أدوات مُكمِّلة، لا منافسة، ويشرح الموضوع 5.3 — إدارة محفظة ومشاريع المؤسسة (EPPM) كيف تحفظها معًا.

مفاهيم جوهرية#

فريق منتج دائم. فريق متعدد الوظائف وطويل العمر يملك منتجًا أو خدمة عبر دورة حياتها الكاملة. يستمر الفريق؛ يتدفق العمل إليه. هذه الوحدة الذرية لنموذج تشغيل المنتج الذي وصفه Marty Cagan وSilicon Valley Product Group (SVPG): مجموعة مستقرة من مدير منتج، مُصمِّم منتج، ومهندسين، مدعومة بخبرة سريرية وبيانات في سياق صحي.

فريق مُمكَّن. يرسم Cagan خطًا حادًا بين "فريق ميزات" يُسلَّم خارطة طريق لأشياء يبنيها، و"فريق مُمكَّن" يُسلَّم مشاكل ليحلها ونتائج ليُحقِّقها، ويُوثَق به لإيجاد أفضل حل. التمكين ليس ترخيصًا لفعل أي شيء؛ إنه مساءلة عن النتائج ضمن إطار استراتيجي واضح.

النتائج فوق المخرجات. المخرجة هي ما تشحنه — ميزة، إصدار، شاشة. النتيجة هي التغيير في العالم الناتج — مواعيد فائتة أقل، خروج أسرع، أخطاء دواء مُقلَّلة، تبنٍ أكثر إنصافًا. يقيس العمل المُوجَّه بالمنتج الفرق على النتائج، لأن شحن ميزة لا يستخدمها أحد، أو لا يُصبح أحد أكثر أمانًا بسببها، هدر مُزيَّن كتقدم.

مدير منتج. قائد إدارة المنتج، مساءل عن قيمة وقابلية تطبيق المنتج: هل يستحق هذا البناء، هل سيستخدمه الناس، هل يُناسِب استراتيجية المؤسسة، لوائحها، وماليتها؟ في الصحة والرعاية، يجب أن يُشارِك هذا الدور بشدة مع قادة السلامة السريرية وحوكمة المعلومات، لا يجلس فوقهم.

نموذج تشغيل المنتج. يُوضِّح SVPG صراحة أن هذا نموذج، لا منهجية أو إطار صارم: مجموعة مبادئ حول كيف تبني وتُشغِّل شركة منتجات مُمكَّنة تقنيًا — فرق مُمكَّنة، مساءلة نتائج، استكشاف مستمر، واستراتيجية منتج — بدلًا من عملية مُوصَفة تُثبِّتها.

دورة حياة المنتج. الاستكشاف (هل توجد مشكلة حقيقية تستحق الحل؟)، التسليم (ابنه بأمان وجودة)، النمو والتحسين (حسِّن التبني والنتائج)، وأخيرًا الغروب (تقاعد أو استبدل بلطف). تملك الفرق المُوجَّهة بالمنتج كل ذلك، وهذا لماذا تستطيع اتخاذ مفاضلات حياة كاملة منطقية لا يستطيع فريق مشروع اتخاذها.

أفضل الممارسات#

1. مَوِّل الفريق، لا المشروع. انقل المال من ميزانيات مشروع محدودة بالوقت لميزانيات منتج دائمة مربوطة بـدفق قيمة، كما يجادل Mik Kersten في Project to Product. مَوِّل فريقًا دائمًا لمتابعة نتائج عبر دورات تخطيط متتالية، وأعد تفويض التمويل بناءً على نتائج مُثبَتة، لا خطة معلم مُتَّفَق عليها منذ سنوات.

2. أعطِ الفرق مشاكل ونتائج، لا قوائم ميزات. صمِّم التفويض كـ"قلِّل معدلات عدم الحضور في العيادات الخارجية" أو "قلِّل الوقت الذي يصرفه طبيب في إيجاد نتيجة"، ثم دع الفريق المُمكَّن يكتشف أفضل حل. خارطة طريق ميزات مُلتزَم بها مُسلَّمة من الأعلى تُعيد إنشاء نمط فريق-الميزات المضاد الذي يُحذِّر منه Cagan.

3. اجعل مقاييس النتيجة صريحة وذات معنى سريري. اتفق على مجموعة صغيرة من مقاييس النتيجة مقدمًا، مثاليًا كـأهداف ونتائج رئيسية (OKRs — انظر الموضوع 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 وDPIAs داخل وتيرة الفريق، لا يُلحَق ببوابة إصدار. التوتر حقيقي: دمج ضابط سلامة سريرية وقائد حوكمة معلومات في كل فريق منتج مُكلِف وتلك المهارات نادرة، لذا تُغرَى المؤسسات بمشاركتهم برقة أو معاملة الضمان كموافقة يسعى إليها الفريق متأخرًا. ذلك الإغراء هو بالضبط ما يُعيد إنشاء فشل البناء-والترك للسلامة، لأن فريقًا يُحسِّن مقياس نتيجة تحت ضغط تسليم سيكتشف، دون صوت سلامة داخلي، الضرر فقط بعد وصوله للمرضى. فكّر كيف تُحفَظ حالة السلامة حية عبر إصدارات صغيرة كثيرة، من يملك سجل المخاطر، وما إذا كان لزملاء الحوكمة تأثير حقيقي على الاستكشاف وترتيب الأولويات أو فقط حق نقض في النهاية. إجابة جيدة صريحة حول أين السلامة بوابة حاليًا بدلًا من مُدخَل تصميم، وتلتزم بالتزويد بالموظفين والوتيرة التي تجعل الضمان المستمر ميسورًا.

6. كيف سنحفظ فريقًا دائمًا قريبًا فعليًا من مستخدمين ناقصي الخدمة بحيث يُضيِّق التحسين المستمر بدلًا من توسيع الاستثناء الرقمي؟ يَعِد العمل المُوجَّه بالمنتج بالإنصاف كنتيجة من الدرجة الأولى، لكن فريقًا مستقرًا يُجهِّز منتجه الخاص سيسمع بشكل طبيعي بأعلى صوت من المستخدمين المُشارِكين بالفعل — الواثقون رقميًا، المتصلون، من يظهرون في التتبع عن بُعد — لذا يمكن أن يُصبح القرب من المستخدمين بهدوء قربًا من المستخدمين السهلين. التوتر هو أن الفئات الأكثر خطرًا للاستثناء (مرضى أكبر سنًا، ناس في مناطق محرومة، من لديهم وصول رقمي منخفض أو حواجز لغة) الأصعب والأكثر تكلفة للوصول إليها من خلال الاستكشاف المستمر، لكنهم بالضبط الناس الذين توجد خدمة صحية عامة لخدمتهم. أحضر ممارسة ملموسة للطاولة: أي فئات مُجنَّدة عمدًا للبحث، كيف يُراقَب التبني بالمنطقة ومؤشر الوصول الرقمي، وأي رجوع غير رقمي موجود عندما يترك المسار الرقمي شخصًا خلفًا. فكّر ما إذا كان مقياس إنصاف الفريق يُغيِّر قرارات فعليًا أو يُبلَّغ عنه فقط. إجابة أمينة تعترف بأين تنحرف مجموعة البحث الحالية نحو الأسهل وصولًا، تُسمّي المجموعات ناقصة الخدمة التي لا تسمع منها بعد، وتصف الاستثمار المحدد — توعية، رقمي مُساعَد، رجوع هاتفي — الذي يمنع التحسين من تراكم الميزة.

في الممارسة: مثال من الصحة والرعاية#

يُشغِّل نظام رعاية متكامل (ICS) تطبيق إدارة مواعيد مواجه للمرضى مُستخدَمًا عبر عدة مؤسسات ائتمانية. تاريخيًا كان كل تحسين مشروعًا منفصلًا: كُلِّف مورد "بإضافة تذكيرات SMS"، سلَّمها، ورحل. بعد ستة أشهر، كانت التذكيرات تُطلَق خطأ، لم يملك أحد الإصلاح، واحتُجنا عرضًا رأسماليًا لإعادة فتح العقد.

يتحول ICS لنموذج مُوجَّه بالمنتج. يُقيم فريق منتج دائم — مدير منتج، مُصمِّم، أربعة مهندسين، ضابط سلامة سريرية، وقائد حوكمة معلومات — مُموَّل على أساس متجدد ومُكلَّف بنتيجة، لا قائمة ميزات: قلِّل معدل عدم الحضور (DNA) وحسِّن إنصاف الوصول عبر الفئة السكانية.

يُشغِّل الفريق استكشافًا مستمرًا مع مرضى ومُجدوِلي عيادات خارجية. يتعلمون أن التذكيرات تساعد، لكن المُحفِّز الأكبر لـDNAs في منطقة محرومة واحدة هو أن المرضى لا يستطيعون إعادة الحجز بسهولة، فيُفوِّتون الفترة ببساطة. لأن الفريق يملك النتيجة بدلًا من مواصفة، يُحوِّل الاستثمار من ميزة إشعارات لامعة لتدفق إعادة حجز ذاتي بسيط، ويُجهِّزون التبني بالمنطقة وبمؤشر الوصول الرقمي.

عبر ثلاث دورات تخطيط، ينخفض معدل DNA، و— بشكل حاسم — يُراقِب الفريق مقياس الإنصاف ويكتشف أن التبني يتأخر بين المرضى الأكبر سنًا، يدفع مسار رجوع هاتفي بحيث لا يُوسِّع المسار الرقمي عدم المساواة. يستمر التمويل لأن النتائج قابلة للإظهار. لم تُوافَق ميزة أبدًا وتُترَك؛ الخدمة تستمر بالتحسين ببساطة. عندما تُقدِّم منصة وطنية لاحقًا نفس القدرة، يُشغِّل نفس الفريق الهجرة ويُغرِب مكوّنه الخاص — قرار حياة كاملة لن يكون فريق مشروع أبدًا في موضع لاتخاذه.

عدسات قطاعية#

شركة ناشئة#

في شركة صحة رقمية صغيرة، العمل المُوجَّه بالمنتج هو الافتراضي — غالبًا الوضع الوحيد: فريق مُمكَّن واحد، أحيانًا الشركة بأكملها، يملك المنتج من البداية للنهاية. التمويل هو القيد المُلزِم، لأن مدى المستثمر أو مال المنحة يعني أن الفريق يجب أن يُظهر جذب نتيجة (تبني، استبقاء، إشارة سريرية مبكرة) بسرعة كافية لتبرير الجولة التالية، لذا الاستكشاف المستمر والتجهيز أدوات بقاء بدلًا من ترف. شهية الخطر عالية والمساءلة تسير للمؤسسين والمستثمرين، لا مجلس أو الجمهور، لذا يستطيع الفريق التمحور في أيام. الفخ هو معاملة السلامة السريرية وحوكمة المعلومات (DCB0129، DPIA) كعبء مؤسسي يُؤجَّل — في الصحة ذلك الانضباط غير قابل للتفاوض حتى في مرحلة البذرة، وسيطلب مشترو NHS دليل DTAC قبل السماح لك بالاقتراب من بيانات مريض.

شركة صغيرة#

لمقدم خدمة صغير راسخ — عيادة طبيب عام، صيدلية مجتمعية، دار رعاية أو وكالة رعاية منزلية، عيادة أحادية الموقع، أو مورّد تقنية صحية صغير تجاوز مرحلة الشركة الناشئة — نادرًا ما يعني العمل المُوجَّه بالمنتج إقامة فريق مُخصَّص متعدد الوظائف، لأنه لا يوجد مدير منتج، مُصمِّم، أو مهندس فائض للتمويل. "الفريق الدائم" هنا غالبًا مدير عيادة أو مدير مُسجَّل بالإضافة إلى مورد موثوق، لذا الانضباط الذي يهم هو تحميل من يُهيِّئ ويصون النظام مسؤولية النتائج — مواعيد فائتة أقل، تسوية أدوية أكثر أمانًا، وصول أفضل للسكان الأكثر هشاشة — بدلًا من تثبيت لمرة واحدة. المال ضيق ومستمر، لا محدود بمدى، لذا التحرك المنطقي هو الشراء في منتجات يُبقيها آخرون حية (خارطة طريق مورد مُدار جيدًا، سجل رعاية مشترك، منصة ICS) بدلًا من تكليف بناءات مخصصة لن يصونها أحد. تعضّ السلامة السريرية وحوكمة المعلومات بالكامل — نفس واجبات نشر DCB0160 والتزامات DPIA كمؤسسة كبيرة — لكن دون قدرة داخلية، الذي يجعل اختيار موردين يملكون حالة سلامتهم قرار منتج حقيقيًا. زاوية الإنصاف قريبة من المنزل: غالبًا يخدم مقدم خدمة صغير بالضبط المرضى الأكبر سنًا أو الأكثر حرمانًا الأكثر تعرضًا للاستثناء الرقمي، لذا حفظ رجوع غير رقمي ليس اختياريًا.

مؤسسة كبيرة#

في مؤسسة ائتمانية تابعة لـNHS كبيرة، نظام رعاية متكامل (ICS)، أو شركة تقنية صحية، يصطدم نموذج الفريق الدائم بميزنة رأسمالية سنوية وآلية مالية مُصمَّمة كمشروع. العمل الجوهري هو تحويل خدمات دائمة — فريق تحسين EPR، فريق سجل الرعاية المشترك — من مشاريع متوقفة-وبادئة لفرق منتج مُموَّلة بميزانيات متجددة مربوطة بدفقات قيمة، الذي تغيير مالي وحوكمي بقدر ما هو تغيير هيكل تنظيمي. المساءلة طبقات عبر الحوكمة السريرية، حوكمة المعلومات، ضمان المجلس، وعقود الموردين، لذا يجب اقتران التمكين باستراتيجية منتج صريحة ومحاذاة محفظة (انظر الموضوع 5.3 — إدارة محفظة ومشاريع المؤسسة) لإيقاف عشرات الفرق المستقلة من التحسين محليًا. النطاق عدو القرب من المستخدمين، لذا الاستثمار المتعمد في بحث مُدمَج هو ما يحفظ فرق مؤسسة كبيرة أمينة.

حكومة#

على النطاق الوطني — NHS England، DHSC، UKHSA — يُموِّل العمل المُوجَّه بالمنتج منصات طويلة العمر (تطبيق NHS، NHS login، APIs قابلية تشغيل بيني وطنية) كمنتجات بدلًا من برامج، مُحمَّلة على معيار خدمة 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 and Empowered Product Teams (svpg.com); books Inspired, Empowered, and 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 and the NHS Digital Service Standard.
• GOV.UK — Government Digital Service (GDS) Service Manual and Service Standard.
• NHS Digital Clinical Safety standards DCB0129 (manufacture) and DCB0160 (deployment) of health IT systems.
• John Doerr — Measure What Matters (OKRs), for outcome-based goal setting.

المراجع#

1. Product management — ويكيبيديا — https://en.wikipedia.org/wiki/Product_management
2. Product lifecycle — ويكيبيديا — https://en.wikipedia.org/wiki/Product_lifecycle
3. Cross-functional team — ويكيبيديا — https://en.wikipedia.org/wiki/Cross-functional_team
4. Value stream — ويكيبيديا — https://en.wikipedia.org/wiki/Value_stream
5. Objectives and key results (OKR) — ويكيبيديا — https://en.wikipedia.org/wiki/OKR
6. Electronic health record — ويكيبيديا — https://en.wikipedia.org/wiki/Electronic_health_record
7. NHS App — ويكيبيديا — https://en.wikipedia.org/wiki/NHS_App
8. Digital divide — ويكيبيديا — 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/