نظام داخلي لإدارة طلبات التعديلات والتحديثات البرمجية على أنظمة شركات المجموعة، بحيث يقوم كل مسؤول نظام برفع طلبه، ثم يتم مراجعته واعتماده، ثم إسناده لمطور مع تحديد الأولوية والمدة والمتطلبات.
| المستخدم | الصلاحية |
|---|---|
| طالب التذكرة | إنشاء طلبات على الأنظمة المصرح له بها ومتابعة الحالة |
| مالك النظام | مراجعة الطلبات المتعلقة بنظامه وتوفير المتطلبات |
| رئيس قسم البرمجة / المعتمد | قبول أو رفض الطلب قبل التنفيذ |
| مدير المشروع / مسؤول التذاكر | ترتيب الأولويات، الإسناد، المتابعة |
| المطور | استلام التذكرة، تقدير الوقت، التنفيذ، تحديث الحالة |
| المختبر QA | اختبار التعديل قبل الإغلاق |
| الإدارة العليا | الاطلاع على التقارير والمؤشرات فقط |
-
يقوم الموظف بإنشاء تذكرة على نظام محدد.
-
يتم إرسال إشعار بريد للمعتمدين.
-
يراجع رئيس قسم البرمجة الطلب.
-
القرار:
- قبول
- رفض مع السبب
- طلب معلومات إضافية
-
عند القبول يتم تحديد:
- الأولوية
- نوع الطلب
- المدة المتوقعة
- المطور المسؤول
- المتطلبات المطلوبة من مالك التذكرة
-
يبدأ المطور العمل.
-
يتم نقل التذكرة للاختبار.
-
يتم اعتمادها من طالب التذكرة أو مالك النظام.
-
يتم إغلاقها مع توثيق ما تم تنفيذه.
| الحالة | الوصف |
|---|---|
| مسودة | لم يتم إرسالها بعد |
| جديدة | تم إرسالها وتنتظر المراجعة |
| بانتظار معلومات | تحتاج توضيح من طالب التذكرة |
| بانتظار الاعتماد | جاهزة لقرار رئيس القسم |
| معتمدة | مقبولة للتنفيذ |
| مرفوضة | مرفوضة مع السبب |
| مجدولة | تم تحديد موعد التنفيذ |
| قيد التنفيذ | المطور يعمل عليها |
| بانتظار اختبار | منتهية من التطوير وتحتاج QA |
| بانتظار اعتماد المالك | تنتظر تأكيد طالب التذكرة |
| مكتملة | تم قبولها |
| مغلقة | أغلقت نهائيًا |
| معلقة | متوقفة لسبب موثق |
| الحقل | مطلوب |
|---|---|
| عنوان الطلب | نعم |
| النظام المرتبط | نعم |
| الشركة / الجهة | نعم |
| نوع الطلب | نعم |
| الوصف التفصيلي | نعم |
| سبب الطلب / المشكلة | نعم |
| النتيجة المطلوبة | نعم |
| الأولوية المقترحة من الطالب | اختياري |
| الملفات المرفقة | اختياري |
| صور / فيديو توضيحي | اختياري |
| رابط الصفحة أو الشاشة | اختياري |
| التاريخ المطلوب للتسليم | اختياري |
| التأثير على العمل | نعم |
| هل يوجد توقف أو ضرر مالي؟ | نعم |
| ملاحظات الإدارة | اختياري |
- تعديل على نظام قائم
- إضافة ميزة جديدة
- إصلاح خطأ
- تحسين واجهة
- تحسين أداء
- تقرير أو لوحة بيانات
- صلاحيات مستخدمين
- ربط تكاملي API
- طلب طارئ
- طلب استشارة تقنية
| الأولوية | التعريف | مثال |
|---|---|---|
| حرجة | النظام متوقف أو يوجد ضرر مالي مباشر | تعطل الدفع |
| عالية | تؤثر على عملية مهمة لكنها لا توقف النظام بالكامل | خطأ في الفواتير |
| متوسطة | تحسين أو تعديل مهم | إضافة حقل جديد |
| منخفضة | تحسين غير عاجل | تغيير نص أو لون |
| مؤجلة | فكرة مستقبلية | ميزة غير معتمدة بعد |
يجب ألا تدخل أي تذكرة للتنفيذ إلا بعد اعتماد رئيس قسم البرمجة أو من ينوب عنه.
- اعتماد مباشر
- اعتماد مشروط بتوفير متطلبات
- رفض
- تحويل لاجتماع نقاش
- تحويل إلى مشروع مستقل إذا كان الطلب كبيرًا
عند إسناد التذكرة للمطور يتم تحديد:
- اسم المطور
- المدة المتوقعة بالساعات أو الأيام
- تاريخ البداية
- تاريخ التسليم المتوقع
- مستوى الصعوبة
- المتطلبات الناقصة
- هل تحتاج تصميم UI/UX؟
- هل تحتاج Backend؟
- هل تحتاج Frontend؟
- هل تحتاج اختبار؟
- هل تحتاج نشر Production؟
النظام يجب أن يسمح لفريق البرمجة بطلب معلومات إضافية مثل:
- شرح أوضح للطلب
- أمثلة
- ملفات Excel
- صور شاشة
- بيانات دخول تجريبية
- اعتماد من المدير المباشر
- تحديد المستخدمين المتأثرين
- تحديد السيناريو المتوقع قبل وبعد التعديل
ولا يمكن بدء التنفيذ إذا كانت المتطلبات الأساسية غير مكتملة.
- دعوة المستخدمين الجدد عبر البريد.
- رابط قبول الدعوة وتعيين كلمة المرور.
- صلاحية الدعوة تنتهي بعد مدة محددة.
- إعادة إرسال الدعوة.
يرسل النظام إشعارات عند:
- إنشاء تذكرة جديدة
- طلب معلومات إضافية
- اعتماد التذكرة
- رفض التذكرة
- إسنادها لمطور
- تغيير الحالة
- إضافة تعليق
- اقتراب موعد التسليم
- تأخر التذكرة
- اكتمال التنفيذ
- طلب اعتماد الإغلاق
كل تذكرة تحتوي على سجل محادثة داخلي:
- تعليقات عامة
- تعليقات داخلية لفريق البرمجة فقط
- منشن للمستخدمين
- مرفقات داخل التعليقات
- سجل زمني كامل لكل تغيير
يدعم النظام:
- صور
- Excel
- Word
- فيديو قصير
- ملفات مضغوطة
- حد أقصى لحجم الملف
- فحص أمني للملفات
| المؤشر | الوصف |
|---|---|
| عدد التذاكر الجديدة | حسب الفترة |
| التذاكر المتأخرة | حسب المطور / النظام |
| متوسط وقت الإغلاق | من الإنشاء إلى الإغلاق |
| إنتاجية المطورين | عدد التذاكر المنجزة |
| أكثر الأنظمة طلبًا للتعديلات | حسب النظام |
| أكثر الجهات طلبًا | حسب الشركة / الإدارة |
| نسبة الالتزام بالمواعيد | حسب الفريق |
| توزيع الأولويات | حرجة / عالية / متوسطة |
- تذاكر بانتظار الاعتماد
- تذاكر متأخرة
- ضغط العمل على المطورين
- التذاكر الحرجة
- طلبات تحتاج قرار
- أداء الفريق
- تذاكري الحالية
- مواعيد التسليم
- التذاكر المتأخرة
- المتطلبات الناقصة
- سجل إنجازاتي
- طلباتي
- حالاتها
- المطلوب مني
- التعليقات
- الاعتمادات
- المستخدم لا يرى إلا الأنظمة المصرح له بها.
- كل شركة ترى تذاكرها فقط.
- فريق البرمجة يرى جميع التذاكر.
- المطور يرى التذاكر المسندة له.
- الإدارة العليا ترى التقارير بدون تعديل.
- التعليقات الداخلية لا تظهر لطالب التذكرة.
- حذف التذاكر ممنوع، يسمح بالأرشفة فقط.
اسم النظام: برمجلي
- أسلوب حديث جدًا
- ألوان رئيسية: أزرق بنفسجي / Purplish Blue
- تصميم نظيف ومريح
- بطاقات Dashboard
- Kanban Board
- Timeline داخل التذكرة
- Dark Mode اختياري
- دعم كامل للعربية RTL
- واجهة Responsive للجوال والتابلت
| الاستخدام | اللون |
|---|---|
| Primary | #4F46E5 |
| Secondary | #6366F1 |
| Accent | #8B5CF6 |
| Background | #F8FAFC |
| Dark | #111827 |
| Success | #10B981 |
| Warning | #F59E0B |
| Danger | #EF4444 |
- Next.js
- TypeScript
- Tailwind CSS
- shadcn/ui
- React Query
- Zustand أو Redux Toolkit
- RTL Support
- Role-based UI
- Responsive Design
- NestJS
- TypeScript
- REST API
- PostgreSQL
- Prisma ORM
- JWT Authentication
- Role-Based Access Control
- Email Service
- File Upload Service
- Audit Logs
- Background Jobs
- Docker
- Nginx
- PM2 أو Docker Compose
- S3-Compatible Storage للملفات
- Redis للمهام والإشعارات
- Backup يومي لقاعدة البيانات
- Logging مركزي
- Error Tracking
- Users
- Companies
- Departments
- Systems
- Tickets
- TicketComments
- TicketAttachments
- TicketStatusHistory
- TicketAssignments
- TicketApprovals
- Priorities
- Roles
- Permissions
- EmailInvitations
- Notifications
- AuditLogs
- بحث متقدم
- فلترة حسب النظام، الشركة، الحالة، الأولوية، المطور
- تصدير Excel
- أرشفة التذاكر
- سجل كامل لكل تعديل
- منع التعديل بعد الإغلاق إلا بصلاحية خاصة
- إعادة فتح التذكرة
- ربط التذاكر ببعضها
- تكرار تذكرة سابقة
- قوالب جاهزة لأنواع الطلبات
- تقييم طالب التذكرة بعد الإغلاق
- لا يبدأ التنفيذ بدون اعتماد.
- لا تغلق التذكرة بدون توثيق ما تم.
- لا يقبل الطلب العام غير الواضح.
- كل طلب يجب أن يرتبط بنظام محدد.
- الطلبات الكبيرة تتحول إلى مشروع مستقل.
- الأولوية النهائية يحددها قسم البرمجة، وليس طالب التذكرة.
- أي تأخير يجب أن يكون له سبب موثق.
نظام برمجلي يجب أن يكون مركز التحكم الكامل لطلبات البرمجة داخل الشركة، يمنع ضياع الطلبات، يوضح المسؤوليات، يضبط الأولويات، ويعطي الإدارة رؤية واضحة عن أداء قسم البرمجة والضغط التشغيلي على الفريق.