المشاريع ومساحة العمل

البداية · المشاريع ومساحة العمل

الهدف

تشرح هذه الصفحة الفرق بين المشاريع و مساحة العمل و الوكلاء، وتفصل إعدادات المشروع المرئية فعلا في التطبيق.

ثلاث واجهات يجب التمييز بينها

الواجهة	متى تستخدمها
المشاريع	إنشاء مشروع، فتح مشروع موجود، تغيير السياق
مساحة العمل	قراءة ملخص المشروع، والشفافية التشغيلية، والإشارات، والإعدادات على مستوى المشروع
الوكلاء	بدء تبادل مباشر مع وكيل وقراءة المخرج المنظم للـ run

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

الدور الدقيق للمشروع النشط

المشروع النشط هو السياق الذي يطبّق في كل لحظة على صفحات عمل المشروع.

وبشكل ملموس، يحدد:

• الوثائق المرئية في المعرفة؛
• التنفيذات التي تُطلق في الوكلاء؛
• مستندات PM والمخرجات والفروقات المرئية في التقارير والمخرجات؛
• التنفيذات والأحداث المعروضة في سجل الذكاء الاصطناعي؛
• الإشارات والتكاملات والسياسات التي تظهر في مساحة العمل.

يجب عدم الخلط بينه وبين:

• المشروع النشط: السياق التشغيلي الحالي؛
• المحفظة: عرض مقارنة بين عدة مشاريع؛
• All projects: نطاق اختياري لوكيل مخصص مرئي في عدة مشاريع للحساب نفسه.

إنشاء مشروع

يحتوي النموذج على الحقول التالية:

• ID المشروع؛
• الاسم؛
• الوصف؛
• لغة البيانات الافتراضية؛
• لغات البيانات الإضافية.

توصيات الإدخال:

• اختر ID مقروءا ودائما؛
• لا تخلط بين لغة بيانات المشروع و لغة الواجهة؛
• حدد النطاق بشكل صحيح قبل فتح المعرفة أو الوكلاء.

منشئ المشروع: الحقوق الأولية والتفويض

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

التفويض الموصى به مباشرة بعد الإنشاء

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

ما تواصل المنصة حمايته

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

فتح مشروع وتغييره

يمكن فتح مشروع من:

• صفحة المشاريع؛
• محدد المشروع في الشريط العلوي؛
• السياق المحفوظ حديثا في المتصفح.

عند تغيير المشروع، تتوافق الواجهات التالية: المعرفة، الوكلاء، مستندات PM / التقارير والمخرجات، سجل الذكاء الاصطناعي، الإشارات وإعدادات المشروع.

لذلك يغيّر هذا التبديل السياق النشط المستخدم في البحث الوثائقي، والمحادثات مع الوكلاء، والتقارير، والآثار المرتبطة.

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

مساحة العمل: مركز قيادة المشروع

تجمع مساحة العمل في واجهة واحدة:

• ملخص المشروع؛
• اختصارات إلى الوكلاء و مستندات PM و سجل الذكاء الاصطناعي؛
• عرض للشفافية التشغيلية؛
• إشارات المشروع؛
• تبويبات الإعداد على مستوى المشروع.

لم تعد مساحة العمل تعرض بطاقة صوت مخصصة. عندما يظل الإدخال الصوتي موجودا في بعض البيئات، يكون متاحا في الوكلاء، لا كنقطة دخول منفصلة في مساحة العمل.

الشفافية التشغيلية والاستعداد

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

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

استخدم هذه المنطقة لفهم لماذا يمكن أن يكون إجراء أو استيراد متاحا أو بانتظار التأكيد أو محظورا.

كيف تصل الإشارات والموجزات والمسودات

في الواجهة، يعيد لوح إشارات المشروع قراءة ثلاثة تدفقات مشتركة من المنصة من أجل المشروع النشط:

• الإشارات الحالية؛
• الموجزات الأخيرة؛
• مسودات الإشعارات المرتبطة بهذه الإشارات.

قراءة مفيدة:

• يحمّل فتح مساحة العمل الحالة المشتركة المعروفة مسبقا لذلك المشروع؛
• يطلب Refresh صراحة من النظام إعادة تقييم المشروع وجلب أحدث الإشارات الاستباقية؛
• يبني Generate digest draft ملخصا مجمعا جديدا ويمكنه إعداد إشعارات in_app؛
• هذه العناصر ليست مجرد ملاحظات محلية في المتصفح ولا بقايا من المحادثة.

تبويبات مستوى المشروع

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

إعداد الوكلاء

المعاملات المؤكدة على مستوى المشروع هي:

• status؛
• temperature؛
• max tokens.

القيود المرئية

• يتوقع أن تكون temperature بين 0 و 2؛
• يجب أن يكون max tokens عددا صحيحا أكبر من أو يساوي 1.

سجل الإعداد

تعرض الواجهة أيضا سجلا بحسب الإصدار يتضمن على الأقل:

• رقم الإصدار؛
• الحالة؛
• درجة الحرارة؛
• max tokens؛
• تاريخ الإنشاء؛
• المؤلف؛
• Trace ID مرتبط.

التحكم في الوصول

يدير تبويب التحكم في الوصول أعضاء المشروع وأدواره. وهو يدعم:

• الأدوار القياسية؛
• الأدوار المخصصة؛
• ضمانات RBAC؛
• القراءة فقط للملفات الشخصية غير المصرح لها بالتعديل.

راجع الصفحة المخصصة: التحكم في الوصول وأدوار المشروع.

فئات الوثائق

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

الأثر الملموس للتحديث

عندما تُعدّل قائمة الفئات بنجاح:

• يتم تحديث محدد فئة الرفع في المعرفة؛
• تتوافق محددات وفلاتر الفئات في مستندات PM عندما تستخدم هذا التصنيف المشترك؛
• يبقى التغيير محدودا ب المشروع الحالي.

أمثلة عملية

حافظ على تصنيف قصير ومستقر. على سبيل المثال، بدلا من مضاعفة المتغيرات المتقاربة، فضّل بعض الفئات المتماسكة مثل:

• ميثاق المشروع؛
• سجل المخاطر؛
• تقرير الحالة؛
• خطة المشتريات؛
• خطة التواصل.

الهدف ليس ترميز إصدار الوثيقة في الفئة، بل الحفاظ على تصنيف قابل لإعادة الاستخدام بين المعرفة و مستندات PM.

سياسات الحوكمة

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

الواجهات الفرعية المرئية في سياسات الحوكمة

الواجهة الفرعية	ما تنظمه
موصلات التنفيذ	نوع الموصل، الحالة، نمط التنفيذ، البيئة، النطاقات ومعاملات السياق
وجهات المخرجات	الوجهة المستهدفة لمخرج، والموصل المرتبط، والطابع النشط أو الافتراضي
سياسات الإجراءات	الدور المعني، الموصل الهدف، مستوى الإجراء (observe، draft، propose، execute)، الأثر (allow، require_approval، deny) والنطاقات المصرح بها
ملفات render	ملفات render وتنسيق الخرج المستخدمة في المنشورات المحكومة
تفضيلات الإشعارات	القناة، نوع الإشعار، نمط الموجز، عتبة الشدة، وتفعيل التفضيل

أمثلة على إعدادات مفيدة

• طلب موافقة صريحة قبل النشر إلى SharePoint؛
• التصريح بإنشاء تذكرة Jira فقط عند مستوى propose لبعض الأدوار؛
• إعداد تفضيلات signal_digest في in_app للمتابعة الداخلية؛
• إبقاء الإشعارات الخارجية email أو teams أو webhook في مسار معتمد فقط عندما يكون الموصل سليما؛
• اختيار ملفات render منفصلة لمنشورات DOCX و XLSX.

سيناريو معقول - مشروع حساس / نشر محكوم

بالنسبة إلى مشروع يجب التحكم في كل نشر خارجي فيه، يكون الإعداد المتماسك عادة كالتالي:

1. وجهات المخرجات: وجهة SharePoint نشطة مع ملف render معروف؛
2. سياسات الإجراءات: allow لـ observe و draft، لكن require_approval لـ execute في المنشورات والإشعارات الخارجية؛
3. موصلات التنفيذ: موصلات خارجية مرئية فقط للأدوار المصرح لها فعلا؛
4. تفضيلات الإشعارات: signal_digest في daily للفريق، و signal_alert فقط للحالات الأكثر حساسية؛
5. تكاملات المشروع: bindings مفعلة فقط للموصلات المعتمدة مسبقا على مستوى المنصة.

تمنع هذه التركيبة أن تظهر مسودة أو موجز أو إجراء بوصفها قابلة للنشر مباشرة عندما لا يزال المشروع ينتظر موافقة بشرية.

تكاملات المشروع

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

كيفية قراءة هذا التبويب

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

يعرض عادة عدة عائلات من المعلومات:

• موصلات التنفيذ: خيارات خرج محكوم نحو أنظمة خارجية؛
• مزودو الإدخال: مصادر استيراد تستهلكها لاحقا المعرفة؛
• شفافية runtime الذكاء الاصطناعي: مزود الذكاء الاصطناعي الفعلي والمزود المحدد في النشر؛
• وضع التراخيص والمقاعد: الخطة النشطة، والتراخيص المشتراة، والتراخيص المستخدمة، والمقاعد المتاحة المرئية للمشروع.

ما تعرضه شاشة تكاملات المشروع

تفصل الشاشة الجاهزية التقنية عن إتاحة المشروع:

• إعداد المنصة، وbinding المشروع، وpolicy، وpermission، وhealth، وتوفر الترخيص للوصول إلى التطبيق هي أسباب منفصلة. يمكن أن يظل الموصل مرئيا للقراءة فقط حتى يفهم الفريق سبب حظره، بدلا من افتراض أنه مفقود؛
• يبقى الإعداد التقني في إدارة المنصة. يستطيع مسؤولو إعداد المشروع ربط التكاملات المفعلة والجاهزة، بينما تبقى عناوين URL الخاصة بالـ tenant، واستراتيجية المصادقة، ومفاتيح API، ومراجع الأسرار مركزية.

المنطقة	ما يمكنك رؤيته	كيفية التصرف
موصلات التنفيذ	قائمة حالية قد تكون فارغة، إضافة إلى كتالوج Available to bind يضم Asta Powerproject schedule sync، Azure DevOps delivery project، Jira delivery workspace، Microsoft Project schedule sync، Microsoft Teams collaboration، Outlook executive notifications، SharePoint publication library، Smartsheet portfolio workspace، Webhook event delivery و Wrike delivery workspace	استخدم Bind to project فقط للموصلات المفعلة والجاهزة مسبقا على مستوى المنصة
مزودو الإدخال	مزودون مثل Smartsheet sheet import و Azure Data Factory evidence pipeline معلّمون كـ Healthy، إضافة إلى مزودين متاحين مثل SharePoint knowledge import، Azure Blob document ingest، Confluence knowledge import، Jira issue import، SFTP document intake، Microsoft Project schedule import، Wrike task import و Asta Powerproject schedule import	استخدم Validate binding لإعادة التحقق من مزود مرتبط، و Disable لإغلاقه للمشروع، أو Bind to project لمزود معتمد

قد تعرض بطاقات المزود Ready أو Healthy أو Not configured. تعني Not configured أن المزود موجود في كتالوج المنصة، لكنه لا يزال يحتاج إلى مصدر أو بيانات اعتماد أو تحقق من الجاهزية قبل أن يتمكن المشروع من استخدامه.

بالنسبة إلى الحقول الإلزامية، و probes، و mapping الإجراءات، وحدود تنفيذ live، استخدم الموصلات والتكاملات. تشير Ready أو Healthy إلى جاهزية متماسكة، لكنها لا تثبت بمفردها أن تذكرة أو رسالة أو استيرادا خارجيا كاملا قد نُفذ بالفعل.

أسباب الحظر التي يعرضها المنتج

قد يظل تكامل مشروع أو خيار استيراد محظورا بسبب:

• policy؛
• permission؛
• حالة health يجب التحقق منها؛
• تعريف منصة غائب أو معطل؛
• binding مشروع معطل أو غير مضبوط؛
• إعداد أو تحقق خاص بالمزود غير مكتمل.

كيفية تفسير حظر binding

السبب المرئي	القراءة العملية	رد الفعل الموصى به
entitlement	wording موروث لتكامل محظور، وليس اختلافا في ميزات Marketplace	تحقق من الإعداد، والتحقق، و health، و binding، و policy، والدور، وتوفر الترخيص إذا كان الحظر مرتبطا بالوصول
policy	حوكمة المشروع تمنع هذا التدفق أو تحد منه	أعد قراءة سياسات الحوكمة قبل تغيير binding
permission	الموصل موجود، لكن دورك لا يسمح بتفعيله أو استخدامه	تحقق من دور المشروع في التحكم في الوصول وأدوار المشروع
health	تعريف المنصة موجود، لكن جاهزيته أو إتاحته تتطلب التحقق	افتح إدارة المنصة لتأكيد التعريف التقني
تعريف غائب أو معطل	لا شيء جاهز فعلا على مستوى المستأجر	اطلب أولا الإعداد أو إعادة التفعيل في المنصة
binding المشروع غائب	المنصة جاهزة، لكن المشروع لا يستهلك التكامل بعد	فعّل binding صراحة من المشروع

المعنى العملي لـ binding والتراخيص

• يعني binding أن الموصل أو المزود موجود على مستوى المنصة، لكنه لا يزال يحتاج إلى ربط وتفعيل للمشروع قبل أن يتمكن المشروع من استخدامه؛
• يحدد الترخيص ما إذا كان لدى المستخدم مقعد متاح للوصول إلى التطبيق. لا تفتح خطط Marketplace ولا تحظر عائلات مختلفة من الموصلات؛
• لذلك، لا يعني الموصل المرئي لكنه محظور بالضرورة أنه معطل: قد تعرضه الواجهة تحديدا لتفسير سبب الحظر.

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

Jira و SharePoint وسلسلة الموصلات

حافظ على هذا المنطق بسيطا:

1. تكاملات المنصة تعرّف الموصل أو مزود الإدخال؛
2. تكاملات المشروع تعرض فقط binding المعتمد والجاهز؛
3. سياسات الحوكمة تقرر ما يستطيع كل دور مراقبته أو إعداده أو اقتراحه أو تنفيذه؛
4. الإجراءات والموافقات تطبق بعد ذلك هذه القواعد على الطلب الحقيقي؛
5. مستندات PM و سجل الذكاء الاصطناعي يحتفظان بقابلية تتبع التدفق.

راجع الصفحة المخصصة: الموصلات والتكاملات.

الإجراءات والموافقات

يحوّل هذا التبويب توصية إلى عملية مضبوطة.

الحالات الحقيقية التي ينبغي تذكرها

في الواجهة، تميز قائمة الانتظار وبطاقات التركيب خصوصا أربع قراءات قانونية:

الحالة المرئية	القراءة العملية
Execution prerequisites	قد توجد موصلات متوافقة، لكن التنفيذ يبقى محظورا بسبب health أو الإعداد أو binding أو permission أو policy أو الموافقة أو الجاهزية التي لم تصبح متاحة بعد
Pending approval	تم اقتراح الطلب بالفعل ولا يزال ينتظر قرار حوكمة
Ready to execute	أصبح الطلب approved بالفعل، لكن التنفيذ يبقى خطوة مستقلة
Executed history	نُفذ الإجراء فعلا وبقي مرئيا كسجل أو دليل تدقيق

قد يكون الطلب approved من دون أن يكون executed بعد.

كيفية قراءة تبويب يبدو فارغا أو غير مكتمل

لا تعني رؤية التبويب أن إجراء ما أصبح قابلا للتنفيذ. عندما لا يبدو أي شيء ملموس متاحا، تكون القراءة الأكثر فائدة غالبا:

1. لا يوجد موصل تنفيذ متوافق وسليم جاهز لذلك النوع من الإجراءات؛
2. لا يعرّض binding المشروع الخيار للمشروع بعد؛
3. تسمح policy بالمراجعة، لكنها لا تسمح بالاقتراح أو التنفيذ؛
4. يسمح لك permission برؤية قائمة الانتظار، لكنه لا يسمح لك بالتصرف؛
5. الموافقة مطلوبة ولم يُتخذ أي قرار بعد.

عندما يكون كل شيء جاهزا فعلا، يجب أن تجد على الأقل:

• نوع إجراء متوافقا؛
• خيار تنفيذ سليما واحدا على الأقل؛
• binding مشروع صالحا؛
• policy متماسكة؛
• مستخدما مصرحا له بالاقتراح أو الموافقة أو التنفيذ بحسب الحالة.

ماذا تقرأ في Execution readiness

لا يدير كتلة Execution readiness المنصة كلها. فهي تلخص فقط ما يمكن اقتراحه أو تنفيذه الآن في هذا المشروع.

قراءة مفيدة:

• available / healthy: خيار قابل للاستخدام نظريا؛
• blocked by health: الموصل موجود، لكنه لا يملك حالة تشغيلية كافية؛
• blocked by entitlement: wording موروث يشير إلى حظر؛ تحقق من الإعداد، والتحقق، و binding، و policy، والدور، وتوفر الترخيص إذا كان الوصول إلى التطبيق محظورا؛
• blocked by policy: حوكمة المشروع تحظر الخطوة؛
• blocked by permission: دورك غير كاف؛
• لا توجد خيارات مرئية: لا يوجد حاليا أي موصل متوافق ومعتمد معروض للمشروع.

قراءة فقط أو وصول مرفوض

• قراءة فقط: يبقى التبويب مرئيا لكن الحفظ محظور؛
• وصول مرفوض: المسار أو الإجراء غير متاح لحسابك.

هذا الفرق مهم بوجه خاص في التحكم في الوصول و تكاملات المشروع وإعدادات الحوكمة.

المسار الموصى به بعد إنشاء مشروع

1. افتح مساحة العمل؛
2. تحقق أولا من المنشئ و الأعضاء و الأدوار إذا كان المشروع تعاونيا؛
3. اضبط بعد ذلك فئات الوثائق؛
4. راجع سياسات الحوكمة قبل أي نشر خارجي؛
5. اربط فقط تكاملات المشروع الجاهزة فعلا؛
6. حمّل بعد ذلك المعرفة؛
7. انتقل أخيرا إلى الوكلاء و مستندات PM و الإجراءات والموافقات.

سيناريوهان مفيدان للتهيئة

السيناريو 1 - مشروع جديد بحد أدنى

بالنسبة إلى مشروع يبدأ، حافظ على ترتيب بسيط:

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

يتجنب هذا السيناريو فتح موصلات أو قواعد نشر لن تُستخدم فورا في وقت مبكر جدا.

السيناريو 2 - مشروع حساس / نشر محكوم

بالنسبة إلى مشروع معرض لإشعارات خارجية أو لنشر وثائقي رسمي:

1. حد من الأدوار التي لديها وصول إلى الموصلات الخارجية؛
2. أعد وجهة SharePoint أو ما يعادلها في وجهات المخرجات؛
3. طبق require_approval على مستويات الإجراء التي يمكن أن تنتج نشرا خارجيا؛
4. فضّل signal_digest للمتابعة الجارية واحجز التنبيهات الفورية للحالات الحرجة؛
5. اجعل في تكاملات المشروع فقط bindings التي تكون جاهزيتها وسياستها مطابقة.

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

التالي

• التحكم في الوصول وأدوار المشروع
• المعرفة والوكلاء
• الحوكمة والقرارات والإجراءات
• الموصلات والتكاملات
• المحفظة والإدارة التقنية