انتقل إلى المحتوى
في هذه الصفحة

القيادة التقنية: افصل الممارسة عن المشكلة التي يفترض أن تحلها

القيادة التقنية: افصل الممارسة عن المشكلة التي يفترض أن تحلهاصورة منشأة بالذكاء الاصطناعي

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

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

عُد خطوة إلى الخلف

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

من مناقشة الحل إلى معالجة المشكلة الحقيقية: تسمية المشكلة أولاً تقود إلى إجراء متفق عليهصورة منشأة بالذكاء الاصطناعي

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

احتفظ بالمشكلة وغيّر الحل

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

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

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

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

السؤال الذي أطرحه

عندما يرفض الفريق ممارسة هندسية مقترحة، كيف تتأكد من أن المشكلة التي كانت وراءها لا تختفي معها أيضاً؟

إذا جرّبت من قبل إعادة النقاش إلى المشكلة أولاً، فماذا لاحظت؟ شاركه في التعليقات أو تواصل معي مباشرةً.

أقرأ جميع الردود.