วิธีการจัดการโครงการยอดนิยม 7 อันดับแรก: Agile, Scrum, Kanban, PRINCE2 และอื่นๆ

"จากความยากลำบากทั้งหมดที่ NASA เผชิญในการส่งมนุษย์ไปดวงจันทร์ การควบคุมน่าจะเป็นงานที่ยากที่สุด"

— โรเจอร์ เลานิส นักประวัติศาสตร์ของนาซ่า

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

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

ในแง่ง่ายๆ การบริหารโครงการคือทั้งหมดที่เกี่ยวกับการจัดการและจัดระเบียบทุกอย่างที่จำเป็นเพื่อให้บรรลุเป้าหมาย - ตรงเวลาและอยู่ในงบประมาณแน่นอน ไม่ว่าจะเป็นการพัฒนาซอฟต์แวร์ใหม่ การทำแคมเปญการตลาด หรือการส่งมนุษย์ไปดาวอังคาร การจัดการโครงการทำให้ประสบความสำเร็จได้

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

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

ในบทความนี้เราจะดู:

  • การจัดการโครงการแบบคลาสสิก
  • เปรียว
  • Scrum
  • เอียง
  • คัมบัง
  • หกซิกม่า
  • PRINCE2

และก่อนที่จะดูวิธีการเฉพาะ เรามาตอบคำถามที่ชัดเจนก่อนว่า “ทำไมเราถึงต้องการระบบและวิธีการจัดการโครงการเลย”- แน่นอน ลองพิจารณาประวัติโดยย่อของการจัดการโครงการและกำหนดเงื่อนไขพื้นฐานของการจัดการโครงการ

ทำไมต้อง “บริหารโครงการ”?

ชื่อของนีล อาร์มสตรองและบัซ อัลดรินจะจารึกลงในประวัติศาสตร์ตลอดไปในฐานะสัญลักษณ์แห่งความสำเร็จที่ยิ่งใหญ่ที่สุดชิ้นหนึ่งของมนุษยชาติ - การนำมนุษย์ไปเหยียบดวงจันทร์ อย่างไรก็ตาม ผู้มีส่วนร่วมหลักในกิจกรรมนี้คือพนักงานของ NASA 400,000 คน และบริษัทและมหาวิทยาลัย 20,000 แห่งที่ทำงานร่วมกันในภารกิจ Apollo

ในปีพ.ศ. 2504 จอห์น เอฟ. เคนเนดีได้มอบหมายภารกิจให้มนุษย์ลงจอดบนดาวเทียมของโลกแล้วส่งเขากลับมา แม้ว่าในเวลานั้น NASA จะส่งมนุษย์ไปในอวกาศเพียง 15 นาทีก็ตาม เป้าหมายที่ทะเยอทะยานดังกล่าวต้องการทรัพยากร ความร่วมมือ นวัตกรรม และการวางแผนจำนวนมหาศาลอย่างไม่น่าเชื่อ

ตามที่หนังสือของ NASA การจัดการโครงการดวงจันทร์ ปัญหาหลักไม่ได้อยู่ที่ “ จะทำอย่างไร?"และในสิ่งนั้น " จะทำอย่างไรให้มากในเวลาอันสั้น?ตามที่ Dr. Max Faget หัวหน้าฝ่ายวิศวกรรมของ Lyndon Johnson Space Center กล่าว (ศูนย์อวกาศลินดอน บี. จอห์นสัน JSC)จากนั้น NASA ก็ไม่รู้ว่าจะดำเนินการที่จำเป็นทั้งหมดภายใน 10 ปีอย่างไร ดังนั้นขั้นตอนแรกคือ "แบ่งโครงการออกเป็นขั้นตอนที่สามารถจัดการได้"

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

ระบบ 5 ขั้นตอนนี้ - เรียกว่า "GEM Stages" ตามชื่อย่อของ Dr. Muller - ได้รับการออกแบบ "เพื่อมุ่งเน้นไปที่การทดสอบผลิตภัณฑ์ และพัฒนาด้วยความรู้ที่จะทดสอบ" ตามที่ Muller บันทึกไว้ การควบคุมโปรแกรมกำหนดสิ่งที่ต้องทำ จัดการงบประมาณและข้อกำหนด และจัดการความสัมพันธ์ขององค์ประกอบของโปรแกรม วิศวกรรมระบบมีหน้าที่รับผิดชอบในการพัฒนาอุปกรณ์และชุดประกอบใหม่ การทดสอบมีหน้าที่รับผิดชอบในการตรวจสอบว่าองค์ประกอบใหม่เหล่านี้ทำงาน ความน่าเชื่อถือและคุณภาพตรวจสอบองค์ประกอบที่พัฒนาแล้วเพื่อให้สอดคล้องกับข้อกำหนดและมาตรฐาน และฝ่ายปฏิบัติการการบินมีหน้าที่รับผิดชอบในการรับรองว่าโหนดเหล่านี้จะทำงานได้ ระหว่างเที่ยวบิน

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

ประวัติโดยย่อของการบริหารโครงการ

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

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

อย่างไรก็ตาม หากคุณเป็นเชฟและกำลังเตรียมอาหารมากกว่าหนึ่งจาน แต่มีหลายอย่าง เช่น สลัด (ซึ่งประกอบด้วย 3 ขั้นตอน) และของหวาน (ซึ่งต้องเสิร์ฟเท่านั้น) คุณจะต้องมีเครื่องมือที่ ให้คุณติดตามเวลาที่ใช้ไปกับแต่ละรายการ รายการ และเวลาที่ควรจะพร้อม และนี่คือเครื่องมือการจัดการโครงการสมัยใหม่เครื่องแรกเข้ามาช่วยชีวิต: แผนภูมิ Gantt นำเสนอใน รูปที่ 2.

คิดค้นโดยอิสระโดย K อู๋ในบทบาทของ Korol Adamecki และ Henry L. Gantt ในช่วงต้นศตวรรษที่ 20 แผนภูมิ Gantt จะแสดงกำหนดการของโครงการตามวันที่ครบกำหนดและวันที่ครบกำหนดสำหรับงาน งาน ระยะเวลา และความสัมพันธ์ของงานถูกป้อนเข้าไป จากนั้นจึงคำนวณเส้นทางวิกฤติ - สายงานที่ยาวที่สุดของงานที่เชื่อมต่อถึงกันซึ่งกำหนดระยะเวลาของโครงการ ความสัมพันธ์ระหว่างการเริ่มต้นและสิ้นสุดของงานต่างๆ มีความสำคัญมาก - คุณไม่สามารถเสิร์ฟซุปให้แขกของคุณจนกว่าคุณจะปรุงมันเสร็จแล้วใช่ไหม

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

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

วิธีการจัดการโครงการแบบ Agile และวิธีการที่เกี่ยวข้อง เช่น Lean, Kanban และอื่นๆ เหมาะสมกว่าสำหรับโครงการดังกล่าว นอกจากนี้ยังมีวิธีการที่ช่วยให้คุณจัดการทั้งเวิร์กโฟลว์ เวลา และทรัพยากร - 6 Sigma และ Scrum

ระบบการจัดการโครงการยอดนิยม

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

ก่อนที่เราจะเริ่มดูวิธีการที่นิยมมากที่สุด เรามานิยามคำศัพท์สำคัญกันก่อน

เงื่อนไขพื้นฐานของการจัดการโครงการ

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

เส้นทางวิกฤต:ลำดับกิจกรรมและเหตุการณ์ต่อเนื่องตั้งแต่ต้นจนจบซึ่งใช้เวลานานที่สุดกว่าจะเสร็จ

ห่วงโซ่เหตุการณ์ของกระบวนการ (แผนภาพ EPC):ไดอะแกรมแสดงลำดับของการดำเนินโครงการตามความพร้อมใช้งานและปริมาณงานของทรัพยากร

สำรองเวลา:ระยะเวลาที่การเริ่มงานอาจล่าช้าได้โดยไม่กระทบต่อระยะเวลาโดยรวมของโครงการ ดังนั้น ความหย่อนของกิจกรรมบนเส้นทางวิกฤติจะเป็นศูนย์

เหตุการณ์สำคัญ (ด่าน,เหตุการณ์สำคัญ):เหตุการณ์สำคัญที่ทำเครื่องหมาย ตัวอย่างเช่น จุดสิ้นสุดของขั้นตอน ในแผนภูมิแกนต์ จะแสดงด้วยงานที่มีระยะเวลาเป็นศูนย์

ผู้จัดการโครงการ (หัวหน้าโครงการ,โครงการผู้จัดการ,PM ): หัวหน้าทีมโครงการรับผิดชอบการจัดการโครงการ (การวางแผน การดำเนินการ และการปิดโครงการ)

ทรัพยากร:องค์ประกอบที่จำเป็นสำหรับการดำเนินโครงการ ทรัพยากรได้แก่ เวลา อุปกรณ์ วัสดุ พนักงาน และอื่นๆ

วิ่ง (วิ่ง):การวนซ้ำ (วัฏจักรการทำงาน) ใน Scrum ซึ่งกินเวลาตั้งแต่หนึ่งสัปดาห์ถึงหนึ่งเดือน ในระหว่างที่มีการสร้างเวอร์ชันการทำงานของผลิตภัณฑ์หรือองค์ประกอบที่มีคุณค่าต่อลูกค้า

การจัดการโครงการ "คลาสสิก" หรือ "ดั้งเดิม":วิธีการจัดการโครงการที่ใช้กันอย่างแพร่หลายมากที่สุด โดยอิงตามสิ่งที่เรียกว่า "น้ำตก" (น้ำตก) หรือวงจรเรียงซ้อน ซึ่งงานจะถูกถ่ายโอนตามลำดับผ่านขั้นตอน คล้ายกับโฟลว์

การจัดการโครงการแบบคลาสสิก

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

แนวทางนี้มุ่งเน้นไปที่โครงการที่มีข้อจำกัดที่เข้มงวดในลำดับงาน ตัวอย่างเช่น การสร้างบ้าน - คุณไม่สามารถสร้างกำแพงโดยไม่มีรากฐาน

โดยปกติ การจัดการโครงการแบบคลาสสิกจะมี 5 ขั้นตอน แต่สามารถเพิ่มขั้นตอนอื่นๆ ได้หากโครงการต้องการ

5 ขั้นตอนของการจัดการแบบดั้งเดิม:

ด่าน 1 การเริ่มต้นผู้จัดการโครงการและทีมงานเป็นผู้กำหนดข้อกำหนดสำหรับโครงการ ในขั้นตอนนี้ การประชุมและการระดมความคิดมักจะจัดขึ้น ซึ่งจะกำหนดว่าผลงานของโครงการควรเป็นอย่างไร

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

ระยะที่ 3 การพัฒนาขั้นตอนนี้ไม่ได้ดำเนินการกับทุกโครงการ - ตามกฎแล้ว ขั้นตอนนี้เป็นส่วนหนึ่งของขั้นตอนการวางแผน ในขั้นตอนการพัฒนา ลักษณะของโครงการเทคโนโลยี การกำหนดค่าของโครงการในอนาคต และ/หรือผลิตภัณฑ์ และวิธีการทางเทคนิคเพื่อให้บรรลุ ตัวอย่างเช่น ในโครงการไอที ภาษาโปรแกรมจะถูกเลือกในขั้นตอนนี้ ( ในทางปฏิบัติภายในประเทศ ระยะนี้มักจะไม่แตกต่าง และไม่ใช้คำว่า "การพัฒนา" - ประมาณ ทรานส์)

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

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

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

เนื่องจากการจัดการโครงการแบบคลาสสิกนั้นผูกมัดกับเวลาดำเนินการของงานอย่างเคร่งครัด ตามกฎที่กำหนดไว้ล่วงหน้าในขั้นตอนการวางแผน เครื่องมือการวางแผนเครือข่ายปฏิทินจึงยอดเยี่ยมสำหรับการดำเนินโครงการภายใต้กรอบของแนวทางนี้ เครื่องมือจัดตารางเวลาที่พบบ่อยที่สุดคือแผนภูมิแกนต์ที่กล่าวถึงก่อนหน้านี้ มีเครื่องมือมากมายในการสร้าง ตั้งแต่สเปรดชีตอย่างง่าย เช่น Excel และ Smartsheet ไปจนถึงแพ็คเกจซอฟต์แวร์ระดับมืออาชีพ เช่น Microsoft Project และ Primavera

จุดแข็งของการจัดการโครงการแบบคลาสสิก

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

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

จุดอ่อนของการจัดการโครงการแบบคลาสสิก

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

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

เปรียว

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

และนี่คือจุดที่ Agile เข้ามามีบทบาท ซึ่งเป็นกลุ่มของวิธีการแบบวนซ้ำ-แบบเพิ่มหน่วยที่ยืดหยุ่นสำหรับการจัดการโครงการและผลิตภัณฑ์ ตามแนวทางนี้ โปรเจ็กต์ไม่ได้แบ่งเป็นระยะต่อเนื่องกัน แต่เป็นโปรเจ็กต์ย่อยเล็กๆ ซึ่งจากนั้น "ประกอบ" เป็นผลิตภัณฑ์สำเร็จรูป โครงร่างการทำงานแสดงบน รูปที่ 5.

ดังนั้น การเริ่มต้นและการวางแผนระดับบนสุดจึงถูกดำเนินการสำหรับทั้งโครงการ และขั้นตอนต่อมา: การพัฒนา การทดสอบ และอื่นๆ จะดำเนินการสำหรับโครงการย่อยแต่ละโครงการแยกกัน สิ่งนี้ทำให้คุณสามารถถ่ายโอนผลลัพธ์ของโปรเจ็กต์ขนาดเล็กเหล่านี้ ที่เรียกว่าส่วนเพิ่ม เร็วขึ้น และเมื่อเริ่มต้นโปรเจ็กต์ย่อยใหม่ (การวนซ้ำ) คุณสามารถทำการเปลี่ยนแปลงได้โดยไม่มีค่าใช้จ่ายสูงและส่งผลกระทบต่อส่วนที่เหลือของโปรเจ็กต์ .

แม้จะมีความจริงที่ว่า Agile เข้ามาเป็นสมัยค่อนข้างเร็ว แต่แนวคิดของการพัฒนาแบบวนซ้ำนั้นไม่ใช่เรื่องใหม่ (เกี่ยวกับประวัติของรูปลักษณ์เปรียวสามารถอ่านได้ - ประมาณ ต่อ.)ตระกูลของระเบียบวิธีเปรียวได้รับชื่อปัจจุบันในปี 2544 ด้วยการตีพิมพ์ Agile Manifesto (Agile Manifesto) ซึ่งรวมเอาค่านิยมหลักและหลักการพัฒนาซอฟต์แวร์เปรียวซึ่งอยู่บนพื้นฐานของการทำงานเป็นทีมและการปรับตัว แม้กระทั่ง "ความรัก" สำหรับ เปลี่ยน.

Agile เองไม่ใช่วิธีการจัดการโครงการ ค่อนข้างจะเป็นชุดของแนวคิดและหลักการว่าควรดำเนินโครงการอย่างไร บนพื้นฐานของหลักการและแนวทางปฏิบัติที่ดีที่สุดเหล่านี้ วิธีการที่ยืดหยุ่นแยกจากกัน หรือที่บางครั้งเรียกว่าเฟรมเวิร์ก (เฟรมเวิร์ก) ได้รับการพัฒนา: Scrum, Kanban, Crystal และอื่นๆ อีกมากมาย วิธีการเหล่านี้อาจแตกต่างกันค่อนข้างมาก แต่ใช้หลักการเดียวกัน

จุดแข็งเปรียว

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

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

ขอบเขตของ Agile คือการพัฒนาผลิตภัณฑ์ที่เป็นนวัตกรรมใหม่ ในโครงการที่จะพัฒนาผลิตภัณฑ์ดังกล่าว มีความไม่แน่นอนในระดับสูง และข้อมูลเกี่ยวกับผลิตภัณฑ์จะถูกเปิดเผยในระหว่างโครงการ ภายใต้เงื่อนไขดังกล่าว เป็นไปไม่ได้ที่จะดำเนินโครงการใน "น้ำตก" - ไม่มีข้อมูลสำหรับการวางแผน

จุดอ่อนเปรียว

ไม่เหมือนกับ PRINCE2 และ PMBOK ที่ Agile ไม่ใช่วิธีการหรือมาตรฐาน Agile คือชุดของหลักการและค่านิยม ด้านที่อ่อนแอคือแต่ละทีมจะต้องสร้างระบบการจัดการของตนเองโดยอิสระตามหลักการของ Agile นี่เป็นกระบวนการที่ซับซ้อนและใช้เวลานาน ซึ่งจะต้องมีการเปลี่ยนแปลงทั่วทั้งองค์กร ตั้งแต่ขั้นตอนปฏิบัติไปจนถึงค่านิยมหลัก นี่เป็นเส้นทางที่ยุ่งยากและไม่ใช่ทุกองค์กรจะทำได้

เส้นทางนี้จะต้องการจากผู้นำของการเปลี่ยนแปลง ไม่เพียงแต่ความรู้และความอุตสาหะเท่านั้น แต่ยังต้องใช้ทรัพยากรการบริหารที่จริงจัง รวมถึงต้นทุนด้วย โชคดีที่มีชุดปฏิบัติสำเร็จรูปที่ช่วยให้องค์กรเปลี่ยนรูปแบบ Agile ได้ง่าย ชุดเหล่านี้รวมถึงเฟรมเวิร์ก Scrum, เมธอด Kanban และอื่นๆ อีกมากมาย - Crystal, LeSS, SAFe, Nexus

Scrum

เฟรมเวิร์กที่คล่องตัวซึ่งสร้างขึ้นในปี 1986 ถือเป็นโครงสร้างที่มีโครงสร้างมากที่สุดในตระกูล Agile สร้างขึ้นในปี พ.ศ. 2529 โดยผสมผสานองค์ประกอบของกระบวนการแบบคลาสสิกและแนวคิดของแนวทางที่คล่องตัวในการจัดการโครงการ ผลลัพธ์ที่ได้คือการผสมผสานระหว่างความยืดหยุ่นและโครงสร้างที่สมดุล

ตามหลักการของ Agile Scrum จะแบ่งโปรเจ็กต์ออกเป็นส่วนๆ ที่ลูกค้าสามารถใช้ได้ทันทีเพื่อรับมูลค่า ซึ่งเรียกว่า backlog ของผลิตภัณฑ์ และแม้ว่าข้อเท็จจริงที่ว่า "งานในมือของผลิตภัณฑ์" เป็นการแปลที่ค่อนข้างแม่นยำและใช้ในวรรณคดีมืออาชีพ ในทางปฏิบัติของรัสเซีย มักใช้ "งานในมือ" เพียงอย่างเดียว จากนั้นชิ้นส่วนเหล่านี้จะถูกจัดลำดับความสำคัญโดยเจ้าของผลิตภัณฑ์ - ตัวแทนของลูกค้าในทีม "ชิ้นส่วน" ที่สำคัญที่สุดคือชิ้นแรกที่ได้รับเลือกให้ดำเนินการใน Sprint ซึ่งเรียกว่าการวนซ้ำใน Scrum ซึ่งกินเวลาตั้งแต่ 2 ถึง 4 สัปดาห์ ในตอนท้ายของ Sprint ลูกค้าจะได้รับผลิตภัณฑ์ที่ใช้งานได้ - "ชิ้นส่วน" ที่สำคัญที่สุดที่สามารถใช้ได้แล้ว ตัวอย่างเช่น ไซต์ที่มีฟังก์ชันการทำงานบางส่วนหรือโปรแกรมที่ใช้งานได้แล้ว แม้ว่าจะมีเพียงบางส่วน หลังจากนั้น ทีมงานโครงการจะไปยัง Sprint ถัดไป ระยะเวลาของ Sprint ได้รับการแก้ไขแล้ว แต่ทีมจะเลือกมันอย่างอิสระในช่วงเริ่มต้นของโปรเจ็กต์ ขึ้นอยู่กับโปรเจ็กต์และประสิทธิภาพของโปรเจ็กต์เอง

เพื่อให้แน่ใจว่าโครงการตรงตามข้อกำหนดของลูกค้า ซึ่งมีแนวโน้มที่จะเปลี่ยนแปลงเมื่อเวลาผ่านไป ก่อนเริ่ม Sprint แต่ละครั้ง ขอบเขตโครงการที่ยังไม่เสร็จสมบูรณ์จะได้รับการประเมินใหม่และมีการเปลี่ยนแปลง ทุกคนมีส่วนร่วมในกระบวนการนี้ - ทีมงานโครงการ, Scrum Master (Scrum Master, หัวหน้าทีมโครงการ) และ Product Owner และทุกคนมีหน้าที่รับผิดชอบในกระบวนการนี้

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

โครงสร้างพื้นฐานของกระบวนการ Scrum เกี่ยวข้องกับการประชุมหลัก 5 รายการ ได้แก่ การจัดลำดับงานในมือ การวางแผน Sprint การประชุมรายวัน การซักถามเกี่ยวกับ Sprint และการย้อนรอย Sprint

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

จุดแข็งScrum

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

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

ในระหว่างการทำซ้ำแต่ละครั้ง นักพัฒนาจะเพิ่มและทดสอบคุณลักษณะใหม่ของไซต์และลบคุณลักษณะที่ลูกค้าไม่ได้ใช้ ทีมงาน Netflix กล่าวว่าข้อได้เปรียบหลักของ Scrum คือช่วยให้คุณ "ล้มเหลวอย่างรวดเร็ว" แทนที่จะเป็นรุ่นใหญ่ที่ใช้เวลานานและมีค่าใช้จ่ายสูง การส่ง scrum กลับมีขนาดเล็ก ง่ายต่อการติดตาม และหากมีสิ่งใดผิดพลาด ให้แก้ไขอย่างรวดเร็ว

จุดอ่อนScrum

Scrum มีความต้องการอย่างมากในทีมโครงการ ควรมีขนาดเล็ก (5-9 คน) และข้ามสายงาน นั่นคือ สมาชิกในทีมควรมีความสามารถมากกว่าหนึ่งความสามารถที่จำเป็นสำหรับการดำเนินโครงการ ตัวอย่างเช่น นักพัฒนาซอฟต์แวร์ต้องมีความรู้ด้านการทดสอบและ Business Intelligence สิ่งนี้ทำเพื่อให้ส่วนหนึ่งของทีมไม่ "ไม่ได้ใช้งาน" ในขั้นตอนต่างๆ ของโครงการ ตลอดจนเพื่อให้พนักงานสามารถช่วยเหลือและเปลี่ยนซึ่งกันและกันได้

นอกจากนี้สมาชิกในทีมจะต้องเป็น "ผู้เล่นในทีม" มีความรับผิดชอบและสามารถจัดระเบียบตนเองได้ การหาทีมที่โตเต็มที่แบบนี้มันยากมาก!

Scrum ไม่เหมาะสำหรับทุกทีมและทุกองค์กรเช่นกัน เนื่องจากกระบวนการที่เสนออาจไม่เหมาะสำหรับการพัฒนาผลิตภัณฑ์เฉพาะ เช่น เครื่องจักรอุตสาหกรรมหรือการสร้างอาคาร

เอียง

Agile บอกเราว่าควรแยกส่วนงานเล็กๆ น้อยๆ ที่จัดการได้ออกมาอย่างไร แต่ไม่ได้กล่าวถึงวิธีจัดการการพัฒนาแพ็คเกจนี้ Scrum นำเสนอกระบวนการและขั้นตอนต่างๆ แก่เรา ในทางกลับกัน Lean จะเพิ่มโครงร่างเวิร์กโฟลว์ให้กับหลักการของ Agile เพื่อให้การทำซ้ำแต่ละครั้งมีคุณภาพเท่ากัน

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

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

เช่นเดียวกับ Agile Lean เป็นแนวคิดมากกว่าวิธีคิดมากกว่าบางสิ่งบางอย่าง ด้วยการใช้แนวคิดของ Lean คุณสามารถสร้างระบบที่ตรงตามความต้องการของคุณในการจัดการโครงการได้อย่างอิสระ

จุดแข็งเอียง

หากคุณชอบแนวคิดแบบ Agile แต่โครงการต้องการคุณภาพที่ราบรื่นและการดำเนินการที่แม่นยำ Lean มีชุดเครื่องมือที่ตรงตามข้อกำหนดเหล่านี้ Lean ผสมผสานความยืดหยุ่นและโครงสร้างอย่าง Scrum แต่แตกต่างออกไปเล็กน้อย

จุดอ่อนเอียง

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

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

คัมบัง

Lean นั้นดูเป็นนามธรรมเพียงเล็กน้อย แต่เมื่อรวมกับ Kanban แล้ว มันจะง่ายกว่ามากที่จะใช้มันเพื่อสร้างระบบการจัดการโครงการของคุณเอง Kanban สร้างขึ้นโดยวิศวกรของ Toyota Taiichi Ono ในปี 1953 Kanban มีความคล้ายคลึงกับการผลิตภาคอุตสาหกรรมมาก ที่ทางเข้ากระบวนการนี้ ชิ้นส่วนของโลหะเข้ามา และได้รับชิ้นส่วนสำเร็จรูปที่ทางออก นอกจากนี้ ในคัมบัง การเพิ่มผลิตภัณฑ์จะถูกส่งต่อจากเวทีหนึ่งไปอีกขั้น และในตอนท้าย จะได้รับสินค้าพร้อมจัดส่ง

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

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

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

ระบบ Kanban ของคุณเองสามารถยืดหยุ่นได้ตามที่คุณต้องการ เนื่องจาก Kanban เป็นการแสดงภาพแนวคิด Agile ในหลาย ๆ ด้าน แต่คัมบังมี 4 เสาหลักที่ทั้งระบบวางอยู่:

  1. การ์ด:สำหรับแต่ละงาน การ์ดแต่ละใบจะถูกสร้างขึ้น ซึ่งจะมีการป้อนข้อมูลที่จำเป็นทั้งหมดเกี่ยวกับงาน ดังนั้นข้อมูลที่จำเป็นทั้งหมดเกี่ยวกับงานจึงอยู่ใกล้แค่เอื้อม
  2. จำกัดจำนวนงานต่อขั้นตอน:จำนวนไพ่ในหนึ่งขั้นตอนถูกควบคุมอย่างเข้มงวด ด้วยเหตุนี้ จึงชัดเจนในทันทีเมื่อ "ความแออัด" เกิดขึ้นในเวิร์กโฟลว์ ซึ่งถูกขจัดออกไปในทันที
  3. การไหลอย่างต่อเนื่อง:งานจากงานในมือจะตกลงไปในโฟลว์ตามลำดับความสำคัญ งานจึงไม่เคยหยุดนิ่ง
  4. การปรับปรุงอย่างต่อเนื่อง (ไคเซ็น)ไคเซ็น)):แนวคิดของการพัฒนาอย่างต่อเนื่องเกิดขึ้นในประเทศญี่ปุ่นเมื่อปลายศตวรรษที่ 20 สาระสำคัญคือการวิเคราะห์กระบวนการผลิตอย่างต่อเนื่องและค้นหาวิธีปรับปรุงประสิทธิภาพการผลิต

จุดแข็งคัมบัง

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

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

จุดอ่อนคัมบัง

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

6 ซิกม่า (ซิกซิกมา)

โมโตโรล่าและโตโยต้ายังมีส่วนช่วยในการพัฒนาการจัดการโครงการระดับโลกอีกด้วย Bill Smith วิศวกรของบริษัทนี้ สร้างแนวคิดของ 6 Sigma ในปี 1986 Lean เป็นเวอร์ชันที่มีโครงสร้างมากกว่า Kanban ซึ่งเพิ่มการวางแผนเพื่อประหยัดทรัพยากร ปรับปรุงคุณภาพ และลดเศษวัสดุและปัญหา

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

สำหรับสิ่งนี้ กระบวนการ 5 ขั้นตอนที่เรียกว่า DMEDI ได้รับการเสนอ:

  • คำนิยาม (กำหนด):ขั้นตอนแรกจะคล้ายกับระยะเริ่มต้นของระบบการจัดการโครงการอื่นๆ จะกำหนดเนื้อหาของโครงการ รวบรวมข้อมูลเกี่ยวกับข้อกำหนดเบื้องต้นของโครงการ กำหนดเป้าหมาย
  • มิติ (วัด): 6 Sigma มุ่งเน้นไปที่การรวบรวมและวิเคราะห์ข้อมูลเชิงปริมาณเกี่ยวกับโครงการ ในขั้นตอนนี้ จะกำหนดว่าตัวชี้วัดใดจะกำหนดความสำเร็จของโครงการ และข้อมูลใดบ้างที่ต้องรวบรวมและวิเคราะห์
  • ศึกษา (สำรวจ):ในระหว่างขั้นตอนการวิจัย ผู้จัดการโครงการจะตัดสินใจว่าทีมจะบรรลุเป้าหมายได้อย่างไร และตรงตามข้อกำหนดทั้งหมดตรงเวลาและอยู่ในงบประมาณ ในขั้นตอนนี้ การคิดที่ไม่ได้มาตรฐานของผู้จัดการโครงการในการแก้ปัญหาที่เกิดขึ้นมีความสำคัญมาก
  • การพัฒนา (พัฒนา):ในขั้นตอนนี้ แผนและการตัดสินใจในขั้นตอนก่อนหน้ากำลังดำเนินการอยู่ สิ่งสำคัญคือต้องเข้าใจว่าในขั้นตอนนี้ จำเป็นต้องมีแผนรายละเอียด ซึ่งอธิบายการดำเนินการทั้งหมดที่จำเป็นเพื่อให้บรรลุเป้าหมาย ความคืบหน้าของโครงการยังวัดได้ในขั้นตอนนี้
  • ควบคุม (ควบคุม):เหตุการณ์สำคัญในระเบียบวิธี 6 Sigma เป้าหมายหลักคือการปรับปรุงกระบวนการดำเนินโครงการในระยะยาว ขั้นตอนนี้ต้องใช้การจัดทำเอกสารบทเรียนที่ได้รับอย่างรอบคอบ การวิเคราะห์ข้อมูลที่รวบรวม และการประยุกต์ใช้ความรู้ที่ได้รับทั้งในโครงการและทั่วทั้งบริษัทโดยรวม

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

จุดแข็งของ 6 Sigma

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

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

จุดอ่อนของ 6 Sigma

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

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

PRINCE2

NASA ไม่ใช่องค์กรของรัฐเพียงแห่งเดียวที่มีส่วนร่วมในการพัฒนาการจัดการโครงการ รัฐบาลอังกฤษชื่นชมประสิทธิผลของการจัดการโครงการมาอย่างยาวนาน และในปี 1989 ระเบียบวิธีของอังกฤษ PRINCE2 ก็ถูกสร้างขึ้น ชื่อมาจากตัวย่อ " PRวัตถุ ใน คควบคุม อีเวอร์ชั่นสิ่งแวดล้อม 2 ” ซึ่งแปลว่า “โครงการในสภาพแวดล้อมที่มีการควบคุมรุ่น 2” ต่างจากวิธีการแบบ Agile PRINCE2 ไม่ได้ใช้วิธีการแบบวนซ้ำกับโปรเจ็กต์ เมื่อเปรียบเทียบกับผลิตภัณฑ์อื่นๆ PRINCE2 สามารถนำมาเปรียบเทียบกับวิธีการแบบคลาสสิกในการจัดการโครงการและให้ความสำคัญกับคุณภาพตั้งแต่ 6 ซิกมา

วิธีการของ PRINCE2 ซึ่งแตกต่างจากตัวอย่าง PMBOK เนื้อหาไม่มี:

  • ลักษณะเฉพาะของการจัดการโครงการ เช่น อุตสาหกรรม
  • แนวทางปฏิบัติเฉพาะและเครื่องมือการจัดการโครงการ เช่น แผนภูมิแกนต์ WBS เป็นต้น

PRINCE2 มุ่งเน้นด้านการจัดการโครงการที่แสดงใน 7 หลักการ 7 กระบวนการและ 7 ธีมของโครงการ

  • 7 หลักการ กำหนดกฎทั่วไปสำหรับการจัดการโครงการตาม PRINCE2 กำหนดพื้นฐานของวิธีการ
  • 7 กระบวนการ กำหนดขั้นตอนในการดำเนินการตามรอบโครงการ
  • หัวข้อทั้ง 7 ด้านเป็นประเด็นที่ติดตามผลสำเร็จของโครงการ

ในช่วงเริ่มต้นของโครงการ PRINCE2 ขอให้เรากำหนด 3 ประเด็นหลักของโครงการ:

  • ด้านธุรกิจ (โครงการนี้จะก่อให้เกิดประโยชน์หรือไม่)
  • ด้านผู้บริโภค (ต้องการสินค้าอะไร เราจะทำอย่างไร)
  • ด้านทรัพยากร (เรามีเพียงพอที่จะบรรลุเป้าหมายหรือไม่)

PRINCE2 มีโครงสร้างทีมโครงการที่ชัดเจนกว่าแนวทางการจัดการโครงการส่วนใหญ่ เนื่องจาก PRINCE2 ให้ความสำคัญกับโครงการภาครัฐขนาดใหญ่และองค์กรขนาดใหญ่

ตาม PRINCE2 สมาชิกในทีมแต่ละคนมีบทบาทที่แตกต่างกันในแต่ละกระบวนการทั้ง 7 ประการ:

  • เริ่มโครงการ (เริ่มอิง ขึ้นเอ โครงการ): ในระหว่างกระบวนการนี้ จะมีการแต่งตั้งผู้จัดการโครงการและกำหนดข้อกำหนดด้านประสิทธิภาพของผลิตภัณฑ์โดยรวม ผู้จัดการโครงการซึ่งมีหน้าที่หลักในการใส่ใจในรายละเอียดรายงานต่อคณะกรรมการกำกับโครงการซึ่งรับผิดชอบทิศทางโดยรวมของโครงการ เป็นคณะกรรมการกำกับที่ดูแลโครงการให้เป็นไปตามแผนและรับผิดชอบอย่างเต็มที่ต่อความสำเร็จของโครงการ
  • การเริ่มต้นโครงการเอ โครงการ): ในระหว่างกระบวนการนี้ ผู้จัดการโครงการจะเตรียม "เอกสารการเริ่มต้นโครงการ" ที่มีแผนแบ่งเป็นระยะของโครงการ ขั้นตอนสามารถใช้เวลาแตกต่างกันได้ แต่ในแนวทางคลาสสิกพวกเขาปฏิบัติตามอย่างเคร่งครัด
  • การจัดการโครงการ (Directiงึ เอ โครงการ): กระบวนการนี้ช่วยให้คณะกรรมการกำกับรับผิดชอบโดยรวมสำหรับความสำเร็จของโครงการโดยไม่ต้องจมปลักอยู่ในรายละเอียดที่อยู่ในขอบเขตของผู้จัดการโครงการ
  • การควบคุมเวที (Controlหลิง เอ เวที): ในระหว่างการดำเนินโครงการ การเปลี่ยนแปลงบางอย่างจะเกิดขึ้นแม้ในสภาวะที่เหมาะสม กระบวนการควบคุมขั้นตอนดำเนินการตามหลักการหนึ่งของ PRINCE2 - หลักการจัดการตามข้อยกเว้น เป็นความรับผิดชอบของผู้จัดการโครงการที่จะต้องเฝ้าติดตามในระหว่างการดำเนินการส่วนเบี่ยงเบนของขั้นตอนจากพารามิเตอร์โครงการที่วางแผนไว้ในแง่ของเวลา ขอบเขต งบประมาณ ฯลฯ หากการเบี่ยงเบนเหล่านี้เกินอำนาจที่คณะกรรมการกำกับกำหนดให้กับผู้จัดการโครงการ (ใน คำศัพท์ PRINCE2 - ความคลาดเคลื่อน) ผู้จัดการโครงการต้องแจ้งคณะกรรมการกำกับและเสนอวิธีออกจากสถานการณ์
  • การจัดการการสร้างผลิตภัณฑ์ (ผู้จัดการ ผลิตภัณฑ์ จัดส่ง):กระบวนการจัดการการสร้างผลิตภัณฑ์คือการโต้ตอบระหว่างผู้จัดการโครงการและผู้จัดการทีมเพื่อสร้างหนึ่งในผลิตภัณฑ์ของโครงการ ความรับผิดชอบของผู้จัดการโครงการในกระบวนการนี้รวมถึงการมอบอำนาจในการสร้างผลิตภัณฑ์ให้กับผู้จัดการทีมและยอมรับผลิตภัณฑ์ที่สร้างขึ้น
  • การจัดการขอบเขตเวที (Managอิง เอ เวที เขตแดน): ในระหว่างกระบวนการนี้ ผู้จัดการโครงการจะให้ข้อมูลที่จำเป็นทั้งหมดแก่คณะกรรมการขับเคลื่อนเพื่อประเมินผลลัพธ์ของขั้นตอนที่ผ่านและตัดสินใจเกี่ยวกับการเปลี่ยนแปลงไปยังขั้นตอนถัดไป
  • เสร็จสิ้นโครงการ (ปิดเอ โครงการ): ความแตกต่างอย่างหนึ่งใน PRINCE2 คือกระบวนการเสร็จสิ้นของโครงการไม่ได้ถูกแยกออกเป็นขั้นตอนหรือขั้นตอนที่แยกจากกัน เช่นเดียวกับในแนวทางแบบคลาสสิก แต่ดำเนินการเป็นส่วนหนึ่งของขั้นตอนสุดท้ายของการสร้างผลิตภัณฑ์ วัตถุประสงค์ของกระบวนการคือเพื่อยืนยันว่าผลิตภัณฑ์ของโครงการได้รับการยอมรับแล้ว หรือโครงการไม่สามารถส่งมอบสิ่งที่เป็นประโยชน์ได้อีกต่อไป

PRINCE2 สามารถปรับให้เข้ากับโครงการทุกขนาดและทุกสาขาวิชา วิธีการนี้เสนอคำแนะนำเฉพาะสำหรับการเปลี่ยนแปลงวงจรชีวิตโครงการ แบบอย่าง และชุดเอกสารที่จำเป็นตามความต้องการของโครงการ

จุดแข็งของ PRINCE2

  • การปรับตัวให้เข้ากับลักษณะขององค์กร
  • มีคำอธิบายที่ชัดเจนเกี่ยวกับบทบาทและการกระจายความรับผิดชอบ
  • เน้นผลิตภัณฑ์โครงการ
  • ระดับการจัดการบางระดับ;
  • มุ่งเน้นไปที่ความเป็นไปได้ทางเศรษฐกิจ
  • ลำดับของงานโครงการ
  • เน้นการเก็บเกี่ยวประสบการณ์และปรับปรุงอย่างต่อเนื่อง

จุดอ่อนของ PRINCE2

  • ขาดแนวปฏิบัติในอุตสาหกรรม
  • ขาดเครื่องมือเฉพาะสำหรับการทำงานในโครงการ

ระบบบริหารจัดการโครงการที่ดีที่สุด ... สำหรับคุณ!

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

 

อาจเป็นประโยชน์ในการอ่าน: