เมื่อผู้บริหารเมินคำเตือนจาก IT ทีมเทคโนโลยีจึงโต้กลับอย่างหนัก
(theregister.com)การตอบโต้ของทีม IT ที่ให้บทเรียน
- เรื่องราวของ "Bruce" ผู้เคยทำงานในทีมโครงสร้างพื้นฐานอินเทอร์เน็ตของธนาคารแห่งหนึ่งในออสเตรเลีย
- ในช่วงเริ่มต้นของอินเทอร์เน็ตแบงก์กิ้ง ทีมเติบโตอย่างรวดเร็วและปริมาณงานก็เพิ่มขึ้นด้วย
- ก่อนที่การใช้งานลิงก์ ISDN จะเกินครึ่ง ทีมก็ตระหนักถึงความจำเป็นในการซื้อลิงก์เพิ่มและยื่นข้อเสนอให้ CIO
การปฏิเสธของผู้บริหารและการตอบสนองของทีม IT
- CIO ได้นำคำขอซื้อลิงก์ ISDN เพิ่มไปเสนอต่อฝ่ายบริหาร แต่ถูกปฏิเสธเพราะการใช้งานลิงก์ปัจจุบันยังไม่ถึงครึ่ง
- เมื่อการใช้งานลิงก์เกิน 50% ทีม IT ก็ยื่นคำขออีกครั้ง แต่ได้รับคำสั่งให้รอจนกว่าจะเข้าใกล้ 100%
มาตรการเชิงกลยุทธ์ของทีม IT
- ทีม IT ตัดสินใจปรับการเชื่อมต่อเครือข่ายของผู้บริหาร เพื่อทำให้ผู้บริหารรับรู้ปัญหาด้วยตนเอง
- สัปดาห์แรกปรับลดลง 10% และหลังจากนั้นก็ลดเพิ่มอีกสัปดาห์ละ 10%
- หนึ่งเดือนต่อมา การติดตั้งลิงก์ ISDN เพิ่มได้รับการอนุมัติ และผู้บริหารก็เฉลิมฉลองกันเองว่าได้แก้ "ปัญหาอินเทอร์เน็ต" แล้ว
ความเห็นของ GN⁺
สิ่งสำคัญที่สุดในบทความนี้คือการที่ทีม IT กล้าท้าทายการตัดสินใจของผู้บริหาร และใช้ประสบการณ์การใช้งานจริงเพื่อโน้มน้าวให้เกิดการลงทุนด้านโครงสร้างพื้นฐานที่จำเป็น นี่แสดงให้เห็นถึงแนวทางที่สร้างสรรค์และมีประสิทธิภาพในการลดช่องว่างระหว่างปัญหาทางเทคนิคกับการตัดสินใจทางธุรกิจ เรื่องนี้ไม่เพียงน่าสนใจสำหรับผู้เชี่ยวชาญด้าน IT เท่านั้น แต่ยังมีบทเรียนที่ช่วยให้ผู้มีอำนาจตัดสินใจที่ไม่ได้มีพื้นฐานด้านเทคนิคเข้าใจความสำคัญของโครงสร้างพื้นฐานเทคโนโลยีได้ดีขึ้นด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เคยใช้ ซอฟต์แวร์ของบุคคลที่สาม ห่วย ๆ ตัวหนึ่งที่สร้างปัญหาใหญ่ให้ลูกค้า
เรากำลังทำโซลูชันทดแทนภายในอยู่ แต่บางคนอยากต่อสัญญาแล้วใช้ซอฟต์แวร์เดิมที่เต็มไปด้วยบั๊กต่อไป
เลยจัดให้ทิกเก็ตทั้งหมดที่ลูกค้าเปิดไปถึงฝ่ายที่สนับสนุนให้คงโซลูชันเดิมไว้ สุดท้ายหลังจากย้ายมาใช้ระบบของเรา ปัญหาก็แทบหายไป
คนหน้างานมักกันปัญหาไว้ไม่ให้ไหลขึ้นไปข้างบนอย่างกล้าหาญ และองค์กรก็เสพติดสภาพนั้น โดยเอาคนเข้าไปเป็นเหมือนยาแก้ปวดแทนที่จะกำจัดปัญหา
ระบบเก่าทำอะไรไม่ได้เลยนอกจากงานที่มันทำอยู่แล้ว เว้นแต่จะรื้อสายไฟ/ปรับโครงสร้างครั้งใหญ่ และทีมที่ดูแลเชื่อว่าถ้าไม่แชร์ความรู้ก็จะมีงานทำตลอดชีวิต
ระบบใหม่มี latency ของฐานข้อมูลสูง เพราะทีมเชื่อว่าแทนที่จะแก้ query ก็แค่เพิ่ม CPU เข้าไปก็พอ
สองทีมนั่งอยู่ติดกันแต่ไม่คุยกันเลย และทีมระบบเก่ายังเคยแจ้งว่าพัสดุใต้โต๊ะผู้อำนวยการ IT เป็นระเบิดด้วย
สุดท้ายทีมระบบใหม่เรียก Oracle เข้ามา แล้ว Oracle ก็ช่วยเขียน query ใหม่ให้
ความสามารถในการ อธิบายความเสี่ยงให้ชัดเจน และบอกได้ว่าผลลัพธ์ทางเทคนิคจะกระทบธุรกิจอย่างไร เป็นทักษะสำคัญของคนทำงาน IT
ผู้บริหารของธนาคารนี้อาจจะทึ่มอย่างร้ายแรงจริง ๆ ก็ได้ แต่ก็เป็นไปได้เหมือนกันว่าทีมเทคนิคอธิบายไม่ดีพอ
อาจเพราะผมอยู่ในวงการ IT เอง ผมกลับรู้สึกว่าเราสื่อสารกันค่อนข้างดีและแม่นยำ
ปัญหาจริง ๆ คือ การเมืองของผู้จัดการระดับกลาง ที่ทำให้ทุกอย่างขุ่นมัว
กับทีมเราอาจพูดได้ว่า “ผมทำพังเอง เลยต้องแก้” แต่กับคนข้างบน มีคนที่ยกเหตุผลสารพัดเพื่อไม่ต้องย้อนการตัดสินใจ แม้แต่เรื่องที่ไม่ได้สำคัญมากนัก
บางทีอาจมีใครสักคนขายไอเดียกับเจ้านายไปแล้วว่าอุปกรณ์นั้นจะใช้ต่อได้อีก 10 ปี
จากที่ทำงานกับเพื่อนร่วมงาน พวกเขาพยายามมากทีเดียวที่จะอธิบายในหลายระดับความลึกให้เหมาะกับคนฟัง
สิ่งที่เกิดบ่อยกว่าคือผู้บริหารสูงสุดกับผู้จัดการใต้ลงมาแค่ไม่สนใจ
ในหัวพวกเขามี “แผนการใหญ่” อยู่แล้ว และไม่ว่านักพัฒนาจะบอกสักแค่ไหนว่าภาพฝันนั้นเป็นจริงไม่ได้ ก็ไม่เปลี่ยน
ส่วนใหญ่เข้าใจสิ่งที่เราพูดอย่างสมบูรณ์
ไม่ใช่ว่าเราโยนศัพท์เฉพาะลึกลับที่มีแต่ nerd ชนชั้นสูงรู้ใส่เขา แค่พวกเขาไม่สนใจเท่านั้น
ผมก็หวังว่าองค์กรที่มี วิศวกรรับผิดชอบมากขึ้น จะเพิ่มขึ้น และบริษัทที่ถูกบริหารด้วยคนสไตล์ MBA ที่ไร้หัวคิดและไร้หัวใจจะลดลง แต่ชีวิตก็เป็นแบบนี้แหละ
IT ภาคองค์กรเติบโตมาจากงานสนับสนุนงานออฟฟิศ และการให้เครื่องแฟกซ์หรือ PC ใช้งานได้ก็ไม่ได้ต้องมีการวางแผนเชิงกลยุทธ์อะไร ตอนแรกจึงถูกมองเป็นแผนกที่ไม่สำคัญ
มันง่ายที่จะคิดว่าเป็นเพราะพวกคนใส่สูทขี้งกหรือโง่ หรือเพราะฟังเรื่องเทคนิคไม่รู้เรื่อง แต่ในความเป็นจริงหลายครั้งก็เป็นเรื่อง ขาดทักษะการสื่อสาร
ที่ทำงานแรก CFO ปฏิเสธคำขอระบบ สำรองข้อมูล ที่เหมาะสมสำหรับ AS/400 อยู่เรื่อย ๆ
AS/400 เครื่องนั้นมีงานทั้งบริษัทอยู่ในนั้น ทั้ง ERP, CRM, บัญชี ฯลฯ และการสำรองงานของคน 300 คนลงฟลอปปีดิสก์ 8 นิ้วนั้นเป็นไปไม่ได้ตั้งแต่แรก
วันหนึ่งเกิดดิสก์เสียหายครั้งใหญ่ ทั้งบริษัทหยุดชะงักไปหลายสัปดาห์ การประมวลผลคำสั่งซื้อ คำขอซัพพอร์ต ข้อเสนอฝ่ายขาย และการค้นหาเลขลูกค้ากับที่อยู่ถูกบล็อกหมด
จำได้ว่าดิสก์บางส่วนถูกส่งไปให้ Kroll Ontrack
หลังหายนะครั้งนั้นถึงได้ซื้ออุปกรณ์สำรองข้อมูลที่เหมาะสม
ไม่กี่เดือนต่อมา นักพัฒนานักศึกษาคนหนึ่งรัน query ลบในโปรดักชันโดยที่เงื่อนไข
whereถูกคอมเมนต์ออกไป แล้วทั้งตารางก็หายเกลี้ยงมีแบ็กอัปอยู่ แต่ job เบื้องหลังตรวจพบเรื่องนี้แล้วสร้างใบแจ้งหนี้ย้อนหลัง 4 ปีขึ้นมาใหม่ จากนั้นส่งอีเมลไปหาลูกค้าเก่าทั้งหมดให้จ่ายเงินอีกครั้ง
หลังจากนั้นไม่นานก็มีสภาพแวดล้อมสำหรับทดสอบ
เมื่อไม่นานมานี้ผมทำงานให้วิทยาลัยชุมชนสองปีแห่งหนึ่งที่อยู่ห่างไกล ข้อมูลทั้งหมดอยู่บน AS/400 เก่า ๆ และมันล่มครั้งละหนึ่งสองวันทุกไม่กี่สัปดาห์
ไม่มีแบ็กอัป เทปไดรฟ์ก็เสีย และชิ้นส่วนอย่าง NIC 10Mbps ที่แม้ตามมาตรฐานตอนนั้นก็เก่าแล้วก็หาอะไหล่เปลี่ยนไม่ได้
ผมเรียกร้องซ้ำ ๆ ว่าต้องเปลี่ยนหรือย้ายไปเซิร์ฟเวอร์คลาวด์ แต่คำตอบที่ได้มีแต่ “ไม่มีในงบ” กับ “แพงเกินไป”
ถ้าดูจากการใช้งานจริง ค่าใช้จ่ายน่าจะอยู่แค่ไม่กี่ร้อยดอลลาร์ต่อเดือน ซึ่งไม่สมเหตุสมผลเลยเมื่อเทียบกับความเสี่ยงที่ถ้าระบบล่ม วิทยาลัยทั้งแห่งอาจพังและถึงขั้นต้องปิดถาวร
สุดท้ายก็เกิดเหตุขัดข้อง และเป็นเวลาหลายวันที่ยังเข้าถึงได้จากเทอร์มินัลหลัก แต่ไม่สามารถสื่อสารกับเครือข่ายได้เลย
ผู้คนเริ่มตื่นตระหนก และมีการพูดถึงการเรียกผู้เชี่ยวชาญซ่อม AS/400 ที่คิดค่าบริการเกินชั่วโมงละ 100 ดอลลาร์
ในความพยายามครั้งสุดท้าย ผมซ่อม NIC ได้ และตอนแจ้งว่ามันกลับมาทำงานแล้ว ก็ย้ำชัดว่านี่อาจเป็นการบูตครั้งสุดท้าย ดังนั้นต้องสำรองข้อมูลไปไว้ที่ไหนสักแห่งก่อนหน้านั้น
6 สัปดาห์ต่อมา เราก็มี AS/400 บนคลาวด์เงาวับ และจัดพิธีศพด้วยการปิดเจ้าสัตว์ร้ายเก่าแก่เทอะทะตัวนั้นเป็นครั้งสุดท้าย
เวลาทำงานรวมสุดท้ายเกือบ 25 ปี
อาจบอกได้ว่าเรื่องนี้มีโอกาสเกิดขึ้นน้อย หรือแต่งขึ้นมาทั้งหมดก็ได้ แต่ผมไม่ได้มองแบบนั้น
ในองค์กรขนาดใหญ่ ถ้าจะทำอะไรให้สำเร็จ ต้องทำให้ผู้บริหารรู้สึกถึงความเจ็บปวดของเรา
ไม่ได้ประชดนะ โลกมันเดินแบบนี้จริง ๆ
คนที่คาดหวังให้อีกฝ่ายไล่คิดทุกขั้นตอนทางความคิดเพื่อเข้าใจสถานการณ์ด้วยตัวเอง จะต้องเจอกับความประหลาดใจแบบแรง ๆ
แม้แต่ช่วงต้นยุค 90 ISDN ก็คงไม่ได้พบได้ทั่วไปนอกเหนือจากสำนักงานสาขา
ยิ่งมีเรื่อง traffic shaping/QoS เข้ามาด้วยก็ยิ่งเชื่อยาก
เท่าที่รู้ เราเตอร์ Cisco 2500/2600 ที่แทบทุกคนใช้กันตอนนั้น รองรับฟีเจอร์พวกนั้นในช่วงหลังจากนั้นอีกนาน
หรือบางทีเขาอาจหมายถึง T1 ก็ได้ แต่ให้ความรู้สึกแบบ r/thathappened มาก
ตามนิยามแล้ว ผู้จัดการทำงานคนละอย่างกับคนลงมือทำ
เช่น จะทำให้ผู้จัดการรู้สึกถึงความเจ็บปวดของ codebase ที่เละเทะ ได้อย่างไร?
ที่ทำงานพยายามประหยัดค่าใช้จ่ายโดยตั้งค่า เราเตอร์ Cisco 1604 ISDN เป็นแบบโทรออกอัตโนมัติ แทนที่จะเชื่อมต่อไว้ตลอดเวลา
แต่พบว่า IBM AIX ที่ติดตั้งแพ็กเกจเว็บเบราว์เซอร์ไว้ กำลังโทรส่ง telemetry กลับไปยัง Big Blue เป็นระยะทุกชั่วโมง ทำให้เครือข่ายแล็บไม่สามารถลดลงสู่สถานะ idle ได้
จึงเพิ่มกฎ firewall บนเราเตอร์เพื่อบล็อกพฤติกรรมเงียบ ๆ นั้น
แม้แต่ปลายยุค 90 Microsoft, Sun, Novell ก็ยังไม่หน้าด้านเรื่อง telemetry เท่า IBM
ปัญหาจริงที่เห็นจากตรงนี้คือ ฝั่ง IT ต้องมี อำนาจตัดสินใจเอง ในระดับหนึ่ง เพื่อทำสิ่งที่รู้ว่าถูกต้อง โดยค่อนข้างเป็นอิสระจากฝั่งธุรกิจ
สุดท้ายแล้ว องค์กรจะต้องยอมรับการกำกับดูแลมากแค่ไหนก็ขึ้นอยู่กับความไว้วางใจ
ที่ที่ผมอยู่ ถ้าไม่ใช่เรื่องที่กระทบลูกค้า ก็ไม่จำเป็นต้องขออนุญาต
ถ้าเครื่องดูเหมือนเริ่มรับไม่ไหว หรือแพ็กเกจ SaaS ใกล้ชนลิมิต ก็อัปเกรดไปเลย
บางครั้งอาจมีคนถามถึงใบเรียกเก็บเงินใหม่หรือค่าใช้จ่ายที่เพิ่มขึ้น แต่ไม่จำเป็นต้องถูกซักไซ้หลายรอบเพื่อให้งานเดินหน้า
คนใส่สูทควรลองคิดถึงข้อเสียของสภาพแวดล้อมที่ต้องไปอ้อนวอนขออนุญาตแม้แต่กับงานเทคนิคเล็ก ๆ
นวัตกรรมมากแค่ไหนที่ถูกโยนลงถังขยะติดไฟทันที เพราะนโยบายการเปลี่ยนแปลงอันซับซ้อนที่สร้างขึ้นบนหอคอยงาช้างเมื่อกว่าสิบปีก่อน?
เราจะคิดองค์กรใหม่ในแบบที่มองธุรกิจเป็นลูกค้าของทีม IT ได้ไหม?
ถ้าบริษัทล้มเหลว องค์กร IT ก็ไม่มีเหตุผลที่จะดำรงอยู่ ดังนั้นวิธีคิดแบบนั้นดูจะเรียบง่ายกว่ามาก
ดังนั้น ความคุ้มค่าต่อค่าใช้จ่าย จึงเปลี่ยนไป และจำเป็นต้องสื่อสารกัน
เวลาเห็นปฏิกิริยาแบบ “หน้าที่ของคุณคือเคารพการตัดสินใจตามลำดับชั้น” ก็ทำให้นึกได้ว่าองค์กรธุรกิจยังติดอยู่กับ แนวคิดแบบทหาร แค่ไหน
ในกองทัพปรัสเซียสมัยก่อน จะถ่ายทอดภารกิจโดยยึดเป้าหมายเป็นหลัก
แบบว่า “ฉันตั้งใจจะบรรลุ X, คุณรับผิดชอบ Y, หน่วยอื่นทำ Z” และปล่อยให้การปฏิบัติเป็นหน้าที่ของนายทหารในพื้นที่ซึ่งเห็นสถานการณ์จริงและมีความรู้ที่จำเป็น
นอกจากนี้ หากนายทหารหรือนายทหารชั้นประทวนคัดค้านคำสั่งของผู้บังคับบัญชาโดยตรง ก็ยังสามารถอุทธรณ์ไปยังผู้บังคับบัญชาที่สูงกว่าได้
เมื่อรวมกับระบบเสนาธิการที่นายทหารฝ่ายเสนาธิการต้องมีประสบการณ์บังคับบัญชาในระหว่างการฝึก และยังสามารถหักล้างคำสั่งของผู้บังคับบัญชาได้ จึงกลายเป็นระบบที่แข็งแรงและยืดหยุ่นซึ่งปรับตัวต่อสถานการณ์ที่เปลี่ยนไปได้
นายทหารไม่ลังเลที่จะถกเถียงกับผู้บังคับบัญชา ยกระดับเรื่องขึ้นไป หรือหากเห็นว่าจำเป็นจริง ๆ ก็ปฏิเสธคำสั่ง
เพราะสิ่งนั้นทำให้ยศชั้นล่างเห็นด้วยและเข้ามามีส่วนร่วม
คือการตัดสินใจในระดับที่ต่ำที่สุดเท่าที่เป็นไปได้
พอเข้าสู่ยุคสมัยใหม่ความนิยมลดลงไปบ้าง แต่เท่าที่รู้ ไม่มีกองทัพไหนดำเนินงานด้วยหลัก “หน้าที่ของคุณคือทำตามการตัดสินใจตามลำดับชั้น” ล้วน ๆ
เช่น หนังสือ Extreme Ownership
ผมอาจคิดร้ายเกินไปก็ได้ แต่ถ้าเป็นภาวะผู้นำแบบนั้น ผมคงแค่หางานใหม่แล้วปล่อยให้ทั้งลำเรือจมไป
ถ้าลองย่อให้เห็นจากมุมผู้นำ สมมติว่าทุกปีมีข้อเสนอคล้าย ๆ กัน 100 เรื่องขึ้นมา และแต่ละเรื่องใช้เงิน 1 ล้านดอลลาร์
แบบนั้นแม้ตัดเรื่องการตัดค่าเสื่อมหรือกลเม็ดภาษีออกไป ก็เป็นต้นทุนล้วน ๆ ปีละ 100 ล้านดอลลาร์
แม้แต่สำหรับธนาคารก็เป็นเงินก้อนใหญ่ และควรใช้อย่างมีกลยุทธ์ ไม่ใช่ใช้ทิ้งขว้าง
ในกรอบแบบนี้ การทำให้ผู้นำรู้สึกถึงความเจ็บปวด และเข้าใจโดยสัญชาตญาณว่าทำไมเงิน 1 ล้านดอลลาร์ครั้งนี้ถึงเป็นเงินที่ใช้ถูกทาง จึงเป็นกลยุทธ์ที่ค่อนข้างดีต่อทั้งผู้นำ IT และธุรกิจ
อีกอย่าง ผู้บริหารคือคนที่บริหารเวลา พนักงาน ค่าใช้จ่าย และทรัพยากรอื่น ๆ ที่มีจำกัดของบริษัท
แน่นอนว่าโดยมากพวกเขาไม่ได้ทำงานนั้นเก่งเป็นพิเศษ และถ้ามองจากมุมบริษัท ทางเลือกที่มีเหตุผลอย่างแท้จริงอาจเป็นการให้ค่าตอบแทนพวกเขาหรูหราน้อยลง ใกล้เคียงพนักงานทั่วไป
แต่ “บริษัท” ไม่ได้เป็นคนตัดสินใจ คนต่างหากที่ตัดสินใจ และในนั้นมีเกมการเมือง แรงจูงใจ และผลประโยชน์ส่วนตัวปะปนอยู่
ผู้บริหารควบคุมการไหลของข้อมูล การตัดสินใจ ทรัพยากร และเงิน จึงทำตัวเหมือนปรสิตที่ดูดส่วนแบ่งเกินควรจากบริษัทเจ้าบ้าน
การแก้ปัญหานี้ขอฝากไว้เป็นแบบฝึกหัดให้ผู้อ่าน
ถ้าพวกเขาได้ยินแค่ว่า “คาดว่าวงจรจะอิ่มตัว 50% ราววันที่ X” นั่นแปลว่า IT อธิบายได้แย่มากจริง ๆ
เรารู้ว่าในเทคโนโลยีนี้ การอิ่มตัว 50% หมายถึงความล่าช้าของลูกค้าหรือข้อผิดพลาดในการเชื่อมต่อ
ถ้าอย่างนั้นก็ควรพูดว่า “คาดว่าลูกค้าจะประสบปัญหาการเชื่อมต่อราววันที่ X”
ถ้ารู้ว่าขีดจำกัด 100% เป็นค่าเชิงทฤษฎีที่เป็นไปได้เฉพาะในสภาพอุดมคติ ก็ควรพูดโดยอิงขีดจำกัดที่ใช้งานได้จริง
ถ้าต้องการให้คนตัดสินใจจากข้อมูล ก็ต้องให้ข้อมูลที่ถูกต้อง และถ้า IT คือฝ่ายที่รับเงินมาเพื่อเข้าใจเทคโนโลยี การถ่ายทอดคุณลักษณะเหล่านั้นให้คนใส่สูทเข้าใจได้ก็เป็นหน้าที่ของ IT
แน่นอนว่าพวกเขาอาจทำเต็มที่แล้วก็ได้ แต่ถ้าดูจากบทความ มันฟังเหมือนว่าแค่ส่งบันทึกไปโดยไม่มีข้อมูลแบบนั้น
ไม่ค่อยเข้าใจว่าทำไมคำว่า “อัตราการใช้งาน 50%” ถึงถูกใช้เหมือนกับเปิดก๊อกน้ำไว้แค่ครึ่งเดียว
ถ้าภาระงานพุ่งไปกระจุกอยู่ที่ท่อเส้นเดียว สุดท้ายก็ย่อมเกิดประสิทธิภาพตกเป็นช่วง ๆ อยู่ดีไม่ใช่หรือ?
สัดส่วนเวลาที่ผู้ใช้ได้รับ “ประสบการณ์แย่” น่าจะเพิ่มขึ้นอย่างรวดเร็วตามการกระจายของโหลด จนแค่ 60% ก็น่าจะทนได้ยากแล้ว
ถ้าเปรียบเทียบ ก็เหมือนบาร์ดูแค่ดีมานด์เฉลี่ยแล้วตัดสินใจมีพนักงานเสิร์ฟแค่ 1 คน ทั้งที่คืนวันศุกร์กำลังจะมาถึง
นี่แหละคือสิ่งที่ สูตรของ Kingman กล่าวไว้
“เมื่ออัตราการใช้งานเกิน 50% ทีม IT ก็เสนอให้สั่ง ISDN อีกครั้ง แล้วก็ถูกปฏิเสธอีกครั้ง พร้อมคำสั่งว่าอย่ามาถามอีกจนกว่าอัตราการใช้งานจะเข้าใกล้ 100%”
เรื่องนี้คล้ายกับการรับรู้เรื่องโควิดของทางการมาก
ดูเหมือนผู้รับผิดชอบมองแนวโน้มเดิม ๆ แล้วไม่สามารถคาดการณ์อะไรได้เลย และจะตอบสนองก็ต่อเมื่อภัยพิบัติมาถึงตรงหน้าแล้วเท่านั้น