كيف يغيّر وكلاء الذكاء الاصطناعي وIBM إدارة مشاريع تقنية المعلومات ودور مدير المشروع

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

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

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

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

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

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