ฝึกคิดแบบ 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% ที่เรามี

:cool:
 
Top