- ตอนนี้ฉันกลายเป็น Engineering Manager แล้ว แต่สมัยที่ยังทำงานเป็น Software Engineer ฉันเคยใช้เวลาหลายวันทำฟีเจอร์ที่ซับซ้อนแล้วเปิด PR
- ฟีดแบ็กนั้นเด็ดขาดและเย็นชา: “มันคือ over-engineering ซับซ้อนเกินไป รีแฟกเตอร์ใหม่” มีเพียงประโยคสั้น ๆ เท่านั้น
- ฉันโกรธที่ได้รับแต่คำวิจารณ์โดยไม่มีคำชมสักคำ แต่เรื่องราวกับผู้จัดการคนนั้นเป็นเพียงจุดเริ่มต้นเท่านั้น
สไตล์ผู้นำที่ไม่เอาใจใส่ความรู้สึก
- ผู้จัดการคนนี้แตกต่างจากผู้นำที่ฉันเคยรู้จัก
- เขาไม่ได้คอยประคองหรือพูดจานุ่มนวล
- เขามีลักษณะดังนี้
- ปฏิเสธไอเดียที่ยังไม่ตกผลึกทันที
- ไม่ชอบความซับซ้อนที่มีไว้เพื่อความซับซ้อน
- ให้ความสำคัญเฉพาะโค้ดที่สะอาด มีประสิทธิภาพ และดูแลรักษาได้
- แม้แต่ในการรีโทรสเปกทีฟ เขาก็ไม่อ้อมค้อมและชี้ปัญหาตรง ๆ
- ตอนแรกฉันคิดว่าเขาเป็นคนเย็นชาไร้ความปรานี แต่เบื้องหลังนั้นมีปรัชญาอีกแบบหนึ่ง
จุดเปลี่ยนของฟีดแบ็กที่สั่นคลอนความมั่นใจ
- ใน Sprint Review ฉันเดโมฟีเจอร์ที่มั่นใจมาก แต่ผู้จัดการกลับขัดขึ้นมากลางคันและถามว่า
> “สิ่งนี้เปราะบางเกินไป แล้วถ้าอยู่ภายใต้โหลดหนักจะเป็นอย่างไร? มีแผน rollback ไหม?”
- เมื่อฉันตอบไม่ได้ดีนัก ผู้จัดการจึงพูดว่า
> “ตอนนี้คุณกำลังคิดแบบ coder คุณต้องคิดแบบ engineer”
- ตอนแรกฉันโกรธ แต่สุดท้ายก็เริ่มตระหนักว่าสไตล์การเขียนโค้ดของตัวเองเน้นความฉลาดแพรวพราวมากกว่าความยืดหยุ่นทนทาน
บทเรียนที่แท้จริง: ผู้จัดการคนนั้นไม่ได้โจมตีฉันเป็นการส่วนตัว
- วิธีคิดของฉันเปลี่ยนไปอย่างมาก
- แทนที่จะเขียนโค้ดที่ “ดูฉลาด” ก็หันมาเขียน โค้ดที่อ่านง่าย
- โฟกัสที่ การออกแบบเพื่อรองรับสถานการณ์ล้มเหลว
- เขียนโค้ดไม่ใช่เพื่อตัวเอง แต่เป็น โค้ดสำหรับนักพัฒนาที่จะมารับช่วงต่อ
- หลังจากนั้น code review จากผู้จัดการคนนั้นก็ผ่านฉลุย
- ไม่ใช่เพราะผู้จัดการเปลี่ยนไป แต่เพราะตัวฉันเองเติบโตขึ้น
อิทธิพลที่ทิ้งไว้ต่อสไตล์การเป็นผู้นำของฉัน
- หลังจากได้เป็น Engineering Manager ฉันนึกถึงประสบการณ์นั้นบ่อยมาก
- ฉันไม่อยากเป็นผู้นำที่ใคร ๆ ไม่ชอบ แต่ก็ไม่อยากเป็นผู้นำที่มีแต่ความอ่อนโยนเช่นกัน
- ฉันจึงสร้างสไตล์ของตัวเองด้วยวิธีต่อไปนี้
- ให้ ฟีดแบ็กตรงไปตรงมาพร้อมคำอธิบายเบื้องหลัง
- เน้น การคิดเชิงระบบ
- รักษามาตรฐานที่สูงไว้ แต่ก็ให้ ฟีดแบ็กที่ยังคงความเป็นมนุษย์
- วิศวกรอยากถูกท้าทาย แต่ไม่ชอบความรู้สึกเหมือนถูกมองข้ามหรือไม่ให้เกียรติ
เมื่อคุณต้องการผู้จัดการที่เด็ดขาด
- ภาวะผู้นำเต็มไปด้วยเรื่องของอัตตา เดดไลน์ และแรงกดดัน จึงทำให้สับสนได้ง่าย
- ผู้จัดการที่เด็ดขาดจะช่วยปัดเป่าความสับสนนั้นด้วยการทำให้คุณ
- คิดเรื่องการขยายระบบ ไม่ใช่แค่ฟีเจอร์
- เขียนโค้ดที่ดูแลรักษาได้ แทนโค้ดที่แค่ดูฉลาด
- เตรียมพร้อมล่วงหน้าสำหรับความล้มเหลวและกรณียกเว้น
- เขาให้ความสำคัญกับโอกาสรอดของโค้ดมากกว่าความรู้สึก
วิธีอยู่รอดและเติบโตภายใต้ผู้จัดการที่เข้มงวด
- หากคุณอยู่ใต้ผู้นำที่ทำให้อึดอัดจนแทบหายใจไม่ออก ลองรับมือดังนี้
- อย่ารับมันเป็นการโจมตีส่วนตัว: ฟีดแบ็กนั้นพูดถึงโค้ด
- หลังได้รับฟีดแบ็ก ให้ถามว่า “ทำไม?”: โดยมากผู้นำที่เด็ดขาดมักให้คุณค่ากับความอยากรู้อยากเห็น
- ลองคิดถึงจุดล้มเหลวด้วยตัวเองก่อน: คุณต้องเริ่มคิดแบบผู้จัดการ
- ถ้าคุณเป็นผู้นำ ควรทำสิ่งต่อไปนี้
- ตั้งมาตรฐานให้สูง แต่ต้องอธิบายด้วยว่าทำไมมาตรฐานนั้นจึงสำคัญ
- พูดให้ชัดเจนแทนการให้ฟีดแบ็กที่คลุมเครือ
- ฉลองการเติบโตมากกว่าความสำเร็จ: ถ้านักพัฒนามองเห็นปัญหาได้ก่อนผู้จัดการ ก็ควรชมเชย
ของขวัญที่ดีที่สุดจาก Pull Request ที่ถูกปฏิเสธ
- ตอนแรกมันทำร้ายความมั่นใจของฉัน แต่เมื่อมองย้อนกลับไป PR ที่ถูกปฏิเสธครั้งนั้นคือโอกาสที่ดีที่สุดในชีวิต
- มันเป็นจุดเปลี่ยนที่ทำให้ฉันมองการเขียนโค้ดไม่ใช่เป็นโปรเจกต์ส่วนตัว แต่เป็น การสร้างระบบ
- ผู้จัดการที่เด็ดขาดอาจไม่ได้ทำให้คุณรู้สึกดี แต่เขาทำให้คุณ เติบโตในฐานะนักพัฒนา
- การเติบโตที่แท้จริงไม่ได้เริ่มตอน PR ผ่าน แต่เริ่มตอนที่มัน ถูกปฏิเสธ
22 ความคิดเห็น
ถ้ามีผู้จัดการสองแบบ ระหว่างผู้จัดการที่พูดตรง ๆ โดยไม่ใส่ใจความรู้สึก กับผู้จัดการที่รักษาความสัมพันธ์และอ่อนโยน ผู้จัดการแบบไหนกันแน่ที่จะสามารถผลักดันการเติบโตของสมาชิกทีมผ่านฟีดแบ็กได้? ตอนอ่านบทความก่อนหน้านี้ ผมเกิดคำถามแบบนี้ขึ้นมา
ผมคิดว่ามันเป็นเกมของความน่าจะเป็นนะครับ คนที่ฝ่าความน่าจะเป็นอันโหดร้ายแล้วเติบโตขึ้นมาได้มีอยู่ทุกที่ ผู้จัดการควรตัดคนแบบนั้นออกไปก่อน แล้วพยายามเพิ่มความน่าจะเป็นโดยรวมให้สูงขึ้น ผมคิดว่าผู้จัดการที่เชื่อและลงมือทำในแบบที่ตัวเองเห็นว่าเป็นท่าทีซึ่งช่วยเพิ่มความน่าจะเป็นนั้น สมควรได้รับความเคารพ อย่างน้อยขอแค่อย่าเป็นการคงวิธีเดิม ๆ ที่ทำมาตลอดเพียงเพราะคิดว่าแค่นั้นก็พอแล้ว
ฉันคิดว่าฟีดแบ็กประเภทนี้อาจทำให้รู้สึกไม่ดีหรือถึงขั้นโกรธได้ ขึ้นอยู่กับนิสัย พื้นเพทางวัฒนธรรม และความแตกต่างของแต่ละคนเมื่อได้ยินมัน แต่โดยพื้นฐานแล้ว การเข้าหามันด้วยความคิดว่า "คนนี้ไม่ได้ตั้งใจจะแกล้งฉัน" น่าจะดีกว่าทั้งในแง่สุขภาพใจและในมุมของการเติบโต เมื่อเจอสถานการณ์แบบนั้น ก็น่าจะลองนึกถึงบทความนี้แล้วคิดว่า "หรือบางทีผู้จัดการคนนี้ก็...?" ได้เหมือนกัน เป็นบทความที่ดีนะครับ
หลายคนพูดถึงคำว่า kind and direct แต่จริง ๆ แล้วการเป็นคนที่ direct นั้นยากกว่าการเป็นคนที่ kind มาก
ผู้นำที่ไม่สามารถถ่ายทอดบริบทที่ผู้ตามต้องใช้ในการทำตามได้ ถึงจะไม่ได้ให้บริบททั้งหมด ก็ไม่มีคุณค่า
ดูเหมือนเป็นบทความที่เขียนโดยผู้ตามที่ยอดเยี่ยม ซึ่งยกความดีความชอบเรื่องความสามารถอันโดดเด่นของตัวเองให้คนอื่น
ถ้าผู้นำไม่ถ่ายทอดบริบทให้ ผู้นำคนนั้นก็ไม่ได้จำเป็นอะไรนัก
ต้องรีบเปลี่ยนตัวโดยด่วน
คำพูดที่ฟังดูดี ไม่ได้แปลว่าเป็นคำพูดที่ดีเสมอไป ผมเองก็คิดว่าการรีวิวโค้ดที่มีอยู่แค่สองคำว่า "Nasty Code" คือสิ่งที่ช่วยผมได้มากที่สุดในชีวิต
ไม่ใช่นักพัฒนาทุกคนจะเหมือนกันหมด
ฉันลองคิดดูว่า "การคิดเชิงระบบ" คืออะไร แต่ในบริบทของบทความนี้ รู้สึกว่ามันคือ
การคิดจากมุมมองการทำงานของแอปพลิเคชันนะครับ/ค่ะ แต่ก็คิดว่าเป็นมุมมองที่สำคัญมากจริง ๆ
เห็นแล้วอินมาก เพราะพอปล่อยให้ทุกอย่างผ่านไปแบบประนีประนอม สุดท้าย codebase ก็เละเทะจริง ๆ ความสำคัญของความสามารถของผู้จัดการนี่ใหญ่มากจริง ๆ
เห็นด้วยค่ะ
นัยของบทความนี้ดูเหมือนจะให้ความรู้สึกว่า ไม่ได้เป็นเพราะผู้จัดการคนนั้นยอดเยี่ยมอะไรนัก แต่เป็นเพราะตัวผู้เขียนเองทำได้ดีมากกว่า (ผู้เขียนอาจจะเป็นคนประเภทที่เติบโตได้ไม่ว่าจะได้รับฟีดแบ็กแบบไหนหรือเปล่า)
ผมจำได้ว่าเคยเห็นงานวิจัยที่บอกว่า เมื่อได้รับฟีดแบ็กเชิงลบที่ (ขาดบริบท) มีโอกาสสูงที่พฤติกรรมจะเปลี่ยนไปในทิศทางตรงข้ามกับความคาดหวัง
เราต้องตระหนักว่าฟีดแบ็กต่องานไม่ใช่การโจมตีตัวบุคคล
ถ้าผู้จัดการเป็นคนที่ดีกว่านี้ก็คงจะดีกว่า แต่บริษัทไม่ใช่โรงเรียน... และเพราะเราเป็นมืออาชีพ... เราจึงต้องเรียนรู้ที่จะรับมือกับฟีดแบ็กด้วยตัวเอง
เรายังต้องมีความกล้าที่จะพูดด้วยว่าไม่รู้เมื่อเราไม่รู้
ดูเหมือนว่าคุณจะมีมุมมองที่ค่อนข้างต่างจากผมครับ ไม่แน่ใจว่าเป็นเพราะประสบการณ์การทำงานของผมยังน้อยหรือเปล่า แต่ที่ผ่านมา ผมเห็นมาบ่อยว่าฟีดแบ็กที่ไม่ชัดเจนหรือใช้คำอ้างอิงกำกวมกลับให้ผลเสียมากกว่า...
การสะกดคำผิดครับ
"ต้องตระหนักว่านี่ไม่ใช่การตำหนิ" -e ควรเขียนว่า "ต้องตระหนักว่านี่ไม่ใช่การตำหนิ" ครับ
คุณคงทราบว่าไม่ใช่การตำหนิเป็นการส่วนตัว แต่ผมคิดว่าพอเห็นคำทักท้วงของผม คุณก็น่าจะรู้สึกไม่พอใจขึ้นมาทันที ใครบางคนอาจบอกว่าเป็นเรื่องเดียวกันไม่ว่าจะพูดแบบไหน แต่ดูเหมือนว่ามนุษย์เราจะรับคำว่า chosammosa กับ chosamosam ต่างกันจริง ๆ นะครับ
ps. ตอนแรกผมเองก็ไม่รู้เหมือนกันว่าคุณสะกดผิด แต่เพราะอยากหา例อย่าง เลยเอาไปใส่ในตัวตรวจการสะกดคำ แล้วถึงได้เจอว่าคุณเขียนผิดครับ
ถ้ามีคนช่วยแก้คำสะกดผิดให้ ก็แค่ตอบว่าขอบคุณ ไม่เคยรู้มาก่อน ก็น่าจะแก้ปัญหาได้ ไม่น่าใช่เรื่องที่จะต้องโกรธกัน ผมคิดว่าการเชื่อว่าสิ่งที่ตัวเองรู้สึก คนอื่นก็จะรู้สึกเหมือนกัน เป็นการเหมารวมที่อันตราย แล้วก็ไม่ใช่ "การยอมรับ" แต่เป็น "การรับเข้าไว้" ครับ
ฉันคิดว่าความเป็นมืออาชีพคือการสามารถจัดการแม้แต่เรื่องงานที่ทำให้เครียดได้
ฉันไม่ได้พยายามทำให้การทำให้คนเครียดเป็นเรื่องที่ชอบธรรม เมื่อทำงานอย่างมืออาชีพก็คงมีเรื่องที่ทำให้โกรธเกิดขึ้นได้ แต่ฉันคิดว่าการรับมือกับมันอย่างชาญฉลาดนั่นแหละคือความเป็นมืออาชีพ
ฉันไม่ใช่ผู้เชี่ยวชาญด้านการสะกดหรอกนะ แล้วคอมมิวก็ไม่ใช่บริษัทด้วย
เห็นด้วยกับคอมเมนต์นี้มากครับ/ค่ะ ผม/ดิฉันคิดว่านั่นเป็นเพราะทั้งความสามารถและทัศนคติของผู้รับนั้นยอดเยี่ยม ผู้จัดการคนนั้นมีปรัชญาที่ชัดเจน แต่ผม/ดิฉันคิดว่าเขาไม่รู้วิธีเข้าหาทีดีพอที่จะถ่ายทอดปรัชญาของตัวเองไปสู่ทีม
น่าจะเป็นแบบนี้แหละมั้ง ต่อให้โยนมาแบบมั่ว ๆ ก็ยังรับไปต่อได้อย่างลงตัว... 555
เป็นบทความที่ดีมากจริงๆ ดูเหมือนว่าจะต้องกลับมาอ่านเรื่อยๆ ทั้งก่อนส่ง PR และหลังส่ง PR ครับ
ดูเหมือนว่าการสร้างความคุ้นเคยและความไว้วางใจกันไว้ให้ดีเป็นสิ่งสำคัญ เพื่อไม่ให้กลายเป็นการโจมตีส่วนบุคคล (โดยเฉพาะในบริบทของสังคมเกาหลี)
โดยส่วนตัวแล้วผมระวังการใช้ประธานในประโยคครับ สิ่งที่เป็น overengineering คือ "โค้ดนี้" ไม่ใช่ว่า "อีกฝ่าย" เป็นคนทำผิด
ทำให้นึกถึงบทความ ในหัวของผู้เชี่ยวชาญกำลังเกิดอะไรขึ้นกันแน่ เลยครับ ตอนที่ได้รับรีวิวอย่าง “นี่คือการ over-engineering ซับซ้อนเกินไป รีแฟกเตอร์ซะ”, “อันนี้มีช่องโหว่ ภายใต้โหลดหนักจะเป็นยังไง? มีแผน rollback ไหม?” ก็น่าจะดีถ้าได้ถามต่อว่าทำไมเขาถึงคิดแบบนั้น คาดการณ์ปัญหาอะไรไว้ และมองแนวทางการปรับปรุงไปทางไหน (ไม่ใช่ว่าผู้เขียนไม่ได้ทำแบบนั้นนะครับ แต่พอเจอสถานการณ์แบบนี้ก็เลยคิดว่าถ้าทำอย่างไรจะได้ประโยชน์จากมันมากขึ้น)
บทความดีมากจริงๆ..