تجنب تأخير إطلاق المنتجات عبر تقليص اﻷعباء التقنية

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

وفق استبيان مدير المنتج عام 2019، والذي أعدّته شركة غارتنر لخدمات الأبحاث والاستشارات، وُجد أن نسبة عمليات إطلاق المنتجات التي تحدث في الموعد المحدّد تبلغ 55% فقط، وهذه معلومة مهمة، لأن مدير المنتج الذي يتمكّن من إطلاق منتجه في الموعد المحدّد يمتلك قدرةً أكبر على الالتزام بالأهداف الداخلية خلال عامٍ واحدٍ من تاريخ الإطلاق؛ أما بخصوص عمليات إطلاق المنتج المتأخّرة، والتي تبلغ نسبتها 45% وفق الدراسة، فقد تَبيّن- أن 20% منها -في المتوسط- تفشل في الالتزام بأهدافها الداخليّة.

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

يلعب مدير المنتجات دورًا محوريًا في تسهيل نجاح المنتج؛ فهو مسؤولٌ عن الرؤية والميزات ووضع الاستراتيجيّة وإطلاق المنتج وحالة السوق والمنافسين ووضع خارطة الطريق، إذ أن عمل مدير المنتج يتقاطع مع أقسام الهندسة والمبيعات والدعم والتسويق، فهو صاحب المنصب الفريد والمسؤول عن التعرّف على مشكلات اﻷعباء التقنية. إليك سبع استراتيجياتٍ قابلةٍ للتنفيذ، ستُساعدك على تجنُّب حدوث اﻷعباء التقنيّة، ومواجهة هذه المشكلة في حال حدوثها، وتتمثل هذه الاستراتيجات بالآتي:

1. أنشئ تحالفات

يشمل منصب مدير المنتج مسؤوليّة تنمية علاقاتٍ قويّةٍ مع العميل التقني المحتمل والرئيس التنفيذي للتقنية CTO، ورؤساء الأقسام الإداريّة الأخرى، حيث وجدت دراسة غارتنر انخفاضًا في معدّلات فشل المنتجات لدى 78% من مديري المنتجات الذين عَدّوا التعاون الداخلي في قائمة الوظائف الثلاث الأهم بالنسبة لهم.

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

2. مناقشة اﻷعباء التقنية

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

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

3. اطرح الأسئلة الواقعية

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

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

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

4. اعمل على تضمين معالجة اﻷعباء التقنية في خارطة الطريق

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

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

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

5. اعتمد على مؤشرات الأداء الرئيسية التي لها صلة باﻷعباء التقنية

اجعل إنهاء اﻷعباء التقنية جزءًا من الوسائل التي تستخدمها لتتبُّع النجاح في المؤسسة، وأنشئ مؤشرات أداءٍ رئيسية KPI متصلة بأداء المنتج وسرعة عملية التطوير لقياس اﻷعباء التقنية خصوصًا.

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

6. اتخذ الإجراءات اللازمة لمنع حدوث اﻷعباء التقنية

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

7. التزم بتوثيق اﻷعباء التقنية

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

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

ترجمة -وبتصرُّف- لمقالة Product Managers Can Avoid Delays By Reducing Technical Debt لصاحبها Alex Omeyer.