- ตามงานวิจัยด้านจิตวิทยาการรู้คิด ขีดจำกัดของ ดีปเวิร์ก (deep work) ของมนุษย์อยู่ที่วันละ 3–4 ชั่วโมง และหลังจากนั้นสมาธิและคุณภาพโค้ดจะลดลงอย่างรวดเร็ว
- จากการวิเคราะห์นักพัฒนามากกว่า 250,000 คน พบว่า เวลาที่ใช้เขียนโค้ดจริงแบบค่ามัธยฐานอยู่ที่เพียง 52 นาทีต่อวัน เท่านั้น ส่วนที่เหลือหมดไปกับการประชุม การจัดการ และการทำงานร่วมกัน
- หลังการถูกรบกวนหนึ่งครั้ง ต้องใช้เวลา 23 นาทีจึงจะกลับไปสู่งานเดิมได้ และสำหรับโปรแกรมเมอร์ต้องใช้เวลา 30–45 นาที เพื่อกู้คืนบริบททั้งหมด
- ใน ภาวะโฟลว์ (flow state) ผลิตภาพเพิ่มขึ้นได้ถึง 500% แต่ต้องอาศัยช่วงเวลาจดจ่อต่อเนื่อง 15–25 นาทีจึงจะเข้าสู่ภาวะนี้ได้
- บทบาทของผู้จัดการวิศวกรรมไม่ใช่การเพิ่มกระบวนการ แต่ควรโฟกัสที่ การขจัดสิ่งรบกวนและปกป้องเวลาดีปเวิร์ก
ขีดจำกัดทางการรู้คิด: ดีปเวิร์กมีเพดานอยู่ที่วันละ 4 ชั่วโมง
- Cal Newport นิยามดีปเวิร์กว่าเป็น "กิจกรรมเชิงวิชาชีพที่ผลักความสามารถทางการรู้คิดไปจนถึงขีดสุด ภายใต้สภาวะที่ไร้สิ่งรบกวน" และสำหรับคนส่วนใหญ่ ค่าสูงสุดโดยเฉลี่ยอยู่ที่วันละ 4 ชั่วโมง
- งานวิจัยนักไวโอลินของ K. Anders Ericsson ก็ยืนยันเช่นกันว่า หลังจาก การฝึกอย่างมีสมาธิ 4 ชั่วโมง จะเริ่มเกิดความเหนื่อยล้า
- การพัฒนาซอฟต์แวร์ก็เป็นงานทางการรู้คิดความเข้มข้นสูงเช่นกัน เพราะรวมทั้งการแก้ปัญหาเชิงสร้างสรรค์และการออกแบบระบบ ดังนั้นหลังผ่านไป 3–4 ชั่วโมง ผลตอบแทนจะเริ่มลดลง
- นักคณิตศาสตร์ Henri Poincaré ทำงาน 2 ชั่วโมงตอนเช้าและ 2 ชั่วโมงตอนบ่าย, G.H. Hardy ทำงานเฉพาะช่วงเช้า, ส่วน Charles Darwin, B.F. Skinner และ C.S. Lewis ก็รักษาตารางงานวันละ 3–4 ชั่วโมงเช่นกัน
- งานวิจัยของ Gloria Mark จาก UC Irvine ระบุว่า ปัจจุบัน เวลาที่จดจ่อกับหน้าจอโดยเฉลี่ยอยู่ที่ 47 วินาที ลดลงอย่างมากจาก 2.5 นาทีในปี 2004
การใช้เวลาจริงของนักพัฒนา
- ผลการวิเคราะห์ นักพัฒนามากกว่า 250,000 คน ของ Software.com พบว่า เวลาที่ใช้เขียนโค้ดแบบค่ามัธยฐานอยู่ที่ 52 นาทีต่อวัน (ประมาณ 4 ชั่วโมง 21 นาทีต่อสัปดาห์)
- นักพัฒนาที่เขียนโค้ดเกิน 2 ชั่วโมงต่อวันมีเพียง 10% เท่านั้น และผู้ที่เกิน 1 ชั่วโมงมี 40%
- จากการวิเคราะห์ การประชุม 1.5 ล้านครั้ง ของ Clockwise พบว่า วิศวกรซอฟต์แวร์ใช้เวลาประชุมเฉลี่ย 10.9 ชั่วโมงต่อสัปดาห์
- ผู้จัดการวิศวกรรมใช้เวลาประชุม 18 ชั่วโมงต่อสัปดาห์ เกือบครึ่งหนึ่งของการทำงาน 40 ชั่วโมง
- นักพัฒนาในองค์กรขนาดใหญ่เสียเวลากับการประชุม 12.2 ชั่วโมงต่อสัปดาห์ ส่วนองค์กรขนาดเล็กอยู่ที่ 9.7 ชั่วโมง
- เมื่อตัดเวลาการประชุม การจัดการ การรีวิวโค้ด และการทำงานร่วมกันออกไป จะเหลือ เวลาที่พอมีสมาธิได้ 19.6 ชั่วโมงต่อสัปดาห์ ซึ่งส่วนใหญ่ก็เป็นช่วงเวลาสั้น ๆ ที่ใช้งานจริงไม่ได้
- 45% ของการเขียนโค้ดทั้งหมดเกิดขึ้นระหว่างบ่าย 2 ถึง 5 โมง ขณะที่ช่วง 9 ถึง 11 โมงเช้ามีเพียง 10% เท่านั้น
- ไม่ใช่เพราะนักพัฒนาเป็นคนถนัดช่วงบ่ายโดยธรรมชาติ แต่เพราะช่วงเช้าถูกยึดไปกับ stand-up, sync และ ceremony ต่าง ๆ
ต้นทุนอันสูงของการถูกรบกวน
- งานวิจัยของ Gloria Mark ระบุว่า หลังการถูกรบกวน ต้องใช้เวลา 23 นาที 15 วินาทีเต็ม จึงจะกลับเข้าสู่งานเดิมอย่างสมบูรณ์
- งานวิจัยจาก Georgia Institute of Technology พบว่า สำหรับโปรแกรมเมอร์ ต้องใช้เวลา 10–15 นาทีเพื่อกลับมาแก้ไขโค้ดต่อ และต้องใช้เวลา 30–45 นาทีเพื่อสร้างบริบททางความคิดทั้งหมดขึ้นใหม่
- บทความ "Maker's Schedule" ของ Paul Graham ชี้ว่า การประชุมไม่ใช่แค่การสลับงานธรรมดา แต่เป็น exception ที่เปลี่ยนโหมดการทำงานทั้งชุด
- การประชุมเพียงครั้งเดียวอาจทำลายทั้งช่วงบ่าย และแค่รู้ว่ามีประชุมตอนบ่ายก็มากพอจะทำให้คนไม่อยากเริ่มงานยากตั้งแต่ตอนเช้า
ภาวะโฟลว์: ตัวคูณผลิตภาพของโปรแกรมเมอร์
- งานวิจัยของ Mihaly Csikszentmihalyi นิยามภาวะโฟลว์ว่าเป็น "สภาวะที่จมอยู่กับกิจกรรมอย่างสมบูรณ์ จนความเป็นตัวตนเลือนหายและสูญเสียความรู้สึกต่อเวลา"
- จากผลวิจัยต่อเนื่อง 10 ปี พบว่า ในภาวะโฟลว์ ผลิตภาพเพิ่มขึ้น 500% เมื่อเทียบกับภาวะปกติ
- กุญแจของการเข้าสู่โฟลว์คือ สมดุลระหว่างระดับความท้าทายกับระดับทักษะ หากโจทย์ยากหรือง่ายเกินไปก็จะรบกวนโฟลว์
- ทีมซอฟต์แวร์ที่เข้าสู่ภาวะโฟลว์ได้บ่อย จะส่งมอบคุณค่าได้มากกว่า เร็วกว่า และด้วยความพึงพอใจที่สูงกว่า
- โฟลว์ไม่ได้เกิดขึ้นเองตามธรรมชาติ และจำเป็นต้อง ปกป้องมันจากสิ่งที่คอยบั่นทอน
วิธีเข้าสู่ภาวะโฟลว์ระหว่างเขียนโค้ด
- สร้างสภาพแวดล้อมไร้สิ่งรบกวน: ปิด Slack, ปิดเสียงการแจ้งเตือน, ใช้สถานะที่มองเห็นได้เพื่อบอกว่ากำลังอยู่ในโหมดดีปเวิร์ก
- ต่อให้ไม่ตอบการแจ้งเตือน แค่เห็นมันก็ทำให้สมาธิลดลง
- กำหนดเป้าหมายที่ชัดเจนก่อนเริ่มเซสชันเขียนโค้ด: แทนที่จะบอกว่า "ทำงาน backend" ให้ระบุแบบเจาะจง เช่น "แก้ให้ authentication endpoint ส่ง error response ได้ถูกต้อง"
- แก้ปัญหาที่ยากในช่วงเวลาที่สมองพีก: ตามงานวิจัยจังหวะชีวภาพ สมรรถนะทางการรู้คิดเปลี่ยนแปลงตามช่วงเวลาได้ 9–40%
- สำหรับผู้ใหญ่ส่วนใหญ่ ช่วงที่แก้ปัญหาได้ดีที่สุดคือ 10 โมงเช้าถึงบ่าย 2
- คนตื่นเช้า ("lark") และคนถนัดดึก ("owl") มีเวลาพีกต่างกัน จึงต้องปกป้องเวลาพีกของแต่ละคน
- ทำ time blocking สำหรับ Maker's Schedule: จองช่วงดีปเวิร์ก 2–4 ชั่วโมงไว้ในปฏิทินล่วงหน้า และย้ายการประชุมไปกองไว้ท้ายวันหรือบางวันโดยเฉพาะ
- ตั้งหนึ่งเป้าหมายต่อหนึ่งบล็อกงาน และแตกออกเป็นสามงานย่อยที่ลงมือทำได้จริง
- กำจัด context switching: แทนที่จะตอบทันที ให้กำหนด communication window วันละสองครั้ง และปิดแท็บเบราว์เซอร์ที่ไม่เกี่ยวกับงานปัจจุบัน
- ทำงานเป็นเซสชันที่มีสมาธิ ไม่ใช่มาราธอนสปรินต์: Pomodoro 25 นาทีไม่เหมาะกับงานพัฒนาที่ซับซ้อน เพราะพอใกล้จะเข้าสู่โฟลว์ก็ถูกตัวจับเวลาตัดเสียก่อน
- เป้าหมายไม่ใช่เวลาสูงสุด แต่คือ คุณภาพสูงสุด ภายในขอบเขตความสามารถทางการรู้คิด
- พลังทบต้นของการทบทวนและการเรียนรู้: งานวิจัยเรื่อง deliberate practice ของ Ericsson ชี้ว่าสิ่งที่สร้างความเชี่ยวชาญไม่ใช่จำนวนชั่วโมงทำงาน แต่คือ การคิดทบทวนอย่างมีสติ
4 กลยุทธ์ดีปเวิร์กของ Cal Newport
- กลยุทธ์แบบนักบวช (Monastic): ตัดงานตื้นทั้งหมดออกไปอย่างสิ้นเชิง
- ตัวอย่างเด่นคือ Donald Knuth ที่เลิกใช้อีเมลตั้งแต่ปี 1990
- กลยุทธ์สองโหมด (Bimodal): แยกวันในสัปดาห์เป็นวันดีปเวิร์กและวันทำงานตื้น
- เช่น: ติดต่อไม่ได้วันจันทร์ถึงพุธ แล้วค่อยประชุมและจัดการอีเมลในวันพฤหัสถึงศุกร์
- กลยุทธ์แบบจังหวะ (Rhythmic): ทำดีปเวิร์กเวลาเดิมทุกวันแบบไม่มีข้อยกเว้น
- แนวทาง "อย่าทำโซ่ขาด" ของ Jerry Seinfeld
- กลยุทธ์แบบนักข่าว (Journalistic): เข้าดีปเวิร์กทันทีทุกครั้งที่มีเวลาว่าง
- ใช้กับช่วงเวลา 30–45 นาทีได้เช่นกัน แต่ในทางปฏิบัติมีความเสี่ยงที่จะเข้าใจ context switching ผิดว่าเป็นดีปเวิร์ก
- สำหรับนักพัฒนาส่วนใหญ่ กลยุทธ์แบบจังหวะมีประสิทธิภาพที่สุด และหัวใจสำคัญคือการกันช่วงเช้าไว้สำหรับการเขียนโค้ดโดยไม่ตกเป็นเหยื่อของแรงดึงดูดเชิงตอบสนองจาก Slack
ทำไมผู้จัดการวิศวกรรมควรใส่ใจ
- เมื่อเวลาที่นักพัฒนาใช้เขียนโค้ดจริงต่อวันมีเพียง 52 นาที การถูกรบกวนเพียงครั้งเดียวที่ทำให้ต้องเสียเวลาฟื้นตัวมากกว่า 23 นาที จึงเท่ากับว่า ข้อความหนึ่งข้อความอาจเผาผลาญโควตาการเขียนโค้ดของทั้งวันไปเกือบครึ่ง
- การทดลองของ TechSmith: หากตัดการประชุมออกทั้งหมด ความรู้สึกว่าผลิตภาพเพิ่มขึ้น 15% และพนักงาน 85% ตอบว่ายินดีแทนที่การประชุมด้วยการสื่อสารแบบอะซิงก์
- จากแบบสำรวจคน 31,000 คนของ Microsoft พบว่า การประชุมที่ไม่มีประสิทธิภาพเป็นปัจจัยรบกวนผลิตภาพในการทำงานอันดับ 1
- ข้อแนะนำสำหรับผู้จัดการ:
- กันช่วงเช้าไว้ให้ปลอดการรบกวน
- ใช้ วันปลอดประชุม (เช่น วันพุธ)
- ตั้งค่าเริ่มต้นให้การสื่อสารแบบอะซิงก์มาก่อนแบบซิงก์
- กำหนดเดดไลน์ที่สมจริงและเปิดพื้นที่ให้การสำรวจเชิงสร้างสรรค์
- ตัวชี้วัดผลลัพธ์ที่ควรใช้วัด: cycle time ที่ลดลง, ความพึงพอใจของทีม, คะแนน engagement, อัตรา bug และสัดส่วนการทำงานซ้ำ รวมถึงเมตริกด้านคุณภาพอื่น ๆ
บทสรุป
- การเขียนโปรแกรมแบบลึกวันละ 3–4 ชั่วโมงไม่ใช่เรื่องของวินัย แต่เป็น ขีดจำกัดทางกายภาพของภาระทางการรู้คิด
- หัวใจสำคัญคือการปรับสิ่งที่ควบคุมได้ให้เหมาะสม เช่น ปิดการแจ้งเตือน แจ้งทีมว่าจะตอบช่วงบ่าย หรือเจรจางดประชุมเช้าสัปดาห์ละ 2 ครั้ง
- ดีปเวิร์ก 4 ชั่วโมงให้ผลลัพธ์ดีกว่า 8 ชั่วโมงแบบ "มีสมาธิครึ่ง ๆ กลาง ๆ" เสมอ
- การเข้าสู่ภาวะโฟลว์วันละหลายชั่วโมงนำไปสู่โค้ดคุณภาพสูง ความเสี่ยง bug ต่ำลง โซลูชันที่สร้างสรรค์กว่า และ สมดุลชีวิตการทำงานที่ดีขึ้น
- คนเขียนโค้ดไม่ใช่นักวิ่งระยะสั้น แต่เป็น นักวิ่งมาราธอน และต้องรักษาพลังงานไว้
หมายเหตุเกี่ยวกับ AI coding assistant
- เครื่องมืออย่าง Copilot, Cursor และ Claude ไม่ได้ยืดเวลาของดีปเวิร์กออกไป แต่เพียงย้ายจุดที่เราใช้โฟกัส
- ต่อให้เปลี่ยนจากการเขียนโค้ดเองตั้งแต่ต้นมาเป็นการรีวิวผลลัพธ์จาก AI ก็ยังต้องใช้บริบท การตัดสินใจ และสมาธิแบบเดียวกัน
- ขีดจำกัด 3–4 ชั่วโมงไม่ใช่ข้อจำกัดเรื่องความเร็วในการพิมพ์ แต่คือ ขีดจำกัดของสมองในการตัดสินใจคุณภาพสูงอย่างต่อเนื่อง ดังนั้นการที่โค้ดปรากฏเร็วขึ้นจึงไม่ได้เปลี่ยนข้อเท็จจริงนี้
- พื้นที่ที่ AI ช่วยได้จริงคือ ชั่วโมงงานตื้น (shallow hours): การร่างเอกสาร การสร้าง boilerplate การถามวิธีใช้ไลบรารี เป็นต้น
- หากมอบหมายงานเหล่านี้ให้ AI ก็จะเก็บงบประมาณดีปเวิร์กไว้ใช้กับการคิดเชิงสถาปัตยกรรมและการแก้ปัญหาซับซ้อนได้มากขึ้น
- กับดักคือการใช้ AI เพื่อผลิต โค้ดมากเกินกว่าที่เราจะประมวลผลทางความคิดได้
- เป้าหมายไม่ใช่การได้บรรทัดโค้ดมากขึ้นในแต่ละวัน แต่คือการทุ่มทรัพยากรทางการรู้คิดที่มีจำกัดไปกับ การตัดสินใจที่สำคัญที่สุด
13 ความคิดเห็น
ตั้งกลุ่มเปรียบเทียบมาตั้งแต่ต้นก็ผิดแล้ว
งานวิจัยนักไวโอลินของ K. Anders Ericsson ไม่ได้ศึกษาจากเกณฑ์ของคนที่ชำนาญแล้ว แต่ศึกษาจากการฝึกซ้อมเป็นหลัก ในกรณีของเครื่องดนตรี ต่อให้ซ้อมเพลงจนสมบูรณ์แบบ ก็ไม่ได้หมายความว่าจะรับประกันการแสดงที่สมบูรณ์แบบได้เสมอไปอยู่ดี (มีข้อยกเว้นได้ในทุกครั้งที่แสดง) แต่เมื่อเทียบกับการพัฒนา ถ้าความต้องการชัดเจนและทำเสร็จแล้ว ก็จะให้ผลลัพธ์เดิมทุกครั้ง การทำสิ่งที่มีจุดจบต่อเนื่องกัน กับการทำสิ่งที่ไม่มีจุดจบต่อเนื่องกันนั้นต่างกันมาก เพราะฉะนั้นการไปกำหนดเลยว่าความสามารถในการรับรู้ของมนุษย์โดยเฉลี่ยอยู่ที่ 3~4 ชั่วโมงนั้น ในตัวมันเองก็มีปัญหาอยู่แล้ว อีกทั้งการพัฒนา 3~4 ชั่วโมงจากคำสั่งของคนอื่น กับการพัฒนา 3~4 ชั่วโมงด้วยความสมัครใจ ก็ยังเป็นความต่างอีกแบบหนึ่ง บทความนี้ให้ความรู้สึกเหมือนเป็นการเหมารวมทุกอย่าง แล้วพยายามโน้มน้าวอย่างมีชั้นเชิงว่า 3~4 ชั่วโมงคือขีดจำกัดของความสามารถในการรับรู้ของมนุษย์ การที่พวกเขามีเวลาจดจ่อ 3~4 ชั่วโมง ไม่ได้แปลว่าทุกคนจะมีเวลาจดจ่อ 3~4 ชั่วโมงเหมือนกัน ตรงกันข้าม มันดูเหมือนบทความที่ตั้งเพดานไว้ล่วงหน้า แล้วชวนกันฮั้วว่าเราทำงานกันแค่ 3~4 ชั่วโมงก็พอ
ถูกต้อง~! จริง ๆ ก็มีคนที่ทำงานเก่งมาก ๆ อยู่เยอะเลย
ไม่อยากให้เอาผลงานช่วงที่โฟกัสได้ดีที่สุดในอาชีพของตัวเองมาตั้งเป็นตัวตนว่าเราเป็นคนแบบนี้ บทความนี้วางให้ deep work เป็นสภาวะการทำงานในอุดมคติแล้วพยายามมากเกินไปที่จะเข้าไปสู่สภาวะนั้น แน่นอนว่าเมื่อมองเห็นไอเดียที่น่าสนใจในการแก้ปัญหาและทิศทางที่จะลองทำ deep work ก็จะเกิดขึ้นและประสิทธิภาพก็ดีขึ้น แต่ถ้าพอมองไม่เห็นสิ่งนั้นแล้วกลับเชื่อว่าสมองของเราจริงๆ อัจฉริยะกว่านี้ และใช้ชีวิตด้วยความไม่พอใจอยู่ตลอด สุดท้ายก็จะยิ่งลดโอกาสที่ตัวเองจะเข้าสู่ 'flow' ลงไปมาก ยิ่งมีเมตาคอกนิชันน้อย ก็ยิ่งคิดง่ายว่าสมองนี้เป็นของเราเอง แต่สภาพของสมองนั้นไม่ได้ถูกสร้างขึ้นมาคนเดียวเด็ดขาด ต้องยอมรับด้วยว่ากว่าจะมีสมาธิแบบนั้นได้ เราได้รับความช่วยเหลือจากรอบข้างมาแค่ไหน (ไม่ใช่แค่ปล่อยให้อยู่นิ่งๆ หรือให้เงินเท่านั้น แต่ยังรวมถึงการได้รับสิ่งกระตุ้นหลากหลาย และเมื่อถึงจุดหนึ่งสิ่งเหล่านั้นถูกร้อยเรียงอย่างประณีตไปในทิศทางเดียวกัน จึงเกิดสภาวะจดจ่อขึ้นมา) ไม่ว่าผลลัพธ์จะออกมาเป็นอย่างไร การรู้สึกขอบคุณอยู่ลึกๆ แม้ไม่จำเป็นต้องแสดงออกกับอีกฝ่าย และการพอใจกับตัวเองในระดับที่เหมาะสมพร้อมยอมรับตัวเอง จะช่วยยกระดับสมาธิและสภาพร่างกายในระยะยาว
ฉันทำงานอยู่ที่บริษัทที่ทำงานตอนเช้า 3 ชั่วโมง กินข้าวกลางวัน แล้วกลับมาทำงานต่อช่วงบ่ายอีก 3 ชั่วโมง (รวม 7 ชั่วโมง ทำงานสัปดาห์ละ 4 วัน) แค่นี้ก็รู้สึกสบายใจขึ้นมากแล้วครับ
เป็นบริษัทที่ดีนะ !
ทุกคนคงเข้าใจว่าทำไมหลังเลิกงาน ตอนที่ไม่มีใครอยู่แล้วได้นั่งโค้ดคนเดียวถึงไปได้ดี.......;;;
เพราะงั้นเวลาคนอื่นทำโอที ผมกลับเลิกงานเร็วแทนครับ
ผมคิดว่าน่าจะเพิ่มได้อีกหน่อยด้วยการฝึกฝน การพักผ่อน และสภาพแวดล้อมที่เหมาะสม แต่เพราะมันคือการโหมใช้คน จึงทนทำแบบนั้นได้นานยาก บริษัทก็มักจะเร่งกดดันให้โหมงานและปิดเงียบไว้ แต่ผมก็เห็นวิศวกรที่ทำงานไปพร้อมกับพึ่งยาอยู่บ่อย ๆ (ยาต้านซึมเศร้า, ยา ADHD)
ใช่เลย ความจริงที่ชวนอึดอัดก็คือธุรกิจจิตเวชในพังโยกำลังไปได้ดี
ผมคิดว่าแค่วันละชั่วโมงสำหรับการเขียนโค้ดก็เพียงพอแล้วครับ แม้แต่ก่อนยุค AI เวลาที่ใช้เขียนโค้ดจริง ๆ ก็ไม่ได้มากอยู่แล้ว แต่ตอนนี้ยิ่งลดลงไปอีก
เวลาได้ทำงานพัฒนาหรือเล่นเกมหรืออ่านหนังสือในแบบที่ 'ฉันอยากทำ' ดูเหมือนว่าจะมีสมาธิได้เป็นชั่วโมง ๆ จนกว่างานนั้นจะเสร็จ
ตรงนี้ 4 ชั่วโมงอาจหมายถึงความสามารถในการจดจ่อกับงานประเภทที่ 'ไม่ได้อยากทำแต่ทำเพราะเป็นอาชีพ' (ควรเรียกว่าเป็นสมาธิแบบตั้งรับดีไหม?)
ง่ายมาก แค่มีประสบการณ์ที่เคยรักษาสมาธิไว้ได้ตลอดทั้งคืนระหว่างเล่นเกม ผู้ชายก็น่าจะเคยกันทุกคน
จากประสบการณ์ส่วนตัว เวลาที่ได้พัฒนาสิ่งที่ตัวเองอยากทำ ต่อให้ทำต่อเนื่องหลายชั่วโมงก็แทบไม่รู้สึกเหนื่อยเลยครับ
การรันหลายเซสชันเองก็กลายเป็นการทำงานหลายอย่างพร้อมกัน ซึ่งอาจทำให้สมาธิลดลงด้วย