ประสบการณ์นักพัฒนาที่ดี

Good Developer Experience

• TL;DR
  อย่าลืมทำให้นักพัฒนามีความสุข และรักษาความสุขนั้นไว้

# ประสบการณ์นักพัฒนาที่ดี (Developer Experience, DX) คืออะไร

ประสบการณ์นักพัฒนาคือประสบการณ์ที่นักพัฒนาได้รับระหว่างการใช้งานหรือการพัฒนาผลิตภัณฑ์
แต่ในหลายบริษัท สิ่งนี้มักถูกลดความสำคัญลงเมื่อเทียบกับ UX (User Experience) นักพัฒนาก็เป็นผู้ใช้เช่นกัน และพวกเขาใช้ผลิตภัณฑ์
ความพึงพอใจและความสุขของพวกเขาสำคัญอย่างยิ่งต่อความสำเร็จของโปรเจกต์ นักพัฒนาที่มีความสุขจะสร้างซอฟต์แวร์ที่ยอดเยี่ยมและมีแนวโน้มจะไม่ออกจากทีม
เราให้นิยามประสบการณ์นักพัฒนาที่ดีจาก 4 องค์ประกอบด้านล่างนี้

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

2. เครื่องมือที่ดี
   ควรทำส่วนที่ทำได้ให้เป็นอัตโนมัติ งานที่ทำซ้ำ ๆ นั้นน่าเหนื่อยล้า

3. กระบวนการที่ช่วยเสริมหลังการพัฒนา
   กระบวนการนี้ควรทำงานเป็นเช็กลิสต์อัตโนมัติและให้ขั้นตอนที่สม่ำเสมอ กระบวนการที่กำหนดไว้อย่างชัดเจนช่วยในการฝึกทีม
   หากเป็นบริษัทที่มีขนาดใหญ่พอ ให้ใช้กระบวนการอย่าง QA, การปล่อยใช้งาน, การรับฟีดแบ็ก, การ onboarding เป็นต้น

4. วัฒนธรรมทีมที่ไม่เป็นพิษ
   กำหนดเป้าหมายของบริษัทให้ชัดเจน เป้าหมายต้องไม่ใช่แค่การหาเงินเพียงอย่างเดียว
   วัฒนธรรมคือ brainware ที่สำคัญที่สุดที่คุณสามารถติดตั้งลงในบริษัทและทีมได้ (ซอฟต์แวร์ที่ทำงานอยู่ในหัว)
   ทุกการตัดสินใจที่นักพัฒนาทำจะถูกกรองผ่าน brainware ที่ติดตั้งไว้
   หากพวกเขาไม่เห็นด้วยกับ brainware พวกเขาก็จะเพิกเฉยมัน

# ทำไมจึงต้องมีประสบการณ์นักพัฒนาที่ดี

## ทีมที่มีประสบการณ์นักพัฒนาที่ดีจะมีประสิทธิภาพสูง และแสดงลักษณะดังต่อไปนี้:

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

2. ความเป็นเจ้าของและความรับผิดชอบ
   พวกเขารับผิดชอบต่อความสำเร็จ สมาชิกทุกคนในทีมควรรู้สึกถึงความรับผิดชอบต่อความสำเร็จของบริษัท

3. เป้าหมายร่วมกัน
   ทั้งทีม ทั้งแผนก และทั้งบริษัทมีเป้าหมายร่วมกัน

4. ความเป็นมิตรและความซื่อสัตย์
   เราเรียกสิ่งนี้ว่าวัฒนธรรม 'hey bro' เราเน้นความจริงใจควบคู่ไปกับความเคารพอย่างสูง

5. การยอมรับความล้มเหลว
   นักพัฒนาควรกล้าหาญและพร้อมรับความเสี่ยง แต่ความเสี่ยงต้องคำนวณเสมอ และนักพัฒนาควรรู้ว่างานทุกชิ้นอาจก่อให้เกิดปัญหาได้มากเพียงใด

## ลักษณะของวัฒนธรรมที่มีประสบการณ์นักพัฒนาไม่ดี:

1. การชี้นิ้วโทษกัน
   สมาชิกทีมกล่าวโทษกันเองเมื่อเกิดความผิดพลาด นี่เป็นสิ่งที่เป็นพิษอย่างมาก แต่เกิดขึ้นบ่อย

2. การลงโทษความล้มเหลวอย่างรุนแรง
   ตัวอย่างเช่น หัวหน้าที่พูดว่าถ้าไม่ทำตามเดดไลน์ คุณอาจถูกไล่ออกได้

3. ช่วง crunch time ที่ไม่เคยเปลี่ยนแปลง และภาระงานล้นทีมอย่างต่อเนื่อง

4. ความเป็นปฏิปักษ์และความไม่แน่นอน
   การแข่งขันที่ไม่ดีต่อสุขภาพระหว่างทีม (เช่น คนนี้เก่งกว่าฉันเลยได้เลื่อนตำแหน่ง)

5. ความรับผิดชอบที่เจือจาง
   ในองค์กรใหญ่ อาจรู้สึกเหมือนไม่มีใครรับผิดชอบ ต้องใช้ความกล้าที่จะพูดว่า 'ขอโทษ ฉันทำพังเอง' การที่สามารถรับผิดชอบได้เป็นเรื่องสำคัญ

# ปัญหาที่ประสบการณ์นักพัฒนาที่ดีสามารถแก้ได้

• การสะสมและถ่ายทอดความรู้
• product-market fit ที่ไม่ถูกต้อง
• ทีมที่ขาดแรงจูงใจ
• วิธีคิดแบบ 'ไม่ใช่ปัญหาของฉัน'
• ผลิตภัณฑ์ที่ล้มเหลว
• ลูกค้าที่ไม่มีความสุข
• การขาดการเชื่อมต่อระหว่างธุรกิจกับ IT
• วัฒนธรรมทีมที่เป็นพิษ
• คุณภาพโค้ดที่ย่ำแย่
• ต้นทุนที่เพิ่มขึ้น
• งานที่ไร้ความหมาย

# วิธีสร้างประสบการณ์นักพัฒนาที่ดี

ในช่วงกลางทศวรรษ 1980 มี 'Scope Triangle' ที่สร้างโดย Dr. Martin Barnes ซึ่งแสดงความสัมพันธ์ระหว่างแรงพื้นฐาน 3 อย่าง

เวลา เงิน คุณภาพ

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

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

# กับดักทั่วไปของประสบการณ์นักพัฒนาที่ดี

1. ให้ข้อมูลกับนักพัฒนามากเกินไปเร็วเกินไป
2. ให้ข้อมูลกับนักพัฒนาน้อยเกินไปในเวลาที่พวกเขาต้องการข้อมูลมากขึ้น
3. การใช้กระบวนการมากเกินไปอาจก่อให้เกิดวิธีคิดแบบ 'ทุกอย่างต้องเข้ากันให้ได้'
4. แนวโน้มของการทำเกินความจำเป็นทางวิศวกรรม
5. Agile = ข้ออ้างในการโยนงานให้นักพัฒนามากขึ้น

[youngiggy]

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