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

PlAwAnSaI

Administrator

เปลี่ยน 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

:cool:
 
Last edited:

PlAwAnSaI

Administrator

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 ต้องการ

:cool:
 
Last edited:

PlAwAnSaI

Administrator

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


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

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.

:cool:
 
Top