Product Graph وذاكرة الوكلاء: لماذا لا ينقذ الذكاء الاصطناعي المنتج دون بنية معرفية

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

أين يضيع السياق

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

ولا تقتصر المشكلة على سوء التوثيق. فحتى لو حرص الفريق على إعداد PRD وملاحظات الأبحاث وسجلات القرارات (decision records)، يبقى ذلك مجموعة من الوثائق المنفصلة. تحفظ Notion وConfluence وJira وGoogle Docs المقاطع بشكل جيد، لكنها بالكاد تساعد على رؤية الروابط بينها. فالوثيقة تسجّل الواقعة، لكنها لا تصنع الفهم بذاتها. ولهذا تقع الشركات كثيرًا في حلقة متكررة: تجادل من جديد في مسائل قديمة، وتعيد أبحاثًا أُجريت من قبل، وتتخذ قرارات دون مراعاة القيود السابقة.

لماذا لا ينقذ الوكلاء الموقف

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

الذكاء الاصطناعي لا يقلّل الفوضى بالضرورة. أحيانًا يزيد طاقتها الاستيعابية فحسب.

عند هذه النقطة يطرح الكاتب فكرة العمل الميتا (meta-work). والمقصود ليس بيروقراطية لأجل البيروقراطية، بل طبقة من الإجراءات تحوّل الأحداث المتناثرة إلى منظومة معرفية. فلا بد أن يربط أحدٌ البحث الجديد برؤية قديمة، ويوثّق البيانات التي يستند إليها المتطلب، ويُظهر المواضع التي يسير فيها فريقان في اتجاهين مختلفين. وقد يكون هذا الدور أنفع للوكلاء من كتابة الكود من الصفر: ألا يحلّوا محل عمل المنتج، بل أن يصونوا الذاكرة الجماعية ويعيدوا إلى السياق كل ما ينساه الفريق.

لماذا نحتاج إلى Product Graph

بديلًا عن النهج المعتاد القائم على المهام أولًا (task-first)، يُقترح Product Graph، وهو ليس نظامًا جديدًا لتتبع المهام، بل نموذج يصبح فيه الكيان الرئيسي هو المعرفة المترابطة لا البطاقة على اللوحة. وفي هذا النظام لا تكتسب المهمة أهميتها بذاتها، بل بوصفها امتدادًا لسلسلة: مصدر الإشارة، فالرؤية، فالقرار، فالمتطلب، فالتنفيذ، فالنتيجة. وإذا لم تنقطع هذه السلسلة، يستطيع الفريق في أي لحظة أن يعود من الإصدار إلى السبب الذي نشأ العمل من أجله أصلًا.

يقوم هذا النهج على عدة مبادئ عملية:

• يجب أن يكون لكل مهمة مصدر واضح: إشارة من المستخدم، أو مقياس، أو بحث، أو رهان استراتيجي
• يجب أن يوجد القرار ككيان مستقل له بدائله وحججه وشروط إعادة النظر فيه
• يجب أن تعود النتائج الجديدة إلى النظام وتصحّح الاستنتاجات القديمة، لا أن تختفي بعد الإصدار
• يجب أن تظهر التناقضات بين الاستراتيجية وتجربة المستخدم (UX) والأبحاث والقيود التقنية في أبكر وقت ممكن

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

ماذا يعني ذلك

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