คำขอที่เล็กและไม่แม่นยำ ทำให้ทีมเสียเวลาอย่างมาก
(staysaasy.com)- คำขอที่คลุมเครือ จากผู้จัดการและผู้นำ แม้จะดูเป็นคำถามเล็ก ๆ แต่สามารถสั่นคลอนเวลา ลำดับความสำคัญ และทิศทางการลงมือทำของทีมได้อย่างมาก
- คำอย่าง “ช่วยตรวจสอบให้หน่อย” หรือ “ต้องทำให้ดูทันสมัย” มักลุกลามไปเป็น การตอบสนองเกินความจำเป็น เช่น รายงาน สไลด์ งานช่วงสุดสัปดาห์ หรือการอัปเกรดครั้งใหญ่
- ผู้ขอควรบอกให้ครบทั้ง เวลาที่คาดหวังให้ใช้, ผลกระทบต่อลำดับความสำคัญ, เป็นการตรวจดูข้อมูลเดิมหรือเป็นงานใหม่, และจะนำผลลัพธ์ไปใช้อย่างไร
- คนที่ได้รับคำขอก็ควรถามกลับถึงระดับความพยายามและตรวจสอบสิ่งที่ไม่ชัดเจน และไม่ควร เดาเอาเอง ว่าผู้นำคงยุ่งเกินกว่าจะตอบได้
- หากพูดให้เฉพาะเจาะจงตั้งแต่ต้น แม้จะรู้สึกกระอักกระอ่วนเล็กน้อย ก็จะช่วยลดความสับสน งานที่ทำผิดทิศ และการสูญเปล่าของต้นทุนในภายหลังได้มาก
คำขอเล็ก ๆ ขยายกลายเป็นงานใหญ่ได้อย่างไร
- ในองค์กร มักเกิดเหตุซ้ำ ๆ ที่คำขอสั้น ๆ ดูเบา ๆ กลับขยายเป็นงานใหญ่กว่าที่คาดมาก
- มีกรณีที่ผู้จัดการถามว่า “ช่วยทำ X ได้ไหม?” แล้วผู้ใต้บังคับบัญชาโดยตรงใช้เวลามากกว่าที่คาด 10 เท่า และผู้จัดการก็ตอบว่า “ไม่ได้ตั้งใจให้ใช้เวลาขนาดนั้น”
- คำพูดสั้น ๆ ของผู้บริหารในที่ประชุมว่า “ช่วยเช็กอันนี้หน่อยได้ไหม?” อาจนำไปสู่สถานการณ์ที่คน 24 คนช่วยกันทำสไลด์ 4 เวอร์ชัน และต้องทำงานถึงสุดสัปดาห์
- แต่พอถึงในประชุมจริง ผู้บริหารอาจดูแค่สรุปประโยคแรกของสไลด์หน้าแรก แล้วบอกว่า “ไม่ต้องนำเสนอทั้งหมดก็ได้”
- คำว่า “ต้องทันสมัยโดยไม่มีข้อแก้ตัว” หากไม่ตรวจสอบความหมายให้ชัด อาจถูกตีความว่าเป็น การอัปเกรดเทคโนโลยีครั้งใหญ่
- ทั้งที่เจตนาจริงอาจเป็นเพียงการอัปเดตไวยากรณ์ API ในเวอร์ชันใหม่ตลอดหลายปี
- ระหว่างนั้น การปล่อยโปรเจ็กต์สำคัญอาจต้องเลื่อนออกไป
สิ่งที่ผู้ขอควรกำหนดก่อน
- เวลาที่ผู้นำขออะไร ควรบอก ขอบเขตเวลา ที่คาดหวังโดยตรง
- ตัวอย่าง: “อย่าใช้เวลาเกิน 20 นาที แล้วอีก 20 นาทีค่อยเอาเท่าที่มีมา”
- ควรระบุด้วยว่าจะให้กระทบต่อลำดับความสำคัญอย่างไร
- ตัวอย่าง: “คาดว่าน่าจะใช้เวลาราว 2 สัปดาห์ และไม่ควรลดลำดับความสำคัญของงานหลักอื่นลงมากนัก”
- หากกำหนดการจริงต่างออกไป หรือชนกับงานอื่น ก็ควรบอกให้ติดต่อกลับทันที
- ควรแยกให้ออกว่าแค่ตรวจดูข้อมูลที่มีอยู่แล้วพอ หรือจำเป็นต้องวิเคราะห์หรือสร้างใหม่
- ตัวอย่าง: “ช่วยบอกแค่ว่าเรามีอะไรเกี่ยวกับหัวข้อนี้อยู่แล้วหรือไม่ ถ้ายังไม่เคยคิดเรื่องนี้มาก่อน แค่บอกเท่านั้นก็พอ”
- หากบอกว่าจะนำผลลัพธ์ไปใช้อย่างไร ก็จะช่วยให้อีกฝ่ายปรับระดับความพยายามได้ง่ายขึ้น
- ตัวอย่าง: คำตอบที่จะส่งให้ลูกค้าเป้าหมาย, การเตรียม Q&A สำหรับ All Hands ครั้งถัดไป, หรือหัวข้อสำคัญสำหรับบอร์ดครั้งหน้า
สิ่งที่คนรับคำขอต้องตรวจสอบ
- คนที่ได้รับคำขอควรถาม คำถามเพื่อให้ชัดเจน
- ควรถามเพื่อตรวจสอบระดับความพยายาม เช่น “คาดหวังผลลัพธ์ที่ละเอียดมากจนต้องใช้เวลาหลายชั่วโมง หรือแค่สรุปสั้น ๆ?”
- การถามไม่ได้ทำให้ดูโง่ แต่การไม่ถามแล้วไปทำงานผิดทั้งหมดนั้นเสี่ยงกว่า
- แทนที่จะเสียเวลาไปกับการตีความอีเมลหรือข้อความของผู้นำราวกับเป็นโบราณวัตถุ ควรตรวจสอบกับผู้นำที่เป็นคนขอโดยตรงจะดีกว่า
- หากผู้นำมีเวลาส่งคำขอ ก็ย่อมมีเวลา ทำให้คำขอนั้นชัดเจน ด้วย
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สิ่งที่เกลียดที่สุดคือเวลาผู้นำที่ไม่ใช่สายเทคนิคข้ามไปหนึ่งหรือสองขั้น แล้วไปคุยกับ บุคลากรเทคนิคระดับจูเนียร์ โดยตรง แทนที่จะคุยกับคนเทคนิคอาวุโสที่มีประสบการณ์ในการถามคำถามเพื่อทำให้ชัดเจน หรือกำหนดตารางเวลาและผลลัพธ์ส่งมอบ
นี่เป็นรูปแบบที่เห็นบ่อยมากในหลายองค์กรรณรงค์และองค์กรเทคโนโลยีการเมือง
คนเทคนิคระดับจูเนียร์เองก็เข้าใจสายการบังคับบัญชาอยู่แล้ว ดังนั้นไม่ว่าผู้ใหญ่จะตั้งใจหรือไม่ ถ้าทำลายมันก็จะเกิดความสับสนและความวุ่นวาย
คนที่ลงมือทำงานจริงมักเป็นวิศวกรจูเนียร์ และพวกเขาอาจตอบคำถามเฉพาะทางบางอย่างได้ดีกว่าคนที่มองจากระดับสูง
เลยรู้สึกว่าไม่น่าจำเป็นต้องเล่นเกมส่งสารต่อกัน
ถ้า ผู้ประสานงานโครงการ ของผู้ขายที่ยังไม่มีประสบการณ์, วิศวกรของผู้ขายที่ชินกับการมีคนประสานงานจัดการทุกอย่างให้, และลูกค้าที่เพิ่งเจอสถานการณ์แบบนี้เป็นครั้งแรก มาเจอกัน ก็อาจเกิดความสับสนครั้งใหญ่ได้
สำหรับคำพูดที่ว่า “ถ้าไม่ถามแล้วไปทำงานผิดทางสุด ๆ มันจะดูโง่มาก” และ “อย่าคิดเองเด็ดขาดว่าอีกฝ่ายคงยุ่งเกินกว่าจะตอบคำถามระหว่างทำงาน” ผมสงสัยว่าควรทำอย่างไรในสถานการณ์ที่ทำงานทางไกลและคุยผ่านแชตออนไลน์ก็ไม่ได้
ถ้าเจอหน้ากัน จะโยนคำถามเล็ก ๆ เร็ว ๆ แบบยังไม่ค่อยเป็นระเบียบได้ง่ายกว่า แต่พอเป็นอีเมลมันให้ความรู้สึกทางการและเหมือนรบกวนมากกว่า เลยต้องใช้เวลาเพิ่มในการอธิบายว่าติดตรงไหนและพยายามกันคำตอบที่คาดไว้อยู่ล่วงหน้า
การนัดวิดีโอคอลก็ใช้เวลาจัดตารางและมีต้นทุนแฝงสูง
ในโปรเจกต์ลูกค้า ผมจะเติมคำถามเล็ก ๆ ลงใน Google Doc ทุกครั้งที่มีขึ้นมา แล้วค่อยแจ้งลูกค้าเป็นครั้งคราวให้เข้ามาดูเอกสาร หรือให้ลูกค้าสมัครรับการแจ้งเตือนเมื่อมีการแก้ไข
ลูกค้าจะเขียนคำตอบลงในเอกสารโดยตรง แล้วงานก็ดำเนินต่อไปพร้อมกับทำแบบนี้ซ้ำไปเรื่อย ๆ
ข้อดีคือ ลูกค้าไม่จำเป็นต้องตอบทุกอย่างทีเดียว, การแจ้งเตือนลดลง, ทั้งสองฝ่ายเขียนกันได้แบบไม่ต้องทางการมาก, ให้ความรู้สึกร่วมมือกัน, เพิ่มคำถามต่อยอดไว้ข้างส่วนที่เกี่ยวข้องได้ง่าย, และยังใช้คอมเมนต์ในเอกสารสำหรับการคุยสั้น ๆ หรือมอบหมาย/ติดตามงานเล็ก ๆ ได้ รวมถึงคนอื่นก็เข้ามาอ่านและช่วยเติมได้ง่าย
ที่คิดไว้ตรงนี้คือสถานการณ์ที่มีคำถามเล็ก ๆ จำนวนมาก เช่นงาน รับจ้างตามสัญญา กับลูกค้าที่ไม่ใช่สายเทคนิคและยังไม่ค่อยเข้าใจ
คนอื่นไม่ได้ตั้งข้อจำกัดแบบนั้นกับอีเมล
ถ้าไม่ได้ส่งถึง CEO ก็แค่พิมพ์คำถามตามที่นึกออกแล้วส่งไปได้เลย
ไม่ต้องกลัวที่จะส่งอีเมลฉบับที่สองทันทีแบบ “อ้อ ลืมถามข้อนี้ไปด้วย ขอบคุณครับ/ค่ะ! $QUESTION”
ถ้าไปดูอีเมลของผู้บริหารระดับสูงใน https://twitter.com/TechEmails ส่วนใหญ่ก็ไม่เป็นทางการมาก
อีเมลเก่า ๆ บางฉบับที่ Bill Gates กับผู้บริหาร Microsoft ส่งหากัน ก็ไม่ได้เป็นระเบียบกว่าข้อความแชตของเด็กมัธยมสักเท่าไร
ไม่ได้หมายความว่าควรใส่อีโมจิส่งไปหาหัวหน้าของหัวหน้าของหัวหน้าของหัวหน้า แต่ อีเมลสั้น ๆ แบบไม่เป็นทางการ จะไม่ทำให้เส้นทางอาชีพคุณจบลงหรอก
เข้าใจได้ว่าหลายคนรู้สึกว่ามันหนักกว่า แต่ไม่แน่ใจว่าสำหรับทั้งสองฝ่ายแล้วมันน่ารำคาญกว่าจริงหรือไม่
ถ้าการทำให้คำถามชัดต้องอาศัยการโต้ตอบไปมา ก็ทำแบบนั้นได้เลย
วิธีใช้เอกสารร่วมกันก็เป็นไอเดียที่ดี และยังมีข้อดีเพิ่มอีกสองอย่าง
การเขียนออกมาเป็นขั้นตอนเพิ่มเติมที่ช่วยทำให้คำถามชัดขึ้น และคำถามกับคำตอบก็ถูกบันทึกไว้เป็นเอกสารสำหรับภายหลัง
ทั้งสองอย่างนี้ดีกว่าการคุยเร็ว ๆ ที่สุดท้ายต้องมาเขียนใหม่ทีหลังมาก
คุณสามารถโยน ภาระทางการรับรู้ ไปให้อีกฝ่ายได้
เพราะรบกวนครั้งเดียวย่อมดีกว่ารบกวนหลายครั้งต่อวัน
พอได้รับงานใหม่มา ผมจะไล่ดูคร่าว ๆ ก่อน วางแผนว่าจะทำอะไร เจาะลึกปัญหาหรือความขัดแย้งที่อาจเกิดขึ้นในหัว บางทีก็ทำรายการคำถามยาวมาก แล้วแยกว่าคำถามไหนใครน่าจะตอบได้ ก่อนค่อยเริ่มคุยออนไลน์
ภายในบริษัท ปกติก็แค่ขอคุยวิดีโอสั้น ๆ 5 นาทีผ่านแอปส่งข้อความภายในอย่าง Slack
ถ้าเป็นเพื่อนร่วมงานที่ทำงานใกล้ชิดกันก็อาจโทรไปเลยแบบไม่ต้องนัดล่วงหน้า
กับลูกค้าภายนอกก็ทำคล้ายกันได้ผ่านเบอร์โทรจริงหรือวิดีโอคอล ถ้ามีการตกลงกันไว้ล่วงหน้า
ตัวอย่างเช่น ในการประชุมคิกออฟก็กำหนดไปเลยว่าลูกค้าต้องการความถี่ในการติดต่อแค่ไหน และคำถามแบบใดควรสื่อสารทันที กับคำถามแบบใดใช้การสื่อสารแบบอะซิงโครนัสช้าหน่อยก็พอ
เวลาเป็นตัวชี้วัดแทน ความพยายาม·เนื้อหาสาระ·ขอบเขตงาน ที่แย่มาก
ตัวอย่างเช่น เมื่อเห็นคำขออย่าง “ลองดูแค่ 20 นาที แล้วอีก 20 นาทีค่อยเอาสิ่งที่มีมาดู” แต่ละคนก็ทำสิ่งที่สำเร็จได้ภายใน 20 นาทีไม่เท่ากันเล็กน้อย
ต่อให้มองข้ามความต่างนั้น ก็ไม่ได้มีอะไรรับประกันว่าผู้จัดการที่ขอจะได้สิ่งที่ต้องการจากความพยายาม 20 นาทีนั้น
ในสภาพแวดล้อมแบบ Agile มักเรียกงานค้นหา·สืบสวนว่า “spike” และมักกำหนด “timebox” ให้ แต่ถ้าถามว่า “แล้วถ้าภายในเวลานั้นยังค้นไม่พบสิ่งที่ต้องการล่ะ?” ก็มักไม่มีคำตอบที่ดีนัก
ในความเป็นจริง timebox จะถูกยืดออกไปเรื่อย ๆ จนกว่าจะรู้สิ่งที่ต้องการ
เพราะงั้นเวลาเลยเป็นตัวชี้วัดแทนที่ไม่ดีทั้งสำหรับความพยายาม เนื้อหาสาระ และขอบเขตงาน
ผมคิดว่าตัวอย่างช่วงท้ายบทความที่ว่า “คาดหวังอะไรที่ละเอียดมากซึ่งต้องใช้เวลาหลายชั่วโมง หรือแค่สรุปเร็ว ๆ ก็พอ?” ดีกว่า
เพราะมันพูดถึง ขอบเขตของงาน ไม่ใช่เวลาที่ใช้
ถ้าวัดด้วยเวลา ก็ไม่มีอะไรรับประกันว่าจะได้สิ่งที่ต้องการภายในเวลานั้น และสุดท้ายก็มักต้องเพิ่มเวลาเข้าไปอีก
คำตอบของ “ถ้าภายในเวลานั้นยังค้นไม่พบสิ่งที่ต้องการล่ะ?” คือ เราจะได้รู้ว่าไม่สามารถหาคำตอบได้ภายในเวลาที่คาดไว้ และปรับความคาดหวังต่อแรงงานที่ต้องใช้สำหรับงานสืบสวนนี้
สำหรับผู้จัดการแล้ว นี่แหละคือหนึ่งในข้อมูลสำคัญที่อยากรู้ที่สุด
เพราะงั้นเพื่อป้องกันไม่ให้โปรเจกต์หลุดรางแล้วลงถังขยะ จึงต้องมี timebox กับทุกอย่าง
ใช้ได้แม้กับงานส่วนตัวหรือการทำงานคนเดียว
เพราะเราสามารถยึดติดกับอะไรก็ได้ไปตลอด ดังนั้นการบังคับให้มีจุดหยุด รับ feedback หรือปล่อยออกไปก่อน แล้วค่อยตัดสินใจว่าจะคุ้มค่าพอให้ทำต่อไหม จึงดีกว่ามาก
กลไกที่ทำงานตรงนี้คือการบังคับให้คนจัดลำดับความสำคัญ
ถ้าคุณเก่งเรื่องการตัดสินใจจัดลำดับความสำคัญมาก ๆ อาจต้องพึ่ง timebox น้อยลง แต่ถึงอย่างนั้น หากไม่มี timebox ก็อาจต้านทานความยั่วยวนที่จะทำงานต่อไปจนคุณภาพสูงเกินระดับที่จำเป็นได้ยาก
รูปแบบการทำงานแบบนี้มีประโยชน์เมื่อสิ่งที่ไม่รู้นั้นมีมากกว่าสิ่งที่รู้อย่างมาก
เป้าหมายไม่ใช่การเดาสุ่มแบบไร้ทิศทาง แต่คือการค่อย ๆ เพิ่มสัดส่วนของ “สิ่งที่รู้” ให้มากพอจะเดาอย่างมีข้อมูลรองรับได้
ตัวอย่างเช่น มีบั๊กใน codebase แบบ legacy แต่ระบบทดแทนก็เกือบเสร็จแล้วและมีกำหนดปล่อยในอีกสองเดือน จะจัดการกับบั๊กนั้นอย่างไร
จะปล่อยมันไว้ก็ได้ หรือจะสั่งใครสักคนว่า “แก้ให้ได้ไม่ว่าจะทำยังไงก็ตาม” ก็ได้ แต่ทั้งสองอย่างไม่ดี
เลยบอกว่า “ลองตรวจบั๊กนี้ แต่อย่าเกินหนึ่งชั่วโมง แล้วมาบอกว่าคืบหน้าไปถึงไหน”
พอเสร็จแล้วก็จะเข้าใจลักษณะของปัญหาได้ดีขึ้น
ถ้ากลับมาบอกว่า “เจอขอบเขตปัญหาแล้ว แต่ต้องแก้ร่วมกับคนที่เข้าใจ business logic ดี” ก็จัดทรัพยากรที่เหมาะสมแล้วเดินหน้าซ่อมต่อได้
ถ้าบอกว่า “อยู่ในส่วนนี้ของโค้ด และจัดระเบียบไว้ค่อนข้างดี แต่ยังตามครบไม่หมด” ก็อาจให้เวลาเพิ่มได้โดยเชื่อว่ามันไม่น่าจะเป็นงานใหญ่โต
แต่ถ้าบอกว่า “มันอยู่ที่ไหนสักแห่งในสปาเกตตีประหลาดกองนี้ พอส่องเข้าไป เหวลึกก็จ้องกลับมาที่ผม กระดูกสันหลังเย็นวาบ และภาพบนกำแพงก็ร้องไห้เป็นน้ำตาเลือด ได้โปรดอย่าส่งผมกลับไปอีก” ก็จะเห็นชัดว่ามันไม่คุ้มจะตามต่อและปล่อยวางได้
ผมเชื่อว่าคุณเคยเจอประสบการณ์ที่พอไม่ได้สิ่งที่ต้องการภายในเวลาก็ต้องเติมเวลาเพิ่ม แต่ก็ไม่ได้เป็นสากลเสมอไป
ปัญหาอยู่ที่การปฏิบัติต่อ “สิ่งที่ต้องการ” ราวกับเป็นเป้าหมายสุดท้ายในตัวมันเอง
ดังนั้นบทความจึงบอกว่า “ให้บอกด้วยว่าทำไมถึงต้องการสิ่งนั้น”
“ลูกค้ารายใหญ่ที่สุดต้องรู้ก่อนต่อสัญญา” คุ้มค่ากับการใช้เงินและเวลาเจ้าหน้าที่มากกว่า “ก็แค่อยากรู้เฉย ๆ”
ในระดับผู้นำ ต้องตระหนักว่าตามเก็บทุกผลประโยชน์ไม่ได้ และควรโฟกัสเชิงกลยุทธ์กับสิ่งที่ คุ้มค่าต่อราคา ที่สุด
ไม่ใช่แค่เอาคนไปโปะงาน แต่รวมถึงการมอบหมายงานที่เหมาะสมให้กับ คนที่มีทักษะเหมาะสม ด้วย
CEO ของสตาร์ตอัปเคยขออะไรบางอย่าง ซึ่งดูเหมือนว่าจะเป็นคำขอสั้น ๆ แค่หนึ่งหรือสองประโยค
ผลคือผมทำ รายงาน 14 หน้า ใช้เวลาไปหลายชั่วโมง และส่วนใหญ่ทำในเวลาส่วนตัว
ผมส่งรายงานให้ CEO แต่หลังจากนั้นก็ไม่มีคำตอบใด ๆ และไม่มีอะไรเกิดขึ้น
หลังจากนั้นผมเลยตั้งกฎใหม่ให้ตัวเอง
ต้นทุนของคำขอควรแปรผันตามต้นทุนในการสื่อสารคำขอนั้น
ตอนนี้ถ้าได้รับคำขอที่มีต้นทุนสูง ผมจะรอ ดึงเวลา และเรียกร้องให้มีการ escalated
คนที่ขอต้องทำการตรวจสอบอย่างจริงจังและขออนุมัติจากผู้มีอำนาจสูงกว่า เพื่อแสดงให้เห็นว่ามันคุ้มค่าพอจะจ่ายต้นทุนนั้น
ถ้าเป็นคำขอเหลวไหล มันก็จะเงียบหายไปเอง และถ้าเป็นคำขอที่มีคุณค่า ผมก็จะจัดการมัน อีกข้อดีเพิ่มเติมคือความพยายามนั้นจะไม่เกิดขึ้นแบบเงียบ ๆ โดยไม่มีการมองเห็นที่เหมาะสม
ข้อแรก ผมจะไม่ทำอะไรเลยกับคำขอครั้งแรก
ถ้ามันสำคัญจริง เขาจะมาขออีก แล้วค่อยคิดตอนนั้น
ข้อสอง ถ้าผมต้องทำงานล่วงเวลา อีกฝ่ายก็ต้องทำงานล่วงเวลาเหมือนกัน
ถ้าอีกฝ่ายไม่อยากทำงานล่วงเวลา ก็แปลว่ามันไม่ได้สำคัญขนาดนั้น
จากการอยู่ในสายวิศวกรรมมาหลายระดับ ตั้งแต่จูเนียร์จนถึงผู้บริหารระดับ C ได้เรียนรู้อะไรอยู่บ้าง
อย่างแรก ทุกคนต้องทำไปด้วยเจตนาดี
เคยเห็นผู้นำขออะไรบางอย่างกับลูกน้องโดยตรงแบบฉับพลันโดยไม่คิดแม้แต่ 5 วินาที และในทางกลับกันก็เคยเห็นลูกน้องที่ขยับตัวก็ต่อเมื่อได้รับไวยากรณ์ที่แม่นยำราวกับเป็น “human command line”
ทั้งสองแบบไม่ควรเกิดขึ้น
อย่างที่สอง สำหรับผู้จัดการหรือผู้นำ ไม่มีคำว่า “คำขอครั้งเดียว”
ไม่ว่าคำขอไหนก็จะมีลำดับความสำคัญโดยนัยเหนือกว่างานอื่นทั้งหมด
ต้องขยับตัวภายในระบบและบริบทโดยรวม ไม่อย่างนั้นก็เท่ากับโยนภาระการเลือกนั้นให้ทีม
อย่างที่สาม ถ้าเป็นฝ่ายรับคำขอ ก็ควรช่วยให้ผู้ขอเข้าใจว่าตัวเองต้องการอะไร
ต้องกำจัดสมมติฐานโดยนัยออกไป เพราะตรงนั้นแหละที่มังกรซ่อนอยู่
ต้องสื่อสาร แจ้งให้รู้ สอน และยืนยันว่าผู้ขอต้องการอะไร เพื่อให้แน่ใจว่าทั้งสองฝ่ายเห็นตรงกัน
เรื่องแบบนี้เกิดขึ้นเพราะความพยายามจะมีประสิทธิภาพ ไม่เสียเวลาไปกับสิ่งที่ไม่จำเป็น แต่ถ้าทั้งผู้ขอและผู้รับพยายามช่วยกัน ชีวิตก็มักจะทนได้มากขึ้นเยอะ
ผู้นำที่คอยดันขอบเขตว่าไปได้ไกลแค่ไหน กับผู้นำที่พยายามสร้างความสัมพันธ์บนพื้นฐานของเจตนาดีกับทีม ต่างกันอย่างชัดเจน
ผู้จัดการที่คอยเรียกร้องอะไรแบบไม่คิดหน้าคิดหลังจะค่อย ๆ เสียพนักงานที่ดีที่สุดไปเรื่อย ๆ
จากประสบการณ์ พอเวลาผ่านไปมากพอ ใต้ผู้นำแบบนี้จะเหลือแต่คนจูเนียร์ เพราะคนมีประสบการณ์จะหลีกเลี่ยงทีมนั้น
สมาชิกทีมแบบ “human command line” ก็เป็นตัวอย่างที่ดีของการกระทำโดยไม่สุจริตใจเช่นกัน
เคยทำงานกับคนที่แม้แต่คำขอเล็กน้อยมากก็ยังต้องให้กรอกแบบฟอร์มหรือเอกสารที่ตัวเองทำขึ้นก่อนถึงจะเริ่มได้ แล้วกว่าจะยอมคิดเรื่องเล็ก ๆ นั้นก็ต้องถกเถียง วิจารณ์ หรือเวียนให้คนอื่นดูอยู่หลายวัน
พวกเขาคิดว่าตัวเองปกป้องตัวเองจากคำขอเล็ก ๆ โดยทำให้ไม่มีใครอยากเสียแรงตั้งคำถามให้เป๊ะ แต่พอเวลาผ่านไปก็สะสมชื่อเสียงว่าเป็นคนร่วมงานด้วยยาก
อีกแบบหนึ่งคือคนที่ฉวยใช้ความกำกวมของทุกคำขอ
ทั้งที่โดยมากก็รู้ว่าถูกขออะไร แต่จะทำตัวเหมือน “จะสอนบทเรียนให้” แล้วส่งมอบผลลัพธ์ที่ตรงตามถ้อยคำเป๊ะ ๆ แต่ทุกคนก็รู้ว่าไม่ใช่สิ่งที่ต้องการหรือจำเป็นจริง ๆ
และไม่ใช่เรื่องบังเอิญที่คนส่วนใหญ่ที่เล่นเกมแบบนี้ถูกไล่ออกไปภายในปีที่ผ่านมา
คนเราพอจะทนเพื่อนร่วมงานแย่ ๆ ที่ยังพอทำงานได้อยู่สักพักหนึ่งได้ แต่พอถึงเวลาปลดคน คนแบบนี้จะขึ้นไปอยู่บนสุดของรายชื่อที่ต้องเอาออก
เมื่อเดือนก่อนฉันเพิ่งตระหนักถึงความล้มเหลวที่ตัวเองก่อในฐานะผู้นำ
ภายนอกดูเหมือนตั้งใจจะมอบความเป็นเจ้าของให้ทีม และก็เทงานหลายอย่างลงไป แต่ความจริงคือกำลังโยนความเครียดเรื่อง “ตอนนี้ต้องทำอะไรก่อน” ไปให้ทีม
มันเป็นกับดักที่แนบเนียนมากจนคิดได้ง่ายว่า “ฉันกำลังกระจายอำนาจให้ทีมสุด ๆ เลย!” แต่จริง ๆ แล้วกำลังทำให้ทีมเครียดและบั่นทอนสมาธิ
askเปลี่ยนจากคำกริยาเก่าแก่ไปเป็นคำนามสมัยใหม่ที่ดูตามแฟชั่นและฟังแปลก ๆตาม OED บอกว่าการทำให้เป็นคำนามเริ่มจากภาษาพูดในออสเตรเลีย
https://www.oed.com/search/dictionary/?q=ask
ทุกคนก็รู้ว่าไม่มี “กฎ” จริง ๆ อยู่แล้ว เพราะภาษาเป็นผลผลิตทางชีวะ-สังคม-ความรู้ความเข้าใจที่เปลี่ยนแปลงตลอดเวลา แต่การใช้แบบนี้ก็ยังขัดหูเหมือนเคี้ยวทราย ทั้งที่มีคำพ้องความหมายที่ดีก็มีอยู่แล้ว
เพราะหวังว่าข้อมูลนั้นจะไม่มากำหนดการตัดสินใจ
ฉันคิดว่าควรทำสิ่งที่ดีที่สุดต่อธุรกิจและผู้ใช้ปลายทาง ไม่ใช่สิ่งที่ง่ายกับฉัน
แต่สุดท้ายอีกฝ่ายเลือกทางที่ยาวและยากกว่า แล้วภายหลังถึงรู้ว่าจริง ๆ เขาต้องการอีกทาง แต่คิดว่านั่นจะยากกว่าสำหรับฉัน
เรื่องแบบเดียวกันนี้เกิดขึ้นในชีวิตจริงด้วย
ตอนทำตู้เก็บของในครัวใหม่ ฉันให้ภรรยาเลือกตัวเลือกสองแบบของรางด้านบนของบานตู้ โดยไม่ได้บอกว่าแบบหนึ่งทำยากกว่า เพราะอยากให้เธอเลือกแบบที่ชอบจริง ๆ
แน่นอนว่าเธอเลือกแบบที่ยากกว่า และภายหลังพบว่าเธอคิดว่าแบบนั้นง่ายกว่า ทั้งที่จริง ๆ แล้วเธอชอบอีกแบบมากกว่า
เพราะอย่างนั้นต้องให้ข้อมูลทั้งหมดกับอีกฝ่ายเสมอ
ทำไมเราถึงพูดไม่ได้ว่าคำถามที่ผู้บริหารโยนมามันไม่สมเหตุสมผล
คำตอบก็คือแน่นอนว่าเพราะไม่อยากขัดลำดับชั้น
แต่การคล้อยตามลำดับชั้นแบบนี้ไม่ได้ช่วยธุรกิจจริง ๆ
มันดูเป็นค่านิยมที่ควรทิ้งได้ง่ายกว่านี้
คำถามว่า “คาดหวังความละเอียดมาก ๆ หรือแค่สรุปเร็ว ๆ ก็พอ?” ฟังแล้วตลกดี
ถ้าวิศวกรพูดตรง ๆ กับคนที่ไม่ใช่วิศวกรว่างานบางอย่างใช้เวลานานแค่ไหน คนที่ไม่ใช่วิศวกรก็คงช็อกแล้วบอกว่าเป็นไปไม่ได้
คำขอแบบ “อย่าใช้เวลาเกิน 20 นาที แล้วเอาสิ่งที่มีอยู่ในอีก 20 นาทีมาให้” ฟังดูบ้าสิ้นดี
ไม่มีงานอะไรที่ใช้เวลา 20 นาทีหรอก
จะดีกว่าถ้าพูดว่า “อย่าเพิ่งดูอันนี้ ไปดื่มกาแฟแล้วกลับมาประเมินคร่าว ๆ ให้หน่อย”
เรากำลังทำงานที่ซับซ้อนและต้องมีเวลาคิด
ถ้าไม่อยากให้ใช้เวลาคิด ก็แค่ไม่ต้องถาม
ส่วนหนึ่งของปัญหาคือเราเองก็ไม่อยากบอกหัวหน้าว่าเลิกกวนได้แล้ว และก็ไม่อยากบอกว่ากับงานที่หัวหน้าคิดว่าใช้ 20 นาที เรากลับใช้ไป 6 ชั่วโมง
สุดท้ายงานอื่นทั้งหมดเลยถูกเลื่อนออกไป
นี่จึงเป็นเหตุผลว่าทำไมการจัดการวิศวกรรมที่ดีถึงพยายามกันวิศวกรออกห่างจากคนที่จะคอยดึงตัวคนเทคนิคไปใช้แบบไม่ตั้งใจให้มากที่สุด
สัญญาณแบบฉบับของการบริหารที่อ่อนแอคือการสั่งรายงานหรือมอบหมายงานทั้งที่ตัวเองยังไม่เข้าใจผลกระทบโดยรวมทั้งหมด
สัญญาณแบบฉบับของวิศวกรรมที่อ่อนแอคือการตอบคำขอนั้นว่า “ได้”
เมื่อผู้จัดการที่อ่อนแอขอสิ่งที่เกินขอบเขตงานเล็กน้อยที่ควรจัดการเองได้ ผู้ปฏิบัติงานควรทำอย่างใดอย่างหนึ่งในสามข้อตามบริบททางเทคนิคและสังคม
A) ถามว่า “แล้วต้องทำอย่างไร?”
ใช้ได้เมื่อผู้จัดการเป็นสายเทคนิคและโยนงานมาแบบคลุมเครือเพื่อชดเชยความไร้ความสามารถทางเทคนิคของตัวเอง
ถ้าสะท้อนคำพูดเหลวไหลนั้นกลับไปตรง ๆ เขาจะต้องเผชิญกับความเป็นจริงของขอบเขตและกลไกของสิ่งที่ตัวเองกำลังขอ
B) แจ้งว่า “งานนั้นต้องใช้ทรัพยากร X ความคาดหวังคืออะไร?”
ตรงนี้ X อาจเป็นอะไรก็ได้ เช่น ชั่วโมงคนจำนวนมหาศาล เงิน หรือ GP ของ RuneScape แบบ old school
เหมาะกับผู้จัดการที่ไม่ใช่สายเทคนิค และคล้ายกับข้อ A ตรงที่ทำให้เขาต้องเผชิญว่านี่ไม่ใช่เรื่องที่จะอนุมัติสด ๆ ได้ แต่เป็นคำขอขนาดใหญ่ที่ต้องผ่านกระบวนการปกติ
C) พูดว่า “ไม่”
อาจทำไม่ได้ในทุกองค์กรหรือทุกบริบททางสังคม แต่ในองค์กรสมรรถนะสูง สิ่งนี้เป็นไปได้
ในสภาพแวดล้อมวิศวกรรมที่มีผลงานสูง องค์กรวิศวกรรมจะมีสิทธิยับยั้งงานไร้สาระที่ไม่มีเหตุผล และมีเพียงผู้บริหารระดับ C-level เท่านั้นที่กลับคำได้
การรู้ว่าจะใช้สิทธิยับยั้งนี้เมื่อไรและอย่างไรก็เป็นทักษะสำคัญที่วิศวกรรมควรพัฒนาเช่นกัน
ดังนั้นไม่ว่าจะพูดอะไรเกี่ยวกับเรื่องนั้น ก็อาจกลายเป็นการผลักตัวเองให้เข้าใกล้ประตูทางออกมากขึ้น
ทุกครั้งที่เห็นการใช้ “ask” เป็นคำนาม มันทำให้ความรู้สึกทางภาษาของฉันคันยุบยิบ เลยไปค้นดูแล้วเจอบทความนี้
https://english.stackexchange.com/questions/4246/can-or-shou...
อาจช่วยคนที่รู้สึกขัดหูขัดตาแบบเดียวกันได้
เวลาที่เปลืองที่สุดอย่างหนึ่งคือเวลาคำขอไม่มีบริบท
มันอาจดูเหมือนเป็นการประหยัดเวลาด้วยการบอกเฉพาะคนที่จำเป็นต้องรู้ แต่ “ทำไม” และบริบทนั้นสำคัญมากต่อการหาทางแก้ที่ดี
ถ้าไม่มีสิ่งนั้น ก็ไม่มีทางรู้ได้ว่าอีกฝ่ายคิดอะไรมาแล้วบ้าง
ตัวอย่างเช่น ถ้าบอกว่า “ต้องบล็อกคำขอที่มาจากประเทศ X” มันก็ไม่ได้ยากอะไรนักด้วยบริการไฟร์วอลล์ส่วนใหญ่
แต่ทำไปทำไม
ถ้าจุดประสงค์คือจะให้ การรับประกันตามสัญญา ว่าจะไม่มีทราฟฟิกจากบางประเทศเกิดขึ้น วิธีนั้นใช้ไม่ได้ เพราะใครก็ใช้ VPN เพื่อหลบการตรวจจับรหัสประเทศได้ภายใน 2 นาที
ผู้ใช้ต้องการทำ X แต่ไม่รู้วิธี และคิดว่า Y น่าจะใช้ได้ จึงขอความช่วยเหลือเกี่ยวกับ Y ขณะที่คนอื่นเห็นว่า Y แปลก ๆ เลยสับสน
https://xyproblem.info/
มีคนจำนวนมากตายคาเนินนั้นไปแล้ว แต่สุดท้ายมันก็ยังถูกนำไปใช้
อย่าไปเป็นเหยื่อรายถัดไปจะดีกว่า
ท้ายที่สุดแล้วมันขึ้นอยู่กับวัฒนธรรมบริษัทและขึ้นอยู่มากว่าผู้คนรู้สึกสบายใจแค่ไหนที่จะโต้แย้งกับผู้นำระดับอาวุโส
ภาระนั้นอยู่ที่ ผู้นำระดับอาวุโส ที่ต้องทำให้คนข้างล่างโต้แย้งได้อย่างสบายใจ
จากประสบการณ์ของฉัน ผู้นำที่ดีที่สุดคือคนที่ถ่อมตัวและพร้อมรับฟัง
แต่บางครั้งการทำงานไร้สาระก็เป็นส่วนหนึ่งของอาชีพ
ถ้ามันมากเกินไป แน่นอนว่าก็ควรหางานอื่น แต่ก็คงไม่ดีนักถ้าจะกลายเป็นคนที่คอยสงสัยและซักย้อนผู้บริหารอยู่ตลอดเวลา