การคิดอย่างเป็นระบบ

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

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

จากระบบ :

จะรู้ได้อย่างไรว่าคุณกำลังดูระบบหรือแค่บางส่วน:

A) คุณสามารถระบุชิ้นส่วนได้หรือไม่?

B) ส่วนต่างๆ มีผลซึ่งกันและกันหรือไม่?

C) ส่วนประกอบต่างๆ รวมกันสร้างเอฟเฟกต์ที่แตกต่างจากเอฟเฟกต์ของแต่ละส่วนด้วยตัวมันเองหรือไม่?

ง) ผลกระทบ พฤติกรรมเมื่อเวลาผ่านไป ยังคงมีอยู่ในสถานการณ์ที่หลากหลายหรือไม่?

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

ตัวอย่างเช่น บ่อยครั้งที่วิศวกรเจอ “โค้ดที่ไม่ถูกต้อง” และรีบสรุปว่าโค้ดที่ไม่ถูกต้องนั้นเกิดจาก “วิศวกรที่แย่” อย่างไรก็ตาม นักคิดเชิงระบบอาจตรวจสอบเพิ่มเติม:

เหตุใดรหัสที่ไม่ถูกต้องจึงเกิดขึ้น (ทีมผู้ผลิตอยู่ภายใต้แรงกดดันให้จัดส่งอย่างรวดเร็ว)

เหตุใดทีมจึงตัดสินใจที่จะลดมุมแทนที่จะเลื่อนไปตามเส้นเวลาและรักษามาตรฐาน (ทีมสูญเสียวิศวกรอาวุโสทั้งหมด)

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

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

เหตุใดองค์กรจึงล้มเหลวในการส่งมอบ (หนี้ทางเทคนิคมากเกินไปและ “โค้ดเสีย” ทำให้ทีมทำซ้ำในโค้ดเบสได้ยาก)

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

ผู้อ่านบางคนจะเปรียบกระบวนการคิดนี้กับ เทคนิค การ สืบสวน 5 Whysซึ่งมักใช้สำหรับการวิเคราะห์สาเหตุ ของเหตุการณ์ RCA เป็นการประยุกต์ใช้การคิดเชิงระบบซึ่งพยายามเปิดเผยสาเหตุเอกพจน์ของการรบกวนในระบบ อีกครั้งจากหนังสือ:

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

1) ทุกสิ่งที่เราคิดว่าเรารู้เกี่ยวกับโลกคือแบบจำลอง

2) แบบจำลองของเรามักจะมีความสอดคล้องกันอย่างมากกับโลก

3) นางแบบของเราขาดการเป็นตัวแทนโลกอย่างเต็มที่

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

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