في نوت كتبتها قبل كده، حكيت عن شغل كانت فيه الملفات بتضيع، كل واحد ماشي بطريقته، وقرارات بتتاخد من غير بيانات. أول تغيير ماكانش منصة ضخمة. كان checklist صغيرة، شيت، وروتين متابعة يومي. الفكرة مش إن الشيت حل سحري. الفكرة إن المجهود محتاج مكان واضح يفضل موجود فيه بعد ما الحماس يهدى.
مسار الشغل
- 01حادثة متكررة
- 02نقطة تسريب
- 03اتفاق تسليم
- 04تجربة محدودة
- 05مراجعة وتعديل
سمّي التسريب قبل ما تشتري أداة
ابدأ بملاحظة بتتكرر، مش بحكم عام إن الفريق فوضوي. هل الطلب بيضيع بين التسويق والتصميم؟ هل الناس بتستخدم نسخ مختلفة من الملف؟ هل كل قرار بيتفتح من الأول؟ اكتب حادثة محددة، المرحلة اللي حصلت فيها، وأثرها على الشغل. افصل بين اللي شفته وبين تفسيرك. تأخر التسليم ملاحظة؛ إن الفريق مش مهتم تفسير محتاج دليل.
خد ثلاثة أمثلة من الأسبوع اللي فات. لكل مثال: إيه اللي كان المفروض يحصل، إيه اللي حصل، وإيه المعلومة اللي ماوصلتش. الهدف مش توزيع اللوم. الهدف تحديد نقطة واحدة تقدر تغيّرها، وتجرب إذا كان التغيير بيحل مشكلة فعلية.
اختار مسار واحد تظبطه
النظام الصغير يبدأ من أول طلب لحد تسليم واضح. مثلًا: فكرة محتوى، brief، مسودة، مراجعة، وتسليم للتصميم. لو حاولت تعيد بناء كل الشركة مرة واحدة، هتخسر فرصة تعرف إيه اللي فرق. اختار مسار بيتكرر وفيه ألم واضح، وصمّم له قواعد أقل من اللي نفسك تعملها.
في مثال افتراضي لفريق محتوى، البداية مش شراء أداة جديدة. كل طلب لازم يبقى فيه جمهور، هدف، رسالة أساسية، مسؤول وميعاد. الطلب اللي ناقص فيه قرار يرجع لصاحبه بدل ما المصمم يخمن. الاستثناءات تتسجل عشان نعرف هل القاعدة محتاجة تعديل.
حوّل الاتفاق لحاجة الناس تقدر تستخدمها
خلي لكل مهمة ID ثابت، مسؤول واحد عن الخطوة الحالية، حالة، ميعاد، رابط آخر نسخة، والعائق إن وجد. الحالات تكون قليلة وواضحة: جاهز، شغال، محتاج مراجعة، متعطل، واتسلم. لو «خلص» معناها مختلف لكل شخص، حط تعريف للتسليم. وجود ملف مش معناه إن اللي بعدك يقدر يشتغل منه.
تعريف التسليم في مثال المحتوى: النص اتراجع، المصادر موجودة، المقاس معروف، والصورة المطلوبة محددة. دي checklist انتقال بين شخصين، مش قائمة تعليمات تتحول لحراسة على الناس. المسؤول عن التسليم يعرف إيه اللي مطلوب، والمستلم يعرف إيه اللي يراجعه.
خلّي المتابعة تغيّر قرار
المتابعة اليومية مش لازم تبقى اجتماع يومي. ممكن تكون تحديث قصير في مكان واحد: خلصت إيه؟ متعطل في إيه؟ ومحتاج قرار من مين؟ الاجتماع يبقى للحاجات اللي محتاجة نقاش فعلًا. لو كل متابعة بتنتهي من غير مسؤول أو خطوة، أنت عملت طقس جديد مش نظام.
بعد أسبوع، راجع عينات من المهام: كام طلب رجع عشان معلومات ناقصة؟ كام مرة حد فتح نسخة قديمة؟ وكم مهمة واقفة من غير صاحب قرار؟ دي مقاييس تشخيصية مقترحة، مش نتائج تجربة منشورة. ما تقيسش كل حاجة لمجرد إن الأداة تسمح. اختار اللي يوضح التسريب اللي بدأت منه.
متخلطش التنظيم مع كثرة الخطوات
كل حقل وكل موافقة ليهم تكلفة. اسأل: لو شيلنا الخطوة دي، إيه الغلط اللي ممكن يرجع؟ لو مفيش إجابة، اختصر. ولو الخطوة بتمنع خطأ حقيقي، وضّح السبب عشان الفريق يعرف إمتى يطلبها. النظام المفيد بيقلل التخمين؛ مش بيجبر كل طلب صغير يعدي على سلسلة مراجعات كبيرة.
NN/g بتشرح progressive disclosure كطريقة لإظهار المهم أولًا وتأجيل التفاصيل الأقل استخدامًا. ده مبدأ تصميم واجهات، مش إثبات إن checklist معينة هتزود إنتاجية فريقك. نقدر نستفيد من الفكرة: الطلب البسيط يفضل بسيط، والتفاصيل تظهر وقت الحاجة.
ابدأ بتجربة، مش إعلان تحول
اتفق على تجربة قصيرة لمسار واحد ومقياس أو اثنين. سجّل الوضع قبل التغيير بالطريقة نفسها اللي هتقيس بيها بعده. بعد التجربة، اسأل الناس: إيه اللي سهّل؟ إيه اللي زوّد شغل؟ وإيه اللي لسه بيتسرب؟ ما تنسبش كل تحسن للنظام تلقائيًا؛ حجم الطلبات ونوعها ممكن يكون اتغير.
لو النظام نجح، وثّق نسخة صغيرة ووسّعها لمسار قريب. لو ما نجحش، عدّل الجزء اللي بيصنع الاحتكاك. الهدف إن حد جديد يقدر يفهم الشغل ويكمله، مش إننا نثبت إن الأداة اللي اخترناها صح. خليك مستعد تمسح قاعدة مش بتفيد.
تمرين صغير
افتح آخر مهمة رجعت لك بعد ما كنت فاكرها خلصت. اكتب المعلومة اللي كانت ناقصة، ومين كان محتاجها، وفي أي لحظة. صمّم سؤال واحد أو شرط تسليم يمنع الرجوع ده. جرّبه قبل ما تبني workflow كامل.
المصادر والحدود
الافتتاح مبني على نوت حسام الأصلية. الخطوات والمثال الافتراضي توسعة تحريرية، وليست تقريرًا بنتائج عميل.