لا تؤتمت الفوضى: حوّل التكرار أولًا إلى قاعدة، ثم إلى نظام

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

لا تبدأ بالكود، ابدأ بالتكرار

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

المرحلة الأولى: اجعل القاعدة مرئية

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

المرحلة الثانية: حوّل القاعدة إلى قائمة تحقق

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

لا تنسَ هذه الخطوة.

تصبح:

هذه الخطوة جزء رسمي من العملية.

المرحلة الثالثة: اصنع قالبًا

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

المرحلة الرابعة: أتمت ما أصبح حتميًا

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

لا تجعل الأتمتة تخفي القرار

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

كل أتمتة تضيف عبئًا جديدًا

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

ابحث عن الاستقرار قبل الأتمتة

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

استخدم سلمًا بسيطًا بدل القفز مباشرة إلى الأتمتة

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

أفضل أتمتة هي التي تختفي

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

اجعل التكرار استثمارًا

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