هل سيستبدل وكلاء الذكاء الاصطناعي مديري المشاريع؟ ما الذي يتغير فعلًا

الإجابة القصيرة: لا، لكن الوظيفة ستتغير في ملمسها، والتظاهر بغير ذلك لا يفيد أحدًا.

السوق صاخب الآن. هناك مكاتب إدارة مشاريع "وكيلية"، و"مدير مشاريع بالذكاء الاصطناعي" في كل عرض إطلاق، وتوقع يُقتبس كثيرًا بأن معظم أعمال مدير المشاريع التنفيذية ستُؤتمت بحلول 2030. بعض هذا حقيقي. وكثير منه عرض توضيحي ينهار في اللحظة التي يحاول فيها أحد إدارة مشروع فعلي عليه. من المفيد الفصل بين الاثنين، لأن النسخة الصادقة أنفع من الضجيج وأقل إخافة من الهلع.

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

ما يتولاه الوكلاء فعلًا اليوم

ابدأ بالعمل الذي يلتهم أسبوع مدير المشاريع ولا ينتج أي حكم تقريبًا. هنا يثبت الوكلاء جدواهم الآن، لا في توقعات 2030.

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

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

flowchart LR
    A[Board state] --> B[Agent drafts]
    B --> C[Human glances at it]
    C -->|looks right| D[Ship it]
    C -->|off| E[Correct and rescope]
    E --> B

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

وحين يبلّغ عما يعمل عليه، يفتح جلسة لها حالة تظهر على المهمة نفسها:

stateDiagram-v2
    [*] --> running
    running --> needs_input
    needs_input --> running
    running --> review
    review --> done
    done --> [*]

تسند إليه العمل كما تسنده إلى شخص، وترى ما فعله بالطريقة نفسها.

لا شيء من هذا يستبدل مدير المشاريع. إنه يخلي المكتب كي يتوقف مدير المشاريع عن قضاء الخميس في تجميع تقرير والجمعة في ملاحقة التحديثات.

ما يبقى بشريًا

الآن الجزء الذي تتجاوزه العروض التوضيحية.

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

المفاضلات هي المشكلة نفسها في صورة أصعب. كل قرار حقيقي في مشروع هو مقايضة بين الوقت والنطاق والمال والمعنويات، والأوزان تعيش في رؤوس الناس وفي سياق لم يُعطَ للوكيل قط.

ما يستطيع الوكيل إخبارك به	ما لا يقرره إلا إنسان
أي ميزة عليها أخطاء مفتوحة أكثر	أي ميزة سيغفر لك مجلس الإدارة قصّها
تقدير مشتق من اللوحة	هل تقف وراء ذلك التاريخ أمام عميل
ما تحرك وما تعثر	ما الخسارة المقبولة هذا الربع

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

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

وهناك زاوية موثوقية هنا أيضًا، وليست هامشًا:

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

هذه ليست عوائق قاطعة. إنها سبب إبقاء إنسان على القرارات التي تحمل مخاطرة.

الدور يتحول ولا يختفي

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

ثلاثة أشياء تصبح جوهر العمل:

1. عرّف النتائج بوضوح يكفي ليتصرف الوكيل بناء عليها دون أن تروي له كل خطوة.
2. ارسم الحدود، أي الصلاحيات وبوابات الموافقة، فيعمل الوكيل داخل سياج رسمته عن قصد.
3. راجع، لأن القرارات المهمة تصل الآن مسودات جاهزة لا مادة خام، ودورك أن تقول نعم أو لا أو ليس هكذا.

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

أين يقع Taskfolk، باختصار

التصميم يلزم عن كل ما سبق. يتصل الوكلاء عبر الأبواب نفسها التي يستخدمها فريقك: خادم MCP وواجهة REST API، بمفتاح صلاحياته واسعة في القراءة ضيقة في الكتابة.

لحظة "التقطت هذه التذكرة" استدعاء API واحد. حين يبدأ الوكيل العمل يفتح جلسة على المهمة، وتلك الجلسة هي ما يراه فريقك على اللوحة. يحتاج المفتاح إلى صلاحية agents:write، وحين يكون المفتاح مفتاح الوكيل نفسه تُنسب الجلسة إلى ذلك الوكيل تلقائيًا:

curl -X POST "https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions" \
  -H "Authorization: Bearer tfk_live_a1b2..." \
  -H "Content-Type: application/json" \
  -d '{ "title": "Triaging the overnight bug reports", "issue_key": "WEB-12" }'

await fetch("https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions", {
  method: "POST",
  headers: {
    Authorization: "Bearer tfk_live_a1b2...",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    title: "Triaging the overnight bug reports",
    issue_key: "WEB-12",
  }),
});

import requests

requests.post(
    "https://taskfolk.ai/api/v1/workspaces/taskfolk/agent-sessions",
    headers={"Authorization": "Bearer tfk_live_a1b2..."},
    json={"title": "Triaging the overnight bug reports", "issue_key": "WEB-12"},
)

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

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

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