ฝึกคิดแบบ Amazon Leadership Principle

[PlAwAnSaI]

เปลี่ยน 16 Leadership Principle ให้กลายเป็นนิสัยในการทำงาน และการใช้ชีวิต​

DAY 1 — “ไม่ใช่หน้าที่เรา”​

Leadership Principle: Ownership

วันจันทร์ เวลา 9:12 น. ข้อความนึงเด้งขึ้นมาในกลุ่มงาน

“Customer แจ้งว่า Report ที่ได้รับเมื่อเช้ามีตัวเลขผิดครับ”

Pete เปิด File ขึ้นมาดู ใช้เวลาไม่ถึงสองนาทีก็พบว่าตัวเลขผิดจริง แต่เรื่องนี้ไม่ใช่ความผิดของเขา Report เป็นของ Team Data ส่วน Team ของ Pete ดูแล Application ที่นำข้อมูลจาก Report ไปใช้ต่อ ไม่ได้เป็นเจ้าของกระบวนการสร้าง Report

Pete พิมพ์ตอบกลับไปว่า

“รับทราบครับ เดี๋ยวแจ้ง Team Data ให้”

จากนั้นเขา Tag Team Data เข้าไปใน Conversation แล้วกลับไปทำงานของตัวเอง เพราะวันนี้ยังมีอีกสองงานที่ต้องส่งให้หัวหน้า

ฟังดูไม่มีอะไรผิด เขาพบปัญหาแล้ว เขาแจ้ง Team ที่รับผิดชอบแล้ว และปัญหานั้นก็ไม่ใช่งานของเขา

แต่สามชั่วโมงต่อมา Customer โทรเข้ามาอีกครั้ง ครั้งนี้ Customer ไม่ได้ถามว่า Data Team ทำงานถึงไหนแล้ว ไม่ได้ถามว่าใครเป็นคนสร้าง Report และไม่ได้สนใจว่าใน Organization Chart ใครรับผิดชอบอะไร

Customer ถามเพียงว่า

“ตกลงใครรับผิดชอบเรื่องนี้ครับ?”

Pete เงียบไปครู่หนึ่ง เพราะคำตอบที่อยู่ในหัวคือ “ไม่ใช่ผมครับ” แต่คำตอบนั้นไม่ได้ช่วยให้ Customer ได้ Report ที่ถูกต้องขึ้นมาเลย

---

เมื่อ “ไม่ใช่หน้าที่เรา” กลายเป็นปัญหาของทั้งองค์กร​

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

ปัญหาไม่ได้อยู่ที่การมี Boundary ปัญหาเกิดขึ้นเมื่อเราใช้ Boundary เป็นเหตุผลในการหยุดรับผิดชอบต่อ ผลลัพธ์

ลองแยกสองเรื่องนี้ออกจากกัน

Responsibility คือ งานที่องค์กร หรือหัวหน้ามอบหมายให้เราทำ

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

Pete ไม่จำเป็นต้องเข้าไปแก้ SQL ของ Team Data เขาไม่จำเป็นต้องสร้าง Report ใหม่ และไม่จำเป็นต้องกลายเป็น Owner ของระบบที่เขาไม่ได้ดูแล แต่เขาสามารถทำให้แน่ใจได้ว่าเรื่องนี้มีคนรับผิดชอบจริง ๆ

เขาอาจติดตามว่าใครกำลังรับเรื่อง ช่วยสื่อสาร Customer Impact ให้ชัดเจน ประสาน Team ที่เกี่ยวข้อง หรือ Escalate เมื่อเห็นว่าปัญหากำลังส่งผลต่อลูกค้า

นี่คือความแตกต่างระหว่าง

“ฉันไม่ใช่ Owner ของงานนี้”

กับ

“ฉันไม่ใช่ Owner แต่ฉันจะไม่ปล่อยให้ปัญหานี้หายไปเฉย ๆ”

---

Ownership ไม่ใช่การแบกทุกอย่างไว้บนบ่า​

มีความเข้าใจผิดอย่างนึงเกี่ยวกับ Ownership คือ ถ้าเรามี Ownership เราต้องทำทุกอย่างด้วยตัวเอง

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

Ownership ที่ดีไม่ได้หมายความว่า

“เดี๋ยวผมทำเองทั้งหมด”

แต่มันหมายความว่า

“ผมจะทำให้เรื่องนี้เดินไปจนถึงผลลัพธ์ที่ต้องการ”

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

สิ่งสำคัญคือ เราไม่ได้ใช้ Organizational Boundary เป็นกำแพงเพื่อป้องกันตัวเองจากปัญหา

---

แล้วถ้าทุกคนรับทุกเรื่องล่ะ?​

คำถามนี้สำคัญมาก เพราะถ้าอ่านมาถึงตรงนี้แล้วคิดว่า

“ถ้าทุกคนทำแบบนี้ เดี๋ยวก็มีคนมายุ่งกับงานคนอื่นหมดสิ”

คำตอบคือ ใช่ ถ้าเราเข้าใจ Ownership ผิด

Ownership ไม่ได้แปลว่าเรามีสิทธิ์เข้าไปตัดสินใจทุกเรื่อง ต้องแยก Ownership ออกจาก Authority

ตัวอย่างเช่น Team Application พบว่าข้อมูลจาก Data Team ผิด, Team Application ไม่มีสิทธิ์ไปเปลี่ยน Database ของ Data Team เอง แต่สามารถแจ้งปัญหา ระบุ Customer Impact ประสาน Owner ติดตาม Progress และ Escalate เมื่อมีความเสี่ยง

เรายังเคารพ Boundary เดิม แต่ไม่ปล่อยให้ Boundary กลายเป็นข้ออ้างว่า

“ไม่ใช่เรื่องของเรา”

นี่คือ Ownership ที่มีวุฒิภาวะ

---

ปัญหานี้เกิดขึ้นในองค์กรไทยบ่อยกว่าที่คิด​

ลองฟังประโยคที่เราได้ยินในที่ทำงาน

“รอ Team Infra ก่อน”

“อันนี้ต้องถาม Security”

“Business เป็นคน Request มา”

“Vendor ทำพลาด”

“ผมส่งต่อให้ Team อื่นแล้ว”

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

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

นี่เป็นปัญหาที่เกิดขึ้นได้มากเมื่อองค์กรเติบโตขึ้น เพราะเมื่อมี Team มากขึ้น Process ก็เพิ่มขึ้น ระบบก็เพิ่มขึ้น KPI ก็เพิ่มขึ้น และ Boundary ระหว่าง Team ก็ชัดขึ้น สิ่งเหล่านี้จำเป็นต่อการ Scale

แต่ถ้าไม่มี Ownership สิ่งเดียวกันนี้สามารถสร้าง Silo ได้ ทุก Team ทำหน้าที่ของตัวเองครบ, ทุก KPI อาจผ่าน, ทุก Ticket อาจถูกส่งต่อ แต่สุดท้ายไม่มีใครตอบคำถามง่าย ๆ ว่า

“แล้วภาพรวมสำเร็จหรือยัง?”

---

Ownership ไม่ได้มีเฉพาะในเวลาทำงาน​

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

หรือใน Project ส่วนตัว เรารู้ว่าแผนกำลังมีปัญหา แต่บอกตัวเองว่า “เดี๋ยวค่อยว่ากัน” จนถึงวันสุดท้ายแล้วค่อยแก้

Ownership เริ่มจากคำถามง่าย ๆ ว่า

“ในสิ่งที่ฉันควบคุมได้ ฉันสามารถทำอะไรให้สถานการณ์ดีขึ้น?”

ไม่ใช่

“ใครผิด?”

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

---

Challenge ประจำวัน​

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

หนึ่ง — มันไม่ใช่หน้าที่เราจริงหรือไม่? - ถ้าใช่ ก็ไม่เป็นไร เราไม่จำเป็นต้องเข้าไปทำงานแทนทุกคน

สอง — แล้วมันส่งผลต่อ Customer หรือเป้าหมายของ Team เราหรือไม่? - ถ้าใช่ เราอาจมีส่วนใน Outcome แม้ไม่ได้เป็น Task Owner

สาม — เราสามารถทำอะไรได้หนึ่งอย่างโดยไม่ก้าวข้าม Boundary? - อาจเป็นการแจ้ง ประสาน ติดตาม ช่วยวิเคราะห์ หรือ Escalate ไม่ต้องทำสิบอย่าง ทำเพียงหนึ่งอย่าง

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

---

ก่อนจบวัน​

คืนนี้ลองถามตัวเองสามข้อ

วันนี้มีปัญหาอะไรที่เราเห็น แต่ไม่ได้ทำอะไรเพราะคิดว่า “ไม่ใช่หน้าที่เรา”?

มีเรื่องอะไรที่เราเป็น Owner แต่กำลังโยนความรับผิดชอบให้คนอื่นหรือไม่?

และคำถามที่สำคัญที่สุด

ถ้า Customer ไม่สนใจว่า Organization Chart ของเราหน้าตาเป็นอย่างไร เราจะมองปัญหานี้ต่างจากเดิมไหม?

Ownership ไม่ได้ถามว่า

“นี่เป็นงานของฉันหรือเปล่า?”

มันถามว่า

“ผลลัพธ์นี้สำคัญหรือเปล่า และฉันสามารถช่วยให้มันดีขึ้นได้อย่างไร?”

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

ก่อนที่เราจะไปเปลี่ยน Team เปลี่ยนองค์กร หรือเปลี่ยนวิธีทำงานของคนอื่น สิ่งแรกที่เราต้องเปลี่ยนคือคำถามที่เราถามตัวเองเวลามีปัญหา

จาก

“ใครรับผิดชอบ?”

เป็น

“ฉันช่วยให้เรื่องนี้เดินหน้าได้อย่างไร?”

นั่นคือจุดเริ่มต้นของ Ownership

 

[PlAwAnSaI]

DAY 2 — “รอให้พร้อม หรือเริ่มก่อน?”​

Leadership Principle: Bias for Action

วันพุธ เวลา 10:15 น. ในห้องประชุมเล็ก ๆ ของบริษัท Team Product กำลังคุยกันเรื่องนึงที่ดูเหมือนง่าย แต่กลับคุยกันมาเกือบหนึ่งชั่วโมงแล้ว

ทุกคนเห็นตรงกันว่า Process ปัจจุบันมีปัญหา ลูกค้าต้องกรอกข้อมูลซ้ำหลายครั้ง และ Team งานเองก็เสียเวลาตรวจสอบข้อมูลเดิมซ้ำ ๆ มีคนเสนอว่า

“ลองทำ Form ใหม่ก่อนดีไหม?”

ทุกคนเงียบไปพักนึง

ฝ่าย Business บอกว่าอยากเห็นข้อมูลจากลูกค้าเพิ่ม

ฝ่าย IT บอกว่าต้องตรวจสอบ Integration ก่อน

ฝ่าย Security ขอ Review เรื่อง Data Privacy

ฝ่าย Finance บอกว่าต้องประเมิน Cost

ส่วน Manager สรุปว่า

“งั้นเรารวบรวมข้อมูลให้ครบก่อน แล้วค่อยตัดสินใจกัน”

ทุกคนพยักหน้า Meeting จบ

หนึ่งสัปดาห์ผ่านไป ข้อมูลยังไม่ครบ

อีกสองสัปดาห์ผ่านไป มี Meeting เพิ่มอีกสามครั้ง

หนึ่งเดือนต่อมา Process ยังเหมือนเดิม ลูกค้ายังต้องกรอกข้อมูลซ้ำ และ Team ยังเสียเวลาเหมือนเดิม

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

---

เมื่อ “ขอข้อมูลเพิ่ม” กลายเป็นข้ออ้างในการไม่ตัดสินใจ​

ในโลกการทำงาน เรามักคิดว่าการตัดสินใจที่ดีต้องเกิดจากข้อมูลที่ครบถ้วน ฟังดูถูกต้อง แต่ปัญหาคือ ในสถานการณ์จริง ข้อมูล 100% แทบไม่มีอยู่จริง

ลูกค้าเปลี่ยนใจ ตลาดเปลี่ยน คู่แข่งเปลี่ยน Technology เปลี่ยน และข้อมูลที่เรากำลังรอวันนี้อาจใช้ไม่ได้เมื่อเราได้มันมาในอีกสามเดือน

นี่คือเหตุผลที่ Bias for Action เป็นหนึ่งในหลักคิดที่สำคัญ มันไม่ได้บอกว่า

“คิดน้อย ๆ แล้วรีบทำ”

และไม่ได้หมายความว่า

“ตัดสินใจทุกอย่างให้เร็วที่สุด”

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

คำสำคัญคือ ระดับความเสี่ยง เพราะ Decision ไม่ได้มีผลกระทบเท่ากันทุกเรื่อง

การทดลอง Form ใหม่กับลูกค้า 10 คน อาจยกเลิกได้ในวันพรุ่งนี้

การเปลี่ยน Database Production อาจยกเลิกได้ยากกว่ามาก

การเลือก Campaign ใหม่ อาจใช้เวลาทดลองหนึ่งสัปดาห์

แต่การเซ็นสัญญาระยะยาวอาจต้องใช้เวลาและข้อมูลมากกว่านั้น

ดังนั้น Bias for Action ไม่ใช่การทำทุกอย่างเร็ว แต่คือการรู้ว่า

เรื่องไหนควรเริ่มทดลอง และเรื่องไหนควรหยุดคิดให้รอบคอบก่อนลงมือ

---

“Decision” กับ “Experiment” ไม่เหมือนกัน​

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

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

เราสามารถทำ Prototype ให้ Customer 10 คนทดลอง เก็บ Feedback แล้วค่อยตัดสินใจ

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

---

แล้วเมื่อไหร่ควรรอ?​

Bias for Action ไม่ได้แปลว่า “อย่ารอ” บางเรื่อง ควรรอ

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

ลองคิดง่าย ๆ ว่า ถ้าตัดสินใจผิด เราแก้กลับได้ง่ายแค่ไหน?

ถ้าแก้ได้ง่าย เราอาจมีพื้นที่สำหรับการทดลองมากขึ้น ถ้าแก้ยาก เราควรเพิ่มความรอบคอบ นี่เป็นจุดที่ Bias for Action ต้องทำงานร่วมกับ Are Right, A Lot และ Dive Deep

เราไม่ได้เลือก “เร็ว” แทน “ถูก” เราเลือก ความเร็วที่เหมาะสมกับความเสี่ยง

---

กับดักของคนเก่ง: อยากให้ทุกอย่างสมบูรณ์​

คนที่มีความรับผิดชอบสูงบางครั้งไม่ได้ช้าเพราะขี้เกียจ แต่ช้าเพราะอยากทำให้ดีที่สุด อยากวิเคราะห์ให้ครบ อยากถามทุกฝ่าย อยากเตรียมทุก Scenario อยากให้ไม่มีใครสามารถตั้งคำถามกับ Decision ได้

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

ลองนึกถึง Product ที่ใช้เวลาพัฒนาหนึ่งปีโดยไม่เคยให้ Customer ทดลอง

Team อาจสร้างสิ่งที่ “สมบูรณ์แบบ” ในมุมของตัวเอง แต่เมื่อเปิดให้ลูกค้าใช้จริงกลับพบว่า ลูกค้าไม่ได้ต้องการมันตั้งแต่แรก

ถ้าให้ลูกค้าทดลองตั้งแต่เดือนแรก Team อาจรู้เรื่องนี้เร็วกว่าถึงสิบเอ็ดเดือน นี่คือเหตุผลที่ Bias for Action ต้องทำงานคู่กับ Customer Obsession

เราไม่ได้รีบเพื่อให้เสร็จ เรารีบเพื่อ เรียนรู้

---

ในองค์กรไทย เรามักติดกับดัก “รออนุมัติ”​

“ขอถามหัวหน้าก่อน” “รอ Meeting”

“รอ Team อื่น” “รอข้อมูล”

“รอ Budget” “รอ Vendor”

บางเรื่องจำเป็นต้องรอจริง แต่บางเรื่องเราใช้คำว่า “รอ” เพราะมันปลอดภัยกว่า

ถ้าเราไม่ตัดสินใจ เราก็ไม่ต้องรับผิดชอบว่า Decision นั้นผิด ถ้าเราไม่เริ่ม เราก็ไม่ต้องเจอกับความล้มเหลว ถ้าเราไม่ทดลอง เราก็ยังสามารถพูดได้ว่า

“ยังไม่มีข้อมูลครับ”

แต่การไม่ตัดสินใจก็เป็น Decision แบบหนึ่ง เพราะเวลาที่ผ่านไปก็มี Cost ของมัน

Customer ยังรอ, Team ยังทำงานแบบเดิม, คู่แข่งยังเดินหน้า และ Opportunity อาจหายไปโดยที่ไม่มีใครรู้ว่าเราเสียมันไปเมื่อไหร่

---

ลองเปลี่ยนคำถาม​

ครั้งต่อไปที่คุณพบว่าตัวเองกำลังพูดว่า

“เรายังไม่มีข้อมูลพอ”

ลองเปลี่ยนเป็น

“ข้อมูลขั้นต่ำที่เราต้องมีเพื่อเริ่มทดลองคืออะไร?”

คำถามแรกทำให้เราหยุด คำถามที่สองทำให้เราเริ่มคิดถึงทางไปข้างหน้า และนั่นคือหัวใจของ Bias for Action

เราไม่ได้พยายามกำจัดความไม่แน่นอน เพราะทำไม่ได้ เราเรียนรู้ที่จะ ตัดสินใจ และเดินหน้าภายใต้ความไม่แน่นอน

---

Challenge ประจำวัน​

วันนี้ลองเลือกงานหนึ่งเรื่องที่คุณกำลัง “รอ”

รอข้อมูล รอ Approval
รอ Meeting รอคนอื่น
หรือรอให้ตัวเองพร้อม

แล้วแบ่งมันออกเป็นสามส่วน

สิ่งที่ต้องรู้ก่อนเริ่ม มีอะไรที่จำเป็นจริง ๆ?

สิ่งที่รู้เพิ่มทีหลังก็ได้ มีอะไรที่สามารถเรียนรู้ระหว่างทาง?

สิ่งที่สามารถทดลองได้ทันที มีอะไรที่เราสามารถทำเล็ก ๆ โดยไม่สร้างความเสียหายถ้าผลออกมาไม่ดี?

จากนั้นเลือก หนึ่ง Action ที่เล็กที่สุด แล้วลงมือทำวันนี้

ไม่ต้องแก้ทั้งระบบ ไม่ต้องทำ Project ใหญ่ แค่สร้างความคืบหน้าหนึ่งขั้น

---

ก่อนจบวัน​

ลองตอบคำถามสามข้อ

วันนี้เรากำลังรออะไรอยู่?

ถ้าเราไม่ทำอะไรอีกหนึ่งสัปดาห์ จะเกิดอะไรขึ้น?

และคำถามสำคัญที่สุด

“ถ้าการทดลองนี้ล้มเหลว เราสามารถเสียอะไรได้บ้าง และถ้าการทดลองนี้สำเร็จ เราจะได้เรียนรู้อะไร?”

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

---

Bias for Action ไม่ได้สอนให้เราเป็นคนใจร้อน มันสอนให้เราไม่ปล่อยให้ ความกลัว ความไม่แน่นอน หรือความต้องการความสมบูรณ์แบบ กลายเป็นเหตุผลที่ทำให้ทุกอย่างหยุดนิ่ง

คนที่ทำงานเร็วไม่จำเป็นต้องเป็นคนที่คิดน้อย คนที่ตัดสินใจเร็วก็ไม่จำเป็นต้องเป็นคนที่ประมาท คนที่มี Bias for Action คือคนที่รู้ว่า

เมื่อไหร่ควรคิด เมื่อไหร่ควรทดลอง และเมื่อไหร่ถึงเวลาต้องลงมือ

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

ความกล้าที่จะเริ่มจาก 80% ที่เรามี

---

DAY 3 — “เสร็จแล้วครับ”​

Leadership Principle: Insist on the Highest Standards

เวลา 17:48 น. ก่อนเลิกงานไม่ถึงสิบห้านาที ในห้อง Chat ของ Team มีข้อความจาก Nut เด้งขึ้นมา

“Deploy เสร็จแล้วครับ”

หัวหน้ากดเข้าไปดู Feature ใหม่ขึ้น Production เรียบร้อย ระบบไม่ล่ม ไม่มี Error และ Test Case ที่กำหนดไว้ทั้งหมดผ่าน ทุกอย่างดูเหมือนจะเรียบร้อย หัวหน้าตอบกลับสั้น ๆ

“Good job ครับ”

Nut ปิด Laptop ด้วยความรู้สึกโล่งใจ เพราะงานชิ้นนี้ใช้เวลามาเกือบสองสัปดาห์ และวันนี้คือ Deadline ที่ตกลงกับ Business เอาไว้

เช้าวันรุ่งขึ้น Customer คนแรกส่งข้อความเข้ามา

“ทำไมข้อมูลบางรายการหายไปครับ?”

Team เปิด Log ขึ้นมาตรวจสอบ พบว่า Feature ทำงานถูกต้องตาม Test Case ทุกอย่าง แต่ Test Case ที่เขียนไว้ไม่ได้ครอบคลุมกรณีของ Customer กลุ่มนี้ ระบบจึงไม่ได้ “พัง” มันเพียงแค่ทำงานตามที่ Team ออกแบบไว้ แต่สิ่งที่ Team ออกแบบไว้ ไม่ตรงกับสิ่งที่ Customer ต้องการ

 

[PlAwAnSaI]

งานเสร็จ กับงานที่ดี ไม่ใช่เรื่องเดียวกัน​

คำว่า “เสร็จแล้ว” เป็นคำที่เราใช้กันทุกวัน

Code, Report, Presentation, Project เสร็จแล้ว แต่คำถามคือ เสร็จในความหมายไหน?

เสร็จตาม Checklist / Requirement / Deadline? หรือเสร็จจนคนที่รับงานต่อสามารถใช้งานได้จริง?

หนึ่งในความท้าทายของการทำงานคือ เรามักวัดสิ่งที่ ตรวจสอบง่าย มากกว่าสิ่งที่ สำคัญจริง

จำนวน Task ที่ปิดได้, Ticket ที่ Clear ได้, Feature ที่ Release ได้วัดง่าย

แต่ Customer พอใจหรือไม่? Process ดีขึ้นหรือไม่? ปัญหากลับมาอีกหรือเปล่า? สิ่งเหล่านี้ต้องใช้ความพยายามในการมองให้ลึกกว่าเดิม นี่คือพื้นที่ของ Insist on the Highest Standards

---

Highest Standards ไม่ได้แปลว่า Perfect​

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

งานบางอย่างต้องการความเร็ว บางอย่างต้องการความแม่นยำ บางอย่างเป็นเพียง Prototype บางอย่างเกี่ยวข้องกับเงินจำนวนมาก บางอย่างเกี่ยวข้องกับความปลอดภัยของลูกค้า

มาตรฐานที่เหมาะสมจึงไม่จำเป็นต้องเท่ากันทุกงาน สิ่งสำคัญคือเราต้องรู้ว่า

“งานประเภทนี้ควรดีแค่ไหนจึงจะถือว่ายอมรับได้?”

และที่สำคัญกว่านั้นคือ

“อะไรคือสิ่งที่เราไม่มีสิทธิ์ปล่อยให้ต่ำกว่ามาตรฐาน?”

---

ปัญหาไม่ได้เกิดจากความผิดพลาดครั้งเดียว​

องค์กรส่วนใหญ่ไม่ได้มีปัญหาเพราะคนทำงานผิดพลาดหนึ่งครั้ง ปัญหามักเกิดจากการที่เรา ยอมรับความผิดพลาดเดิมซ้ำ ๆ

ครั้งแรกอาจเป็นเรื่องฉุกเฉิน ครั้งที่สองอาจเป็นเพราะ Deadline ครั้งที่สามอาจเป็นเพราะคนไม่พอ ครั้งที่สี่เริ่มกลายเป็น “วิธีทำงานปกติ” และเมื่อเวลาผ่านไป ทุกคนก็ลืมไปแล้วว่าจริง ๆ สิ่งนี้ไม่ควรเป็นเรื่องปกติ

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

ถ้าส่งงานที่มีข้อมูลผิดแล้วไม่มีใครถาม คนก็จะเรียนรู้ว่า “ผิดนิดหน่อยไม่เป็นไร”

ถ้า Test ไม่ครบแล้วผ่านทุกครั้ง คนก็จะเรียนรู้ว่า “Test เท่านี้ก็พอ”

ถ้า Documentation ไม่เคย Update และไม่มีใครสนใจ คนก็จะเรียนรู้ว่า “ไม่ต้องทำก็ได้”

สิ่งที่เรายอมรับในวันนี้ อาจกลายเป็นมาตรฐานของ Team ในวันพรุ่งนี้

---

“พอใช้ได้” เป็นกับดักที่อันตราย​

ลองนึกถึงประโยคที่เราได้ยินในที่ทำงาน

“เอาแบบนี้ไปก่อนครับ”

“เดี๋ยวค่อยแก้”

“Customer คงไม่เจอหรอก”

“Case นี้มีน้อย”

“Deadline แล้วครับ”

“อย่างน้อยก็ใช้งานได้”

ไม่มีประโยคไหนผิดเสมอไป บางครั้งการ Trade-off เป็นสิ่งที่จำเป็น

ปัญหาเกิดขึ้นเมื่อเรา ไม่เคยกลับมาแก้สิ่งที่บอกว่าจะ “เอาไว้ก่อน”

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

ดังนั้น Highest Standards ไม่ได้หมายความว่าเราต้องปฏิเสธทุก Trade-off แต่หมายถึง ถ้าเราตัดสินใจลดมาตรฐาน เราต้องรู้ว่าเรากำลังลดอะไร ทำไมถึงลด และเมื่อไหร่จะกลับมาจัดการมัน

---

แล้วหัวหน้าควรทำอย่างไร?​

มาตรฐานของ Team ไม่ได้เกิดจากการบอกว่า

“ทุกคนต้องทำงานให้ดีนะ”

เพราะคำว่า “ดี” ของแต่ละคนไม่เท่ากัน

หัวหน้าต้องทำให้ Team เห็นภาพว่า งานที่ดีหน้าตาเป็นอย่างไร

ถ้าเป็น Software > Definition of Done ต้องชัด

ถ้าเป็น Report ต้องรู้ว่า Data Quality ระดับไหนถึงยอมรับได้

ถ้าเป็น Customer Service ต้องรู้ว่า Customer Experience แบบไหนคือมาตรฐาน

ถ้าเป็น Marketing ต้องไม่วัดแค่จำนวน Content แต่อาจต้องมองไปถึง Impact

มาตรฐานที่ดีต้องสามารถอธิบายได้ และเมื่อเกิดปัญหา เราต้องถามด้วยว่า

“ระบบของเราปล่อยให้เรื่องนี้เกิดขึ้นได้อย่างไร?”

ไม่ใช่เพียง

“ใครเป็นคนทำ?”

เพราะถ้าคนหนึ่งทำผิดแล้วเราลงโทษเขา แต่ Process เดิมยังอยู่ พรุ่งนี้ก็อาจมีคนอื่นทำผิดแบบเดิม

---

อย่าสับสนระหว่าง Standard กับ Perfectionism​

เรื่องนี้สำคัญมาก คนที่ตั้งมาตรฐานสูงอาจกลายเป็นคนที่ทำงานช้าได้ ถ้าไม่รู้จักแยก สิ่งสำคัญ ออกจาก สิ่งที่แค่สวยงาม

ตัวอย่างเช่น Presentation สำหรับ Internal Meeting อาจไม่จำเป็นต้องใช้เวลาสามวันเพื่อจัดทุก Pixel ให้สมบูรณ์ แต่ Report ที่ใช้ประกอบการตัดสินใจเรื่องเงินจำนวนมากอาจต้องตรวจ Data ซ้ำหลายรอบ

การมี Standard สูงจึงไม่ใช่การทำทุกอย่างให้หนักขึ้น แต่คือการ ใช้ความพยายามให้ถูกจุด ถามตัวเองว่า

“ถ้าสิ่งนี้ผิด จะเกิดผลกระทบอะไร?”

ถ้าผลกระทบต่ำ เราอาจยอมรับความไม่สมบูรณ์ได้ แต่ถ้าผลกระทบสูง เราไม่ควรใช้คำว่า “Deadline” เป็นข้ออ้างในการลดมาตรฐานที่สำคัญ

---

กลับมาที่ Nut​

หลังจาก Customer แจ้งปัญหา Team แก้ไขข้อมูลให้เรียบร้อย แต่หัวหน้าของ Nut ไม่ได้หยุดแค่การถามว่า

“ใครเขียน Test Case พลาด?”

เขาถามว่า

“ทำไมเราถึงคิดว่า Test Case ชุดนี้เพียงพอตั้งแต่แรก?”

คำถามเปลี่ยนทุกอย่าง Team พบว่า Requirement ไม่ได้ระบุ Customer Scenario บางกลุ่ม Team QA จึงไม่สามารถ Test สิ่งที่ไม่เคยถูกระบุไว้ ปัญหาจึงไม่ได้อยู่ที่ QA อย่างเดียว มันเริ่มตั้งแต่ตอนเก็บ Requirement

Team จึงเพิ่ม Customer Scenario เข้าไปใน Definition of Done และเปลี่ยน Review Process ก่อน Release ครั้งต่อไป Team ไม่ได้แค่ “ระวังให้มากขึ้น” แต่สร้างระบบที่ช่วยให้ ความผิดพลาดแบบเดิมเกิดยากขึ้น

นี่คือความแตกต่างระหว่างการแก้ปัญหา กับการยกระดับมาตรฐาน

---

Challenge ประจำวัน​

วันนี้เลือกงานหนึ่งชิ้นที่คุณพึ่งทำเสร็จ หรือกำลังจะส่ง อย่าพึ่งถามว่า

“เสร็จหรือยัง?”

ลองถามใหม่ว่า

“ถ้าฉันเป็นคนรับงานนี้ ฉันจะรู้สึกว่านี่เป็นงานที่ดี หรือแค่เป็นงานที่ส่งครบ?”

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

ไม่ต้องทำทุกอย่าง เลือกสิ่งที่มี Impact สูงที่สุดหนึ่งอย่าง

---

ก่อนจบวัน​

ลองถามตัวเองว่า วันนี้มีเรื่องอะไรที่เราพูดว่า “พอใช้ได้” ทั้งที่รู้ว่ายังไม่ดีพอ?

มีมาตรฐานอะไรที่ Team กำลังยอมให้ลดลงทีละนิดโดยไม่มีใครสังเกตหรือไม่? และคำถามสุดท้าย

“ถ้าเราทำงานแบบนี้ต่อไปอีกหนึ่งปี สิ่งที่วันนี้เราคิดว่าเป็นข้อยกเว้น จะกลายเป็นมาตรฐานใหม่หรือเปล่า?”

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

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

“งานนี้ผ่านไหม?”

แต่จะถามว่า

“ถ้าฉันเป็นคนที่ต้องใช้ผลลัพธ์จากงานนี้ ฉันจะภูมิใจที่ได้รับมันหรือไม่?”

นั่นต่างหากคือจุดเริ่มต้นของ Insist on the Highest Standards.

---

DAY 4 — “ไม่รู้” ไม่ใช่คำตอบสุดท้าย​

Leadership Principle: Learn and Be Curious

วันอังคาร เวลา 14:20 น. ในห้องประชุมกำลังมีการคุยเรื่องระบบใหม่ที่บริษัทกำลังจะนำมาใช้ ผู้จัดการถามขึ้นมาว่า

“ถ้าเราเปลี่ยน Architecture แบบนี้ Performance จะดีขึ้นไหม?”

ห้องเงียบไปสองสามวินาที ก่อนที่ต้นจะตอบว่า

“น่าจะดีขึ้นครับ”

ผู้จัดการถามต่อ

“ทำไมถึงคิดแบบนั้น?”

ต้นหยุดไปนิดนึง

“เพราะ Architecture แบบนี้เป็น Best Practice ที่หลายองค์กรใช้กันครับ”

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

 

[PlAwAnSaI]

“ไม่รู้” ไม่ใช่ปัญหา​

คนทำงานจำนวนมากกลัวการพูดว่า

“ไม่รู้ครับ”

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

“น่าจะใช่ครับ”

“คิดว่าน่าจะได้”

“ปกติเขาก็ทำกันแบบนี้”

“Best Practice บอกไว้”

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

---

คนที่เรียนรู้เร็ว ไม่ใช่คนที่รู้ทุกอย่าง​

Learn and Be Curious ไม่ได้หมายความว่าเราต้องอ่านหนังสือทุกวัน หรือเรียน Course ใหม่ทุกเดือน หัวใจของ Principle นี้คือ ความอยากรู้ เมื่อเจอสิ่งที่ไม่เข้าใจ เราไม่รีบปิดเรื่องด้วยคำตอบง่าย ๆ แต่ถามต่อว่า

“ทำไม?”

“มีหลักฐานอะไร?”

“ถ้าลองวิธีอื่นจะเกิดอะไรขึ้น?”

“ข้อมูลนี้มาจากไหน?”

“มีอะไรที่เรายังไม่รู้?”

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

---

“เคยทำแบบนี้มาตลอด” ไม่ใช่เหตุผล​

ลองนึกถึง Process ในองค์กรซักอย่าง มีคนถามว่า

“ทำไมเราต้องส่ง Report นี้ทุกวัน?”

คำตอบคือ

“ก็ทำแบบนี้มาตลอดครับ”

ถ้าถามต่อว่า

“ใครใช้ Report นี้?”

ไม่มีใครตอบได้ชัดเจน ถ้าถามอีกว่า

“ถ้าไม่ส่งจะเกิดอะไรขึ้น?”

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

Process เพิ่มขึ้นทีละอย่าง, Meeting เพิ่มขึ้นทีละห้อง, Approval เพิ่มขึ้นทีละขั้น, Report เพิ่มขึ้นทีละ File สุดท้ายคนทำงานใช้เวลาไปกับการรักษาระบบเดิม มากกว่าการสร้างผลลัพธ์ใหม่ คนที่มี Learn and Be Curious จะกล้าถามว่า

“ถ้าเราเริ่มกระบวนการนี้ใหม่วันนี้ เราจะออกแบบมันเหมือนเดิมหรือเปล่า?”

คำตอบอาจเป็น “เหมือนเดิม” และนั่นก็ไม่เป็นไร เพราะอย่างน้อยเรารู้ว่า เหตุผลของมันยังอยู่

---

อย่าหยุดที่คำตอบแรก​

สมมติว่า Server ทำงานช้า คนแรกบอกว่า

“CPU สูงครับ”

เราจึงเพิ่ม CPU ระบบดีขึ้น จบ หรือเปล่า? ถ้าเรา Curious เราจะถามต่อว่า

“ทำไม CPU ถึงสูง?”

พบว่า Application มี Process บางอย่างทำงานซ้ำ ถามต่อว่า

“ทำไม Process ถึงทำงานซ้ำ?”

พบว่าเกิดจาก Configuration ถามต่อว่า

“ทำไม Configuration ถึงเป็นแบบนี้?”

สุดท้ายอาจพบว่า Root Cause อยู่ที่การออกแบบตั้งแต่ต้น

การถามต่อไม่ได้หมายความว่าเราต้องขุดทุกเรื่องจนไม่มีวันจบ แต่เราต้องรู้ว่า คำตอบระดับไหนเพียงพอสำหรับการตัดสินใจที่เรากำลังจะทำ นี่คือจุดที่ Learn and Be Curious เชื่อมกับ Dive Deep

Curiosity ทำให้เราอยากรู้ Dive Deep ทำให้เรารู้ว่าจะลงลึกแค่ไหน

---

คนเก่งที่สุดในห้องอาจเป็นคนที่ถามมากที่สุด​

ใน Meeting เรามักมองคนที่พูดเก่งว่าเก่ง แต่บางครั้งคนที่สร้าง Value มากที่สุดอาจเป็นคนที่ถามว่า

“Customer ต้องการสิ่งนี้จริง ๆ หรือเปล่า?”

“ตัวเลขนี้มาจากไหน?”

“ถ้า Assumption นี้ผิดจะเกิดอะไรขึ้น?”

“เรามีข้อมูลสนับสนุนหรือไม่?”

“มีทางเลือกอื่นไหม?”

คำถามที่ดีสามารถเปลี่ยน Direction ของ Project ได้ เพราะมันทำให้ Team เห็นสิ่งที่ยังไม่เคยเห็น และนี่เป็นเหตุผลว่าทำไมองค์กรที่ต้องการเรียนรู้เร็ว ไม่ควรสร้างวัฒนธรรมที่ทำให้คนกลัวการถาม

ถ้าทุกคนกลัวว่าการถามจะทำให้ตัวเองดูโง่ สุดท้ายทุกคนจะพยักหน้า และองค์กรจะเดินหน้าด้วย Assumption ที่ไม่มีใครกล้าท้าทาย

---

แต่ Curiosity ก็มีด้านที่ต้องระวัง​

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

เรากำลังเรียนรู้เพื่ออะไร?

เพื่อแก้ปัญหา / เข้าใจ Customer / ประเมิน Risk / สร้างสิ่งใหม่ หรือเพียงเพราะเราอยากรู้?

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

---

กลับมาที่ต้น​

หลัง Meeting วันนั้น ต้นกลับไปคิดถึงคำถามของผู้จัดการ “Architecture แบบนี้ Performance จะดีขึ้นไหม?” เขารู้ตัวว่าเขาไม่มีคำตอบจริง ๆ วันต่อมาเขาจึงกลับไปทดลองกับ Prototype เล็ก ๆ

ใช้ Workload ที่ใกล้เคียงกับ Production เปรียบเทียบ Architecture เดิมกับ Architecture ใหม่ ผลออกมาน่าสนใจ ในบางกรณี Architecture ใหม่เร็วขึ้นจริง แต่ในบาง Workload กลับช้าลง สิ่งที่ต้นค้นพบจึงไม่ใช่

“Architecture ใหม่ดีกว่า”

แต่เป็น

“Architecture ใหม่เหมาะกับ Workload แบบไหน และไม่เหมาะกับ Workload แบบไหน”

นี่เป็นคำตอบที่มีค่ากว่ามาก เพราะมันไม่ได้ทำให้เขา “ชนะ” ใน Meeting แต่มันทำให้ Team ตัดสินใจได้ดีขึ้น และนี่คือสิ่งที่ Learn and Be Curious ต้องการ

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

---

Challenge ประจำวัน​

วันนี้ลองเลือกเรื่องนึงที่คุณคิดว่าตัวเอง “รู้อยู่แล้ว” แล้วถามตัวเองว่า

“จริง ๆ แล้วเรารู้ หรือเราแค่คุ้นเคยกับมัน?”

จากนั้นลองถามต่ออีกหนึ่งคำถาม ทำไม?

ไม่จำเป็นต้องทำ Research ใหญ่ / อาจเปิด Documentation / ถามคนที่มีประสบการณ์ / ดู Data / ทดลองเอง หรือค้นหาคำตอบจากแหล่งที่น่าเชื่อถือ

เป้าหมายไม่ใช่การรู้ทุกอย่าง แต่คือการเปลี่ยนคำว่า

“น่าจะ”

ให้กลายเป็น

“ตอนนี้เรามีข้อมูลมากพอที่จะเชื่อแล้ว”

---

ก่อนจบวัน​

ลองคิดถึงคำถามสามข้อนี้ วันนี้มีเรื่องอะไรที่เราแกล้งทำเป็นรู้ ทั้งที่จริง ๆ ยังไม่รู้?

มี Process อะไรในงานที่เราทำต่อเนื่องโดยไม่เคยถามว่าทำไปเพื่ออะไร?

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

“พรุ่งนี้ฉันอยากรู้อะไร?”

เพราะโลกของการทำงานเปลี่ยนเร็วเกินกว่าที่เราจะใช้ความรู้เดิมไปตลอดชีวิต Technology, Customer, Business เปลี่ยน และสิ่งที่เคยเป็น Best Practice วันนี้ อาจกลายเป็นวิธีที่ล้าสมัยในวันพรุ่งนี้ คนที่คิดว่าตัวเองรู้พอแล้ว จะเริ่มปกป้องสิ่งที่ตัวเองรู้

แต่คนที่ยัง Curious จะยังถามต่อ “มีอะไรอีกที่ฉันยังไม่รู้?” และบางครั้งคำถามง่าย ๆ นี้เองที่ทำให้คนหนึ่งคนเติบโตเร็วกว่าคนอื่น เพราะการเรียนรู้ไม่ได้เริ่มจากการมีคำตอบ มันเริ่มจากการกล้ายอมรับว่า

“เรื่องนี้ฉันยังไม่รู้”

แล้วตามด้วยคำถามที่สำคัญกว่า

“แล้วฉันจะรู้มันได้อย่างไร?”

นั่นคือจุดเริ่มต้นของ Learn and Be Curious

---

DAY 5 — “ข้อมูลบอกอย่างนั้นจริงหรือ?”​

Leadership Principle: Dive Deep

วันศุกร์ เวลา 10:30 น. ผู้จัดการเรียก Team เข้าประชุมด่วน เพราะยอดขายของ Product ตัวหนึ่งลดลง 18% จากเดือนก่อน ตัวเลขถูกเปิดขึ้นบนหน้าจอ ทุกคนเห็นตรงกันว่า

“ยอดขายตกครับ”

Marketing บอกว่า Campaign เดือนนี้ทำผลงานไม่ดี, Sales บอกว่า Customer ชะลอการซื้อ, Product บอกว่า Feature ยังไม่ตอบโจทย์ แต่มีคนหนึ่งถามขึ้นมาว่า

“18% นี่ลดจากอะไรครับ?”

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

Team เปิด Dashboard เพิ่ม พบว่ายอดขายรวมลดลงจริง แต่เมื่อแยกตาม Region กลับพบว่า สาม Region ยอดขายเพิ่มขึ้น, สอง Region แทบไม่เปลี่ยน มีเพียง Region เดียวที่ยอดขายลดลงมากถึง 42%

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

Team เพียงกำลังมอง ตัวเลขรวม แล้วรีบสร้างเรื่องราวขึ้นมาอธิบายมัน

 

[PlAwAnSaI]

ตัวเลขที่ถูกต้อง อาจนำไปสู่คำตอบที่ผิด​

หนึ่งในกับดักของการทำงานยุค Data-Driven คือ เรามักคิดว่า

“ถ้ามี Data แสดงว่าเรากำลังตัดสินใจด้วยข้อเท็จจริง”

แต่ Data อย่างเดียวไม่ได้รับประกันว่าเราจะเข้าใจความจริง เพราะตัวเลขหนึ่งตัวสามารถซ่อนรายละเอียดอีกมากมายไว้ข้างใต้

ยอดขายลดลง แต่ลดลงที่ไหน? ลูกค้าหายไป แต่ลูกค้ากลุ่มไหน? Traffic ลดลง แต่ลดจาก Channel ใด?

Server ใช้ CPU สูง แต่ Process ไหนเป็นต้นเหตุ? Project ล่าช้า แต่ล่าช้าที่ขั้นตอนใด?

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

---

“เพราะอะไร?” อาจเป็นคำถามที่ทรงพลังที่สุด​

ลองเริ่มจากปัญหาง่าย ๆ Customer ร้องเรียนเพิ่มขึ้น

ทำไม? เพราะ Response Time ช้าลง ทำไม? เพราะ Ticket เพิ่มขึ้น ทำไม? เพราะมี Incident มากขึ้น

ทำไม? เพราะ Deployment ใหม่ทำให้ Error เพิ่มขึ้น ทำไม? เพราะ Test Coverage ไม่ครอบคลุม Scenario บางประเภท เราจึงไม่ได้หยุดอยู่ที่

“Customer ร้องเรียนเยอะขึ้น”

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

Observation บอกว่าเกิดอะไรขึ้น Dive Deep พยายามตอบว่า

“ทำไมมันถึงเกิดขึ้น?”

และบางครั้งคำตอบที่เราเจออาจไม่ใช่สิ่งที่เราอยากได้ยิน

---

อย่าขุดลึกเพราะอยากขุด​

อีกด้านนึงของ Dive Deep คือการขุดลึกเกินความจำเป็น บางคนเมื่อได้รับปัญหาหนึ่งเรื่อง จะเปิดทุก Data Source ที่หาได้ สร้าง Dashboard ใหม่สิบอัน เรียก Meeting อีกห้าครั้ง แล้วพบว่าผ่านไปสองสัปดาห์ยังไม่ได้ตัดสินใจอะไร

นี่ไม่ใช่ Dive Deep มันคือ Analysis Paralysis การลงลึกที่ดีต้องรู้ว่า

“เราต้องรู้ลึกแค่ไหนเพื่อทำให้ Decision นี้ดีขึ้น?”

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

---

อย่าเชื่อ Dashboard มากกว่าความจริง​

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

ถ้าเราดู Average เราอาจไม่เห็น Outlier ถ้าดู Total เราอาจไม่เห็น Segment ถ้าดู Percentage เราอาจไม่เห็นจำนวนจริง ถ้าดูเดือนนี้เทียบเดือนก่อน เราอาจไม่เห็น Seasonal Pattern ดังนั้นเมื่อเห็นตัวเลขสำคัญ อย่าพึ่งถามว่า

“ตัวเลขเท่าไหร่?”

ลองถามเพิ่มว่า

“ตัวเลขนี้คำนวณอย่างไร?”

“เทียบกับอะไร?”

“มีอะไรซ่อนอยู่ข้างใน?”

“มีข้อมูลอะไรที่ไม่ได้อยู่ใน Dashboard?”

คำถามเหล่านี้อาจทำให้เราพบว่า สิ่งที่ดูเหมือนเป็นปัญหาใหญ่ จริง ๆ แล้วเล็กกว่าที่คิด หรือสิ่งที่ดูเล็ก อาจกำลังซ่อนปัญหาใหญ่เอาไว้

---

Dive Deep ไม่ใช่แค่เรื่อง Data​

หลายคนคิดว่า Principle นี้เหมาะกับ Data Analyst หรือ Engineer จริง ๆ แล้วทุกคนใช้ได้

Manager ใช้เมื่ออ่าน Performance ของ Team, Marketing ใช้เมื่อวิเคราะห์ Campaign, Sales ใช้เมื่อลูกค้าหาย

HR ใช้เมื่อ Employee Turnover เพิ่มขึ้น, Finance ใช้เมื่อ Cost สูงขึ้น และพนักงานทั่วไปใช้เมื่อเจอปัญหาในงานประจำวัน ตัวอย่างเช่น

“Team ทำงานช้า”

นี่เป็นคำอธิบายที่กว้างมาก

ช้าที่ไหน? ขั้นตอนใด?

รอใคร? รอนานแค่ไหน?

เกิดกับทุกคนหรือบางคน? เกิดทุกวันหรือเฉพาะช่วงสิ้นเดือน?

ถ้าเราไม่ลงลึก เราอาจแก้ผิดจุด และการแก้ผิดจุดในองค์กรขนาดใหญ่มีต้นทุนสูงกว่าที่คิด

---

กลับมาที่ Team Sales​

หลังจาก Team พบว่าปัญหาหลักมาจากลูกค้ารายใหญ่สองราย ผู้จัดการไม่ได้สรุปว่า

“งั้นไม่มีปัญหา”

เขาถามต่อว่า

“แล้วทำไมลูกค้าสองรายนี้ถึงหยุดซื้อพร้อมกัน?”

Team จึงติดต่อ Customer พบว่าทั้งสองบริษัทกำลังเปลี่ยน Budget Cycle เป็นเหตุการณ์ที่เกิดขึ้นทุกปี Team จึงกลับไปดูข้อมูลย้อนหลังสามปี พบ Pattern เดิมซ้ำทุกปีในช่วงเวลาเดียวกัน

สิ่งที่ Team คิดว่าเป็น ยอดขายตกผิดปกติ จริง ๆ แล้วเป็น Seasonality ที่ Team ไม่เคยวิเคราะห์ คำตอบไม่ได้อยู่ใน Dashboard หน้าแรก แต่อยู่ลึกลงไปในข้อมูลที่ไม่มีใครคิดจะเปิด นี่คือสิ่งที่ Dive Deep ทำให้เกิดขึ้น เราไม่ได้แค่รู้ว่า

“เกิดอะไรขึ้น”

แต่เข้าใจว่า

“มันเกิดขึ้นเพราะอะไร และมันเกิดขึ้นแบบนี้มานานแค่ไหนแล้ว”

---

Challenge ประจำวัน​

วันนี้เลือกตัวเลขหนึ่งตัวที่คุณเห็นเป็นประจำ อาจเป็นยอดขาย / จำนวน Ticket / Conversion Rate / Cloud Cost / Response Time / จำนวนลูกค้า หรือแม้แต่จำนวนงานที่คุณทำเสร็จในแต่ละวัน แล้วถามตัวเองว่า

“ถ้าตัวเลขนี้เป็นเพียงภาพรวม แล้วอะไรอาจซ่อนอยู่ข้างใต้?”

จากนั้นลองแยกมันออกเป็นอย่างน้อยหนึ่งมิติ เช่น

เวลา วันนี้เทียบกับเมื่อวาน กลุ่ม Customer กลุ่มไหน?

สถานที่ Region ไหน? ประเภท ปัญหาประเภทใด?

ขั้นตอน มันเกิดขึ้นตรงไหนของ Process?

คุณไม่จำเป็นต้องสร้าง Report ใหม่ ไม่ต้องทำ Analysis ใหญ่ เพียงลองลงไป อีกหนึ่งระดับ

---

ก่อนจบวัน​

ลองถามตัวเอง วันนี้มีเรื่องอะไรที่เรากำลังเชื่อจากข้อมูลเพียงชั้นเดียว?

มีคำอธิบายอะไรที่เราเชื่อเพราะมันฟังดูสมเหตุสมผล แต่ยังไม่มีหลักฐานเพียงพอ? และคำถามสุดท้าย

“ถ้าสิ่งที่ฉันเชื่ออยู่ตอนนี้ผิด ฉันควรไปดูข้อมูลอะไรเพื่อพิสูจน์ว่ามันผิด?”

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

---

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

ตัวเลข, Report, คนอาจบอกว่าเกิดอะไรขึ้น แต่หน้าที่ของคนที่ Dive Deep คือถามต่อว่า

“แล้วมันเกิดขึ้นจริง ๆ เพราะอะไร?”

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

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

---

DAY 6 — “ลูกค้าไม่ได้ซื้อสิ่งที่เราทำ”​

Leadership Principle: Customer Obsession

วันหนึ่ง Team Product ประชุมกันเพื่อฉลอง Feature ใหม่ที่เพิ่งเปิดใช้งาน

Team ใช้เวลาพัฒนามาสามเดือน ทุกคนรู้สึกภูมิใจ เพราะ Feature นี้มีทั้ง Dashboard ใหม่ ระบบแจ้งเตือนอัตโนมัติ และ Report ที่ละเอียดกว่าเดิมหลายเท่า ผู้จัดการเปิดตัวเลขขึ้นมา

“เดือนแรกมีคนใช้ Feature นี้ 7% ครับ”

ห้องเงียบลงเล็กน้อย หนึ่งใน Team ถามว่า

“7% ถือว่าน้อยไหมครับ?”

ผู้จัดการไม่ได้ตอบทันที แต่ถามกลับว่า

“แล้วเราสร้าง Feature นี้ขึ้นมาเพื่ออะไร?”

ทุกคนเปิด Requirement เดิมขึ้นมาดู เป้าหมายของ Feature คือช่วยให้ Customer ลดเวลาการตรวจสอบข้อมูลจาก 30 นาที เหลือไม่เกิน 5 นาที Team จึงกลับไปดูข้อมูลใหม่

พบว่า Customer ที่ใช้ Feature ใช้เวลาเฉลี่ย 28 นาที ระบบใหม่มีคนใช้จริง แต่ไม่ได้แก้ปัญหาที่ Team ตั้งใจจะแก้ Feature จึงไม่ได้ล้มเหลวเพราะคนไม่ใช้ มันอาจล้มเหลวกว่านั้น เพราะ คนใช้แล้ว แต่ชีวิตไม่ได้ดีขึ้น

---

ลูกค้าไม่ได้สนใจว่าเราทำอะไร​

องค์กรจำนวนมากเริ่มต้นจากคำถามว่า

“เราจะสร้างอะไร?”

สร้าง Application / Feature / Campaign / Dashboard / Product ใหม่ แต่ Customer ไม่ได้ตื่นขึ้นมาในตอนเช้าแล้วคิดว่า

“วันนี้ฉันอยากใช้ Dashboard ใหม่จัง”

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

“ทำตามที่ลูกค้าบอกทุกอย่าง”

แต่หมายถึง

“เข้าใจว่าลูกค้าต้องการผลลัพธ์อะไร และตัดสินใจโดยไม่ลืมผลลัพธ์นั้น”

สองอย่างนี้ต่างกันมาก

 

[PlAwAnSaI]

ลูกค้าบอก Solution แต่เราอาจต้องหา Problem​

ลองนึกภาพ Customer โทรเข้ามาบอกว่า

“อยากให้เพิ่มปุ่ม Export Excel ครับ”

ถ้าเราคิดแบบ Task-Oriented เราอาจตอบว่า

“ได้ครับ เดี๋ยวเพิ่มปุ่มให้”

แต่ถ้าเราคิดแบบ Customer Obsession เราอาจถามว่า

“ต้องการ Export ไปทำอะไรครับ?”

Customer อาจตอบว่า

“เอาไปส่งให้หัวหน้าทุกวันครับ”

เราถามต่อ

“แล้วต้องเอาไปแก้ไขข้อมูลใน Excel ก่อนส่งไหมครับ?”

Customer บอกว่า

“ต้องลบข้อมูลบางส่วน แล้วจัด Format ใหม่ทุกครั้งครับ”

ทันทีที่ถามลึกขึ้น เราอาจพบว่า Customer ไม่ได้ต้องการ “ปุ่ม Export” สิ่งที่เขาต้องการคือ ไม่ต้องเสียเวลาเตรียม Report ทุกเช้า ถ้าเราเพิ่มปุ่ม Export เราอาจทำตาม Request สำเร็จ แต่ยังไม่ได้แก้ Pain Point

ถ้าเราเข้าใจ Problem เราอาจออกแบบระบบให้สร้าง Report ที่พร้อมส่งโดยอัตโนมัติ ใช้เวลาพัฒนามากกว่า แต่สร้าง Value ให้ Customer มากกว่า นี่คือ Customer Obsession

---

อย่าสับสนระหว่าง Customer Obsession กับ Customer Is Always Right​

ประโยคว่า

“ลูกค้าคือพระเจ้า”

ฟังดูดี แต่ถ้าเอามาใช้โดยไม่คิด อาจสร้างปัญหาได้ Customer อาจขอ Feature ที่ไม่จำเป็น / ต้องการ Solution ที่ไม่เหมาะ / ไม่เห็นข้อมูลทั้งหมดที่เรามี หรือ อาจรู้ว่าตัวเองมีปัญหา แต่ยังไม่รู้วิธีแก้

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

ในโลกธุรกิจก็เหมือนกัน Customer บอกว่าอยากได้อะไร แต่เราต้องค้นหาว่า

“ทำไมถึงอยากได้?”

คำถามนี้อาจเปลี่ยน Solution ทั้งหมด

---

Customer ไม่ได้มีแค่คนที่จ่ายเงิน​

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

ถ้าเราเป็น IT Team > Customer อาจเป็น Business User, ถ้าเราเป็น Platform Team > Customer อาจเป็น Developer

ถ้าเราเป็น HR > Customer อาจเป็น Employee และ Manager, ถ้าเราเป็น Finance > Customer อาจเป็น Team ที่ต้องใช้ข้อมูลในการตัดสินใจ

ดังนั้นคำถามที่ควรถามคือ

“ใครได้รับผลกระทบจากสิ่งที่เราทำ?”

และ

“เขากำลังพยายามทำอะไรให้สำเร็จ?”

เมื่อเรามองแบบนี้ เราจะเริ่มเห็น Customer มากกว่าแค่ชื่อใน Ticket

---

Customer Experience เกิดขึ้นในทุกขั้นตอน​

หลายองค์กรสนใจ Customer ตอนขายของ แต่ Customer Experience ไม่ได้เริ่มตอนขาย และไม่ได้จบหลังจากรับเงิน มันอยู่ในทุกจุด การสมัคร, ชำระเงิน, ใช้งาน, ขอความช่วยเหลือ, แก้ปัญหา, ยกเลิก

แม้แต่ข้อความ Error บนหน้าจอก็เป็นส่วนหนึ่งของประสบการณ์ ลองคิดง่าย ๆ ถ้า Customer ทำอะไรผิด แล้วระบบขึ้นว่า

“Error 500”

เขาไม่รู้ว่าต้องทำอะไรต่อ แต่ถ้าระบบบอกว่า

“ไม่สามารถบันทึกข้อมูลได้ เนื่องจาก File มีขนาดเกิน 10 MB กรุณาลดขนาด File แล้วลองใหม่”

ปัญหาอาจเป็นเรื่องเดียวกัน แต่ Experience ต่างกันมาก Customer Obsession จึงไม่ใช่เพียงเรื่องของ Customer Service มันเป็นเรื่องของ ทุกคนที่สร้างสิ่งซึ่งส่งผลต่อ Customer

---

แล้วเราจะรู้ได้อย่างไรว่าลูกค้าต้องการอะไร?​

อย่าเดา, ถาม, ดู Data, ฟัง Complaint, อ่าน Feedback, ดูพฤติกรรมการใช้งาน, คุยกับคนที่อยู่หน้างาน และที่สำคัญคือ ไปดูสถานการณ์จริง เพราะสิ่งที่ Customer บอกกับสิ่งที่ Customer ทำ อาจไม่เหมือนกัน เราอาจถามว่า

“ระบบใช้งานง่ายไหมครับ?”

Customer อาจตอบว่า

“ง่ายครับ”

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

---

กลับมาที่ Feature ของ Team Product​

Team กลับไปคุยกับ Customer อีกครั้ง พบว่า Customer ไม่ได้ต้องการ Dashboard ที่ละเอียดขึ้น พวกเขาต้องการเพียงคำตอบง่าย ๆ ว่า

“วันนี้มีรายการไหนที่ฉันต้องจัดการ?”

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

Feature เดิมไม่ได้ไร้ค่า แต่ Team พึ่งเข้าใจว่า Value ไม่ได้อยู่ที่จำนวนสิ่งที่เราสร้าง Value อยู่ที่จำนวนปัญหาที่เราช่วย Customer แก้ได้ นี่เป็นบทเรียนที่สำคัญมาก เพราะบางครั้ง Team ภูมิใจกับสิ่งที่ตัวเองสร้าง แต่ Customer สนใจเพียงว่า

“แล้วชีวิตฉันดีขึ้นตรงไหน?”

---

Challenge ประจำวัน​

วันนี้เลือกงานหนึ่งอย่างที่คุณกำลังทำ อาจเป็น Report / System / Process / Presentation / Campaign หรือแม้แต่ Meeting แล้วถามตัวเองว่า

“ใครคือ Customer ของสิ่งนี้?”

จากนั้นถามอีกสามคำถาม เขากำลังพยายามทำอะไรให้สำเร็จ?

ปัญหาที่แท้จริงของเขาคืออะไร? และ

สิ่งที่เรากำลังทำช่วยให้เขาดีขึ้นจริง หรือแค่ทำให้ Task ของเราสำเร็จ?

ถ้าตอบไม่ได้ ไม่เป็นไร นั่นอาจเป็นสัญญาณที่ดี เพราะคุณพึ่งค้นพบว่าเรายังรู้จัก Customer ไม่มากพอ

---

ก่อนจบวัน​

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

“Report ที่เราส่งทุกวัน”

ลองถามต่อว่า

“เขาคิดถึง Report หรือคิดถึงข้อมูลที่อยู่ใน Report?”

ถ้าคำตอบคือ

“ระบบที่เราดูแล”

ลองถามต่อว่า

“เขาต้องการระบบ หรือเขาต้องการสิ่งที่ระบบช่วยให้เขาทำได้?”

การถามต่อแบบนี้จะค่อย ๆ เปลี่ยนมุมมองของเรา จาก สิ่งที่เราทำ ไปสู่ คุณค่าที่คนอื่นได้รับ

---

Customer Obsession ไม่ได้หมายความว่าเราต้องทำให้ Customer พอใจทุกครั้ง บางครั้งเราต้องบอกว่า “ไม่”, ปฏิเสธ Request, อธิบายว่าทำไม่ได้ และบางครั้งต้องเสนอวิธีที่ Customer ไม่ได้ขอ แต่ทุกครั้งเราต้องสามารถตอบได้ว่า

“เรากำลังตัดสินใจเรื่องนี้โดยคำนึงถึง Customer อย่างไร?”

เพราะองค์กรที่ Customer Obsession ไม่ได้ถามแค่

“เราทำงานเสร็จหรือยัง?”

แต่ถามว่า

“สิ่งที่เราทำสร้างคุณค่าให้คนที่เราทำงานให้จริงหรือยัง?”

และเมื่อคำถามนี้กลายเป็นนิสัย เราจะเริ่มมองงานต่างออกไป Report ไม่ใช่แค่ Report, ระบบไม่ใช่แค่ระบบ, Feature ไม่ใช่แค่ Feature, Process ไม่ใช่แค่ Process

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

---

DAY 7 — “ถ้าหัวหน้าไม่อยู่ เราจะตัดสินใจอย่างไร?”​

Leadership Principle: Have Backbone; Disagree and Commit

วันพฤหัสบดี เวลา 15:40 น. Team กำลังประชุมเรื่อง Project สำคัญที่ต้องส่งให้ลูกค้าภายในสิ้นเดือน

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

“มีใครติดอะไรไหมครับ?”

เงียบอีกครั้ง สุดท้ายมีคนตอบว่า

“ไม่มีครับ น่าจะทำได้”

Meeting จบลงด้วยความเห็นตรงกัน แต่หลังจากออกจากห้องไปไม่ถึงสิบนาที คนใน Team กลับมาคุยกันเอง

“จริง ๆ ผมว่าไม่น่าทันนะ”

“ผมก็คิดเหมือนกัน”

“แต่หัวหน้าตัดสินใจไปแล้ว จะให้ทำยังไง”

หนึ่งสัปดาห์ผ่านไป ความเสี่ยงที่ทุกคนเคยเห็นเริ่มเกิดขึ้นจริง งานล่าช้า, Customer เริ่มถาม, Team เริ่มทำ OT และคนที่เคยคิดว่า “ไม่น่าทัน” กลับพูดกันว่า

“ก็หัวหน้าเป็นคนเลือกแผนนี้เอง”

ปัญหาคือ ทุกคนเห็นปัญหาตั้งแต่ต้น แต่ไม่มีใครกล้าพูด

---

การเห็นต่างไม่ใช่การต่อต้าน​

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

“ผมคิดว่าแผนนี้มีความเสี่ยงครับ”

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

 

[PlAwAnSaI]

แต่ต้องมีเหตุผล ไม่ใช่มีแค่ความเห็น​

การพูดว่า

“ผมไม่เห็นด้วยครับ”

อย่างเดียวไม่ได้ช่วยอะไร เพราะคนอื่นก็สามารถถามว่า

“แล้วทำไม?”

ดังนั้นการ Disagree ที่ดีควรมีข้อมูล เหตุผล หรือหลักฐานรองรับ เช่น

“ผมคิดว่า Timeline นี้มีความเสี่ยง เพราะงาน Integration ยังไม่เคยทดสอบ และจาก Project ก่อนหน้าใช้เวลาเฉลี่ยประมาณสองสัปดาห์ครับ”

ประโยคนี้แตกต่างจาก

“ผมรู้สึกว่าไม่น่าทัน”

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

---

อย่าเห็นด้วยต่อหน้า แล้วบ่นลับหลัง​

พฤติกรรมนึงที่พบได้ในหลายองค์กรคือ ในห้องประชุมทุกคนพูดว่า

“OK ครับ”

แต่หลังประชุมกลับพูดว่า

“ผมว่าไม่ Work”

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

“เห็นไหม ผมบอกแล้ว”

ประโยค “ผมบอกแล้ว” ไม่เคยช่วยแก้ Project ที่พัง

---

แล้วถ้าเราพูดแล้ว แต่ Team ยังเลือกอีกทาง?​

นี่คือส่วนที่สำคัญที่สุดของ Principle นี้ สมมติว่าเราเสนอความคิดเห็นอย่างเต็มที่แล้ว อธิบายข้อมูลแล้ว ชี้ Risk แล้ว แต่คนที่มีหน้าที่ตัดสินใจเลือกอีกทาง เราควรทำอย่างไร?

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

“ก็ได้ครับ แต่ผมไม่เห็นด้วยนะ”

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

Disagree ก่อนตัดสินใจ Commit หลังตัดสินใจ สองส่วนนี้ต้องมาด้วยกัน

---

“แต่ถ้าหัวหน้าผิดล่ะ?”​

หัวหน้าก็ผิดได้ Manager / Director ก็ผิดได้ คนที่มีตำแหน่งสูงไม่ได้มีข้อมูลครบทุกอย่าง บางครั้งคนที่อยู่หน้างานอาจเห็นสิ่งที่ผู้บริหารไม่เห็น คนที่คุยกับ Customer ทุกวันอาจรู้ Pain Point มากกว่า, Engineer อาจเห็น Technical Risk ที่ Business ไม่เห็น, Sales อาจรู้ข้อมูลตลาดที่ Product ยังไม่รู้ ดังนั้นองค์กรที่ดีต้องมีพื้นที่ให้คนพูดความจริงจากมุมของตัวเอง แต่การพูดความจริงไม่ได้หมายถึงการทำลาย Authority เราสามารถพูดว่า

“ผมไม่เห็นด้วยครับ และเหตุผลคือ…”

โดยยังให้เกียรติคนที่เป็น Decision Maker ความเป็นมืออาชีพไม่ได้อยู่ที่ว่าเราเห็นด้วยหรือไม่ แต่อยู่ที่ว่า เราเห็นต่างอย่างไร

---

อย่าใช้ Backbone เป็นข้ออ้างในการดื้อ​

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

“ฉันกำลังปกป้องสิ่งที่สำคัญ หรือกำลังปกป้องความคิดเห็นของตัวเอง?”

ถ้าเราได้รับข้อมูลใหม่แล้วพบว่าตัวเองผิด เราต้องพร้อมเปลี่ยนความคิด การยอมรับว่า

“OK ครับ ข้อมูลนี้ทำให้ผมเปลี่ยนมุมมอง”

ไม่ได้ทำให้เราอ่อนแอ กลับกัน มันแสดงว่าเราสนใจ ความถูกต้องมากกว่า Ego

---

กลับมาที่ Team ของเรา​

สมมติว่าครั้งนี้มีคนนึงชื่อ May ใน Meeting เธอพูดขึ้นมาว่า

“หนูคิดว่า Timeline นี้มี Risk ค่ะ เพราะ Integration ยังไม่ได้ทดสอบจริง ถ้าจะส่งตามกำหนด เราอาจต้องลด Scope บางส่วน หรือเพิ่มเวลาอีกหนึ่งสัปดาห์”

Manager ถามว่า

“มีข้อมูลอะไรสนับสนุนไหม?”

May เปิดข้อมูล Project ก่อนหน้าให้ดู Team คุยกันต่ออีกสิบห้านาที สุดท้าย Manager ตัดสินใจว่า

“OK ครับ เราจะไม่เลื่อน Deadline แต่ลด Scope ใน Phase แรก”

May อาจไม่ได้สิ่งที่เธอเสนอทั้งหมด แต่เธอทำหน้าที่ของตัวเองแล้ว เธอพูดสิ่งที่เชื่อว่าจำเป็น ให้ข้อมูล และช่วยให้ Team มองเห็น Risk หลังจากนั้นเธอไม่ได้พูดว่า

“เห็นไหม หนูบอกแล้ว”

เธอพูดว่า

“โอเคค่ะ งั้นเรามาช่วยกันทำ Scope นี้ให้ทัน”

นี่คือ Disagree and Commit

---

Challenge ประจำวัน​

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

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

“ผมไม่เห็นด้วย”

อาจเริ่มด้วย

“มีอีกมุมนึงที่ผมคิดว่าเราน่าจะลองพิจารณาครับ…”

เป้าหมายไม่ใช่การเอาชนะ แต่คือการทำให้ Decision ดีขึ้น

---

ก่อนจบวัน​

ลองถามตัวเองสามข้อ วันนี้มีเรื่องอะไรที่เราเห็น Risk แต่ไม่ได้พูด?

เวลาคนอื่นเห็นต่างกับเรา เราฟังเหตุผลจริง ๆ หรือกำลังเตรียมคำตอบเพื่อโต้กลับ?

และคำถามสุดท้าย

“ถ้า Decision ไม่เป็นไปตามความเห็นของเรา เราจะยังทำให้มันสำเร็จเต็มที่ได้หรือไม่?”

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

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

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

Have Backbone; Disagree and Commit

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

---

DAY 8 — “อย่าถามว่าใครผิด ถามว่าอะไรผิด”​

Leadership Principle: Ownership

วันจันทร์ เวลา 09:05 น. ลูกค้ารายหนึ่งส่ง Email เข้ามาว่า

“ระบบใช้งานไม่ได้ตั้งแต่เช้าครับ”

Team IT ตรวจสอบทันที พบว่า Service ตัวหนึ่งหยุดทำงาน คนแรกบอกว่า

“Application มีปัญหาครับ”

Team Application ตรวจสอบแล้วตอบกลับว่า

“Application ปกติดีครับ น่าจะเป็น Infrastructure”

Infrastructure บอกว่า

“Server ก็ปกติครับ น่าจะเป็น Network”

Network ตรวจสอบแล้วบอกว่า

“Network ไม่มีปัญหาครับ น่าจะเป็น Firewall”

Firewall Team บอกว่า

“Rule ไม่ได้ถูกแก้ครับ น่าจะเป็นฝั่ง Application”

วงจรเริ่มขึ้น ทุกคนกำลังพยายามพิสูจน์ว่า “ไม่ใช่ความผิดของฉัน” เวลาผ่านไปหนึ่งชั่วโมง ระบบยังใช้งานไม่ได้ Customer ไม่ได้สนใจว่าใครเป็นเจ้าของ Server / Network หรือใครเป็นคนแก้ Config

Customer สนใจเพียงเรื่องเดียว

“เมื่อไหร่จะกลับมาใช้ได้?”

---

Ownership เริ่มต้นเมื่อเราเลิกพูดว่า “ไม่ใช่หน้าที่เรา”​

ในองค์กรใหญ่ งานหนึ่งเรื่องมักเกี่ยวข้องกับหลาย Team

Business, Sales, Marketing, Product, Engineering, IT, Finance, HR, Legal ทุก Team มีขอบเขตงานของตัวเอง การมีขอบเขตเป็นเรื่องจำเป็น แต่ปัญหาเกิดขึ้นเมื่อ ขอบเขตของ Team กลายเป็นกำแพงที่ทำให้ไม่มีใครรับผิดชอบผลลัพธ์สุดท้าย คำว่า

“ไม่ใช่หน้าที่ผมครับ”

อาจถูกต้องตาม Job Description แต่ไม่ได้แปลว่ามันเป็นคำตอบที่ดีสำหรับ Customer

Ownership จึงไม่ได้หมายความว่าเราต้องทำทุกอย่างด้วยตัวเอง มันหมายถึง

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

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

 

[PlAwAnSaI]

Ownership ไม่ใช่การแบกทุกอย่างไว้คนเดียว​

บางคนเข้าใจ Ownership ว่า

“ถ้าเป็น Owner ต้องทำทุกอย่างเอง”

ไม่จริง ถ้า Manager ต้องทำทุกงาน, Project Owner ต้องเขียนทุก Code, Marketing ต้องทำ Design เอง, Engineer ต้องแก้ทุกปัญหาด้วยตัวเอง องค์กรจะโตไม่ได้

Ownership ไม่ใช่การเป็น Hero แต่คือการ รับผิดชอบผลลัพธ์

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

---

“ฉันทำส่วนของฉันแล้ว” อาจยังไม่พอ​

สมมติว่า Project มีห้า Team

Team A ทำ Requirement, B ทำ Development, C ทำ Testing, D ทำ Deployment, E ดูแล Customer ทุก Team ทำงานของตัวเองครบ แต่ Project ยังส่งไม่ทัน ถ้าแต่ละ Team บอกว่า

“ส่วนของผมเสร็จแล้วครับ”

Project ก็ยังล่าช้าอยู่ดี เพราะ Customer ไม่ได้รับ “ส่วนของแต่ละ Team” Customer ได้รับ ผลลัพธ์สุดท้าย Ownership จึงเปลี่ยนคำถามจาก

“งานของฉันเสร็จหรือยัง?”

เป็น

“ผลลัพธ์ที่เราสัญญากับ Customer สำเร็จหรือยัง?”

นี่เป็นการเปลี่ยนมุมมองที่สำคัญมาก เพราะบางครั้งงานของเราเสร็จ 100% แต่สิ่งที่ Customer ต้องการยังไม่เสร็จเลย

---

Ownership ต้องมองไกลกว่า Deadline​

อีกเรื่องที่สำคัญคือ Ownership ไม่ได้จบเมื่อ Project เปิดใช้งาน บางคนคิดว่า

“Go-Live แล้วครับ งานผมจบ”

แต่หลังจากนั้นใครดูแล? Customer เจอปัญหาใครรับ? Documentation อยู่ไหน? Monitoring มีหรือไม่? ถ้าคนทำเดิมลาออก ระบบยังทำงานต่อได้ไหม? ถ้าเราไม่คิดเรื่องเหล่านี้ Project อาจ “เสร็จ” ในวันที่ Release แต่สร้างปัญหาให้คนอื่นในอีกหกเดือนข้างหน้า

Ownership จึงหมายถึงการมอง Life Cycle ของสิ่งที่เรารับผิดชอบ ไม่ใช่เพียงวันที่เราส่งงาน

---

คนที่มี Ownership จะไม่โยนปัญหา​

เมื่อเกิดปัญหา เรามักได้ยินคำว่า

“ผมส่งต่อให้ Team แล้วครับ”

คำว่า “ส่งต่อ” ไม่ผิด แต่คำถามคือ

“ส่งต่อแล้วจบ หรือส่งต่อแล้วติดตาม?”

ถ้าเราส่ง Ticket ไปอีก Team แล้วไม่เคยดูอีกเลย Customer อาจรออยู่สามวัน ถ้าเราส่งต่อแล้วติดตามว่า

“ได้รับเรื่องหรือยังครับ?”

“ต้องการข้อมูลเพิ่มไหม?”

“มี ETA ไหม?”

“ถ้าติดอะไรบอกผมได้ครับ”

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

---

กลับมาที่ระบบของ Customer​

ในเหตุการณ์วันนั้น มี Engineer คนหนึ่งชื่อ Art เขาไม่แน่ใจว่า Root Cause อยู่ Team ไหน แต่เขารู้ว่าลูกค้ากำลังใช้งานไม่ได้ แทนที่จะเริ่มหาว่าใครผิด เขาจึงสร้าง Incident Channel แล้วเชิญทุก Team ที่เกี่ยวข้องเข้ามา เขารวบรวมข้อมูล เวลาที่เริ่มเกิดปัญหา, Service ที่ได้รับผลกระทบ, Log, Error, การเปลี่ยนแปลงล่าสุด และสิ่งที่ทดลองไปแล้ว จากนั้นถามทุก Team ว่า

“เรามาช่วยกันหาสาเหตุกันก่อนครับ เรื่องว่าใครเป็น Owner ของ Component ค่อยจัดการทีหลัง”

ผ่านไปไม่นาน Team พบว่า Configuration หนึ่งค่าถูกเปลี่ยนจากระบบ Automation ไม่มีใครตั้งใจทำผิด แต่ Process ทำให้เกิดการเปลี่ยนแปลงโดยไม่มี Validation ที่เหมาะสม Team แก้ระบบกลับมาได้ Customer ใช้งานได้ หลัง Incident จบ Art ไม่ได้บอกว่า

“เห็นไหม ผมช่วยทุกอย่างเลย”

เขากลับถามว่า

“เราจะทำอย่างไรไม่ให้เรื่องนี้เกิดอีก?”

นี่คือ Ownership ที่แท้จริง ไม่ใช่การเป็นคนเก่งที่สุด แต่เป็นคนที่ ไม่ปล่อยให้ปัญหาหยุดอยู่กลางทาง

---

Ownership กับคำว่า “ไม่ใช่หน้าที่”​

พรุ่งนี้ถ้ามีเพื่อนร่วมงานมาบอกว่า

“พี่ครับ เรื่องนี้ผมไม่รู้ว่าต้องติดต่อใคร”

เราสามารถตอบว่า

“ไม่ใช่ Team พี่ครับ”

หรืออาจตอบว่า

“เดี๋ยวพี่ช่วยชี้ให้ว่าควรติดต่อ Team ไหน”

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

Ownership ไม่ได้ต้องการให้เรารับทุกอย่างเข้ามา แต่ต้องการให้เรา ช่วยให้สิ่งที่ควรเดินหน้า เดินหน้าต่อ

---

Ownership ในระดับชีวิตการทำงาน​

หลักนี้ใช้กับเรื่องเล็กมากได้ด้วย ถ้าคุณเห็นห้องประชุมสกปรก คุณอาจคิดว่า

“ไม่ใช่หน้าที่เรา แม่บ้านดูแล”

ถูกต้อง แต่ถ้าคุณทำกาแฟหกแล้วเดินออกมา โดยคิดว่าเดี๋ยวมีคนทำความสะอาด นั่นต่างกัน

ถ้าคุณพบข้อมูลผิดใน Report ที่กำลังจะถูกส่งให้ผู้บริหาร คุณอาจคิดว่า

“คนอื่นเป็นคนทำ”

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

Ownership จึงเริ่มจากคำถามง่าย ๆ

“ฉันรู้เรื่องนี้แล้ว ฉันจะทำเป็นไม่เห็นได้จริงหรือ?”

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

---

Challenge ประจำวัน​

วันนี้ลองสังเกตปัญหาหนึ่งเรื่องในที่ทำงานที่ทุกคนพูดว่า

“ไม่ใช่หน้าที่ฉัน”

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

---

ก่อนจบวัน​

ลองถามตัวเองสามข้อ วันนี้มีเรื่องอะไรที่เรารู้ว่าเป็นปัญหา แต่เลือกเดินผ่านเพราะไม่ใช่งานเรา?

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

“ถ้าทุกคนในองค์กรทำเฉพาะสิ่งที่อยู่ใน Job Description ปัญหาอะไรบ้างที่จะไม่มีใครเป็นคนแก้?”

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

---

Ownership ไม่ได้หมายความว่า “ทุกอย่างเป็นความผิดของฉัน” และไม่ได้หมายความว่า “ทุกอย่างฉันต้องทำเอง” มันหมายถึง

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

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

“ไม่ใช่หน้าที่ผม”

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

“OK ครับ เรื่องนี้เดี๋ยวผมช่วยประสานให้เอง”

จากนั้นงานก็เดินต่อ นั่นคือจุดเริ่มต้นของ Ownership

---

DAY 9 — “เราไม่ต้องรู้ทุกคำตอบ”​

Leadership Principle: Hire and Develop the Best

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

“คนนี้แหละ ใช้งานได้เลย”

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

“ถ้าเจอสถานการณ์แบบนี้จริง ๆ ผมขอเวลาศึกษาเพิ่มได้ไหมครับ?”

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

---

การจ้างคน ไม่ใช่แค่หาคนที่ทำงานได้​

เวลาองค์กรเปิดตำแหน่งงาน เรามักถามว่า

“ผู้สมัครคนนี้ทำงานนี้ได้ไหม?”

คำถามนี้สำคัญ แต่ยังไม่พอ เพราะองค์กรไม่ได้จ้างคนมาเพื่อทำงานเดิมตลอดไป Business, Technology, Customer, Team เปลี่ยน และหน้าที่ของตำแหน่งก็เปลี่ยน ดังนั้นคำถามที่สำคัญไม่แพ้กันคือ

“คนนี้จะเติบโตไปพร้อมกับงานได้ไหม?”

คนที่เก่งมากในวันนี้อาจไม่ใช่คนที่สร้าง Value ได้มากที่สุดในอีกสามปี ในทางกลับกัน คนที่ยังมีบางอย่างต้องเรียนรู้อาจเติบโตอย่างรวดเร็ว ถ้ามี Mindset ที่ดี และได้รับโอกาสที่เหมาะสม นี่เป็นหนึ่งในเหตุผลที่ Leadership Principle นี้ไม่ได้พูดแค่ Hire the Best แต่พูดว่า

Hire and Develop the Best

เพราะการสร้าง Team ที่ดีไม่ได้จบตอนรับคนเข้าทำงาน มันพึ่งเริ่มต้น

 

[PlAwAnSaI]

“เก่ง” ไม่ได้มีความหมายเดียว​

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

“เขาทำอะไรได้แล้ว?”

แต่ควรถามว่า

“เขามีศักยภาพที่จะเรียนรู้อะไรต่อได้อีก?”

และที่สำคัญ

“เขาจะทำให้คนรอบตัวเก่งขึ้นได้หรือไม่?”

เพราะ Team ที่ดีไม่ควรมีแค่คนเก่งหลายคน แต่ควรเป็น Team ที่ ความเก่งถูกส่งต่อถึงกัน

---

หัวหน้าที่ดีไม่ได้ทำให้ตัวเองสำคัญที่สุด​

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

“เรื่องนี้ฉันทำเองได้ แต่ถ้าให้ลูก Team ทำ เขาจะได้เรียนรู้อะไร?”

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

---

การพัฒนาคนไม่ใช่การส่งไปเรียนอย่างเดียว​

เวลาได้ยินคำว่า Develop People เรามักนึกถึง Course, Training, Certification, Workshop สิ่งเหล่านี้มีประโยชน์ แต่การพัฒนาคนที่เกิดขึ้นจริงทุกวันมักมาจากงาน ให้คนลองรับผิดชอบ Project ใหม่, ให้ Present ต่อผู้บริหาร, ให้เป็นคนคุยกับ Customer, ให้ลองแก้ปัญหาที่ยากขึ้น, ให้เข้าร่วม Decision ที่ใหญ่ขึ้น แล้วคอยให้ Feedback นี่คือการเรียนรู้ที่เกิดจาก Stretch Assignment แต่ต้องระวังไม่ให้กลายเป็นการโยนงานยากให้คนโดยไม่ช่วยเหลือ การ Develop ที่ดีไม่ใช่

“เอาไปทำเองนะ”

แล้วปล่อยให้จม แต่เป็น

“เรื่องนี้ใหญ่ขึ้นจากงานเดิม ลองเป็น Owner ดู ถ้าติดตรงไหนมาคุยกัน”

เรากำลังเพิ่มความรับผิดชอบ พร้อมสร้างพื้นที่ให้เรียนรู้

---

Feedback ที่ดีไม่ใช่การด่า​

การพัฒนาคนต้องมี Feedback แต่ Feedback ไม่ควรเป็นเพียง

“ทำดีมาก”

หรือ

“ยังไม่ดี”

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

“Presentation ยังไม่ดีครับ”

อาจบอกว่า

“ข้อมูลครบดีครับ แต่ Executive ยังต้องใช้เวลาหา Key Message เอง ลองเริ่มด้วย Recommendation ก่อน แล้วค่อยใส่รายละเอียดสนับสนุน จะทำให้ Decision เร็วขึ้นครับ”

คนฟังจะรู้ทันทีว่าต้องพัฒนาอะไร นี่คือ Feedback ที่ช่วยให้คนเก่งขึ้น

---

อย่าจ้างคนที่เหมือนเราไปหมด​

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

“ทุกคนคิดเหมือนกัน เพราะทุกคนมองโลกเหมือนกัน”

---

กลับมาที่ผู้สมัครสองคน​

สุดท้ายหัวหน้าถามผู้สมัครคนที่สองว่า

“ถ้าคุณเจอ Technology ที่ไม่เคยใช้มาก่อน คุณจะทำอย่างไร?”

เขาตอบว่า

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

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

---

Challenge ประจำวัน​

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

“ฉันช่วยให้คนนี้เก่งขึ้นได้อย่างไรหนึ่งอย่าง?”

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

---

ก่อนจบวัน​

ลองถามตัวเอง ถ้าฉันลาออกพรุ่งนี้ Team จะทำงานต่อได้หรือไม่? ถ้าคำตอบคือ “ไม่ได้” อาจไม่ได้หมายความว่าคุณเก่งเกินไป แต่อาจหมายความว่า ความรู้ของคุณยังไม่ได้ถูกส่งต่อ จากนั้นถามต่อ

มีงานอะไรที่ฉันทำเองเพราะทำเร็วกว่า ทั้งที่จริง ๆ แล้วควรเปิดโอกาสให้คนอื่นเรียนรู้? และคำถามสุดท้าย

“ในปีที่ผ่านมา มีใครเก่งขึ้นเพราะได้ทำงานร่วมกับฉันบ้าง?”

คำถามนี้อาจสำคัญกว่าการถามว่า

“ฉันเก่งขึ้นแค่ไหน?”

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

“ฉันจะทำให้ Team เก่งขึ้นอย่างไร?”

ลองถามให้ลึกขึ้นว่า

“ถ้าวันนึงไม่มีฉันอยู่ใน Team นี้แล้ว คนที่เคยทำงานกับฉันจะเก่งขึ้นจากสิ่งที่เราเคยทำร่วมกันหรือไม่?”

ถ้าคำตอบคือใช่ นั่นแปลว่าคุณไม่ได้แค่ทำงาน คุณกำลัง สร้างคน และนั่นคือหัวใจของ Hire and Develop the Best