การป้องกันการรั่วไหลของความรู้และกระบวนการถ่ายทอดทักษะแบบเป็นขั้นตอนในการพัฒนาซอฟต์แวร์แบบ Offshore

ในแวดวงการพัฒนาซอฟต์แวร์แบบ Offshore Development สถานการณ์ที่วิศวกรฝีมือดีลาออกกะทันหัน หรือการที่ทีมงานถูกเปลี่ยนยกชุดนั้นไม่ใช่เรื่องแปลกใหม่ ทุกครั้งที่เกิดเหตุการณ์เช่นนี้ "ความรู้ที่ไม่ได้ถูกบันทึกไว้" (Tacit knowledge) เช่น เบื้องหลังการตัดสินใจด้านการออกแบบ หรือเหตุผลทางตรรกะของธุรกิจก็จะสูญหายไป ส่งผลให้ผู้ที่มารับช่วงต่อต้องกลับไปทำผิดพลาดซ้ำรอยเดิม ซึ่ง "การสูญเสียความรู้" (Knowledge loss) นี้ถือเป็นปัญหาที่เกิดขึ้นจริงและเป็นสิ่งที่ผู้ว่าจ้างจำนวนมากต้องเผชิญ

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

การสูญเสียความรู้ (Knowledge Loss) ไม่ได้เกิดขึ้นจากการลาออกเพียงอย่างเดียว แต่เกิดขึ้นในสภาวะที่ความรู้แบบฝังลึก (Tacit Knowledge) ยังไม่ได้ถูกเปลี่ยนให้เป็นความรู้ที่ชัดแจ้ง (Explicit Knowledge) การที่เกิดสถานการณ์ที่ว่า "ไม่มีใครอธิบายได้ว่าทำไมสเปกนั้นถึงเป็นเช่นนั้น" ทันทีที่ผู้รับผิดชอบงานลาออกไป เป็นเพราะความรู้นั้นมีอยู่เพียงแค่ในหัวของบุคคลเท่านั้น ในการพัฒนาแบบ Offshore Development ปัญหานี้จะทวีความรุนแรงขึ้นด้วยกำแพงด้านภาษา วัฒนธรรม และเขตเวลา ซึ่งทำให้โอกาสในการแบ่งปันความรู้แบบฝังลึกมีน้อยกว่าการพัฒนาภายในประเทศ ส่งผลให้ปัญหาคุณภาพลดลงหรือการส่งมอบงานล่าช้า มักจะปรากฏให้เห็นหลังจากพนักงานลาออกไปแล้วไม่กี่สัปดาห์ ในหัวข้อถัดไป เราจะมาจัดระเบียบปัจจัยที่เป็นต้นเหตุทั้ง 3 ประการตามลำดับครับ

หากการลาออกเกิดขึ้นในช่วงเวลาสั้นๆ พร้อมกัน จะมีความเสี่ยงสูงที่ความรู้ในการทำงานจะสูญหายไปทั้งหมด ในขณะที่หากการลาออกค่อยๆ ทยอยเกิดขึ้น จะสามารถจัดหาโอกาสในการส่งมอบงานได้ง่ายกว่า ในทีมพัฒนาแบบ Offshore มักมีการเปลี่ยนตัวบุคลากรตามช่วงเวลาการต่อสัญญาหรือเมื่อจบโปรเจกต์ หากผู้ที่ถือครอง "ความรู้โดยนัย" (Tacit knowledge) ลาออกไปกะทันหัน เบื้องหลังการตัดสินใจด้านการออกแบบและประวัติการแก้ไขปัญหาในอดีตจะหายไปโดยไม่มีการบันทึกไว้

ISO 30401:2018 กำหนดให้การจัดการความรู้ต้องดำเนินการเป็นกลไกขององค์กร และระบุว่าการรักษาความรู้ที่พึ่งพาความจำของบุคคลนั้นเป็นความเสี่ยง สิ่งที่หลงเหลืออยู่ในคอมเมนต์ของโค้ดหรือเอกสารการออกแบบมักเป็นเพียง "ความรู้ที่ชัดแจ้ง" (Explicit knowledge) ว่า "สร้างอะไรขึ้นมา" เท่านั้น ส่วนเหตุผลประกอบการตัดสินใจว่า "ทำไมจึงเลือกการใช้งานนั้น" มักพึ่งพาการสื่อสารด้วยวาจา ความแตกต่างนี้แม้จะดูเล็กน้อยแต่หยั่งรากลึก แม้จะตรวจสอบความครบถ้วนของความรู้ที่ชัดแจ้งในการทบทวนเอกสาร แต่การขาดหายไปของเหตุผลประกอบการตัดสินใจนั้น ผู้ตรวจสอบเองก็สังเกตเห็นได้ยาก จึงมักหลุดรอดจากการตรวจสอบไปได้

ในรูปแบบสัญญาที่เฉพาะเจาะจงของงาน Offshore ทีมมักถูกจัดตั้งขึ้นตามโปรเจกต์ ทำให้เกิดกรณีที่ความรู้ที่ "ยึดติดกับตัวบุคคล" (Personalization) สูญหายไปพร้อมกับการสิ้นสุดของโปรเจกต์ เพื่อชดเชยจุดอ่อนเชิงโครงสร้างนี้ จำเป็นต้องมีทั้งกลไกในการตรวจจับสัญญาณเตือนของการลาออก และการปฏิบัติงานที่บันทึกเหตุผลประกอบการตัดสินใจไว้ในงานประจำวัน แนวคิดเรื่องการพัฒนาบุคลากรที่ระบุไว้ใน ISO 10015:2019 ยังสามารถนำมาอ้างอิงเป็นกรอบการทำงานสำหรับการ "ถ่ายทอดทักษะ" (Skill transfer) อย่างต่อเนื่อง แทนที่จะเป็นการส่งมอบงานแบบครั้งเดียวจบได้อีกด้วย

อุปสรรคด้านภาษา วัฒนธรรม และเขตเวลา ไม่เพียงแต่ทำให้เกิดการสูญเสียความรู้โดยนัย (Tacit Knowledge) จากการลาออกของพนักงานเท่านั้น แต่ยังเป็นปัจจัยที่ขัดขวางการสื่อสารข้อมูลในชีวิตประจำวันอีกด้วย หากฝ่ายผู้ว่าจ้างและทีมพัฒนา Offshore ใช้ภาษาที่แตกต่างกัน การถ่ายทอดเจตจำนงในการออกแบบหรือเบื้องหลังของการเปลี่ยนแปลงข้อกำหนด (Specification) ด้วยวาจาให้ถูกต้องแม่นยำนั้นทำได้ยาก และข้อมูลจะค่อยๆ สูญหายไปทุกครั้งที่มีการแปล ยิ่งมีการสื่อสารหลายทอด ปริมาณข้อมูลต้นฉบับยิ่งรักษาไว้ได้ยาก โดยเฉพาะข้อมูลเบื้องหลังอย่าง "ทำไมถึงกำหนดสเปกเช่นนั้น" มักจะเป็นส่วนที่ถูกตัดออกไปก่อนข้อสรุปหรือขั้นตอนการทำงานเสมอ

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

สำหรับกำแพงด้านเขตเวลา ปัญหาที่เกิดขึ้นนั้นเรียบง่าย คือการที่เวลาทำงานไม่ตรงกันทำให้การถาม-ตอบล่าช้าออกไปเป็นวันถัดไปหรือนานกว่านั้น ส่งผลให้การเขียนโปรแกรมดำเนินต่อไปโดยที่ข้อสงสัยยังคงค้างคาอยู่ การที่ "แนวทางการประยุกต์ใช้ UML สำหรับการพัฒนา Offshore" ของ JISA แนะนำให้ใช้แผนภาพและตารางในการแชร์ข้อกำหนด ก็เพื่อจุดประสงค์ในการชดเชยความคลาดเคลื่อนด้านภาษาและเขตเวลาเหล่านี้ด้วยเช่นกัน

หากปล่อยทิ้งไว้ Knowledge Loss จะส่งผลกระทบต่อตัวเลขในหน้างานพัฒนาซอฟต์แวร์อย่างไรบ้าง

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

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

ผลกระทบเหล่านี้ไม่ได้จบลงเพียงแค่ครั้งเดียว แต่การแก้ไขงาน (Rework) อันเนื่องมาจากคุณภาพที่ลดลงจะทำลายความเชื่อมั่นกับฝั่งผู้ว่าจ้าง และการที่ต้องเพิ่มกระบวนการตรวจสอบเพิ่มเติมจะทำให้เกิดความล่าช้าต่อเนื่องไปยังตารางเวลาถัดไป เราจำเป็นต้องมองว่า Knowledge Loss ไม่ใช่แค่ความสูญเสีย ณ ขณะที่เกิดขึ้นเท่านั้น แต่เป็นความเสี่ยงเชิงโครงสร้างที่ส่งผลกระทบต่อกระบวนการทั้งหมดหลังจากนั้นด้วย

เมื่อเกิดปัญหาความรู้สูญหาย (Knowledge Loss) ในหน้างานการพัฒนาซอฟต์แวร์แบบ Offshore มักจะถูกสรุปสาเหตุว่าเกิดจากการอบรมเพื่อส่งต่องานเพียงครั้งเดียวที่ไม่เพียงพอ แต่ในความเป็นจริงแล้ว สาเหตุรากเหง้าคือการที่ไม่ได้ออกแบบกระบวนการตั้งแต่การจ้างงาน การมอบอำนาจ ไปจนถึงการพัฒนาผู้สืบทอดตำแหน่งให้เป็นกระแสที่ต่อเนื่องกัน หากแบ่งพิจารณาเป็น 3 ขั้นตอน ได้แก่ การสร้างฐานความรู้ในช่วง Onboarding, การมอบอำนาจแบบค่อยเป็นค่อยไปผ่านการปฏิบัติงานจริง และการพัฒนาความเป็นผู้นำ จะทำให้เห็นชัดเจนว่าในแต่ละช่วงใครมีหน้าที่รับผิดชอบอะไร และการถ่ายทอดทักษะติดขัดอยู่ที่ขั้นตอนใด

สำหรับฐานที่มีสมาชิกเดิมอยู่มาก การใช้รูปแบบรายบุคคลโดยให้พี่เลี้ยง 1 คนดูแลพนักงานใหม่หนึ่งคนจะได้ผลดี ในทางกลับกัน หากเป็นการจัดตั้งฐานใหม่ที่มีผู้เข้าร่วมหลายคนพร้อมกัน การใช้รูปแบบกลุ่มโดยใช้หลักสูตรส่วนกลางจะมีประสิทธิภาพมากกว่า สิ่งที่ควรจัดเตรียมในช่วงเริ่มต้นของการทำ Onboarding ไม่ใช่ความรู้เฉพาะทางของงาน แต่คือ ฐานความรู้ (Knowledge Base) โดยตรง ซึ่งได้แก่ เอกสารขั้นตอนการสร้างสภาพแวดล้อมการพัฒนา, ข้อกำหนดในการเขียนโค้ด (Coding Convention), บันทึกการแก้ไขปัญหาในอดีต และเอกสารสรุปที่มาของการตัดสินใจ หากละเลยส่วนนี้ไป ในขั้นตอนการมอบอำนาจหรือการถ่ายโอนงานในภายหลัง ระดับความเข้าใจของสมาชิกแต่ละคนจะแตกต่างกัน จนสุดท้ายพี่เลี้ยงจะต้องคอยตามแก้ปัญหาเป็นรายบุคคล

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

นอกจากนี้ ไม่ควรมองข้ามกลไกที่อนุญาตให้พนักงานใหม่สามารถเพิ่มข้อสงสัยลงในเอกสารได้ ซึ่งจะทำให้ฐานความรู้ได้รับการอัปเดตอย่างต่อเนื่อง อันที่จริง ข้อสงสัยของพนักงานใหม่คือวัตถุดิบชั้นดีในการทำให้สิ่งที่สมาชิกเดิมมองว่าเป็นความรู้ที่ฝังอยู่ในตัวบุคคล (Tacit Knowledge) และละเลยที่จะบันทึกไว้ กลายเป็นสิ่งที่มองเห็นได้ชัดเจน การวางตำแหน่งให้ Onboarding ไม่ใช่แค่ช่วงเวลาการฝึกอบรม แต่เป็นกระบวนการสร้างรากฐานที่รองรับการมอบอำนาจในขั้นตอนถัดไป จะส่งผลโดยตรงต่อการป้องกันการสูญเสียความรู้ (Knowledge Loss) ในอนาคต หากประหยัดการลงทุนในช่วงนี้ ต่อให้จัดเตรียมกระบวนการถ่ายโอนงานในขั้นตอนถัดไปได้ดีเพียงใด รากฐานก็จะยังคงสั่นคลอนได้ง่ายอยู่ดี

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

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

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

เราควรปล่อยให้บุคลากรที่ได้รับมอบอำนาจไปแล้วกลายเป็นเพียงแคนดิเดตผู้นำโดยไม่มีการดูแลต่อหรือไม่?

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

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

กำแพงด้านภาษาไม่สามารถแก้ไขได้ด้วยการเพิ่มปริมาณการแปล แต่เป็นปัญหาที่สามารถก้าวข้ามได้ด้วยการปรับเปลี่ยนการออกแบบวิธีการเขียน

ไม่ว่าการมอบอำนาจหรือการพัฒนาความเป็นผู้นำจะก้าวหน้าไปเพียงใด ตราบใดที่ความรู้ยังคงติดอยู่ในหัวของบุคคล เมื่อบุคคลนั้นลาออกไป ทุกอย่างก็จะสูญหายไปในทันที เราจะมาดูรายละเอียดกันว่า จะมีวิธีการสร้างรูปแบบเอกสารที่สื่อสารกับผู้อ่านได้อย่างถูกต้องในสภาพแวดล้อมที่ใช้หลายภาษาได้อย่างไร และจะสร้างกลไกในการเปลี่ยน "ความรู้ที่ฝังอยู่ในตัวคน" (Tacit Knowledge) ให้เป็น "ความรู้ที่ถ่ายทอดได้" (Explicit Knowledge) ได้อย่างไร

หากผู้รับผิดชอบที่อ่านภาษาที่ใช้อ้างอิงไม่ใช่เจ้าของภาษาญี่ปุ่นหรือภาษาอังกฤษ การให้ความสำคัญกับประโยคสั้นที่มีโครงสร้างชัดเจนและแผนภาพเป็นหลัก พร้อมทั้งเพิ่มหมายเหตุเสริมในรูปแบบที่สามารถใช้อภิธานศัพท์ในภาษาแม่ควบคู่กันได้ ถือเป็นแนวทางที่ใช้ได้จริงในทางปฏิบัติ JISA ใน "OffshoreDevelopmentUML ApplicationGuideline V3.0" (แนวทางการประยุกต์ใช้ UML สำหรับการพัฒนาแบบออฟชอร์ V3.0) แนะนำให้จัดทำเอกสารโดยใช้สัญกรณ์แบบแผนภาพ เช่น UML เป็นวิธีการลดความคลุมเครือของภาษาธรรมชาติในโครงการที่มีหลายภาษาเช่นนี้

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

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

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

สำหรับกลไกที่เป็นรูปธรรม การกำหนดกฎให้ทิ้งเหตุผลในการตัดสินใจไว้ในช่องความคิดเห็นของระบบ Code Review หรือระบบจัดการ Ticket และการสรุปประเด็นสำคัญจากสิ่งที่สะสมไว้ไปคัดลอกลงใน Knowledge Base เป็นระยะๆ ถือเป็นการปฏิบัติงานที่ใช้งานได้จริง ข้อกำหนดของระบบการจัดการความรู้ที่ระบุไว้ใน ISO 30401:2018 เรียกร้องให้มีการระบุ การได้รับ และการรักษาความรู้เหล่านี้ให้เป็นกลไกขององค์กรอย่างต่อเนื่อง ซึ่งถือเป็นพื้นฐานในการสร้างระบบที่ไม่พึ่งพาความปรารถนาดีของบุคคล

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

เราจะสร้างกลไกเพื่อหมุนเวียนความรู้ที่ขึ้นอยู่กับตัวบุคคล (Personalized knowledge) ให้กระจายไปทั่วทั้งทีมแทนที่จะเก็บไว้เพียงในหัวของคนใดคนหนึ่งได้อย่างไร การทำเอกสารเพียงอย่างเดียวไม่สามารถแบ่งปันความเข้าใจที่เกิดขึ้นเฉพาะหน้าหรือความรู้เชิงปฏิบัติที่ไม่ได้บันทึกไว้ (Tacit knowledge) ได้ทั้งหมด การผสมผสานระหว่าง "การประชุม" และ "การทำงานเป็นคู่" (Pair working) ซึ่งเป็นพื้นที่ปฏิบัติจริงทั้งสองรูปแบบ จะช่วยให้การหมุนเวียนและการฝังรากลึกของความรู้กลายเป็นระบบขึ้นมาได้

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

การจัดสรรเวลา 30-45 นาที ทุกสัปดาห์หรือทุกสองสัปดาห์ และกำหนดวาระให้คงที่เป็น 3 หัวข้อ ได้แก่ "ปัญหาทางเทคนิคที่แก้ไขได้เมื่อเร็วๆ นี้" "ข้อจำกัดด้านสเปกที่พบใหม่" และ "ความเป็นมาของงานที่จะส่งต่อในสัปดาห์ถัดไป" จะช่วยลดภาระในการเตรียมตัวและทำให้การจัดประชุมเป็นกิจวัตรได้ง่ายขึ้น ในการพัฒนาแบบออฟชอร์ (offshore) มีหลายกรณีที่ทุกคนไม่สามารถเข้าร่วมพร้อมกันได้เนื่องจากความแตกต่างของเขตเวลาระหว่างฐานปฏิบัติงาน ดังนั้นการแนบวิดีโอบันทึกและบันทึกแชท (chat log) ไปกับรายงานการประชุม เพื่อให้สามารถติดตามเนื้อหาได้แม้จะเป็นแบบไม่พร้อมกัน (asynchronous) จึงเป็นสิ่งสำคัญ

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

จุดประสงค์ของการประชุมไม่ใช่การแบ่งปันข้อมูลเพียงอย่างเดียว แต่อยู่ที่การเก็บบันทึกที่ทุกคนสามารถอ้างอิงได้เมื่อเกิดปัญหาเดียวกันขึ้นอีกในอนาคต การนำรายงานการประชุมไปปรับปรุงในฐานความรู้ (knowledge base) ทันทีในวันเดียวกัน พร้อมทั้งกำหนดกฎการปฏิบัติงานที่ไม่ให้จบแค่การประชุมเพียงครั้งเดียว จะช่วยให้ผลลัพธ์นี้คงอยู่ต่อไปได้อย่างยั่งยืน

ในขั้นตอนการพัฒนาสมาชิกใหม่ การใช้ Pair Programming ควบคู่ไปกับการทำ Mentoring เพื่อขยายมุมมองทางเทคนิคของสมาชิกเดิม จะช่วยเพิ่มประสิทธิภาพในการถ่ายทอดความรู้ที่ฝังอยู่ในตัวบุคคล (Tacit Knowledge) ได้ดียิ่งขึ้น จุดแข็งของ Pair Programming คือการที่ทั้งสองคนมองหน้าจอเดียวกันขณะลงมือเขียนโค้ด ทำให้สามารถแบ่งปันเหตุผลในการตัดสินใจหรือเทคนิคเฉพาะทางในการออกแบบที่เขียนลงในเอกสารได้ยากในทันที โดยเฉพาะความรู้ทางธุรกิจที่เป็นเบื้องหลังของข้อกำหนด (Specification) หรือบทเรียนที่ได้รับจากการแก้ไขปัญหาในอดีต ซึ่งมักจะถ่ายทอดได้ยากแม้จะเขียนเป็นลายลักษณ์อักษร การอธิบายไปพร้อมกับการลงมือปฏิบัติจริงจึงช่วยให้เกิดความเข้าใจที่ฝังลึกได้ง่ายกว่า

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

สำหรับแนวทางการปฏิบัติ ในช่วงไม่กี่เดือนแรกหลังจากเริ่มงาน ควรเน้นสัดส่วนของ Pair Programming ให้สูงขึ้น และเมื่อมีความเข้าใจในงานมากขึ้นแล้ว จึงค่อยปรับสัดส่วนของ Mentoring ให้เพิ่มขึ้นตามลำดับ ซึ่งเป็นวิธีที่ใช้งานได้จริงในทางปฏิบัติ การตรวจสอบ ความคืบหน้า (Progress) ควรเชื่อมโยงกับวาระการประชุมประจำที่กล่าวถึงในหัวข้อก่อนหน้า โดยการนำประเด็นที่พบจากการทำงานเป็นคู่มาแบ่งปันในที่ประชุม จะช่วยไม่ให้การพัฒนาบุคลากรรายบุคคลและการแบ่งปันความรู้ของทั้งองค์กรแยกออกจากกัน สำหรับสาขาที่อยู่ต่างเขตเวลา การจำกัดช่วงเวลาทำงานคู่ให้ตรงกัน และใช้การแชทแบบไม่ประสานเวลา (Asynchronous) ควบคู่ไปกับการสนทนาออนไลน์สำหรับการทำ Mentoring ถือเป็นแนวทางที่เหมาะสมในทางปฏิบัติ

เพื่อป้องกันการสูญเสียความรู้ (Knowledge Loss) หัวใจสำคัญคือการใช้ RACI เพื่อระบุให้ชัดเจนว่าใครเป็นผู้รับผิดชอบในด้าน "การปฏิบัติ" (Responsible), "การอนุมัติ" (Accountable), "การให้คำปรึกษา" (Consulted) และ "การรายงาน" (Informed) รวมถึงการสร้างโครงสร้างที่ทำให้มั่นใจได้ว่าตำแหน่งเจ้าของงาน (Owner) จะไม่ว่างลงแม้จะมีการลาออกเกิดขึ้น โดยเฉพาะอย่างยิ่ง หากการดำเนินงานยังคงคลุมเครือในเรื่องความรับผิดชอบระหว่างฐานปฏิบัติการนอกประเทศ (Offshore) และฝั่งลูกค้า มักจะนำไปสู่สถานการณ์ที่ต้องมาเริ่มหารือขอบเขตการส่งมอบงานกันก็ต่อเมื่อได้รับแจ้งการลาออกแล้วเท่านั้น

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

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

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

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

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

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

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

ในทางปฏิบัติ มีข้อค้นพบว่า การกำหนดอภิธานศัพท์ให้คงที่ก่อนเริ่มเขียน จะช่วยให้เกิดผลลัพธ์ที่ดีกว่า เนื่องจากหากคำแปลของศัพท์ไม่สอดคล้องกัน จะทำให้แนวคิดเดียวกันถูกเรียกด้วยชื่อที่หลากหลาย ซึ่งนำไปสู่ความสับสนของผู้อ่าน ทั้งนี้ "แนวทางการประยุกต์ใช้ UML สำหรับการพัฒนาแบบออฟชอร์" (Offshore Development UML Application Guidelines) ที่เผยแพร่โดย JISA ก็ได้แสดงแนวคิดที่ให้ความสำคัญกับการสร้างความเข้าใจร่วมกันผ่านแผนภาพ ซึ่งแนวคิดที่ให้ความสำคัญกับการแชร์ภาพประกอบมากกว่าภาษานั้นถือเป็นสิ่งที่น่าอ้างอิง

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

ความคืบหน้าของการถ่ายทอดทักษะ (Skill Inheritance) ไม่ควรวัดจากตัวชี้วัดเพียงตัวเดียว แต่ต้องอาศัยการผสมผสานหลายมุมมองเข้าด้วยกัน

ตัวชี้วัดที่เป็นตัวแทน ได้แก่ Document Coverage (สัดส่วนของงานที่จัดทำเป็นเอกสารแล้ว), ระดับการมอบอำนาจ (สามารถถ่ายโอนงานตั้งแต่ขั้นตอนการออกแบบ การตรวจสอบ ไปจนถึงการตัดสินใจได้มากน้อยเพียงใด) และผลการทดสอบการปฏิบัติงานจริง (Reproducibility Test) ในการตรวจสอบความรู้ โดยการทดสอบนี้เป็นวิธีการตรวจสอบว่าผู้สืบทอดสามารถทำงานที่กำหนดให้สำเร็จได้โดยปราศจากการดูแลจากสมาชิกเดิมหรือไม่ ซึ่งสอดคล้องกับแนวคิดการจัดการสมรรถนะตามมาตรฐาน ISO 10015:2019

จุดตัดสินใจที่สำคัญคือบุคลากรคนนั้นมีความเสี่ยงในการลาออกสูงหรือไม่ หากเป็นบุคลากรที่รับผิดชอบการตัดสินใจด้านการออกแบบหลัก ควรให้ความสำคัญกับการติดตามระดับการมอบอำนาจและผลการทดสอบการปฏิบัติงานจริง แต่หากเป็นบุคลากรที่เน้นงานด้านการลงมือปฏิบัติที่เป็นรูปแบบตายตัว (Routine Implementation) สามารถใช้ความคืบหน้าของ Document Coverage เป็นตัวชี้วัดหลักและลดความถี่ในการตรวจสอบลงได้

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