ทำไม Kanban ถึงทำงาน — และวิธีรู้ว่าทีมของคุณพร้อมสำหรับมันหรือไม่

ทีมส่วนใหญ่นำ Kanban มาใช้เพราะมีคนอ่านบล็อก คำถามที่ฉลาดกว่าคือปัญหาที่ Kanban แก้ไขนั้นเป็นปัญหาที่ทีมของคุณมีจริงหรือไม่

มีช่วงเวลาที่ทีมส่วนใหญ่รู้จัก มักจะเกิดขึ้นประมาณเวลาที่พวกเขามีคนมากกว่า 8 หรือ 9 คน งานกำลังทำสำเร็จ — ส่งอีเมล ฟีเจอร์เรือ ลูกค้าถูกจัดการ — แต่ไม่มีใครมีความเข้าใจที่ชัดเจนว่าคนอื่น ๆ ทำอะไร โครงการหลายกองทุน สิ่งต่าง ๆ สัญญาแล้วจากนั้นเพื่อให้ลืมไปเรื่อย ๆ คุณใช้เวลา 20 นาทีก่อนแต่ละการประชุมเพื่อหาว่างานหนึ่งชิ้นจริง ๆ อยู่ที่ไหน คำตอบมักจะเป็น "ที่ไหนสักแห่ง"

นั่นคือปัญหาที่ Kanban ได้รับการออกแบบเพื่อแก้ไข ไม่ใช่ปัญหาของการตั้งกลยุทธ์ หรือการจ้างคนที่เหมาะสม หรือการสร้างวัฒนธรรม — แต่เป็นปัญหาปฏิบัติการที่เฉพาะเจาะจง การรู้ว่าทีมของคุณกำลังทำอะไรและสิ่งที่ขัดขวางเส้นทาง

มันเป็นเครื่องมือที่ค่อนข้างจริงจังสำหรับสิ่งที่ดึงดูดความสนใจมากมาย Kanban ไม่อ้างว่าจะแก้ไของค์การของคุณ มันเพียงแค่ทำให้งานมองเห็นได้ และปรากฎว่าการมองเห็น การใช้อย่างสม่ำเสมอ เปลี่ยนจำนวนสิ่งที่น่าประหลาดใจในลำดับที่สอง

Kanban มาจากที่ไหนจริง ๆ

คำว่า "signboard" หรือ "billboard" ในภาษาญี่ปุ่น ระบบนี้ได้รับการพัฒนาโดย Toyota ในช่วงปลายทศวรรษ 1940 เป็นวิธีการจัดการสินค้าคงคลังในโรงงานการผลิตของพวกเขา แนวคิดนั้นง่าย: แทนที่จะผลิตชิ้นส่วนตามตารางเวลาที่กำหนด โรงงานจะผลิตเฉพาะเมื่อสถานี ด้านล่างส่งสัญญาณว่าต้องการมัน บัตรกระดาษ — kanban — จะเดินทางย้อนกลับไปตามบรรทัดเป็นคำขอ ไม่มีอะไรถูกทำขึ้นอย่างคิดเห็น ไม่มีอะไรสะสมโดยไม่จำเป็น

ข้อมูลเชิงลึกที่ Toyota มีและที่ทีมซอฟต์แวร์ยืมมาต่อมาคือประสิทธิภาพส่วนใหญ่ในระบบไม่ได้มาจากคนที่ทำงานช้าเกินไป แต่มาจากสิ่งที่ผิดที่ถูกทำในเวลาที่ผิด มีสิ่งที่เริ่มต้นมากเกินไปในคราวเดียวกัน ที่คอขวดที่ไม่มีใครสังเกตจนกว่าจะปลายทาง งานที่สิ้นสุดในที่หนึ่งในขณะที่ขั้นตอนต่อไปมีความสำคัญเกินไปที่อื่น

นักพัฒนาซอฟต์แวร์ โดยเฉพาะที่บริษัทเช่น Microsoft ในช่วงต้นทศวรรษ 2000 เริ่มปรับตัวให้เหมาะสมกับแนวคิดเหล่านี้เพื่อทำงานความรู้ บัตรกลายเป็นงาน สถานี Factory กลายเป็นขั้นตอนในขั้นตอนการทำงาน และ Signboard กลายเป็นกระดาน — กระดานอยู่ก่อน จากนั้นดิจิทัล — ที่ใครบนทีมสามารถมองเห็นได้ ในแวบแรก สิ่งที่มีอยู่ แต่ว่ากำลังรอ และสิ่งที่สำเร็จแล้ว

กระดาน Kanban จริง ๆ แล้วแสดงอะไร

กระดาน Kanban พื้นฐานมีสามคอลัมน์: To Do In Progress และ Done นั่นเพียงพอสำหรับทีมเล็ก ๆ มากมายและที่ดีที่สุดในการเริ่มต้น แต่มูลค่าจริงเกิดขึ้นเมื่อคุณเริ่มปรับแต่งขั้นตอนเหล่านั้นเพื่อให้สอดคล้องกับวิธีการทำงานจริง ๆ ของคุณ — ไม่ใช่วิธีที่คุณอยากให้ไปแบบนั้น

ทีมเนื้อหาอาจใช้: ไอเดียสั้น ๆ ในร่างอยู่ในการตรวจสอบกำหนดการเผยแพร่ ทีมซอฟต์แวร์อาจแบ่งการทำงานอยู่ในความก้าวหน้าแยกต่างหากคอลัมน์สำหรับการพัฒนา ตรวจสอบรหัส และ QA ทีมปรึกษามีแนวโน้มที่จะติดตาม Discovery Proposal Active Awaiting ลูกค้า และปิด ขั้นตอนควรสะท้อนให้เห็นส่วนงานจริงและเวลารอ — สถานที่ที่งานเปลี่ยนมือหรือที่มันอยู่จนกว่าสิ่งอื่นจะเกิดขึ้น

สังเกตบัตรในคอลัมน์กลาง — รายงานการตรวจสอบคลัง แปดวันในการทำเครื่องหมายเป็นบล็อก ในระบบที่ไม่มีกระดาน งานนั้นอาจนั่งสำหรับอีกสองสัปดาห์ก่อนที่ใครบางคนจะตระหนักว่ามันไม่ได้เคลื่อนที่ บางคนกำลังรอสำหรับคู่ค้าบุคคลที่สาม หรือการตัดสินใจนั้นจำเป็นจากผู้จัดการที่ไม่รู้ว่าพวกเขาเป็นผู้บล็อก กระดานทำให้การจัดการบล็อคมองเห็นได้ นั่นคือการทำงานส่วนใหญ่

กฎที่ทำให้มันทำงาน: ลิมิต WIP

หากมีแนวคิดหนึ่งที่แยกทีมที่ใช้ Kanban อย่างถูกต้องจากทีมที่มีรายการสิ่งที่ต้องทำที่สวยงามขึ้น มันจะจำกัดการทำงาน — ลิมิต WIP สำหรับสั้น ๆ แนวคิดคือแต่ละคอลัมน์มีจำนวนสูงสุดของรายการที่อยู่ได้ในคราวเดียวกัน เมื่อคอลัมน์เต็มแล้ว คุณไม่สามารถเพิ่มงานมากขึ้นจนกว่าสิ่งใดอย่างหนึ่งจะออกไป

สิ่งนี้รู้สึกสวนทางสัญชาตญาณ ให้มีโอกาสในการใส่งานมากขึ้นในความก้าวหน้า หมายความว่าเพิ่มเติมนั้นได้รับการทำเสร็จ มันไม่ได้ สิ่งที่เกิดขึ้นจริงเมื่อคนทำงานบนสิ่งมากมายพร้อมกันคือทุกอย่างใช้เวลานานขึ้น การสลับบริบทมีราคาแพง งานครึ่งสิ้นสร้างสัญเจ็จการประสานกำลังงาน และเมื่อสิบสิ่ง "กำลังดำเนินการ" มันเป็นเรื่องยากมากที่จะบอกว่าคนที่อยู่นั้นเคลื่อนตัวจริง ๆ และคนที่จมติดแต่ไม่ถูกทำเครื่องหมาย

ลิมิต WIP ที่สามบน In Progress column ของคุณหมายความว่าเมื่อสิ่งที่สี่มาถึงโต๊ะของใครซักคน คนบนทีมของคุณจะต้องตัดสินใจ: งานที่มีอยู่แล้วได้รับสำเร็จแรก มันบังคับให้สัญญา มันบังคับให้สนทนา และมีแนวโน้มที่จะให้ความเร็วเสร็จสิ้นของรายการแต่ละรายการ แม้ว่าอัตราการเริ่มงานใหม่จะช้าลง

Kanban เทียบกับ Scrum: คำถามทีมเสมอถาม

หากคุณใช้เวลาใด ๆ รอบทีมซอฟต์แวร์หรือความคิดการปฏิบัติการสมัยใหม่ คุณอาจได้พบ Scrum — กรอบที่จัดระเบียบงานเป็นนัดสปรินต์สองสัปดาห์คงที่ ด้วยการวางแผนเซสชั่น ย้อนกลับ และบทบาทที่กำหนดเช่น Scrum Master และ Product Owner ทีมหลายแห่งถือว่า Scrum และ Kanban เป็นระเบียบวิธี Competing และรู้สึกว่าพวกเขาต้องเลือก ความแตกต่างจริงมีความเรียบง่ายกว่านั้น

ทีมหลายแห่ง — โดยเฉพาะอย่างยิ่งผู้ที่ไม่ใช่ทีมวิศวกรรมซอฟต์แวร์ล้วนแต่ — ค้นหา Scrum ceremony heavy และโครงสร้างนัด Sprint ค่อนข้างอึดอัดที่จะใช้สำหรับงานปฏิบัติการต่อเนื่อง ทีมการตลาด ทีมความสำเร็จของลูกค้า ทีมการปฏิบัติการ และผู้ก่อตั้งการจัดการทุกสิ่งทั้งหมดไม่ค่อยมีงานที่พอดีในวงจร Sprint สองสัปดาห์เรียบร้อย Kanban model คุณผลมีแนวโน้มที่จะเหมาะสมกับพวกเขา

นั่นกล่าว ทีมหลายแห่งรวมทั้งสอง พวกเขาใช้วัฏจักรการวางแผนแบบ Sprint สำหรับการพัฒนาผลิตภัณฑ์ในขณะที่เรียกใช้กระดาน Kanban สำหรับงาน Operational และ Support ที่ไหลไปยังอื่น ๆ โดยไม่คำนึงถึง Sprint ที่คุณอยู่ นั่นเป็นไฮบริดที่สมเหตุสมผลโดยสิ้นเชิง

คำถามสามข้อกระดานของคุณควรตอบในสามสิบวินาที

กระดาน Kanban ที่มีประโยชน์มากที่สุดคือเมื่อคุณสามารถมองไปที่มัน และโดยไม่พูดคุยกับใครเลย ตอบคำถามสามข้อนี้อย่างรวดเร็ว: ทีมของคุณกำลังทำอะไร? ที่ไหนงานที่ได้รับการติดขัด? มีสิ่งใดที่ควรทำแล้วไม่ได้เริ่มต้น?

หากคุณไม่สามารถตอบทั้งสามภายในสามสิบวินาทีของการมองไปที่กระดาน มันก็อาจจะไม่ได้รับการบำรุงรักษาอย่างเหมาะสม โหมดล้มเหลวที่พบบ่อยที่สุดคือกระดานที่เป็นงาน ที่สร้างขึ้นแล้วไม่เคยย้าย — มันกลายเป็นสุสานของความตั้งใจที่ดีแทนแผนที่มีชีวิตของงานจริง กระดานที่ไม่ใช่ปัจจุบันมีความแย่กว่าไม่มีกระดาน เพราะมันสร้างความเข้าใจผิดปลอม ของการมองเห็น

วินัยที่จำเป็นในการรักษากระดาน คือ งานจริง บัตรต้องเคลื่อนตัวเมื่องานเคลื่อนตัว รายการบล็อกต้องถูกเก็บไว้ทันทีที่หยุดชั่งคราว ไม่ใช่สองสัปดาห์ต่อมา บัตรจำเป็นต้องมีเจ้าของชัดเจน และเจ้าของต้องปรับปรุงบัตร ไม่มีอะไรต้องเวลามาก — การปฏิบัติ Kanban ที่ทำงานได้ดีอาจใช้เวลาห้าถึงสิบนาทีต่อคนต่อวัน — แต่จำเป็นต้องสม่ำเสมอ ทีมที่ได้รับประโยชน์มากที่สุดจาก Kanban คือผู้ที่ถือว่ากระดานเป็นแหล่งความจริง ไม่ใช่การออกกำลังอบรมเพิ่มเติม

สิ่งที่ Kanban ไม่ได้ทำ

Kanban ไม่ใช่เครื่องมือกลยุทธ์ มันจะไม่ช่วยคุณหาว่าจะทำให้เสร็จอะไร — เพียงแค่ช่วยคุณจัดการสิ่งที่คุณได้ตัดสินใจแล้วว่าจะทำ หากองค์การของคุณมีปัญหาการจัดลำดับความสำคัญ หรือปัญหา "คำสั่ง" ที่ไม่ชัดเจน หรือ "เราเริ่มโครงการมากเกินไปก่อนการสิ้นสุดเก่า" ปัญหา rooted ในพฤติกรรมความเป็นผู้นำแทน process กระดาน Kanban จะเปิด Seaเผยปัญหาเหล่านั้น แต่ไม่แก้ไขปัญหา

มันยังไม่ได้แทนการจัดการที่ดี กระดานไม่ได้แทน one-to-ones หรือการมอบหมายที่คิดอย่างลึกซึ้ง หรือการสื่อสารที่ชัดเจนเกี่ยวกับเหตุผลบางส่วนของการทำงาน ทีมบางคนใช้เครื่องมือกระบวนการหวังว่ากระบวนการจะทำความสัมพันธ์และองค์การทำงานที่เป็นหน้าที่ของผู้จัดการจริง มันจะไม่

สิ่งที่มันจะทำคือลดความไม่แน่นอนแวดล้อมที่ชะลอทีมส่วนใหญ่ลง คำถามของ "ใครกำลังทำสิ่งใด" "คือสิ่งนี้สำเร็จ" และ "อะไรควรเลือกต่อไป" สร้างมากมายการสื่อสารค่าต่ำในองค์การที่ไม่มีระบบที่ใช้ร่วมกันที่มองเห็นได้ Kanban ได้กำจัดเสียงส่วนใหญ่ และสำหรับทีมที่เสียงนั้นปัญหาที่ครอบงำ ความแตกต่างคือ

วิธีเริ่มต้น — โดยไม่มีการประชุมสามวัน

โครงการ Kanban ที่ดีที่สุดที่ฉันเคยเห็นเริ่มเล็ก ๆ และพัฒนา อย่างแย่ที่สุดเกี่ยวข้องกับที่ปรึกษา การหลีกลี่ยสองวันและกระดานที่ออกแบบอย่างสวยงาม ที่ไม่มีใครใช้โดยสัปดาห์สามสำหรับการ

เริ่มต้นด้วยทีมของคุณตามที่เป็นจริง ด้วยงานที่คุณมีจริง ๆ สร้างสามคอลัมน์: Backlog In Progress Done ใช้เวลาสามสิบนาทีกับทีมของคุณ ใส่ทุกรายการงานปัจจุบันบนบัตร เห็นด้วยสำหรับหนึ่งกฎ: เมื่อคุณเริ่มบางสิ่ง มันจะไปบนกระดาน เมื่อมันเคลื่อนตัว คุณย้ายบัตร ไม่ทำอะไรอื่นสำหรับสองสัปดาห์

หลังจากสองสัปดาห์ ดูกระดานด้วยกัน ที่ไหนสิ่งที่สะสมขึ้น? ที่ได้ยืนยังอยู่ใน Backlog ที่ทุกคนกล่าวว่าเป็นลำดับความสำคัญ? สิ่งที่ย้ายอย่างรวดเร็วกว่าที่คาดไว้ สิ่งที่ติดขัด และเหตุใด ใช้สิ่งที่คุณเห็นเพื่อชี้แจงคอลัมน์และเพิ่มระบุ บางที "In Progress" ต้องแยกเป็น "In Progress" และ "Waiting on External" บางทีคุณต้องการคอลัมน์เรียกว่า "In Review" เพราะขั้นตอนนั้นต่อเนื่องได้รับการหลีกเลี่ยง ให้ ความเข้าใจและวิวัฒนากระดานเป็นการตอบสนองต่อสิ่งที่การทำงานจริงของคุณเผยให้เห็น ไม่อยู่ในการตอบสนองต่อหนังสือระเบียบวิธี

เกมที่นานขึ้น: เมตริกการไหล

เมื่อระบบ Kanban ทำงาน มันสร้างข้อมูลที่ทีมส่วนใหญ่ไม่เคยใช้ ที่นำเสนอเวลา — เวลาทั้งหมดจากเมื่อการ create task คือเมื่อสำเร็จแล้ว — เป็นสิ่งที่สำคัญที่สุด หากเวลาในการนำเสนออัตราเฉลี่ยสำหรับ task โดยทั่วไป สิบสองวันและคุณต้องการให้มันเป็นห้า คุณตอนนี้มีตัวเลขในการทำงานกับและกระดานที่จะแสดงให้เห็นว่าวันพิเศษเจ็ดวันนั้นไป

ช่วง Cycle เวลาวัดเฉพาะระยะเวลาการทำงานแบบ Active โดยรวมเวลา task ที่อยู่ใน backlog ปริมาณงานวัดวิธีการมากมายรายการที่ทีมของคุณเสร็จในสัปดาห์ หนึ่งในตัวชี้วัดเหล่านี้ต้องการซอฟต์แวร์พิเศษหากคุณมีวินัยเกี่ยวกับการสมหมายถึง ว่า Cardกำหนด และเมื่อพวกเขาปิด ร่วมกัน พวกเขาให้ภาพที่จริงจังมากขึ้นของทีม capacity ของคุณ กว่าขั้นตอนการวางแผนใด ๆ ที่ยึดถือการประมาณเป็นพื้นฐาน

ทีมเล็ก ๆและขนาดกลางส่วนใหญ่ไม่เคยได้มาที่นี่ พวกเขาใช้ Kanban เป็นเครื่องมือการมองเห็น — ซึ่งมีค่า ด้วยตัวของมันเอง — และไม่ไปไกลกว่านั้น นั่นเรียบ แต่ถ้าคุณพบตัวเองที่ต้องการทำให้มั่นใจว่า stakeholders เกี่ยวกับเมื่อใดบางสิ่งสำเร็จ หรือต้องการเข้าใจสาเหตุทำไมงานบางอย่างใช้เวลา 3 เท่า เท่าที่คาดไว้ เมตริกอยู่ที่นี่เมื่อคุณต้องการมัน