การไม่ทำอะไรเลยในที่ทำงาน
(seangoedecke.com)- ผลงานของวิศวกรซอฟต์แวร์ไม่ได้ขึ้นอยู่กับเวลาที่มากขึ้นหรือโค้ดที่มากขึ้น แต่ขึ้นอยู่กับ งานที่มีอิมแพกต์สูงในจังหวะที่เหมาะสม และโดยปกติการทำงานที่ระดับการใช้งาน 80% โดยใช้เวลาราว 20% ของวันทำงานอยู่ห่างจากคอมพิวเตอร์นั้นได้ผล
- ในองค์กรวิศวกรรมขนาดใหญ่ โอกาสที่ขึ้นกับจังหวะเวลา เช่น การสนับสนุนดีลสัญญาใหญ่ การบรรเทาเหตุขัดข้อง หรือการปล่อยฟีเจอร์สำคัญ สามารถสร้างมูลค่าสูงมากได้ และถ้ายุ่งอยู่แล้วก็มักพลาดโอกาสเหล่านี้ได้ง่าย
- หากคอยปิด ticket ลำดับความสำคัญต่ำต่อเนื่อง ก็จะมองไม่เห็นสถานการณ์ของทีมอื่น อัปเดตของทีม หรือเหตุขัดข้องที่กำลังดำเนินอยู่ และผู้จัดการก็ยากจะมองว่าเป็นคนที่ยังมีเวลาว่าง
- เวลาที่ไม่ได้ทำอะไรเปิดโอกาสให้ฟื้นตัวจากความเครียด รักษาความนิ่งระหว่างรับมือเหตุขัดข้อง เกิดไอเดียใหม่ และมี สมาธิ กับงานสำคัญ
- การตั้งใจเหลือแรงไว้ในช่วงปกติ และทุ่มเต็ม 100% เฉพาะช่วงที่ผลตอบแทนสูงมาก จะสร้างเงื่อนไขที่ทำให้เป็นวิศวกรผลงานสูงได้ง่ายกว่า
โอกาสที่มีอิมแพกต์สูง
- วิศวกรจำนวนมากควรทำงานให้น้อยลง ไม่ได้หมายถึงให้เขียนโค้ดหรือลดปริมาณการเปลี่ยนแปลง แต่หมายถึงลดเวลาที่ทำงานจริงในแต่ละวัน และแม้ตอนทำงานก็ควรทำช้าลง
- ในสภาวะปกติให้ตั้งเป้า อัตราการใช้งาน 80% และเมื่อไม่มีโปรเจ็กต์กดดันสูง ก็ควรใช้เวลางาน 20% อยู่ห่างจากคอมพิวเตอร์
- ผลลัพธ์ของบริษัทเทคโนโลยีได้รับอิทธิพลอย่างมากจาก เหตุการณ์ที่ไม่ปกติ และการเปลี่ยนแปลงที่สร้างผลกระทบใหญ่ที่สุดจำนวนมากอาจเกิดจากปริมาณงานที่น้อยอย่างน่าประหลาด
- ในการพัฒนาซอฟต์แวร์ ความพยายามล้วน ๆ ไม่ได้มีคะแนน สิ่งสำคัญคือการแก้ปัญหาที่ถูกต้องในเวลาที่ถูกต้อง
-
สามกรณีที่เป็นไปได้ในองค์กรขนาดใหญ่
- การช่วยสนับสนุนฟีเจอร์หรือแก้บั๊กในจังหวะที่กำลังพยายามปิดดีลสัญญาองค์กรใหญ่ อาจช่วยให้ดีลสำเร็จได้
- ฟีเจอร์นั้นไม่จำเป็นต้องยอดเยี่ยมมาก บางครั้งแค่แสดงให้เห็นว่ามีความตั้งใจและความสามารถในการทำการเปลี่ยนแปลงเฉพาะจุดก็เพียงพอแล้ว
- หากป้องกันหรือบรรเทาเหตุขัดข้องได้ตั้งแต่ต้น ก็จะลดทั้งการสูญเสียรายได้ทันทีระหว่างเหตุการณ์ และการสูญเสียรายได้ภายหลังจากการที่ลูกค้ายกเลิกบริการหรือปฏิเสธสัญญา
- แค่รู้ว่าต้องปิด feature flag ตัวไหน ก็อาจประหยัดเงินจำนวนมากได้
- เมื่อบริษัทกำลังจะปล่อยฟีเจอร์สำคัญ ความสำเร็จหรือความล้มเหลวอาจขึ้นอยู่กับการเปลี่ยนแปลงเล็กน้อยแต่หาเจอยาก
- ตัวอย่างเช่น การเพิ่มฟิลด์ใหม่ใน user settings อย่างรวดเร็ว หรือการซ่อมฟังก์ชัน export ข้อมูลองค์กรแบบเก่าที่ไม่มีใครแตะมาหลายปี
- ความคุ้นเคยกับระบบอาจเป็นความต่างระหว่างงานที่ใช้ไม่กี่ชั่วโมงกับงานที่ใช้เวลาหนึ่งสัปดาห์
-
การพึ่งพาเวลา
- โอกาสทั้งหมดนี้ ขึ้นกับจังหวะเวลา จะล็อกอินตอนเช้าแล้วสุ่มไปปิดดีลใหญ่ บรรเทาเหตุขัดข้อง หรือทำฟีเจอร์หลักให้เสร็จอย่างรวดเร็วไม่ได้
- แค่อยู่ถูกที่ถูกเวลาไม่พอ ต้องไม่ใช่คนที่ยุ่งอยู่ก่อนแล้วด้วย
การรักษาช่องว่างเอาไว้
- ถ้าคอยทำงานลำดับความสำคัญต่ำต่อไปเรื่อย ๆ และทำงานเต็ม 100% ก็จะพลาดโอกาสทำงานอิมแพกต์สูงได้สองทาง
- อย่างแรก ถ้ายุ่งเกินไป ก็จะไม่ทันสังเกตเห็นโอกาสนั้นตั้งแต่แรก
- จะมีเวลาน้อยลงในการคุยกับคนที่กำลังทำงานอื่น อ่านอัปเดตทีม หรือดูเหตุขัดข้องที่กำลังเกิดขึ้น
- วิธีที่ดีที่สุดในการเข้าไปมีส่วนร่วมกับงานอิมแพกต์สูงคืออาสาความเชี่ยวชาญของตัวเอง
- อย่างที่สอง ถ้าดูยุ่งตลอด ผู้จัดการก็ยากจะดึงเข้าไปร่วมได้
- ผู้จัดการหรือผู้จัดการผลิตภัณฑ์ที่มองว่า “คนนี้น่าจะยังพอช่วยได้” แล้วค่อยเชื่อมให้ คือเส้นทางที่ดีที่สุดอันดับสองในการเข้าไปร่วม
- ผู้จัดการและผู้จัดการผลิตภัณฑ์มักเข้าประชุมที่วิศวกรไม่ได้เข้า จึงมักมองเห็นได้ดีกว่าว่ามีงานอิมแพกต์สูงอะไรเกิดขึ้นบ้าง
การไม่ทำอะไรเลย
- ถ้าต้องกันเวลาไว้สำหรับงานอิมแพกต์สูง และไม่ควรเอาแต่ปิด ticket อย่างเดียว งั้นในระดับนาทีต่อนาที คุณอาจไม่ต้องทำอะไรเลยจริง ๆ ก็ได้
- วิศวกรรมซอฟต์แวร์อาจเป็นอาชีพที่เครียดมาก แต่โดยทั่วไปไม่ใช่อาชีพที่เครียดสูงตลอดเวลา
- ความเครียดมักเกิดจากเหตุขัดข้องเป็นครั้งคราว งานเร่งด่วนที่กดดันสูง หรือสถานการณ์อย่างการเลย์ออฟล่าสุด
- หากปฏิบัติกับช่วงงานที่แรงกดดันค่อนข้างต่ำด้วยความเร่งด่วนระดับเดียวกับงานฉุกเฉิน พอถึงเวลาต้องรับมือสถานการณ์กดดันสูงจริง ๆ คุณก็จะเหนื่อยล้าและหงุดหงิดไปก่อนแล้ว
- แม้ในช่วงงานกดดันสูง ท่าทีแบบไม่ทำอะไรเลยก็ยังช่วยได้
- วิศวกรที่ไม่คุ้นกับ on-call ไม่ควรรีบร้อน ควรหยุดหายใจลึก ๆ สักสองสามครั้งก่อนเข้าคอลหรือก่อนพูด
- โดยรวมแล้ว การรับมือเหตุขัดข้องต้องอาศัย “การคิดอย่างชัดเจนด้วยการเคลื่อนไหวที่ช้าลง”
- เหตุขัดข้องส่วนใหญ่มักหายไปเอง และการรีบใส่การเปลี่ยนแปลงแบบ “เผื่อว่าจะช่วยได้” ระหว่างเกิดเหตุ มักทำให้สถานการณ์แย่ลงมากกว่าดีขึ้น
- โดยทั่วไป แค่ไม่ตื่นตระหนก คุณก็ทำการรับมือเหตุขัดข้องได้ดีกว่าวิศวกรส่วนใหญ่แล้ว
- เวลาที่ไม่ได้ทำอะไรคือพื้นที่ให้สิ่งต่าง ๆ เกิดขึ้นได้
- เมื่อสมองมีโอกาสพัก ก็มีโอกาสเกิดไอเดียใหม่มากขึ้น
- เมื่อได้รับงานสำคัญ ก็จะโฟกัสได้เต็มที่โดยไม่ต้องคอยทำอีกสามอย่างที่รันค้างอยู่เบื้องหลังพร้อมกัน
- เมื่อไม่ยุ่ง ก็จะมีเวลาแค่มองสิ่งต่าง ๆ และรับข้อมูลใหม่เข้าไป
การตั้งใจไม่ทำบางอย่าง
- วิศวกรจำนวนมากรู้สึกไม่สบายใจเมื่อเห็นงานที่ควรทำแต่กลับไม่ทำ
- นี่เป็นลักษณะทางจิตวิทยาที่วิศวกรซอฟต์แวร์จำนวนมากมีร่วมกัน และในระดับหนึ่งก็เป็นสิ่งที่ทำให้เหมาะกับงานนี้
- หากอยากสร้างเวลาว่างแบบไม่ทำอะไรเลย บางครั้งต้องบังคับตัวเองไม่ให้กระโดดเข้าไปช่วยโดยตั้งใจ
-
หลีกเลี่ยงงาน glue work
- โดยทั่วไปวิศวกรควรหลีกเลี่ยง glue work
- glue work หมายถึงงานอย่างการทำให้คนคุยกัน การอัปเดตเอกสารของงานที่ตัวเองไม่ได้เป็นผู้นำ หรือการจัดสรรทรัพยากรเพื่อแก้ technical debt
- glue work ส่วนใหญ่สะท้อนว่าองค์กรไม่ได้จัดให้งานนั้นมีความสำคัญอย่างชัดเจน
- ถ้าองค์กรให้ความสำคัญจริง บุคคลก็ไม่จำเป็นต้องอาสาเข้าไปทำเอง
- ถ้าเป็นเรื่องที่ไม่เป็นไรแม้องค์กรจะไม่ได้ให้ความสำคัญ การรับมาทำก็เป็นการเสียเวลา และอาจทำให้ผู้จัดการรำคาญได้
- แม้กรณีที่การที่องค์กรไม่ให้ความสำคัญจะเป็นความผิดพลาดร้ายแรง หากบุคคลเข้าไปทำแทน บริษัทก็จะไม่ได้รับผลของความผิดพลาดนั้น และคนที่จ่ายต้นทุนกลับเป็นอาชีพการงานกับสุขภาวะทางใจของตัวเอง
- นี่เป็นดีลที่ไม่ดีกับตัวเอง เป็นตัวอย่างที่ไม่ดีกับเพื่อนร่วมงานรุ่นน้อง และเป็นแบบอย่างที่ไม่ดีที่หลังจาก burnout แล้วจะมีคนใหม่เข้ามาอยู่ตำแหน่งเดิมอีก
- ถ้าผลลัพธ์มันร้ายแรงจริง ก็ควรปล่อยให้ผลนั้นเกิดขึ้นเพื่อให้องค์กรรู้สึกเจ็บและเปลี่ยนนโยบาย
-
การช่วยมากเกินไปทำให้เปราะบาง
- ความพยายามจะเป็นคนที่ช่วยเหลือมากเกินไปทำให้เปราะบางต่อคนที่อยากดึง แรงงานที่ไม่ได้รับผลตอบแทน ออกไปใช้
- ในบริษัทเทคโนโลยีมีคนจำนวนมากที่พยายามดึงงานจากวิศวกรซอฟต์แวร์โดยที่งานนั้นไม่ได้รับการตอบแทน
- มันต่างจากงานที่เข้ามาตามช่องทางปกติและได้รับผลตอบแทนผ่านการเลื่อนตำแหน่ง โบนัส หรือเงินเดือนตามปกติ
- งานที่มีปัญหามักเข้ามาทางช่องทางไม่เป็นทางการ และมาจากคนที่ไม่มีความสามารถหรือไม่มีความตั้งใจจะบันทึกงานนั้นไว้ภายใต้ชื่อของคุณอย่างเป็นทางการ
- ตัวอย่างเช่น ผู้จัดการผลิตภัณฑ์จากอีกองค์กรหนึ่งมาขอให้ช่วยดึงสถิติบางอย่างเพราะคุณ query ข้อมูลเก่ง
- หรือวิศวกรจากทีมอื่นขอ pair ทำงาน แต่จริง ๆ แล้วทำให้คุณเป็นคนเขียนโค้ดทั้งหมด ส่วนการเปลี่ยนแปลงกลับส่งในชื่อตัวเอง
- การทำงานแบบนี้บ้างเป็นครั้งคราวถือว่าไม่เป็นไร และถ้าช่วยคนได้ก็ช่วยได้เมื่อสะดวก
- แต่ก็ควรสามารถสร้าง แรงต้านกลับ ได้ด้วยการปฏิเสธ หรือการตอบช้าออกไปหลายชั่วโมงหรือหลายวัน
-
อย่าลงทุนกับงานที่มีโอกาสหายไปมากเกินไป
- ไม่ควรลงทุนมากเกินไปกับงานที่มีโอกาสจะหายไป
- ในสถานการณ์ที่ product designer กำลังปรับสิ่งที่ต้องการแบบเรียลไทม์ ไม่ควรเขียนหน้าใหม่ทั้งหมดทุกชั่วโมง
- ตัวอย่างเช่น ตอน 9 โมงเช้าอยากได้ page header แบบหนึ่ง 10 โมงแก้ใหม่ และ 11 โมงก็เปลี่ยนอีก
- ในกรณีแบบนี้ การออกไปเดินเล่นหรือไม่ทำอะไรไปก่อน แล้วค่อยกลับมาเขียนใหม่ทีเดียวในช่วงบ่ายตามดีไซน์ล่าสุด จะดีกว่า
- อีกกรณีที่พบบ่อยคือไอเดียใหญ่ของผู้จัดการที่ไม่มีแรงส่งทางการเมืองมากพอ
- บ่อยครั้งคุณแค่ปล่อยเวลาให้ผ่านไปจนโปรเจ็กต์ถูกยกเลิกได้
- แต่ถ้าประเมินระดับการสนับสนุนทางการเมืองของโปรเจ็กต์ผิด ก็อาจดูเหมือนเป็นคนขี้เกียจและต้องรีบเร่งส่งงานในภายหลัง
บทสรุป
- คำแนะนำและเครื่องมือด้านวิศวกรรมซอฟต์แวร์มักมุ่งไปที่ความสามารถในการขยายแรงทางเทคนิคให้ทำงานได้มากขึ้น รับโปรเจ็กต์ที่ใหญ่ขึ้น และเขียนโค้ดได้มากขึ้นพร้อมกัน
- ความสำเร็จในวิศวกรรมซอฟต์แวร์ไม่ได้ถูกตัดสินด้วยปัจจัยเหล่านั้น
- ความสำเร็จถูกตัดสินจากความสามารถในการทำ สิ่งที่ถูกต้อง ใน เวลาที่ถูกต้อง และเพื่อให้ทำแบบนั้นได้ คุณต้องตั้งใจเหลือแรงบางส่วนไว้จากงานประจำวัน
- การเป็นวิศวกรผลงานสูงด้วยแรงเพียง 80% เป็นไปได้ และจริง ๆ แล้วทำให้ลดความผิดพลาดโง่ ๆ จากความเครียด และกระโดดเข้าไปทำงานอิมแพกต์สูงที่สร้างผลตอบแทนก้อนใหญ่ได้ง่ายขึ้น
- ก็มีช่วงที่ต้องทุ่มเต็ม 100% เช่นกัน โดยปีหนึ่งอาจมีสักสองหรือสามครั้งที่ต้องทำงานยาว ใช้สมาธิหนัก และคิดเรื่องปัญหานั้นตลอดทั้งวัน
- ควรเก็บรูปแบบการทำงานแบบนั้นไว้ใช้ตอนที่ผลตอบแทนสูงมากจริง ๆ และช่วงเวลาที่เหลือก็ควรทำงานแบบมีช่องว่างพอสมควร
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เป็นบทความที่ดี แต่สุดท้ายปัญหาก็กลับมาที่เรื่อง แรงจูงใจ อีกอยู่ดี
การบอกว่าการหยุดยั้งหรือบรรเทาปัญหาได้ตั้งแต่เนิ่น ๆ สามารถประหยัดเงินก้อนใหญ่ได้นั้นก็จริง แต่สิ่งที่ฉันเห็นซ้ำแล้วซ้ำเล่าในหลายบริษัทคือ การป้องกันปัญหาไม่ค่อยได้รับการยอมรับ ขณะที่ถ้ากองเชื้อไฟไว้เต็มที่แล้วไปดับไฟที่เลี่ยงไม่ได้ ก็จะได้รับการยกย่องถึงสองรอบ แม้แต่ในองค์กรที่ “ดี” ก็เป็นแบบนั้น
ฉันไม่เคยอินกับการเมืองเชิง game theory ที่จงใจปล่อยโค้ดขยะออกไปเร็ว ๆ แล้วเก็บเครดิตเอาเอง เพราะฉันภูมิใจกับงานของตัวเองมากเกินไป
ฉันดูแลและพัฒนาฟramework มานานกว่า 5 ปีเพื่อกำจัดชุดปัญหาที่คอยหลอกหลอนผลิตภัณฑ์เวอร์ชันก่อนหน้า แต่ทีมพาร์ตเนอร์ที่ปล่อยโค้ดขยะจนเกิด incident แล้วค่อยแก้กลับได้รับคำชมในที่สาธารณะ ส่วนทีมของเรากลับไม่ได้เครดิตอะไรเลย เพราะเราไม่มี incident แบบนั้นให้เกิดขึ้น นั่นคือ การป้องกันที่วัดไม่ได้
Thread.sleep(100000)ไว้ทั่ว ๆ แล้วรอจนมันพังก็พอ จากนั้นคุณก็จะกลายเป็นคนที่ต่อสู้อย่างยาวนานและกล้าหาญเพื่อ ดับไฟ จนถึงเที่ยงคืนวันศุกร์หลังปล่อยรีลีสอย่าถามว่าทำไมถึงได้รางวัล และแน่นอนว่าบางครั้งองค์กรก็เปลี่ยนเกณฑ์การให้รางวัลไปเป็นอย่างอื่น
วิธีแบบซื่อตรงกว่าคือสร้างเครื่องมือที่ซับซ้อนแต่จำเป็นขึ้นมาสักสองสามอย่าง จนวิศวกรคนอื่นต้องกลับมาหาฉันเรื่อย ๆ คุณจะเก่งในการจับการใช้เครื่องมือบางอย่างผิดวิธี และถ้าชี้บั๊กในโค้ดคนอื่นได้ภายในไม่กี่วินาที คุณจะดูฉลาดกว่าความเป็นจริงมาก
ตามอุดมคติ เครื่องมือนั้นควรเชื่อถือได้ มีประโยชน์ แต่ก็ซับซ้อนพอที่นักพัฒนาคนอื่นใช้แล้วพอเจอบั๊กก็ต้องกลับมาหาคุณ และคุณก็จะชี้ให้เห็นความผิดพลาดของพวกเขาได้ กลยุทธ์นี้จะใช้ได้ก็ต่อเมื่อความผิดแทบจะอยู่ฝั่งตรงข้ามเสมอ และโค้ดของคุณต้อง แข็งแรงทนทาน
ถ้ามีการพบบั๊กจริง ๆ ในโค้ดของฉัน โดยเฉพาะเคสขอบเล็ก ๆ ฉันก็ควรอ่อนน้อมและขอโทษมาก ๆ และควรชื่นชมคนที่หาบั๊กซับซ้อนนั้นเจอในที่ประชุมทีม
มันดีกว่าวิธีสร้างเครดิตด้วยการแก้บั๊กในโค้ดเสียของตัวเอง วิธีนั้นอาจใช้ได้กับผู้จัดการหรือคนจูเนียร์ แต่ซีเนียร์คนอื่นจะไม่ชอบ
วิธีสร้างเครื่องมือที่ซับซ้อนแต่เสถียรจะทำให้คุณได้รับการยอมรับซ้ำแล้วซ้ำเล่า และบ่อยครั้งมากกว่าสองครั้งเสียอีก และการยอมรับจากนักพัฒนาคนอื่นสุดท้ายก็จะไปถึงหูผู้จัดการเอง ผู้นำที่ฉลาดจะรู้ว่าสัญญาณแบบนี้ดีกว่าเดโมหวือหวา
ผู้นำที่ชมใครสักคนเพียงเพราะสร้าง prototype ได้เร็ว สุดท้ายก็จะได้เรียนรู้จากความผิดพลาด ดูเหมือนผู้ก่อตั้งวัยหนุ่มสาวมักผ่านช่วงที่ชื่นชมสิ่งฉาบฉวยแบบนี้บ่อย ๆ
ส่วนหนึ่งของการสร้างผลิตภัณฑ์หรือชุดฟีเจอร์นั้นใกล้เคียงกับ การสำรวจ มากกว่าวิศวกรรมที่ยอดเยี่ยม บางครั้งแทนที่จะสร้างฟีเจอร์เดียวที่แข็งแรงมาก การสร้างฟีเจอร์ที่ดีพอ 2 อย่างเพื่อหาว่าอะไรมีคุณค่าต่อผู้ใช้มากกว่าก็อาจดีกว่า
ฉันเป็นคนสาย “ลองทำก่อนแล้วค่อยรู้” มาตลอด แต่ก็ขอบคุณที่มีคนทัศนคติต่างจากฉันสร้าง git ขึ้นมา
มันมีเรื่องของสมดุล และขึ้นอยู่กับว่าปัญหาที่กำลังจัดการอยู่นั้นเป็นปัญหาเชิงสำรวจมากแค่ไหน โดยคำว่า “แข็งแรง” ในที่นี้หมายถึงความพร้อมใช้งาน การดูแลรักษาได้ และความเป็นไปได้ที่รูปภาพอ่อนไหวของผู้ใช้อาจรั่วไหล ในมุมมองวิศวกรรมล้วน ๆ
ส่วนที่พูดถึง “คนที่พยายามรีดเอางานที่ไม่มีรางวัลตอบแทน” นั้น เหมาะจะเอาไปใส่กรอบแขวนไว้
โดยเฉพาะสถานการณ์ที่ผู้จัดการผลิตภัณฑ์จากอีกองค์กรพูดว่า “คุณเก่งเรื่อง data query ช่วยดึงสถิติของ X ให้หน่อยได้ไหม?” หรือวิศวกรจากอีกทีมขอ “pair” แต่สุดท้ายฉันกลับเป็นคนเขียนโค้ดทั้งหมด แล้วเขาก็ส่งการเปลี่ยนแปลงในชื่อของตัวเองแบบเงียบ ๆ
กลยุทธ์ของเขาคือช่วยเหลือผู้คนและส่งต่อเครดิตให้อย่างจริงจัง เขาคอยเน้นย้ำคุณค่าของงานของสมาชิกทีมอย่างสม่ำเสมอ ทั้งในการคุย 1:1 และในการประชุมที่มีผู้จัดการหลายชั้นอยู่ด้วย จนได้รับความชื่นชอบจากทีม
หลายปีต่อมา เมื่อโปรเจกต์ที่มีเงินก้อนใหญ่เป็นเดิมพันเริ่มหลุดกำหนด และวิศวกรหลักหลายคนลาออก เขาก็ทำงานล่วงเวลาเพื่อนำโปรเจกต์นั้นไปสู่ความสำเร็จ และในการประเมินรอบถัดไปก็ได้ทั้งตำแหน่งและขึ้นเงินเดือน
แม้โปรเจกต์นั้นจะเป็นแรงส่งครั้งสุดท้ายก็จริง แต่คนที่ทำโอทีไม่ได้มีแค่เขาคนเดียว เขามองว่าการเลื่อนตำแหน่งของตัวเองเกิดจาก ไมตรีจิตที่สะสมไว้ด้วยการยกเครดิตให้ผู้อื่น ตลอดช่วงเวลาที่ทำงานอยู่
ไม่ว่าจะอยู่ใน job description หรือไม่ ฉันอยากทำงานกับคนที่มองเห็นปัญหาแล้วเสนอทางแก้
ถ้างานของฉันไม่ได้รับการยอมรับ นั่นคือ ปัญหาด้านภาวะผู้นำ วิธีตอบแบบตัดบทปฏิเสธงานดูเหมือนเป็นเส้นทางไปสู่วัฒนธรรมองค์กรที่แข็งทื่อและเชื่องช้า
เช่นกัน สักวันหนึ่งฉันเองก็อาจต้องการอะไรบางอย่างจากเพื่อนร่วมงาน และถ้าเขาช่วยอย่างกระตือรือร้นก็คงน่าขอบคุณมากกว่าถูกไล่ให้ไป “เข้าตามช่องทางปกติ” ซึ่งอาจใช้เวลานานกว่ามาก
บทสนทนาตอนมื้อกลางวันก็เป็นแบบที่ช่วยให้ผู้คนเข้าใจบางอย่างได้
แต่ถ้าต้องไปทำงานหลายชั่วโมงให้ใครบางคน นั่นก็อาจเป็นอีกเรื่องหนึ่ง
ไม่ได้จะประชด แต่เป็นการสังเกตมากกว่า: ในองค์กรที่ใหญ่พอหรือมีระบบราชการมากพอ ต่อให้ป้องกันปัญหาไว้ล่วงหน้า ก็มักได้เครดิตหรือการมองเห็นน้อยมาก ความสำเร็จแบบนั้นมักถูกนับว่าเป็น “งานที่ควรต้องทำอยู่แล้ว”
เพราะงั้นคนที่เก่งเรื่องการเมืองในองค์กรจึงเลือกปล่อยให้ปัญหาเกิดขึ้น แล้วค่อยขยับตัวอย่างเอิกเกริกในรายการติดตามแก้ไขแทน เคล็ดลับคืออย่าปล่อยให้เหตุการณ์ลุกลามเป็น หายนะ ซึ่งเป็นงานที่ละเอียดอ่อนพอสมควร
ถ้าช่วยกู้สัญญาการขายไว้ได้ คนที่ได้เสียงปรบมือก็คือทีมขาย และค่านายหน้าก็เป็นของพวกเขา ผมไม่ได้ส่วนแบ่งจากสิ่งนั้นเลย
แต่ถ้าปล่อยให้บางอย่างไหม้ไปบ้าง เจ้านายของเจ้านายของเจ้านายจะเห็นไฟนั้น และอาจเกิดการปรับปรุงขึ้นก็ได้ บางทีนี่อาจเป็นวิธีสื่อสารกับคนพวกนั้นที่ง่ายที่สุด
ผมเคยเขียนอะไรในทิศทางนี้ค้างไว้ครึ่ง ๆ กลาง ๆ มาก่อน โดยใช้เปรียบเทียบกับเกม RPG แฟนตาซี ถ้าคุณเล่นตัวละครที่ใช้มานา ในเกมแบบนี้คุณจะเรียนรู้เร็วมากว่าถ้าเผามานาจนหมดกับการสู้จุกจิกทุกครั้ง แล้วเดินไปมาแบบถังว่าง สุดท้ายพอถึงเวลาที่ต้องใช้จริงก็จะไม่เหลืออะไรเลย
พลังงานทางใจกับการทำงานก็ไม่ได้ต่างกันมากนัก ถ้าเก็บไว้ในถังสักหน่อย เวลามีเรื่องไม่คาดคิดเกิดขึ้น คุณก็จะใช้มันอย่างมีกลยุทธ์ได้ โดยไม่เอาสุขภาพหรือ ภาวะหมดไฟ ไปเสี่ยง
และถ้าเคยเข้าปาร์ตี้กับผู้เล่นที่บริหารมานาไม่เป็นในเกมแบบนี้ คุณก็จะรู้ด้วยว่าคนแบบนั้นไม่ใช่เพื่อนร่วมทีมที่ดีนัก
ไม่ว่าจะเป็นด้านไหน ช่วงที่ความสามารถของผมอยู่จุดสูงสุดคือช่วงที่มีงานรออยู่ข้างหน้ามากพอให้ผมไหลไปกับมันได้อย่างสม่ำเสมอเหมือนเครื่องจักร และได้รับความไว้วางใจมากพอให้ทำงานมุ่งสู่เป้าหมายโดยไม่ถูกรบกวน ไม่ต้องหยุดมาคอยอธิบายตลอดเวลา ทักษะเพิ่มขึ้นเหมือนไฟลามทุ่ง และงานก็เสร็จเร็วกว่าที่คาด
น่าเสียดายที่ที่ทำงานที่ใช้โครงสร้างแบบนั้นมีน้อยมาก มีสิ่งกีดขวางและการรบกวนมากเกินไปจนเข้า งานเชิงลึก จริง ๆ ไม่ได้
ถ้าอยากทำให้ระบบพัง ก็แค่เดินเครื่องตามมาตรฐานที่ 100% ก็พอ ไม่มีพื้นที่เผื่อ และไม่มีความจุเหลือไว้รองรับความต้องการใหม่ ๆ ดังนั้นแค่มีความปั่นป่วนเล็กน้อย ระบบก็จะเข้าสู่โหมดล้มเหลวถาวร
ปัญหาของบทความแบบนี้หรือหนังสืออย่าง Peopleware / Slack คือมันไม่ได้เสนอ ตัวชี้วัดจริง ที่โน้มน้าวฝ่ายบัญชีได้มากพอให้ลองแนวทางอื่น
อุปมาที่เปลี่ยนมุมมองผมมาจาก “The Power of Full Engagement” ประมาณว่า “คุณกำลังทำตัวเหมือน นักกีฬาความอึดระดับโลก ที่ไม่มีช่วงนอกฤดูกาล เลิกทำแบบนั้นเถอะ”
ตรงนี้มีปัญญาอยู่มาก นอกจากการเหลือความจุไว้บางส่วนสำหรับเวลาที่งานมูลค่าสูงจริง ๆ เข้ามาแล้ว ผมยังคิดว่าวิศวกรรมซอฟต์แวร์ไม่ใช่งานที่ทำได้ดีด้วยการยุ่งตลอดเวลาอย่างเดียว
ถ้าพยายามเขียนโค้ดให้เร็วที่สุด ก็น้อยครั้งที่จะได้การออกแบบที่ดี และบทความนี้ก็ไม่ได้พูดถึงอีกมุมสำคัญ คือจะทำงานที่ 80% ของความจุ โดยไม่โดนผู้จัดการตำหนิได้อย่างไร
เรื่องนี้ต้องอาศัยความใส่ใจด้านการสื่อสารและการประเมินงานเล็กน้อย หนึ่งในคำแนะนำที่ดีที่สุดที่ผมได้รับจากนักพัฒนารุ่นพี่ที่ชำนาญในงานโปรแกรมมิงงานแรกของผมยังจำได้ถึงทุกวันนี้ คือหลังจากประเมินแล้วว่างานหนึ่งจะใช้เวลานานแค่ไหน ให้คูณสองก่อนจะไปบอกผู้จัดการหรือผู้ใช้
เมื่อมีประสบการณ์มากขึ้น สัดส่วนนั้นอาจลดจาก 2 เท่าเหลือราว 1.5 เท่าได้ แต่หลักการยังใช้ได้เหมือนเดิม
สิ่งที่ควรปรับให้เหมาะสมและยกเป็นแบบอย่าง คือการส่งมอบอย่างสม่ำเสมอในระยะยาว ด้วย ความเร็วที่ยั่งยืน มันเป็นเกมยาว และการรับปากเกินไปมีแต่จะกัดกร่อนความน่าเชื่อถือ ซึ่งความน่าเชื่อถือนั่นแหละคือเครื่องมือสำคัญที่สุดที่ทำให้นักพัฒนาได้พื้นที่ที่ต้องการ
ต้องรับปากให้น้อย สร้างความเชื่อมั่นว่าพูดแล้วทำได้ และได้พื้นที่สำหรับไม่ให้ตัวเองหมดไฟ
ยิ่งเป็นระดับซีเนียร์ โดยเฉพาะถ้าเป็นลีด การ ตั้งขอบเขต การรักษาความใส่ใจ และการป้องกันภาวะหมดไฟ ก็กลายเป็นส่วนหนึ่งของงาน เพราะมีวิธีทำตัวเองพังได้มากเหลือเกิน
แม้จะคำนึงถึงกฎของ Hofstadter แล้ว งานก็มักใช้เวลานานกว่าที่คาดเสมอ
https://en.wikipedia.org/wiki/Hofstadter%27s_law
จากมุมของคนที่ทำงานใกล้ชิดกับลูกค้ามาเยอะ กับดักที่แย่ที่สุดที่เจอซ้ำแล้วซ้ำอีกคือการสนิทกับลูกค้าที่จ่ายเงินให้เรา ในฐานะคนที่ถูกจ้างมาเป็นผู้เชี่ยวชาญเพื่อช่วยเหลือ ถ้าลูกค้าเป็นคนดีจริง ๆ การปฏิเสธจะยากแบบสุด ๆ
ที่แย่กว่านั้นคือเวลาคนนั้นไม่ใช่ผู้มีอำนาจตัดสินใจ แต่เป็นฝ่ายที่ถูกบีบให้มาผลักอะไรบางอย่างใส่เรา ในฐานะผู้เชี่ยวชาญที่ลูกค้าเชื่อถือ ถ้าลูกค้าเองเสนอไอเดียแย่ ๆ มา การปฏิเสธยังทำได้ง่ายกว่า แต่ถ้าเป็นคำสั่งจากเจ้านายของเขาที่ผมไม่เคยคุยด้วยโดยตรงเลย ผมก็จะตกอยู่ในจุดที่ดูเหมือนต้นทุนไร้ประโยชน์ หรือไม่ก็กลายเป็น คนคอยรับคำสั่งว่าใช่ ที่ทิ้งสัตว์ประหลาดเอาไว้เบื้องหลัง
บางทีก็อิจฉาคนที่ทำงานภายในองค์กรมาตลอด อย่างน้อยพวกเขายังพอมีโอกาสโน้มน้าวใครสักคนที่อยู่สูงขึ้นไปได้
ประเด็นเรื่อง งานกาว น่าสนใจ ตอนทำงานในบริษัทใหญ่นี่เป็นส่วนที่ถูกระบุไว้อย่างชัดเจนในประเมินผลงานประจำปี Google เรียกสิ่งนี้ว่า “citizenship” และผมคิดว่าเป็นคำที่จับแก่นได้ดี คือ “คุณทำอะไรให้ดีขึ้นเพื่อคนอื่น ๆ ในบริษัท”
ในแง่หนึ่งมันก็ดูแปลก ๆ เพราะมันไม่ได้อยู่ในคำบรรยายงานของผม ดังนั้นในทางเทคนิคมันคือ งานที่ไม่ได้รับค่าตอบแทน แต่ขณะเดียวกันก็เป็นส่วนหนึ่งของความคาดหวังอย่างเป็นทางการด้วย อีกแง่หนึ่ง การได้ทำงานในที่ที่ทุกคนลงเวลาและแรงกันคนละนิดเพื่อทำให้สภาพแวดล้อมดีขึ้นสำหรับทุกคนก็เป็นเรื่องที่ดี
การทำให้สิ่งนี้เป็นข้อกำหนดที่ชัดเจนสำหรับทุกคน ยังเป็นความพยายามหลีกเลี่ยงวัฒนธรรมเป็นพิษแบบ “ฉันเป็นวิศวกรระดับร็อกสตาร์ ยุ่งกับงานสำคัญอยู่ งานกาวให้คนอื่นทำไป” ด้วย แถม “คนอื่น” คนนั้นก็มักจะเป็นผู้หญิง และแทบจะแน่นอนว่าได้เงินน้อยกว่าวิศวกรระดับร็อกสตาร์คนนั้น
ต้นฉบับให้ความหมายเหมือนบริษัทควรจ้างคนมาทำงานกาวอย่างเป็นทางการ แต่ในความเป็นจริงมันประกอบด้วยชิ้นส่วนที่หลากหลายเกินไป จนแทบเป็นไปไม่ได้ที่จะจ้างคนคนเดียวมารับผิดชอบทั้งหมด ตัวอย่างเช่น จะมีตำแหน่งงานอะไรที่ครอบคลุมทั้ง “การเขียนเอกสาร, การสัมภาษณ์วิศวกรซอฟต์แวร์, การจัดกิจกรรมนอกสถานที่ของทีม”
แต่งานพวกนี้ล้วนจำเป็น และข้อกำหนดเรื่อง citizenship ก็ช่วยให้แบ่งภาระได้อย่างยุติธรรมมากขึ้น
ผมคิดว่าคำพูดที่ดีกว่าไม่ใช่ “อย่าทำงานกาว” แต่เป็น “อย่าเป็นคนซวยคนเดียวที่ทำงานกาวแบบไม่ได้ผลตอบแทน” หมายความว่าทุกคนควรรับไปบางส่วน และผลักดันวัฒนธรรมที่สิ่งเหล่านี้ ถูกนับว่าเป็นงานอย่างเป็นทางการ
การทำงานแบบ ใช้กำลังการทำงาน 80% เป็นนิสัยที่ดี และจะยิ่งช่วยได้เมื่อไม่มีผู้จัดการสายจ้องคุมที่คาดหวังให้คุณทำงานเต็ม 100% ตลอดทั้งวันทุกวัน คนแบบนั้นมักเข้าใจผิดว่าเวลาที่วิศวกรซอฟต์แวร์นั่งคิดเงียบ ๆ อย่างสบายใจคือความขี้เกียจและการไม่ทำอะไรเลย
เพราะงั้นการทำงานทางไกลจึงเป็นวิธีที่ดีที่สุดในการเผื่อกำลังการทำงานไว้บางส่วนและปกป้องสุขภาพจิต
งานกาวเล็กน้อยสามารถทำให้ชีวิตการทำงานของทุกคนดีขึ้นมาก และถ้าไม่มีใครรู้วิธีทำ มันก็อาจทำให้ผมกลายเป็นคนสำคัญหรือฮีโร่ของทีมได้
เมื่อคิดถึงวิธีที่ผมต้องดิ้นรนกับการเรียนรู้ การคิด และการเริ่มต้นลงมือทำ 80% ของผมก็ไม่เหมือน 80% ของเพื่อนร่วมงานที่เก่งทางเทคนิคมากกว่าเลยแม้แต่น้อย
ถ้าคำนึงถึงแนวโน้มด้านความหลากหลายทางระบบประสาทแม้เพียงเล็กน้อย 80 ของคนหนึ่งอาจเป็น 120 ของอีกคนก็ได้