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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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