Post by Nour Eldin Arafa

من أكثر الأفكار التي لفتت انتباهي في الفصل الثاني من كتاب Kanban from the Inside هي أن: لا يمكنك تحسين نظام... قبل أن تفهمه. كثير من المؤسسات عندما تواجه تأخيرًا في التسليم، يكون أول رد فعل هو: ❌ نوظف Developers أكثر. ❌ نطلب من الفريق العمل لساعات إضافية. ❌ نغيّر الـ Framework. لكن Mike Burrows يقترح سؤالًا مختلفًا: "هل نفهم فعلًا كيف يتدفق العمل داخل النظام؟" قبل أي تحسين، يجب أن نرسم الـ Workflow الحقيقي، وليس الـ Workflow الموجود في الوثائق. على سبيل المثال: Backlog → Analysis → Development → Code Review → Testing → Deployment ثم نبدأ في طرح الأسئلة الصحيحة: - أين تتراكم المهام؟ - أين تقضي معظم وقتها في الانتظار؟ - ما المرحلة التي تتحول إلى Bottleneck باستمرار؟ - هل المشكلة في سرعة التنفيذ... أم في كثرة العمل قيد التنفيذ؟ المفاجأة أن المشكلة في كثير من الأحيان لا تكون في الأشخاص، بل في طريقة تصميم النظام. قد تكتشف أن فريق التطوير ينهي عمله بسرعة، بينما تتكدس المهام قبل مرحلة الاختبار. الحل هنا ليس زيادة سرعة التطوير... بل معالجة الاختناق في مرحلة الاختبار. وهذا هو جوهر التفكير في Kanban: 🎯 ركز على تحسين تدفق العمل (Flow)، وليس على زيادة انشغال الأفراد (Utilization). عندما نفهم النظام أولًا، تصبح قرارات التحسين مبنية على البيانات والواقع، وليس على التخمين. وهذه واحدة من أهم الرسائل التي يقدمها Mike Burrows في هذا الفصل: «إذا أردت تحسين الأداء، ابدأ بفهم النظام الذي يعمل بداخله فريقك.» 📚 Source: Kanban from the Inside – Mike Burrows