ใช้เดดไลน์อย่างมีประสิทธิภาพเพื่อสร้างทีมที่มีความสุขและทำงานได้อย่างมีประสิทธิผล

เดดไลน์ที่หน่วยธุรกิจตั้งไว้ทุกวันนี้แทบไม่มีความหมายแล้ว เพราะการปล่อยซอฟต์แวร์ทำได้ง่ายเกินไป และต้นทุนของการปล่อยแต่ละครั้งก็ต่ำมาก

ยกเว้นอีเวนต์สำคัญที่ขึ้นกับแต่ละโดเมน (เช่น ฤดูกาลเปิดภาคเรียนสำหรับการศึกษา ฤดูกาลลีกสำหรับกีฬา Black Friday สำหรับอีคอมเมิร์ซ เป็นต้น) เดดไลน์เกือบทั้งหมดเป็นภาพลวงตา เป็นความเร่งด่วนปลอม (false urgency) ที่เกิดจากความกลัวและความกังวล

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

ดังนั้น การใช้เดดไลน์เป็นแส้เพื่อสร้างแรงจูงใจจึงไม่ค่อยดี วิธีใช้เดดไลน์ให้ดีมีอยู่ใหญ่ ๆ สองแบบ

1. ใช้เป็นข้อจำกัดที่ช่วยให้เกิดความคิดสร้างสรรค์

• เมื่อมีข้อจำกัด มักจะเกิดความคิดสร้างสรรค์ที่เหมาะกับสถานการณ์นั้น หรือเพื่อเอาชนะข้อจำกัดนั้น โดยเฉพาะในช่วงเริ่มต้นที่กำลังค้นหา product-market fit เดดไลน์ช่วยป้องกันการวางแผนและการออกแบบที่มากเกินไปได้มาก

• อีกตัวอย่างหนึ่งคือจากประสบการณ์การนำทีมพัฒนาอินฟราสตรักเจอร์ เดดไลน์ก็มีประโยชน์มาก

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

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

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

2. ใช้เป็นเครื่องมือในการจัดการ "giving"

• คนบนโลกมีอยู่ 3 ประเภท

  • giver คือคนที่ช่วยเหลือผู้อื่นโดยไม่คำนึงถึงผลประโยชน์ของตัวเอง

  • taker คือคนที่ต้องการได้ประโยชน์โดยไม่คำนึงถึงผู้อื่น

  • matcher คือคนที่อยู่กึ่งกลาง เมื่อ take ไปแล้วก็จะ give และเมื่อ give ไปแล้วก็อยาก take กลับบ้าง

• หากจัดอันดับคนในบริษัทตามเกณฑ์ด้านผลงาน จะพบว่ามีทั้ง giver ที่ผลงานสูงและ giver ที่ผลงานต่ำอยู่มาก

• เมื่อดูว่าอะไรเป็นตัวสร้างความต่างนี้ ก็จะเห็นว่า top giver รู้วิธีจัดการการ giving ว่าเมื่อไรควร give และเมื่อไรควรทำงานของตัวเอง ซึ่งเดดไลน์เป็นเครื่องมือที่มีประโยชน์มากในเรื่องนี้

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

[wonderer]

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

[kwon5604]

เข้าใจเรื่อง giver / taker / matcher แล้ว แต่พอมองโยงกับเดดไลน์ ยังไม่ค่อยเข้าใจชัดเจนว่าทำไมมันถึงช่วยให้ใช้เดดไลน์ได้ดีขึ้นนะครับ T_T

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

[kwon5604]

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

สรุป + ความเห็น

1. giver มีอยู่ 2 ประเภท

   • ผู้มีผลงานต่ำ

   • ผู้มีผลงานสูง

2. ถ้าดู giver ที่มีผลงานสูง จะเห็นว่าพวกเขารู้วิธีจัดการว่าเมื่อไรและอย่างไรควรทำ giving (การช่วยเหลือผู้อื่น)

3. ในทางกลับกัน giver ที่มีผลงานต่ำจะด้อยกว่า giver ที่มีผลงานสูงในแง่การจัดการ giving (การช่วยเหลือผู้อื่น) (เช่น ไปช่วยคนอื่นจนสุดท้ายดูแลงานของตัวเองได้ไม่ดี เป็นต้น)

4. คนส่วนใหญ่มักอยากทำงานกับ giver และองค์กรที่มี giver มากก็มักมีการย้ายงานน้อยกว่า

   • องค์กรที่ดีมักมี giver เยอะ และองค์กรก็ควรรักษาให้มี giver อยู่มาก ๆ

5. เพราะฉะนั้น ผู้จัดการควรรักษาจำนวน giver ให้มีมากไว้ พร้อมทั้งช่วยให้ giver ที่มีผลงานต่ำสามารถกลายเป็น giver ที่มีผลงานสูงได้

   • ในเมื่อมี giver เยอะอยู่แล้ว ก็ย่อมดีกว่าถ้ามี giver ที่มีผลงานสูงเยอะ ๆ..

6. วิธีหนึ่งก็คือใช้เดดไลน์เป็นเครื่องมือ

7. ในบทความข้างต้นไม่ได้บอกชัด ๆ ว่าควรนำไปใช้อย่างไร แต่ถ้าเดาจากเนื้อหา ผมคิดว่าน่าจะตีความได้ประมาณนี้

   • ถ้ามอบหมายงานโดยไม่มีเดดไลน์ giver ที่มีผลงานต่ำจะมีความสามารถในการจัดการ giving ของตัวเองด้อยกว่า giver ที่มีผลงานสูงอยู่แล้ว (ตามสมมติฐาน) จึงมีโอกาสสูงที่จะไปโฟกัสกับการ giving เองจนทำให้งานของตัวเองออกมาไม่ดี

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

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

ประมาณนี้น่าจะพอใช้ตีความได้ครับ

ผมก็อยากรู้เหมือนกันว่าคนอื่น ๆ คิดอย่างไรกับข้อ 7 ครับ :)

[wonderer]

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

[spilist2]

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

ผมยังไม่ได้ดูนะครับ แต่เห็นว่ามีวิดีโอที่ยาวกว่านี้เกี่ยวกับ giver/taker/matcher เลยกะว่าจะลองดูเผื่อจะมีคำใบ้เพิ่มเติมอยู่ในนั้น (แต่อ่านหนังสือน่าจะเร็วกว่าเหมือนกัน) https://www.youtube.com/watch?v=-egUK2zaZlo

[roxie]

ผมยังนึกภาพไม่ค่อยออกว่าในข้อ 1 มันต่างจากแนวทาง Agile แบบทั่วไปอย่างไรนะครับ หรือเป็นเพราะผมอ่านแค่สรุปก็ไม่แน่ใจ..? ถ้าใครช่วยขยายความเพิ่มอีกสักหน่อยจะขอบคุณมากครับ 555

ส่วนตัวผมรู้สึกว่าข้อ 2 สะกิดใจมากกว่านิดหน่อยครับ ดูเหมือนจะเป็นจุดเริ่มต้นที่ดีในการทำให้การ giving เป็นสิ่งที่วัดเป็นคะแนนได้ เรื่อง giver, taker, matcher ที่พูดถึงในข้อ 2 สามารถดูรายละเอียดเพิ่มเติมได้ที่ https://www.youtube.com/watch?v=YyXRYgjQXX0 เป็นวิดีโอ TED ที่เล่าผลการวิจัยที่น่าสนใจมากว่า ในองค์กร คนที่ผลงานต่ำที่สุดก็เป็น giver และคนที่ผลงานสูงที่สุดก็เป็น giver เช่นกัน

[spilist2]

ขอบคุณมากครับ ได้ดูวิดีโอดี ๆ เพราะโพสต์นี้เลย ขอบคุณที่แนะนำครับ แม้จะแนะนำให้ไปดูวิดีโอต้นฉบับกันจริง ๆ แต่ผมลองสรุปไว้ให้ท่านอื่น ๆ ด้วยครับ https://www.youtube.com/watch?v=YyXRYgjQXX0

===

มีการสำรวจคน 30,000 คน ทั้งวิศวกร พยาบาล พนักงานขาย ฯลฯ

• สัดส่วนโดยประมาณคือ giver 25, taker 19, matcher 56

taker ไปได้เร็วและพังเร็ว

• เพราะ matcher มีจำนวนมาก จึงใช้กลยุทธ์ตาต่อตาเล่นงาน taker จนอยู่ไม่ได้

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

aองค์กรที่มี giver อยู่จะมีทั้ง productivity และความพึงพอใจสูงในหลายด้าน แล้วจะทำอย่างไรให้องค์กรเป็นที่ที่ giver สร้างผลงานสูงและได้รับการยอมรับ?

1. อย่าปล่อยให้ giver หมดไฟ

• giver เหนื่อยล้าได้ง่ายเพราะคอยช่วยคนอื่น ต้องคอยปกป้องคนกลุ่มนี้ไว้

• ถ้ามีคนที่พยายามช่วยคนอื่นมากเกินไป ก็สามารถให้หลักการกับเขาได้ เช่น “ไม่ใช่ต้องเป็น Mother Teresa แต่ลองมอบความปรารถนาดีสัก 5 นาที” อะไรทำนองนั้น

2. ส่งเสริมการขอความช่วยเหลือ สร้างวัฒนธรรมที่การได้รับความช่วยเหลือจาก giver เป็นสิ่งมีคุณค่า

• เมื่อได้จัดการสิ่งที่มีคนร้องขอ giver ก็สามารถสร้างผลงาน ได้รับคำขอบคุณ และมีความสุขมากขึ้น

• อีกทั้ง giver 75~90% เมื่ออยากช่วยคนอื่นจะเริ่มจาก “การถาม” ก่อน นั่นคือความช่วยเหลือจำนวนมากเริ่มจากการตั้งคำถาม ดังนั้นถ้าส่งเสริมให้คนถาม คนอื่น ๆ ก็มีแนวโน้มจะกลายเป็น giver ได้ง่ายขึ้นด้วย

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

3. อย่ารับ taker เข้าทีม และคัดออกให้ได้ ถ้ามี taker เข้ามา 1 คน อาจทำให้ giver หลายคนลาออกหรือหยุดช่วยเหลือไปเลย

• matcher มักทำตามบรรยากาศของทีม ดังนั้นถ้าคัด taker ออกได้ ก็สามารถสร้างวัฒนธรรมแบบ giver ได้

• ปัญหาคือการคัด taker ออกไม่ใช่เรื่องง่าย แม้สิ่งที่เรียกว่า “ความเป็นมิตรagreeableness” จะเป็นสัญญาณที่ดีของ giver แต่ taker ก็อาจเป็นมิตรได้ และ giver ก็อาจพูดแข็ง ๆ ได้เหมือนกัน

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

• เพื่อคัดกรอง taker ที่ดูเป็นมิตร คำถามที่ผมชอบใช้ในการสัมภาษณ์คือ “ช่วยบอกชื่อคน 4 คนที่ยกระดับเส้นทางอาชีพของคุณอย่างมีนัยสำคัญหน่อยครับ”

• โดยมาก taker คุ้นเคยกับการได้รับคำยกยอ จึงมักเอ่ยชื่อคนที่มีอิทธิพลและอำนาจสูง

• ส่วน giver มักเอ่ยชื่อคนที่อยู่ล่างกว่าในโครงสร้างอำนาจหลายคน

[budlebee]

ขอบคุณสำหรับสรุปครับ

แทนที่จะเป็นการบอกว่า takers คุ้นเคยกับการได้รับการประจบสอพลอ คำว่า "takers are great at kissing up" น่าจะสื่อได้แม่นยำกว่าว่า พวกเขาเก่งในการประจบสอพลอผู้อื่น ไม่ใช่หรือครับ?

[spilist2]

อ๋อ ใช่เลย เพราะเป็น kissing up / kicking down.. ขอบคุณครับ

[magicianwoo]

ขอบคุณสำหรับการสรุปที่ดีครับ

[spilist2]

จริง ๆ แล้วผมก็รู้สึกเข้าถึงข้อ 2 มากกว่านะครับ ฮ่า ๆ;

สำหรับผม ข้อ 1 ผมรับมันในฐานะ mental model ว่า ในบทบาทของผู้จัดการ เวลาตั้งเดดไลน์ควรมองจากมุมไหน กล่าวคือ “แทนที่จะมองเดดไลน์เป็นเครื่องมือไว้คอยเฆี่ยนให้ทำตามกำหนดเวลา ลองมองว่าเป็นเครื่องมือที่ช่วยให้ตัดสินใจเลือกสิ่งที่ดีกว่าได้ภายใต้ทรัพยากรที่มีจำกัด” ประมาณนั้นครับ

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

[roxie]

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

[xguru]

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