تعزيز الابتكار والسرعة مع فرق Two-Pizza من Amazon

تم تنظيم Amazon، مثل العديد من الشركات التي بدأت خلال عصر Dot-com، من أجل المرونة السريعة وتقديم قيمة ثابتة للعملاء. في رسالته الأولى إلى المساهمين في عام 1997، ناقش Jeff Bezos أهمية التركيز على العملاء وتقديم قيمة مستمرة طويلة الأجل نيابة عنهم - حتى على حساب أرباح الشركات قصيرة الأجل. اعتمد هذا التركيز المستمر على العملاء على التوظيف والحفاظ على الهيكل التنظيمي للبناة المتمكنين الذين كانوا متحمسين للاستيقاظ كل يوم لحل مشاكل العملاء الشائكة، والابتكار نيابة عنهم.

كتب Jeff: «إن وضع معايير عالية في نهجنا للتوظيف كان وسيظل العنصر الوحيد الأكثر أهمية في نجاح Amazon.com.»

كان تحقيق ذلك أسهل في تلك الأيام الأولى، عندما كان العمل يركز على التجارة الإلكترونية، وكانت الفرق - والبنية التقنية التي اعتمدت عليها لتقديم ابتكار سريع - أكثر مركزية وترابطًا. ولكن مع مرور الوقت، ومع زيادة Amazon في عدد الشركات والابتكارات الجديدة لتلبية احتياجات عملائنا، بدأنا نواجه ضغوطًا في السرعة والمرونة التي يمكننا التنفيذ بها. كما أوضح Jeff في رسالته إلى المساهمين لعام 2015 أن الرغبة في الاستمرار «كآلة للابتكار» بدأت وهي شركة يمكنها «الجمع بين قدرات خدمة العملاء الاستثنائية التي يتم تمكينها من خلال الحجم مع سرعة الحركة والمرونة وعقلية قبول المخاطر المرتبطة عادةً بالشركات الناشئة الريادية» - بدأت تتأثر. إن بنيتنا وتنظيمنا المترابطين بإحكام لم يساعدونا ببساطة على التحرك بالسرعة التي أردناها أو كنا بحاجة إليها.

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

ولكن لم يكن الأمر جيدًا بما يكفي لإصلاح التكنولوجيا التي استخدمها المهندسون لدينا لدفع الابتكار. كنا بحاجة أيضًا إلى إعادة هيكلة الطريقة التي تم بها تنظيم الفرق لزيادة قدرتها على البقاء بالقرب من العملاء واحتياجاتهم، وإطلاق المنتجات والخدمات المبتكرة بسرعة نيابة عنهم، والاستفادة بشكل أفضل من المرونة والسرعة التي يمكن أن توفرها بنية الخدمات المصغرة. أصبح هذا الهيكل التنظيمي معروفًا باسم «فرق two-pizza» في Amazon.

إن مفهوم فرق two-pizza في Amazon واضح ومباشر: لا ينبغي أن يكون أي فريق كبيرًا بما يكفي بحيث يتطلب الأمر أكثر من اثنين من البيتزا لإطعامهم. إذا وضعنا جانبًا عدد الإضافات أو طبيعتها (ليس لدينا الوقت والمساحة لحل النقاش «does pineapple belong on pizza?» هنا)، من الناحية المثالية، هذا فريق مكون من أقل من 10 أشخاص: تعمل الفرق الأصغر على تقليل خطوط الاتصال وتقليل النفقات العامة للبيروقراطية وصنع القرار. وهذا يسمح لفرق two-pizza بقضاء المزيد من الوقت في التركيز على عملائهم، والتجريب والابتكار باستمرار نيابة عنهم - وهي الأولوية القصوى للفرق عالية الأداء في Amazon.

تعمل الفرق الصغيرة أيضًا على زيادة الملكية والتمكين. يمكن أن يخفف هذا من تأثير Ringelmann: ميل الإنتاجية الفردية إلى الانخفاض في المجموعات الأكبر. مع تضخم موارد الفريق، يقل التركيز على الجهد الفردي حيث يعتمد الناس أكثر على الآخرين لتحمل العبء. يتناقص حجم المساهمة الفردية مع نمو حجم الفريق. على العكس من ذلك، يزداد الجهد الفردي مع انخفاض حجم الفريق.

تعمل الفرق الصغيرة أيضًا على زيادة رضا الموظفين - وهو مصدر قلق رئيسي حيث تسعى المؤسسات اليوم إلى جذب أفضل المواهب والاحتفاظ بها. أظهرت دراسة بارزة أجراها Hackman وVidmar أن الرضا الفردي يتناقص مع نمو حجم الفريق. في كثير من الأحيان في الفرق الكبيرة، تكون المساهمات الفردية أقل شهرة، وتصبح الملكية الفردية في مناطق محددة أكثر انتشارًا.

وقد تم إثبات ذلك في دراسات القوى العاملة؛ فقد أظهرت دراسة «حالة مكان العمل الأمريكي» التي أجرتها مؤسسة Gallup أن المنظمات التي تضم أقل من 10 موظفين سجلت مستويات مشاركة بلغت 42% أو أعلى، في حين أن متوسط مستوى المشاركة للمنظمات الأكبر كان أقل من 30%.

لكن فرق two-pizza في Amazon لا تتعلق بالحجم فقط. يتمثل أحد العوامل الرئيسية في تمكين الابتكار المستمر والسرعة في هيكل فريق two-pizza في تمكينهم من خلال التركيز على مجال واحد متخصص.

► استمع إلى البودكاست: استراتيجيات C-Suite لقيادة التغيير الكبير

لا يقتصر دور فريق Two-pizza على الحجم فقط بقدر ما يتعلق بتعزيز الملكية والاستقلالية ودفعهما إلى مستوى الفريق.

في Amazon وAWS، تتحمل فرق two-pizza مسؤولية تامة ومركزة عن تطوير منتج أو خدمة محددة. بدلاً من الحفاظ على الأنظمة المعقدة أو حل المشكلات التي تشمل خدمات أو خطوط أعمال أو شرائح عملاء متعددة، يركز فريق two-pizza على خدمة أو عرض واحد فقط، وعلى العملاء الذين يستخدمونها فقط. يعمل هذا التركيز على تعزيز الكفاءة وقابلية التوسع. تركز خارطة طريق Two-pizza Teams - بما في ذلك المقايضات والأولويات التي يحتاجون إليها - بشكل فريد على الابتكار نيابة عن خدمتهم فقط وشريحة العملاء التي تستخدم هذه الخدمة.

تُعزِّز two-pizza أيضًا مساءلة الفريق. لا تقوم فِرَق Two-pizza بتسليم شيء أطلقوه إلى فريق آخر لتشغيله. تمتد هذه الملكية عبر تجربة العملاء الكاملة ودورة الحياة الكاملة لمنتج أو خدمة فريق two-pizza.

على هذا النحو، تحتاج فِرَق two-pizza إلى البقاء على اطلاع بكل جزء من خدمتهم، بميثاق واضح ومهمة محددة بإحكام. إنهم بحاجة إلى البقاء على مقربة من عملائهم، وإنشاء آليات التتبع والمقاييس ومؤشرات الأداء الرئيسية الصحيحة لضمان أن خدمتهم تقدم باستمرار قيمة للعملاء.

يتطلب هذا أيضًا أن يكون لدى فريق two-pizza الموارد المناسبة المضمنة - الهندسة والاختبار وإدارة المنتجات والبرامج والعمليات وما إلى ذلك - لمساعدتهم على امتلاك خدماتهم وتشغيلها من البداية إلى النهاية.

مع تزايد الطلب على المنتج أو الخدمة، بدلاً من توسيع الفريق ليشمل عددًا أكبر من الأعضاء، نبحث عن طرق لتقسيم فرق two-pizza التي تعمل على منطقة فرعية من الخدمة. يحافظ هذا التقسيم على هيكل تنظيمي مسطح يحافظ على الرشاقة والاستقلالية والملكية.

في النهاية، لا يقتصر دور الفريق في two-pizza على الحجم بقدر ما يتعلق بتعزيز الملكية والاستقلالية ودفعهما إلى مستوى الفريق - من التفكير إلى التنفيذ، ومن التحسين التشغيلي المستمر إلى التكرار المستمر للمنتج والابتكار. يسمح ذلك للفرق بالعمل بسرعة والتجربة مبكرًا وبشكل متكرر وتطبيق الدروس بسرعة لزيادة القيمة لعملائها باستمرار. يساعد الابتكار والتجريب الأسرع أيضًا على خفض تكاليف الفشل - تأتي تعلمك بشكل أسرع وبمخاطر أقل مما قد تواجهه في مراحل لاحقة من التطوير.

على الرغم من أن هيكل فريق two-pizza قد نجح في Amazon وAWS، فإننا نقر بأنه قد لا يكون مناسبًا لجميع المؤسسات، أو لكل وحدة أعمال. فرق two-pizza ليست مثالية، وليست محصنة ضد القيود؛ أحد الأمثلة على ذلك هو أنه مع وجود العديد من الفرق المستقلة التي تعمل بسرعة لتلبية احتياجات عملائها، هناك خطر الازدواجية والتطوير المنعزل. أنت بحاجة إلى هيكل الحوكمة الصحيح لتحديد متى وكيف يتم الجمع بين الجهود التي تكون تكرارية بحتة، مع عدم تحجيم قدرات الفرق لدفع الابتكار في مجالات ملكيتها.

مع التجريب السريع، هناك أيضًا حاجة للتعاون بين الفرق لتحقيق النجاح المضاعف وترشيد الموارد. والأهم من ذلك هو القدرة على التسجيل ومشاركة التعلم من الفشل لتطبيق هذه الدروس بشكل أفضل على التجارب المستقبلية، وضبط اتجاه التكرار وقرارات الاستثمار المستقبلية.

يتمثل أحد جوانب منظمة Amazon وAWS التي تساعد على تعزيز الحوكمة والإشراف مع تمكين الفرق من العمل بسرعة واستقلالية، في مفهوم القادة المتخصصين.

يعد دور القادة ذوي الخيوط الواحدة أمرًا حيويًا في تأسيس المستوى المناسب من الإشراف للحفاظ على تمكين الفريق من الابتكار بشكل مستقل نيابة عن عملائهم.

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

يجب أن توفر حوكمة وإدارة الفرق «حواجز الحماية» - آليات تسمح للفرق بالجري بسرعة واتخاذ قرارات عالية الجودة وسريعة - بدلاً من «بوابات الرسوم» التي تعيق السرعة من خلال زيادة خطوط الموافقة أو التنسيق قبل السماح للفرق بالتقدم في التجارب المبتكرة.

في Amazon وAWS، يعد دور القادة أمرًا حيويًا في تأسيس المستوى الصحيح من الإشراف للحفاظ على تمكين الفريق من الابتكار بشكل مستقل نيابة عن عملائهم، مع إنشاء آليات متسقة تسمح بالمستوى الصحيح من التفتيش والرؤية الاتجاهية. يساعد القادة في تقديم رؤية استراتيجية - ثم الابتعاد عن طريق فريقهم. يحتاج قادة الفرق إلى المساعدة في إزالة العقبات بدلاً من أن يكونوا حاجزًا يجب أن تمر من خلاله جميع القرارات. تعد الفرق الصغيرة والمرنة والمستقلة التي تستحوذ على عملائها كل يوم من أهم الخبراء المتخصصين في مجال الخدمة وقطاع العملاء.

يحتاج القادة ذوو الخيوط الفردية إلى الحفاظ على استقلالية فريقهم لاتخاذ أفضل القرارات للأعمال. غالبًا ما تكون مشاركة القادة في صنع القرار في فريقهم للمساعدة في توجيه الفريق في المواقف التي قد لا يكون فيها المسار إلى الأمام واضحًا حتى مع أدوات البيانات الصحيحة وأعلى درجات التقدير.

تستخدم Amazon السرديات المكتوبة كآلية لتمكين القائد المخصص من الإشراف على النقاط الرئيسية في العمل. تساعد الروايات في هذه الظروف على تحديد المشكلة التي تواجه العملاء والتي ظهرت على السطح؛ وتجلب المعلومات من التحليل العميق والبيانات التي جمعها الفريق للإبلاغ عن الخطوات التالية؛ وتوضح القرار الذي يوصي به الفريق، إلى جانب المسارات البديلة التي تم أخذها في الاعتبار ومخاطر وفوائد كل من هذه المسارات.

قد يبدو أن تخصيص وقت لكتابة السرديات يتعارض مع سرعة التنفيذ والاستمرارية، إلا أن اعتماد السرديات في Amazon وAWS قد أثمر عن فوائد غير مسبوقة. الأول هو أن هذه الوثائق غالبًا ما تتم مناقشتها وتنقيحها بشكل كبير من قبل الفريق وأصحاب المصلحة والخبراء المتخصصين في عروض الفريق وقطاع العملاء حتى قبل وصولها إلى مكتب المدير التنفيذي. هذا يعزز التعاون ووجهات النظر المتنوعة، ويتحدى الافتراضات، ويعمل على تحسين الأفكار والتوصيات داخل الوثيقة. في النهاية، يؤدي هذا غالبًا إلى قرارات عالية الجودة.

هناك العديد من الروايات المختلفة في Amazon وAWS. يركز البعض على إطلاق منتجات جديدة، مثل وثيقة العلاقات العامة/الأسئلة الشائعة (التي تعني البيان الصحفي/الأسئلة الشائعة) والتي هي نتاج نهج العمل العكسي الخاص بنا. البعض الآخر عبارة عن مراجعات أعمال تشغيلية (غالبًا بإيقاعات أسبوعية وشهرية وربع سنوية) توفر الفحص والحوكمة بشأن المقاييس الرئيسية والاتجاهات والتوترات والمخاطر والفرص التي تنشأ في أعمال الفريق.

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

في وثائق تصحيح الأخطاء (أو COE) هذه، يتعمق الفريق في تحديد ما حدث بشكل كامل، مع توفير التحليل الكمي والبيانات ذات الصلة حول تأثير فشل الخدمة وسبب حدوثه. يتعمقون في تحليل الأسباب لتحديد الأسباب الجذرية، مع مراعاة جميع العوامل المساهمة، ويفصلون كيفية معالجة المشكلة وما يبذلونه من جهود مستمرة لمنع تكرارها، وغالبًا ما يشمل ذلك تحسين أو تصميم أنظمة جديدة للتفتيش والتحسين المستمر. يتم بعد ذلك الاحتفاظ بهذه المستندات في قاعدة بيانات قابلة للبحث بحيث يمكن مشاركة التعلم القيّم عبر الوظائف.