วิธีการสร้างเส้นทางการเรียนรู้ต่อเนื่องที่ช่วยให้ทีมวิศวกรรมทันสมัยอยู่เสมอเมื่อมีเทคโนโลยีใหม่ๆ เกิดขึ้น

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

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

เส้นทางการเรียนรู้ต่อเนื่องสำหรับวิศวกรคืออะไร?

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

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

ข้อเท็จจริงด่วน

1. อธิบายปัญหาด้านประสิทธิภาพ

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

2. วิเคราะห์ช่องว่างด้านการเรียนรู้และบริบท

ก่อนเริ่มสร้างเนื้อหา ให้เปรียบเทียบงานที่จะทำกับสิ่งที่คุณมีอยู่ในปัจจุบัน

1. แนวทางการฝึกอบรมในปัจจุบันเป็นอย่างไร? หลักสูตรเกี่ยวกับไวยากรณ์และแนวคิดช่วยฝึกฝนการจดจำ การย้ายถิ่นฐานต้องอาศัยการวิเคราะห์ การตัดสินใจ และการสร้างสรรค์
2. ความต้องการด้านการรับรู้คืออะไร? ในระบบการจำแนกประเภทที่ปรับปรุงใหม่ของบลูม การเปรียบเทียบแนวทางเก่าและใหม่จัดอยู่ในขั้นตอนการวิเคราะห์และประเมินผล และการออกแบบส่วนที่ปรับเปลี่ยนไปนั้นจัดอยู่ในขั้นตอนการสร้างสรรค์ คู่มือของเราสำหรับ การจับคู่กิจกรรมการเรียนรู้กับอนุกรมวิธานของบลูม แสดงวิธีการจับคู่กิจกรรมให้เหมาะสมกับระดับ
3. มีปัจจัยอื่นนอกเหนือจากทักษะที่เป็นอุปสรรคหรือไม่? ตรวจสอบการเข้าถึงแซนด์บ็อกซ์ สภาพแวดล้อมการทดสอบ การเป็นเจ้าของโค้ด ภาระงานนอกเวลาทำการ และดูว่ามีใครมีเวลาเรียนรู้หรือไม่ หากระบบทดสอบล้มเหลว การย้ายระบบครั้งแรกก็จะไม่รวดเร็ว ส่งต่อสาเหตุเหล่านั้นไปยังผู้ที่สามารถแก้ไขได้ การวินิจฉัยช่องว่างการเรียนรู้ สามารถช่วยคุณแยกพวกมันออกจากกันได้

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

3. ออกแบบการเตรียมตัวและการฝึกฝนอย่างมีเป้าหมาย

มอบหมายงานให้แต่ละขั้นตอนอย่างน้อยหนึ่งอย่าง

ตรวจสอบความรู้พื้นฐานใช้แบบสอบถามสั้นๆ เพื่อตรวจสอบว่าใครมีความรู้พื้นฐานอยู่แล้วบ้าง เพื่อไม่ให้ผู้ที่ไม่รู้เนื้อหาพื้นฐานต้องเรียนซ้ำ การตรวจสอบความรู้พื้นฐานจะยืนยันเฉพาะความรู้พื้นฐานเท่านั้น ไม่ได้แสดงถึงความพร้อมในการเรียน

เตรียมตัวด้วยตนเองตามจังหวะที่เหมาะสมอ้างอิงเอกสารทางการ คู่มือภายใน และแหล่งข้อมูลสั้นๆ ที่เน้นเฉพาะเรื่อง ให้กระชับและตรงประเด็นกับงาน

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

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

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

4. ลองทำตัวอย่างที่สมจริงดู

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

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

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

ข้อเสนอแนะและลองใหม่ผู้ตรวจสอบถามว่า "ระบบนี้รับประกันเรื่องการส่งมอบอย่างไร และนั่นหมายความว่าอย่างไรสำหรับหน้าที่ของคุณ" วิศวกรอ่านเอกสารการส่งมอบของแพลตฟอร์มและส่งกลับพร้อมกับการเปลี่ยนแปลง

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

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

5. ประเมินศักยภาพและวางแผนการถ่ายโอน

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

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

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

ในกรณีที่การนำเสนอแบบโต้ตอบมีประโยชน์

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

วัดสิ่งที่เปลี่ยนแปลงไป

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

ข้อจำกัดที่อาจยังคงอยู่

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

คำถามที่พบบ่อย

เส้นทางการเรียนรู้ต่อเนื่องสำหรับวิศวกรคืออะไร?

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

เส้นทางการเรียนรู้สำหรับวิศวกรซอฟต์แวร์ควรใช้เวลานานแค่ไหน?

ใช้เวลานานพอที่วิศวกรแต่ละคนจะทำงานที่สมจริงอย่างน้อยหนึ่งอย่างในระบบใหม่ได้สำเร็จ ทดลองใช้กับทีมหนึ่งก่อน จากนั้นวัดเวลาที่ใช้ในการเตรียมความพร้อมสำหรับงานนั้นๆ

คุณจะพัฒนาทักษะวิศวกรซอฟต์แวร์ได้อย่างไรโดยไม่ต้องดึงพวกเขาออกจากงานส่งมอบ?

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

คุณรู้ได้อย่างไรว่าวิธีการนั้นได้ผล?

วิศวกรทำงานใหม่ที่ไม่เคยเห็นมาก่อนในระบบใหม่ได้ตามมาตรฐานของทีม และรายงานความคืบหน้าก็แสดงให้เห็นถึงคุณภาพเดียวกัน

จะเริ่มที่ไหนดี

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

หากต้องการดูว่ากระบวนการเรียนรู้สามารถนำไปใช้จริงกับทีมของคุณได้อย่างไร และสามารถนำกลับมาใช้ซ้ำได้ตามจังหวะของตนเองในภายหลัง ลองศึกษา AhaSlides ดู