Photo by Sebastian Herrmann on Unsplash

ผมเป็นคนบ้างานในระดับนึงเลย

จะเรียกว่าบ้างานก็ไม่ถูกซะทีเดียว เพราะผมค่อนข้างจะสนุกกับงานเขียนโปรแกรม บางทีก็ไม่ได้รู้สึกว่าตัวเองทำงานอยู่

พอถึงหกโมงเย็น ถ้ายังแก้บั้คไม่เสร็จ ก็ยังจะอยากดีบั๊กต่อ ถ้าทำฟีเจอร์เสร็จ ก็อยากจะทำฟีเจอร์ถัดไป ไม่ก็นั่งรีแฟคเตอร์ต่อ

สมัยมีชีวิตโสด ออกจากงานประมาณ 2-3 ทุ่ม เป็นอย่างเร็ว

สองปีก่อนแต่งงาน ชีวิตเปลี่ยนครับ

แฟนยื่นข้อเสนอที่ปฏิเสธไม่ได้ก่อนแต่งงาน คือเราสองคนต้องกลับมากินข้าวเย็นด้วยกันที่บ้านก่อนทุ่มนึง

ดังนั้น ประมาณ 5.30 ของทุกวัน ผมก็จะเตรียมแพ็คของกลับบ้าน

หลังจากทำได้สักสองสัปดาห์ ยามในออฟฟิซก็เริ่มทัก ว่ายูหายไปไหนตอนกลางคืน (ยามกะดึกจะเจอผมทุกวัน)

เอาจริงๆคือผมยอมรับว่าแฟน(ปัจจุบันคือภรรยาละ)คิดถูกนะ

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

ที่แย่ที่สุด คือมันเป็นการส่งสัญญาณให้กับคนในทีม ว่าเรามี Culture ทำงานแบบหามรุ่งหามค่ำ ซึ่งไม่ใช่ทุกคนที่ทำแบบนี้ได้

ทำอย่างไรให้ได้เยอะสุดใน 8 ช.ม.

การที่มีเวลาทำงานแค่แปดช.ม.ทุกวัน ก็ส่งผลดีให้ผมฝึกทักษะใหม่ คือทำงานให้"ผลลัพธ์"ได้มากที่สุด ในเวลาที่จำกัด

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

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

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

  1. วางแผนก่อนทำงานตอนเช้าใน Calendar

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

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

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

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

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

เช่น Implement feature A อาจจะใช้เวลาหลายวัน ผมก็จะแตกงานเป็นงานย่อยๆ แต่ละงานไม่ให้เกิน 2 ช.ม.

  1. เขียน Design document แล้วเขียน diagram ส่งไปให้เพื่อนร่วมงานรีวิว (~60 mins)
  2. นั่งอ่านโค้ดตรงส่วนที่ต้องแก้ เขียน Class diagram ออกมาเพื่อทำความเข้าใจ (~120 mins)
  3. เขียนเทสเคสออกมาให้ครบ (60 mins)
  4. เขียนโค้ดกับ unit test (240 mins)
  5. เขียน integration tests (120 mins)

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

งานนึงผมไม่ค่อยอยากให้เกิน 2 ช.ม. เพราะถ้าใหญ่กว่านั้น ส่วนใหญ่จะกะเวลาทำได้ไม่ค่อยตรง

  1. บล็อคเวลาส่วนตัว และเวลาทำงานหลัก ไว้ล่วงหน้า

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

พวกนี้จะแย่งเวลาเขียนโค้ด หรือทำงาน Technical ไปเยอะ

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

ดังนั้น ผมจะบล็อคเวลาที่เอาไว้เขียนโค้ดหรือเอกสาร บล็อคทีก็ครึ่งวัน ประมาณ 4 ช.ม.

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

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

อีกอย่างหนึ่ง สำหรับคนที่มีเพื่อนร่วมงานต่างประเทศ ผมจะบล็อคเวลาตั้งแต่ก่อน 9 โมง และหลัง 5 โมงครับ

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

ตารางเวลาทำงานตัวเอง ต้องจัดการเองครับ อย่าให้คนอื่นจัดการให้ (โดยการส่ง Meeting invitation มาตามเวลาสะดวกของเค้า)

  1. พักเช็คทุกๆชั่วโมงว่าเราทำงานตรงตามที่วางไว้หรือเปล่า

ถ้าเราแบ่งงานเป็นล็อตเล็กๆ ล็อตละไม่เกิน 60 นาที เราจะรู้อยู่ตลอดเวลาว่าเราทำงานเสร็จตรงตามเป้าหรือเปล่า และเราโดน Distract ไปจากงานรึเปล่า

ตัวอย่างเช่น บางครั้งผมนั่งรอ integration test รันเสร็จ ก็จะไปอ่านบทความหรือเช็คเฟสบุ้ค เช็คอีเมลล์ รู้ตัวอีกทีก็หมดไปช.ม.กว่าแล้ว

(ใครที่กำลังไถเฟสบุ้ครออะไรอยู่ ถึงเวลากลับไปทำงานแล้วนะครับ :D )

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

  1. หยุดพักหากติดเกิน 60 นาที

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

การหยุดพักจะทำให้เราถอยออกจากปัญหามามองในภาพกว้าง

ประมาณ 3 ใน 10 ครั้งที่หยุดพัก ผมจะพบว่ามีวิธีอื่นในการแก้ปัญหาที่เหมาะสมกว่า

หรือบางครั้งก็จะนึกออกว่าเพื่อนร่วมงานเคยเจอปัญหาคล้ายๆกัน ไปถามเขาจะเร็วกว่างมเอง

สมัยตอนเริ่มทำงานใหม่ๆ ผมพยายามจะทำเองทุกอย่าง ไม่ถามคนอื่น

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

แก่แล้วยอมรับว่าไม่รู้ ดูดีกว่าไปขิงใส่คนอื่นมาก

  1. เรียนรู้ที่จะปฏิเสธหรือต่อรองกับงานที่เข้ามา

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

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

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

เพื่อนผมเคยพูดติดตลกว่า ถ้าเราทำงานสัปดาห์ละ 80 ชั่วโมง ทำแค่ 5 ปี ก็ได้ประสบการณ์ 10 ปีแล้ว

พอเวลาแตะเลข 2 ปลายๆ สุขภาพเราจะเริ่มถอย ณ จุดนี้ ถ้าเร่งมากไป เครื่อง(ร่างกาย)เรามันจะพังเร็ว

และพอเครื่องเราพัง ต่อให้เก่งแค่ไหนก็เปล่าประโยชน์

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

สำหรับคนที่รู้สึกอึดอัดเวลาปฏิเสธลูกค้าหรือหัวหน้า ผมอยากให้เข้าใจการปฏิเสธคนอื่นเป็นทักษะอย่างหนึ่ง ที่ต้องฝึกกัน

บางคนเคยฝึกมาตั้งแต่เด็ก ก็อาจจะทำได้ง่าย แต่บางคนก็ต้องมาฝึกตอนทำงานนี่แหละ

ถ้าอยู่ในทีมหรือบริษัทที่คุณไม่ปฏิเสธอะไรได้เลย ทำงานวันละ 12 ช.ม. เสาร์อาทิตย์ก็ต้องปั่นงาน ไม่งั้นส่งโปรเจ็คให้ทัน

ปัญหาอาจจะไม่ได้อยู่ที่ทักษะของเรา แต่เป็นเชิงโครงสร้างของบริษัท อาจจะเป็นกระบวนการ (เช่น เซลล์รับปากลูกค้ามั่วซั่ว ไม่ปรึกษาทีมเดฟก่อน) หรืออาจจะเป็นด้านวัฒนธรรม บูชางานหนักจนเกินเลย

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

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

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

ถ้าได้ทำเต็มที่แล้ว สุดแล้ว มันไม่ไปไหน อย่างน้อยเราก็ได้ทำเต็มที่แล้ว

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

  1. ฝึกให้คนอื่นทำแทน (Delegate)

ณ จุดนึง โปรแกรมเมอร์ทุกคนจะค้นพบว่าเราทำทุกอย่างคนเดียวไม่ได้

ต่อให้เก่งแค่ไหน เทพแค่ไหน สุดท้ายคนนึงก็มีแค่ 24 ชั่วโมง สุขภาพก็มีแค่นี้ โหมไปสักหกเดือน เดี๋ยวก็ได้เข้าโรงพยาบาลอยู่ดี

เราต้องกระจายงานให้เป็น สอนงานให้เป็น ทักษะพวกนี้จำเป็นมากในการทำงานใหญ่ๆให้สำเร็จ

การ Delegate ก็เป็นทักษะ ไม่มีใครเก่งมาตั้งแต่เกิด ต้องค่อยๆฝึกกัน

หลักการสำคัญๆของผมคือ

  1. อธิบายบริบทและเป้าหมายของงานให้ชัดเจน คนรับงานต้องเข้าใจว่าทำไมเราถึงกำลังทำสิ่งนี้อยู่
  2. ต้องกำหนดขอบเขต (Scope) ของงานให้ชัด รู้ว่าอะไรอยู่ในขอบ อะไรอยู่นอกขอบเขต ไม่งั้นงานจะทำไม่เสร็จเสียที
  3. จ่ายงานให้เหมาะสมกับความถนัดและประสบการณ์ของคน อย่ายากไป แต่ก็อย่าง่ายไปจนไม่ถ้าทายา
  4. ภามความเห็นของอีกฝ่าย อย่าสั่งอย่างเดียว ให้เขามีส่วนร่วมและเป็นเจ้าของงาน
  5. คอยหมั่นเช็คเป็นระยะๆว่าติดปัญหาอะไรรึเปล่า ตรงไปตามแผนที่วางไว้ไหม ถึงคนอื่นจะเป็นคนลงมือ แต่เรายังเป็นผู้รับผิดชอบผลของการทำงานของเขา
  6. คอยให้ Constructive feedback เพื่อให้เพื่อนร่วมงานทำงานได้ดีขึ้น

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

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


---

ติดตามบทความสำหรับโปรแกรมเมอร์ทั้งด้านได้ที่ Facebook page Not about code หรือ Twitter @notaboutcode บทความของเพจจะเน้นเนื้อหาที่นำไปใช้ได้กับชีวิตจริง แต่ไม่ยึดติดกับเทคโนโลยีหรือภาษา เช่น System Design, Continuous Delivery, Testing, Career, etc.

สำหรับท่านที่อยากสนับสนุนผู้เขียน รบกวนช่วยแชร์โพสต์ในเฟสบุ้คให้กับเพื่อนๆที่น่าจะสนใจหัวข้อพวกนี้ด้วยครับ