การจัดการความสัมพันธ์ระหว่างส่วนประกอบ: คู่มือฉบับสมบูรณ์สำหรับโครงการและผลิตภัณฑ์

อินฟอร์เมเทค ดิจิตอล » Recursos » การจัดการความสัมพันธ์ระหว่างส่วนประกอบ: คู่มือฉบับสมบูรณ์สำหรับโครงการและผลิตภัณฑ์

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

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

ความสัมพันธ์แบบพึ่งพาในด้านการจัดการโครงการและผลิตภัณฑ์นั้นหมายถึงอะไร?

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

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

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

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

ประเภทของความสัมพันธ์แบบพึ่งพา: ภาพรวมโดยละเอียด

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

แบ่งแผนกตามลักษณะงาน

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

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

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

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

ความสัมพันธ์ระหว่างงาน: ความสัมพันธ์เชิงเวลาแบบคลาสสิก

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

ในความสัมพันธ์แบบเสร็จสิ้นก่อนเริ่ม (Finish-to-Start หรือ FS) งานที่ตามมาจะไม่สามารถเริ่มต้นได้จนกว่างานที่มาก่อนจะเสร็จสิ้น ความสัมพันธ์แบบนี้พบได้บ่อยที่สุดและเป็นค่าเริ่มต้นที่เครื่องมือส่วนใหญ่ใช้

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

ในกรณีของ Start-to-Start (SS) งานทั้งสองจะต้องถูกเปิดใช้งานพร้อมกันงานที่ตามมาไม่สามารถเริ่มต้นก่อนงานก่อนหน้าได้ แม้ว่างานทั้งสองจะดำเนินไปตามจังหวะของตนเองก็ตาม

ความสัมพันธ์แบบเริ่มต้นจนจบ (SF) ซึ่งพบได้ไม่บ่อยนักแต่ก็ยังคงมีอยู่ หมายความว่างาน A จะถือว่าเสร็จสมบูรณ์ไม่ได้จนกว่างาน B จะเริ่มต้น ตัวอย่างทั่วไปคือ การเปลี่ยนกะในฝ่ายบริการลูกค้า: พนักงานคนหนึ่งไม่สามารถออกไปได้จนกว่าพนักงานอีกคนจะมาถึง

ความสัมพันธ์ภายใน ภายนอก และระหว่างทีม

นอกเหนือจากลักษณะเฉพาะแล้ว สิ่งสำคัญคือต้องแยกแยะความแตกต่างระหว่างการพึ่งพาภายในโครงการ (ระหว่างงานหรือทรัพยากรที่ทีมควบคุมเอง) และการพึ่งพาภายนอก ซึ่งขึ้นอยู่กับบุคคลภายนอก

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

การจัดการการพึ่งพาเชิงรุกเทียบกับการจัดการการพึ่งพาเชิงรับ

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

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

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

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

การแสดงภาพความสัมพันธ์ระหว่างงาน: จาก Kanban สู่เมทริกซ์ใน Jira

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

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

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

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

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

ก่อนที่การทำงานระยะไกลจะแพร่หลาย เมทริกซ์เหล่านี้มักถูกวาดลงบนกระดานจริง ปัจจุบัน ปลั๊กอินและโมดูลของ Jira เช่น Advanced Roadmaps, BigPicture และ Structure ช่วยให้สามารถแสดงเครือข่ายความสัมพันธ์เหล่านี้ในรูปแบบภาพได้ในสภาพแวดล้อมแบบไฮบริดหรือแบบทำงานระยะไกลอย่างเต็มรูปแบบ

คลาสการจองและกระดานการจองในระบบ Kanban

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

คลาสการจองใช้เพื่อจำแนกงานตามลำดับความสำคัญ ความเร่งด่วนหรือเวลาส่งมอบที่ต้องการ ในการใช้วิธีนี้กับงานที่ต้องพึ่งพาซึ่งกันและกัน จะใช้ปฏิทินในการจัดสรรช่วงเวลาเพื่อแก้ไขปัญหาเหล่านั้น ไม่ว่าจะเป็นรายวัน รายสัปดาห์ หรือรอบการทำงาน (เช่น สปรินต์ในทีมสครัม)

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

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

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

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

กิจกรรมเพื่อตรวจสอบความสัมพันธ์ระหว่างส่วนต่างๆ และประสานงานทีม

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

ไม่จำเป็นต้องเป็นการประชุมใหม่ สามารถผนวกรวมเข้าเป็นส่วนหนึ่งของวาระการประชุมที่มีอยู่แล้วได้ เช่น ในการประชุมวางแผนการทำงานในแต่ละรอบ ในการวางแผน PI ตามแนวทาง SAFe หรือในการประชุมประสานงานระหว่างทีม

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

ความสัมพันธ์ที่ดีและไม่ดี: ความสัมพันธ์แบบซิงโครนัสและแบบอะซิงโครนัส

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

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

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

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

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

การออกแบบโครงสร้างองค์กรและทีมงานเพื่อลดการพึ่งพาซึ่งกันและกัน

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

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

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

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

แผนกที่มีทีมงานข้ามสายงาน: ฝ่ายทรัพยากรบุคคล ฝ่ายจัดซื้อ ฝ่ายกฎหมาย…

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

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

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

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

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

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

ในระดับทางเทคนิคแล้ว แหล่งที่มาของการพึ่งพาซึ่งกันและกันที่พบได้บ่อยมีอยู่ 3 แหล่ง ได้แก่ทีมแบ็กเอนด์ที่แยกต่างหากทีมปฏิบัติการ (Ops) ที่แยกจากกัน และทีมพัฒนาแอปพลิเคชันบนมือถือที่เป็นอิสระ

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

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

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

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

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

สถานการณ์คล้ายกันนี้เกิดขึ้นกับทีมพัฒนาแอปพลิเคชันมือถืออิสระ: ทักษะเฉพาะด้านของพวกเขา (iOS, Android, การออกแบบมือถือ, แนวทางปฏิบัติของแพลตฟอร์ม) ทำให้หลายองค์กรรวมพวกเขาไว้ในทีมเดียว ซึ่งสุดท้ายแล้วก็ต้องให้บริการหลายทีมย่อย ส่งผลให้เกิดคิวการจัดลำดับความสำคัญที่ซับซ้อน และปัญหาคอขวดเมื่อทุกทีมร้องขอการเปลี่ยนแปลงแอปพลิเคชันมือถือพร้อมกัน

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

การจัดการการพึ่งพาของซอฟต์แวร์: ไลบรารี เฟรมเวิร์ก และความปลอดภัย

นอกเหนือจากการจัดระเบียบแล้ว ในการพัฒนาซอฟต์แวร์ คำว่า "การพึ่งพา" มักหมายถึงไลบรารีภายนอก เฟรมเวิร์ก และส่วนประกอบต่างๆที่แอปพลิเคชันของคุณจำเป็นต้องใช้ในการทำงาน ในที่นี้เรากำลังพูดถึงตัวจัดการการพึ่งพา เช่น Maven, Gradle, npm หรือComposer

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

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

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

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

เคล็ดลับเชิงปฏิบัติสำหรับการจัดการความสัมพันธ์ระหว่างโปรเจกต์

ในการบริหารจัดการโครงการในแต่ละวัน มีแนวทางปฏิบัติหลายอย่างที่ช่วยให้ควบคุมความสัมพันธ์ระหว่างงานต่างๆ ได้ดียิ่งขึ้น เครื่องมือหลายอย่าง (เช่น Asana, Wrike, Jira เป็นต้น) ต่างก็เห็นพ้องต้องกันในการแนะนำแนวทางต่างๆ เหล่านี้

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

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

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

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

ผลกระทบของความสัมพันธ์ระหว่างกันต่อความสำเร็จของโครงการ

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

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

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

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

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