الأعمدة كحالات

لوحة كانبان تجعل العمل مرئياً. كل قطعة عمل هي بطاقة. تتحرك البطاقات من اليسار إلى اليمين عبر أعمدة تمثل حالات.

الأعمدة الكلاسيكية هي: Backlog → Selected → In Progress → Review → Done

لكن الأعمدة الدقيقة لا تهم. ما يهم هو أن كل بطاقة لها حالة حالية واحدة بالضبط، & تلك الحالة مرئية للجميع الذين يعملون في هذا النظام.

ما الذي تمثله البطاقة

تمثل البطاقة وحدة عمل يمكن إكمالها بشكل مستقل. ليست مشروعاً. ليست هدفاً. شيء محدد محصور له تعريف واضح للإتمام.

بطاقة جيدة: تدوير مفاتيح SSH على خوادم prod: تم عندما تُظهر جميع الخوادم المفتاح الجديد في authorized_keys & تتم إزالة المفتاح القديم.

بطاقة سيئة: تحسين الأمان. (هذا مشروع، وليس مهمة. قسّمها إلى أجزاء أصغر.)

حدود WIP

يُظهر العمود In Progress في الرسم البياني حد WIP: 3. هذا يعني أنه لا يمكن أن يكون هناك أكثر من ثلاث بطاقات في In Progress في نفس الوقت. إذا كنت تريد سحب بطاقة رابعة، يجب عليك إنهاء واحدة أولاً.

يبدو هذا كقيد. إنه كذلك: بالتصميم. تفرض حدود WIP عليك إنهاء ما بدأته قبل البدء بشيء جديد. سيأتي المزيد عن سبب أهمية هذا في قسم لاحق.

تحديد نطاق بطاقات العمل

أصعب مهارة في كانبان ليست رسم اللوحة. إنها تحديد نطاق البطاقات. كبيرة جداً & البطاقة تبقى في In Progress لأسابيع، تحظر العمل الآخر. صغيرة جداً & اللوحة تمتلئ بالضوضاء.

الصوامع تعمل بشكل جيد

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

كانبان لا يذيب هذه الفروق. إنها تجعل الانتقالات بينها مرئية و صريحة.

بطاقة الانتقال

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

ما يوضحه الرسم البياني

تذكرة ★ تبدأ في Design (In Progress: visual assets). عندما ينتهي التصميم من جزءهم، يتم إنشاء بطاقة انتقال و تذكرة ★ تظهر في Backlog لمركز Build. يسحب Build الآن. ثم يسحب Ops. لكل مركز لوحته الخاصة. كل لوحة تُظهر فقط العمل الحالي لهذا المركز. لكن ★ تسافر من خلالها جميعاً، & الجميع يمكنهم أن يروا أين هي.

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

تصميم انتقال

بطاقة الانتقال هي العقد بين مراكز العمل. يجب أن تحتوي على سياق كافٍ للفريق المُستقبِل للتصرف بدون اجتماع.

توقف البدء. ابدأ الإنهاء.

WIP تعني Work In Progress. حد WIP هو حد أقصى لعدد البطاقات التي يمكن أن تكون في عمود معين في نفس الوقت.

يبدو هذا كقيد. إنه كذلك. هذه النقطة.

لماذا تساعد الحدود

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

تمنع حدود WIP تراكم العمل غير المكتمل. يفعلون أيضاً شيء أكثر قيمة: يسطحون الاختناقات.

الاختناقات تصبح مرئية

إذا كان لعمود Review حد WIP قدره 2 و كان دائماً عند 2، فهذه إشارة: المراجعة أبطأ من الإنتاج. يكمل المزيد من العمل في In Progress أكثر مما يمكن استهلاكه بواسطة Review. بدون حد WIP، تمتلئ اللوحة بـ 'تم-لكن-ينتظر-المراجعة' بطاقات و الاختناق غير مرئي. مع حد WIP، لا يمكن للعمود In Progress قبول بطاقات جديدة، و الفريق بأكمله يرى القيد.

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

قانون Little (بشكل غير رسمي)

وقت الرصاص (كم تستغرق البطاقة من البداية إلى النهاية) = العمل قيد الإنجاز ÷ الإنتاجية (البطاقات المكتملة لكل وحدة زمنية). إذا كنت تريد أوقات رصاص أقصر بدون توظيف، قلل WIP. عدد أقل من الأشياء قيد الطيران يعني أن كل شيء ينتهي أسرع.

R = (W × C) + T

حدود WIP تحمي ثلاث متغيرات. سمى مستشار الكفاءة برايان تريسي اسمها في عام 1986.

R = (W × C) + T

- R: النتيجة: النتيجة التي تريدها

- W: وضوح الهدف: كم بدقة تعرف ما تريده (0–10)

- C: التركيز: شدة الجهد المركز (0–10)

- T: الوقت المعمول به بدون تشتتات (ساعات غير منقطعة)

لماذا W & C يضاعفان

الوضوح و التركيز ليسا مستقلين. التركيز العالي على هدف غامض ينتج حركة سريعة في الاتجاه الخاطئ. وضوح الهدف المثالي بدون تركيز ينتج لا شيء. يتفاعلان: وهذا هو السبب في كتابة تريسي لهما كمنتج، وليس كمجموع. 9/10 على كل منهما يعطي R = 81 + T. 3/10 على كل منهما يعطي R = 9 + T. الفرق ليس مضافاً.

لماذا T يضيف

كل ساعة خالية من التشتيت تضيف بشكل خطي إلى النتيجة. T لا يمكن أن يضاعف W & C: يمكنه فقط أن يكدس على منتج. هذا يشرح لماذا الخطوة الأولى هي دائماً تحسين W & C، وليس العمل لساعات أطول. المزيد من T على منتج (W × C) منخفض لا يزال نتيجة سيئة.

ما تفعله لوحة كانبان لكل متغير

- W: بطاقة محددة النطاق جيداً (عنوان واضح، معايير قبول قابلة للقياس، مالك واحد) ترفع W قبل بدء العمل. البطاقات الغامضة تخفضها تلقائياً.

- C: تفرض حدود WIP التركيز. بطاقة واحدة في Active تعني كل الاهتمام على مشكلة واحدة. ثلاث بطاقات في Active يعني C مقسمة إلى ثلاثة.

- T: كتل بومودورو و حماية التقويم تنشئ ساعات بدون تشتت يقيس T. مؤقت اللوحة ليس زينة: يتتبع T في الوقت الفعلي.

ادعى تريسي أن أي مشكلة يمكن حلها في 30 دقيقة عندما تكون W و C و T محسّنة جميعاً. لوحة كانبان هي الأداة لتحسين الثلاثة معاً في نفس الوقت.

قراءة اللوحة

تدرب على قراءة الاختناقات من حالة اللوحة.

ليست Agile. ليست Waterfall.

Agile هي منهجية. Waterfall هي منهجية. Kanban هي نظام.

تحدد المنهجيات كيفية عملك. تصف الأنظمة ما هو صحيح حول العمل. لا تخبرك Kanban بوجود سباقات لمدة أسبوعين، أو اجتماعات يومية، أو استعراضات رجعية. تخبرك بشيء واحد: اجعل العمل مرئياً، و حدّ WIP، و اسحب.

المشكلة مع المنهجيات

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

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

ابحث عن أرضية مشتركة في العمل الذي يجب القيام به

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

هذا ليس غياب العملية. إنها الكمية الصحيحة من العملية: كافية للتنسيق، ليس كافية لإنشاء حمل تنسيق يتجاوز قيمة العمل.

لا تبني ما يمكنك شراؤه. لا تشتر ما يمكنك أن تنميه.

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

شجرة القرار: هل يمكننا أن ننميه؟ عملية، مهارة، علاقة تنتج القدرة بشكل مستدام، فضّل هذا. إذا كان النمو غير قابل للحياة: هل يمكننا شراء هذا؟ أداة خارج الرف تحل 80٪ من المشكلة بدون عمل مخصص، فضّل هذا. إذا كان الشراء غير قابل للحياة: ابنِ ها. و ابنِ معرفة أنك تملكها الآن.

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

بناء / شراء / نمو

طبّق الإطار القرار.

صمّم لوحة

اجمع كل شيء معاً. ستصمم نظام كانبان لسيناريو محدد متعدد الأغراض.

السيناريو

استوديو صغير يُعيد إطلاق منتجه مع علامة تجارية جديدة. يتضمن العمل أربعة مراكز:

- Design: شعار جديد، هوية بصرية، صور منتج، تخطيطات صفحات

- Content: أوصاف منتج معاد كتابتها، نص صفحة الهبوط، إعلان البريد الإلكتروني

- Build: موقع ويب محدث، تدفق الدفع الجديد، إعادة التوجيه من عناوين URL القديمة

- Ops: إعدادات معالج الدفع المحدثة، إحاطة شريك الوفاء، إعادة تكوين التحليلات

لإعادة الإطلاق موعد نهائي صعب: معرض تجاري في 45 يوم حيث تذهب العلامة التجارية الجديدة إلى الجمهور.

الأفراد يبقون صوامع

في معظم المنظمات، توجد Kanban لجعل العمل مرئياً عبر تسلسل هرمي إداري. ينسق المديرون بين الصوامع. Kanban تقلل من حمل التنسيق.

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

Kanban تصبح طبقة التنسيق. ليس بتسطيح الصوامع، الأفراد يبقون مستقلين تماماً، لكن بجعل الانتقالات بينهم مرئية & صريحة. فرد لا يرسل بريداً إلكترونياً أو يجدول اجتماعاً لتسليم العمل. يضع بطاقة على لوحة مشتركة. يسحب الفرد المستقبِل عندما يكون لديه سعة.

هذا يشرح لماذا تناسب Kanban نموذج un بشكل أفضل من agile أو waterfall: لا تتطلب إيقاع مشتركاً، لا مراجعات رجعية مشتركة، لا تخطيط متزامن. كل فرد يضع حدود WIP الخاصة به، وقت الدورة الخاص به، تعريف 'تم' الخاص به. يحدث التنسيق على مستوى البطاقة، وليس على مستوى العملية.