سنوحي

وثق مسار العمل قبل ما تبرمجه أو تعمل له أتمتة

وثق خطوات ومسؤوليات واستثناءات العمل قبل الأتمتة، واختبر الحالات على الورق وحدد القواعد التي تحتاج قرارًا قبل البرمجة.

توثيق مسار العمل قبل برمجته أو أتمتته
محتويات المقال

بتقول للمطور «الطلب يمشي للمسؤول وبعدها يتنفذ». لكن مين المسؤول لو الطلب من فرع تاني؟ وإيه اللي يحصل لو البيانات ناقصة؟ ومين يقدر يرجعه للتعديل؟ التفاصيل اللي بتتجاوب شفهيًا كل يوم هي اللي محتاجة توثيق قبل البرمجة.

توثيق مسار العمل مش رسم مربعات وخلاص. هو اتفاق على بداية العملية ونهايتها، والمدخلات والقرارات والمسؤوليات والاستثناءات. لو الفريق نفسه مختلف على القاعدة، الأتمتة مش هتحسم الخلاف؛ هتختار سلوكًا قد لا يوافق عليه أحد.

اختار عملية محدودة وراقبها

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

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

ارسم الحالة الحالية قبل المقترحة

اكتب الخطوات بترتيبها، ولكل خطوة فعل واحد واضح. بدل «معالجة الطلب» اكتب «مراجعة اكتمال البيانات» ثم «تحديد جهة التنفيذ» ثم «اعتماد النطاق». الكلمات الواسعة تخفي قرارات مختلفة ومسؤولين مختلفين.

في مثال تعليمي افتراضي:

الخطوة

المدخل

المسؤول

النتيجة أو الاستثناء

استلام طلب

نموذج مكتمل أو ناقص

الاستقبال

سجل جديد برقم معروف

فحص البيانات

السجل والمرفقات

منسق الطلبات

جاهز أو مطلوب استكمال

مراجعة النطاق

طلب مكتمل

مسؤول الخدمة

مقبول أو خارج النطاق

توزيع التنفيذ

طلب مقبول

مدير التشغيل

تكليف واضح أو انتظار قدرة

إغلاق

تسليم ومراجعة

المسؤول المعتمد

مكتمل أو يحتاج تصحيحًا

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

وثق قواعد القرار بأمثلة

«الطلبات الكبيرة تروح للمدير» قاعدة ناقصة. إيه تعريف الكبير؟ هل بالقيمة أو النوع أو المخاطر؟ ومن يملك تغيير الحد؟ اكتب القاعدة المعتمدة ومصدرها وأمثلة قبول ورفض وحالات حدودية، من غير اختراع أرقام بالنيابة عن صاحب النشاط.

راجع حالات الرجوع والتكرار: نفس الطلب وصل مرتين، أو اتعدل بعد الاعتماد، أو الشخص المسؤول غاب. حدد ما إذا كان التعديل يفتح اعتمادًا جديدًا، ومن يستلم البديل، وكيف نعرف إن سجلين يمثلان نفس الطلب.

افصل المشكلة عن حل الأداة

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

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

اختبر المسار على الورق

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

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

عن الكاتب

Ilyas Amine Tazi

كاتب المقال

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

كل مقالات الكاتب
0 تعليق

التعليقات

لا توجد تعليقات بعد.