สถิติที่น่าสนใจ
เมื่อเปรียบเทียบกับเฟรมเวิร์กการจัดการโครงการแบบ Agile แบบดั้งเดิมแล้ว Kanban นั้นเข้าใจง่ายมาก ความเรียบง่ายนี้เป็นจุดแข็งหลัก ดังนั้นการใช้คัมบังจึงสามารถเป็นตัวเร่งให้เกิดการเปลี่ยนแปลงในวิธีการจัดระเบียบงานได้
Kanban ในการออกแบบด้านไอที แนวทางปฏิบัติ
ก. แสดงภาพขั้นตอนการทำงานของคุณ
Kanban ยึดตามแนวคิดที่ว่าทีมควรเห็นขั้นตอนการทำงานของพวกเขา ผู้จัดการโครงการสามารถค้นหาศักยภาพในการปรับปรุงได้โดยใช้การแสดงภาพเวิร์กโฟลว์
กิจกรรมของนักพัฒนาทั้งหมดได้รับการวางแผน ติดตาม และนำเสนอเป็นภาพบนกระดาน Kanban มีโอกาสอย่างสม่ำเสมอและต่อเนื่องสำหรับการสนทนาในทีมเกี่ยวกับวิธีตรวจสอบให้แน่ใจว่าทีมมีสมาธิและทำงานที่สำคัญที่สุด การดำเนินการที่เร็วขึ้น เช่น การแก้ไขจุดบกพร่อง สามารถแสดงเป็นภาพด้วยสีอื่นได้
อีกทางเลือกหนึ่ง บอร์ด Kanban สำหรับนักพัฒนาด้าน IT สามารถมีขั้นตอนเวิร์กโฟลว์ได้หลายขั้นตอน
งานค้าง: ฟังก์ชัน/การดำเนินการทั้งหมดที่ต้องดำเนินการ
การวิเคราะห์: ความหย่อนที่จำเป็นในการทำความเข้าใจและวิเคราะห์ปัญหา จับข้อกำหนด กำหนดเกณฑ์ทางออกหรือเสร็จสิ้น และพิจารณาแนวทางสถาปัตยกรรมที่แตกต่างกัน
การออกแบบ: วิศวกรรมการออกแบบเบื้องต้น
การดำเนินการ: การดำเนินการแก้ปัญหา
การตรวจสอบความถูกต้อง: การดีบักและ/หรือการตรวจสอบความถูกต้องของการนำไปใช้และการปฏิบัติตามเกณฑ์ที่กำหนดไว้ในขั้นตอนการวิเคราะห์
เสร็จสิ้น: งาน/การดำเนินการตรงกับเกณฑ์การออก
บอร์ดดังกล่าวอาจมีเวิร์กโฟลว์เร่งด่วนแยกต่างหากที่สร้างความสามารถสำหรับรายการที่หลีกเลี่ยงไม่ได้ซึ่งจำเป็นต้องเร่งดำเนินการ แน่นอนว่า "แบนด์" นี้ควรใช้ไม่บ่อยนัก
มุมมองภาพของบอร์ด Kanban สนับสนุนการอภิปรายภายในทีมเกี่ยวกับวิธีการปรับกระบวนการและวิธีการของทีมให้เหมาะสมเพื่อลดการเสียเวลาในกระบวนการทำงานของทีม
เนื่องจากการแสดงภาพของ Kanban ช่วยให้ทั้งทีมเห็นกระบวนการทั้งหมด จึงเป็นขั้นตอนแรกในการอนุญาตให้ทีมปรับกระบวนการให้เหมาะสม ในขณะที่ทีมกำลังทำงานในโครงการ มีเวลาเสมอที่จะเสนอคำแนะนำสำหรับการเพิ่มหรือลบขั้นตอนออกจากกระบวนการ—บอร์ดคัมบังจะพัฒนาตามกระบวนการที่พัฒนาขึ้นการมีคณะกรรมการอยู่ในสถานที่ที่โดดเด่นจะสร้างทั้งกลไกและโอกาสในการหารือเกี่ยวกับกระบวนการ โดยปกติจะทำระหว่างการประชุมสั้นๆ รายวันเพื่อหารือเกี่ยวกับความคืบหน้าและปัญหาการปิดกั้น (และควรย้ายงานผ่านเวิร์กโฟลว์)
ข. ขีดจำกัด WIP
วิธีการแบบคลาสสิกในการที่ทีมมีส่วนร่วมในงานออกแบบคือการให้งาน/คุณสมบัติหลายอย่างแก่พวกเขาเพื่อดำเนินการในเวลาเดียวกัน เช่นเดียวกับการมีการประชุมอย่างต่อเนื่องเพื่อคิดวิเคราะห์เกี่ยวกับข้อบกพร่องและกำหนดงานที่ "รวดเร็ว" ในปัจจุบัน ต้องทำให้เสร็จในเวลาที่สั้นที่สุด ข้อกำหนด เห็นได้ชัดว่าสิ่งนี้นำไปสู่ความไร้ประสิทธิภาพเนื่องจากจำเป็นต้องสลับระหว่างงานต่างๆ วิธีแก้ไขที่มีประสิทธิภาพมากกว่าคือการทำให้แน่ใจว่าแต่ละคนโฟกัสกับงานน้อยลงและปล่อยให้ทำงานจนจบ วัตถุประสงค์ของแนวทางปฏิบัตินี้คือการจำกัดงานระหว่างดำเนินการ
ทุกโครงการมีขีดจำกัด: คน พลังการประมวลผล ใบอนุญาต วันหยุดที่วางแผนไว้ ฯลฯ ขีดจำกัดเหล่านี้จำเป็นต้องได้รับการกำหนดอย่างชัดเจนและบันทึกไว้ในกระดานคัมบัง ซึ่งทำได้โดยการกำหนดขีดจำกัดของงานระหว่างทำ (WIP) ให้กับแต่ละคอลัมน์บนกระดาน Kanban ที่แสดงถึงขีดจำกัด ตัวอย่างเช่น สมมติว่าเราต้องการกำหนดขีดจำกัดของงานระหว่างดำเนินการให้กับขั้นตอนการดำเนินการ หากเรามีนักพัฒนาสี่รายและเราตั้งสมมติฐานว่านักพัฒนาสามารถทำงานได้ไม่เกินสองงานต่อครั้ง ขีดจำกัด WIP ที่ได้คือ 8 (= นักพัฒนา 4 คน * 2 งานต่อนักพัฒนา 1 คน) สิ่งนี้กำหนดจำนวนสูงสุดของงาน/กิจกรรมที่สามารถเกิดขึ้นได้ในขั้นตอนนี้ของกระบวนการ
ประเด็นสำคัญอยู่ที่ Kanban ใช้สิ่งที่เรียกว่าระบบดึง หากผู้จัดการโครงการเชื่อว่าขีดจำกัด WIP เป็นตัวกำหนดจำนวนช่องว่างที่พร้อมใช้งานสำหรับแต่ละคอลัมน์ เขาจะสามารถย้ายงานไปยังคอลัมน์ได้ก็ต่อเมื่อมีช่องว่างว่างเท่านั้น ตัวอย่างเช่น
ทีมไม่สามารถเริ่มรายการใหม่จากงานในมือได้ หากขั้นตอนการวิเคราะห์ถึงขีดจำกัด WIP
อย่างไรก็ตาม ทันทีที่องค์ประกอบใดๆ ในขั้นตอนการวิเคราะห์เสร็จสิ้น จะสามารถย้ายไปยังขั้นตอนการออกแบบได้ทันทีหากมีช่องว่างว่างหนึ่งช่อง
ไม่มีขีดจำกัดสำหรับคอลัมน์เสร็จสิ้น
แนวคิดของการดึงคืองานสามารถดึงจากทางขวาเท่านั้น แทนที่จะถูกผลักจากทางซ้าย นอกจากนี้ สิ่งสำคัญสำหรับทีมคือการกำหนดเกณฑ์การรับสมัครในแต่ละขั้นตอนเพื่อให้แน่ใจว่าจะยอมรับเฉพาะงานที่เสร็จสมบูรณ์เท่านั้น การยอมรับบางสิ่งที่ไม่สมบูรณ์ย่อมทำให้เสียเวลาและเสียเงิน ใน การส่งคืนงานที่ยังไม่เสร็จอาจเป็นผลเสียของโครงการไอทีใดๆ ก็ได้ โดยเฉพาะอย่างยิ่งหากการกลับสู่โฟลว์นั้นเกิดจากการที่ระบบทำงานมากเกินไป (ไม่เป็นไปตามข้อจำกัดเวิร์กโฟลว์ WIP)
ประเด็นสำคัญเกี่ยวกับการย้ายจากงานในมือไปยังขั้นตอนการวิเคราะห์คือการให้โอกาสในการตัดสินใจว่างานหรือหน้าที่ใดมีค่ามากที่สุดในปัจจุบัน เนื่องจากลำดับความสำคัญมักจะเปลี่ยนแปลงตลอดทั้งโครงการเนื่องจากข้อมูลใหม่หรือปัญหาทางเทคนิค ความสามารถในการพิจารณาใหม่ว่าอะไรควรดำเนินการให้เร็วที่สุดหรือช้าที่สุดเท่าที่จะเป็นไปได้คือค่าสำคัญในการใช้ระบบต่อเนื่องเช่น Kanban
เมื่อมีข้อจำกัดของ WIP แล้ว จะเห็นได้ชัดว่ามีจุดคอขวดอยู่ที่ใดในกระบวนการ เนื่องจากองค์ประกอบหนึ่งหรือหลายองค์ประกอบสร้างแรงกดดันย้อนกลับต่อกิจกรรมต้นน้ำ การเพิ่มขีดจำกัด WIP มักจะหมายความว่างานค้างอยู่ในคอลัมน์นานเกินไป และงานถูกลากยาวเกินไป
เมื่อกำหนดขีดจำกัด WIP ชุดเริ่มต้นแล้ว มีแนวโน้มว่าจะต้องมีการปรับเปลี่ยนเมื่อโครงการดำเนินไป นี่เป็นเรื่องธรรมชาติและเป็นเรื่องที่คาดหวังได้ วิธีหนึ่งคือการสังเกตความราบรื่นของงานที่ไหลผ่านบอร์ดคัมบัง และทดลองค้นหา WIP ที่เหมาะสมที่สุดโดยการเพิ่มและลดขีดจำกัด WIP เพื่อทำให้โฟลว์ราบรื่น
ค. การควบคุมความคืบหน้า
เป้าหมายขององค์กรที่สำคัญประการหนึ่งของโครงการคือการใช้ทรัพยากรของทีมอย่างมีประสิทธิภาพสูงสุดเพื่อแก้ปัญหางานของโครงการ มุมมองด้านภาพและขีดจำกัดของงานระหว่างดำเนินการที่กล่าวถึงในส่วนก่อนหน้านี้ช่วยระบุปัญหาคอขวดและช่วยทีมปรับเวิร์กโฟลว์ให้เหมาะสมตั้งแต่ต้นจนจบ
ง. มั่นใจได้ถึงความโปร่งใสของนโยบาย
ดังสุภาษิตที่ว่า “ยาฆ่าเชื้อที่ดีที่สุดคือแสงแดด” ซึ่งหมายความว่าเฉพาะเมื่อนโยบายมีความชัดเจนเท่านั้นจึงจะมองเห็นปัญหาได้
จุดประสงค์ของแนวทางปฏิบัติหลักนี้คือเพื่ออธิบายนโยบายพื้นฐานใดๆ ในเวิร์กโฟลว์ให้ชัดเจน เช่น วิธีดำเนินการจริง เมื่อจัดทำขึ้นแล้ว ข้อมูลเหล่านี้จะกลายเป็น "ข้อเท็จจริง" สำหรับโครงการ และลดภาระการวิเคราะห์เชิงอัตนัยหรือภาระทางอารมณ์ที่เกี่ยวข้องกับกระบวนการพัฒนา
สิ่งสำคัญคือต้องสร้างโอกาสในการทบทวนกระบวนการผ่านหลักฐานวัตถุประสงค์ที่รวบรวมหรือข้อเท็จจริงแต่ละรายการ โอกาสเหล่านี้สามารถใช้เพื่อสร้างแนวคิดในการปรับปรุงซึ่งทุกคนเห็นพ้องต้องกันเนื่องจากการอภิปรายอิงจากข้อเท็จจริงจริง ตามหลักการแล้ว ข้อเสนอแนะนี้ควรเกิดขึ้นเมื่อใดก็ตามที่มีหลักฐานเพียงพอของปัญหา ประเด็นนี้จะต้องได้รับการอภิปรายอย่างมีความหมาย ซึ่งบางครั้งอาจกินเวลานานหลายสัปดาห์หรือเป็นเดือน
การเกิดขึ้นของคอขวดยังเป็นโอกาสในการหารือเกี่ยวกับแนวคิด แนวคิดหลังการอภิปรายสามารถวางลงในงานในมือ (หรืองาน) เพื่อจัดลำดับความสำคัญและเพิ่มเมื่อช่องว่างถัดไปว่าง
การประชุมรายวันเป็นโอกาสในการหารือเกี่ยวกับปัญหาอย่างเป็นกลาง
กระดาน Kanban เป็นองค์ประกอบทางกายภาพ ช่วยให้ผู้คนสามารถพูดคุยเกี่ยวกับ "กระดาน" แทนที่จะเป็น "บุคคล" ด้วยการเลื่อนการสนทนาไปที่ช่อง "งาน" (“อะไรที่ทำให้งาน A หยุดไม่คืบหน้า”) ผู้จัดการสามารถขจัดปัญหาทั่วไป เช่น การเริ่มเรื่องส่วนตัว (“ทำไมการแก้ปัญหางาน A จึงใช้เวลานานมาก”)
จ. การปรับปรุงร่วมกัน การพัฒนา การทดลอง
ในบริบทของการดำเนินโครงการด้านไอที Kanban นำเสนอเมตริกที่สำคัญ (เช่น แผนภูมิลำดับงาน CFD แบบสะสม) ที่สามารถให้ข้อมูลเชิงลึกที่เป็นจริงเกี่ยวกับ:
สถานะปัจจุบันของโครงการไอที
ความคิดบางอย่างเกี่ยวกับกำหนดการที่คาดการณ์ไว้สำหรับอนาคต
ข้อมูลสำคัญบางอย่างที่จำเป็นสำหรับการวางแผนล่วงหน้า
ข้อมูลทั้งหมดนี้เชื่อมโยงกับโครงสร้างการรายงานการจัดการที่มีอยู่ และสามารถให้มุมมองที่สมจริงยิ่งขึ้นเกี่ยวกับสถานะที่แท้จริงของโครงการมากกว่าแผนภูมิ Gantt
เนื่องจาก Kanban เป็นโฟลว์ที่ต่อเนื่อง จึงเป็นไปได้และจำเป็นต้องหารือถึงการเปลี่ยนแปลงรายการเวิร์กโฟลว์เมื่อใดก็ได้ ตามกฎแล้วนี่เป็นเพราะสถานะเรื้อรังของขั้นตอนกระบวนการซึ่งกลายเป็น "คอขวด" สิ่งนี้ต้องการให้ทีมค้นหาวิธีแก้ไขปัญหาเพื่อกำจัดคอขวดหรือปรับปรุงการไหล ตามหลักการแล้ว โซลูชันดังกล่าวพบบนพื้นฐานของข้อมูลเชิงประจักษ์ที่น่าเชื่อถือ ซึ่งแสดงให้เห็นการเกิดขึ้นอย่างต่อเนื่องของปัญหาคอขวดในระยะนี้
เมื่อมีการตัดสินใจเกี่ยวกับตัวเลือกการปรับปรุงแล้ว ควรกำหนดเวลาเช่นเดียวกับงานอื่นๆ โดยเพิ่มเข้าไปในขั้นตอนเริ่มต้น ในกรณีของเรา นี่คืองานในมือและดำเนินการตามนั้น ในขณะที่การรวบรวมเมตริกดำเนินต่อไป ทีมจะสามารถระบุได้อย่างเป็นกลางว่าแนวคิดนั้นทำให้ประสิทธิภาพของทีมดีขึ้นหรือแย่ลง
ทฤษฎีที่อยู่เบื้องหลังหลักปฏิบัติ Kanban หลักนี้คือการระบุปัญหาจากมุมมองระยะยาว การเปลี่ยนแปลงตามข้อเท็จจริงจะถูกทำขึ้น และจากนั้นผลลัพธ์จะถูกบันทึกเพื่อตรวจหาปัญหา ดังนั้นการปรับปรุงจึงเป็นวัฏจักรอย่างต่อเนื่อง
