Hacking Mindset กล้าตั้งคำถามกับวิธีทำงานเดิม

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

แต่ก่อนจะลงมือปรับปรุงงาน เราอาจต้องย้อนกลับมาถามตัวเองว่า วิธีทำงานที่ใช้อยู่นั้นยังเหมาะสมกับสถานการณ์ปัจจุบันหรือไม่

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

แนวคิดที่เรียกว่า Hacking Mindset ชวนให้เรากลับมาตั้งคำถามในเรื่องนี้

Hacking Mindset คืออะไร และมีที่มาอย่างไร

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

รากฐานสำคัญของวัฒนธรรม Hacker ย้อนกลับไปถึงช่วงทศวรรษ 1950 ที่ Massachusetts Institute of Technology (MIT) โดยเฉพาะกลุ่มนักศึกษาใน Tech Model Railroad Club (TMRC) ซึ่งสนใจระบบควบคุมรถไฟจำลองและการดัดแปลงกลไกต่าง ๆ

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

ต่อมา Steven Levy ได้บันทึกเรื่องราวของ Hacker ยุคแรกไว้ในหนังสือ Hackers: Heroes of the Computer Revolution (1984) พร้อมอธิบายแนวคิด Hacker Ethic ที่ให้ความสำคัญกับการเรียนรู้จากการลงมือทำและการเปิดกว้างทางความรู้

Eric S. Raymond ได้ขยายมุมมองเกี่ยวกับทัศนคติของ Hacker ผ่านบทความ How To Become A Hacker ซึ่งเผยแพร่ครั้งแรกในปี 1996 โดยเน้นความสนใจในการแก้ปัญหา การเรียนรู้ และความสามารถในการลงมือทำ

แม้คำว่า Hacking Mindset จะไม่มีนิยามมาตรฐานหรือผู้บัญญัติที่ชัดเจนเพียงคนเดียว แต่เมื่อพิจารณาจากรากฐานของวัฒนธรรม Hacker ผู้เขียนมองว่า

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

แก่นแท้ของวิธีคิดแบบ Hacker

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

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

เมื่อพบทางเลือกใหม่ การทดลองจึงเข้ามามีบทบาท แทนที่จะถกเถียงกันเพียงว่าวิธีใดน่าจะดีกว่า ก็อาจเริ่มทดลองในขอบเขตที่เหมาะสม แล้วเรียนรู้จากผลที่เกิดขึ้น

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

ทั้งหมดนี้ต้องอาศัยการเรียนรู้อย่างต่อเนื่อง เพราะวิธีที่เหมาะสมในวันนี้อาจต้องเปลี่ยนไปเมื่อเงื่อนไขแวดล้อมเปลี่ยนแปลง

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

ปรับปรุงวิธีทำงาน หรือกลับมาตั้งคำถามกับวิธีทำงาน

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

อย่างไรก็ตาม การปรับปรุงงานมักตั้งอยู่บนสมมติฐานว่ากระบวนการเดิมยังเหมาะสม เพียงแต่ต้องทำให้ดีขึ้น

หากการจัดทำรายงานล่าช้า เราอาจพยายามเร่งให้จัดทำได้เร็วขึ้น หากการอนุมัติใช้เวลานาน ก็อาจเพิ่มการติดตามหรือกำหนดระยะเวลาให้ชัดเจนกว่าเดิม

แต่ลองเปลี่ยนคำถามดูบ้าง

ทำไมจึงต้องจัดทำรายงานในรูปแบบนี้?

ขั้นตอนการอนุมัติทั้งหมดจำเป็นเพียงใด?

ข้อกำหนดที่ใช้อยู่ช่วยสร้างคุณค่าหรือป้องกันความเสี่ยงอะไร?

คำถามเหล่านี้พาเราย้อนกลับไปตรวจสอบเหตุผลของกระบวนการตั้งแต่ต้น

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

Hacking Mindset กับการบริหารองค์กร

ลองพิจารณาตัวอย่างจากกระบวนการบริหารองค์กรที่พบได้ทั่วไปสองกรณี

การจัดทำความเสี่ยงประจำปีของแต่ละหน่วยธุรกิจ

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

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

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

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

หากลองตั้งคำถามใหม่ว่า

ปีนี้ BU มีเป้าหมายอะไร และมีความไม่แน่นอนใดที่อาจทำให้ไม่สามารถบรรลุเป้าหมายเหล่านั้น?

วิธีทำงานอาจเปลี่ยนไป

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

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

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

การกำหนด KPI ประจำปี

อีกตัวอย่างหนึ่งคือการกำหนดตัวชี้วัดผลการดำเนินงาน หรือ KPI

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

แทนที่จะเริ่มจากคำถามว่า

ปีนี้ควรปรับ KPI จากปีก่อนอย่างไร?

อาจเปลี่ยนเป็น

ปีนี้องค์กรต้องการผลลัพธ์อะไร และตัวชี้วัดใดจะสะท้อนความสำเร็จของผลลัพธ์นั้นได้จริง?

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

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

บางครั้ง Hacking Mindset จึงเริ่มต้นได้จากการเปลี่ยนคำถามที่ใช้กับงานประจำ โดยไม่จำเป็นต้องรื้อระบบหรือเปลี่ยนเครื่องมือทั้งหมด

เครื่องมือเปลี่ยนไป แต่วิธีคิดยังเป็นจุดเริ่มต้น

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

แต่เครื่องมือที่ทันสมัยไม่ได้ทำให้เราตั้งคำถามได้ดีขึ้นโดยอัตโนมัติ

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

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

ไม่ใช่ทุกสิ่งจำเป็นต้องถูก Hack

การตั้งคำถามกับวิธีทำงานเดิมไม่ได้หมายความว่าทุกกระบวนการควรเปลี่ยนแปลง

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

สิ่งสำคัญจึงอยู่ที่การแยกให้ออกว่า ข้อจำกัดใดเกิดจากความจำเป็น และข้อจำกัดใดเกิดจากความเคยชิน

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

เมื่อความคุ้นเคยกลายเป็นข้อจำกัด

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

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

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

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

เรากำลังพยายามทำสิ่งที่จำเป็นให้ดีขึ้น หรือกำลังพยายามทำสิ่งที่เคยทำให้ดีขึ้น?

---

แหล่งอ้างอิง (References)

1. MIT Tech Model Railroad Club. A Brief History of the Tech Model Railroad Club. https://tmrc.mit.edu/old/history/index.html

2. MIT Tech Model Railroad Club. Hackers. https://tmrc.mit.edu/old/hackers-ref.html

3. Levy, S. (1984). Hackers: Heroes of the Computer Revolution. Anchor Press/Doubleday. https://www.stevenlevy.com/hackers-heroes-of-the-computer-revolution

4. Raymond, E. S. (1996). How To Become A Hacker. Archived copy hosted by Duke University. https://courses.cs.duke.edu/spring01/cps004/readings/hacker.html