การควบคุมคุณภาพทีม Offshore Development: แนวทางปฏิบัติเพื่อลดช่องว่างในการสื่อสาร

หากคุณเป็นผู้จัดการหรือ PM ที่ได้รับมอบหมายให้ดูแลทีม Offshore Development คุณคงเคยมีประสบการณ์ที่ต้องเสียเวลาทั้งวันไปกับการส่งอีเมลในตอนเช้าแล้วรอรับคำตอบในตอนเย็นเพียงรอบเดียว ปัจจัยต่างๆ ทั้งเรื่องของเขตเวลาที่ต่างกัน กำแพงด้านภาษา และความแตกต่างทางวัฒนธรรม เมื่อรวมกันแล้วมักนำไปสู่ความคลาดเคลื่อนในการกำหนดความต้องการ (Requirement Definition) และความล่าช้าในการตรวจสอบความคืบหน้า ซึ่งส่งผลโดยตรงต่อปัญหาด้านคุณภาพ เช่น การส่งมอบงานล่าช้าหรือบั๊กที่เพิ่มมากขึ้น

บทความนี้จะอธิบายถึงแนวทางปฏิบัติเพื่อลดปัญหาคุณภาพที่เกิดจากช่องว่างในการสื่อสารเหล่านี้ โดยพื้นฐานแล้วจะประกอบด้วยการผสมผสาน 3 องค์ประกอบหลัก ได้แก่ การวางระบบโดยตั้งอยู่บนพื้นฐานของการสื่อสารแบบไม่ประสานเวลา (Asynchronous Communication) การแบ่งปันเกณฑ์มาตรฐานด้านคุณภาพที่ชัดเจน และการสร้างวงจรการรีวิวและให้ฟีดแบ็กอย่างสม่ำเสมอ เราจะนำความรู้ด้านการจัดการคุณภาพอย่าง ISO 9001 และ CMMI มาประยุกต์ใช้เพื่อทำความเข้าใจถึงสาเหตุที่ทำให้เกิดความคลาดเคลื่อน พร้อมทั้งนำเสนอมาตรการปรับปรุงที่เป็นรูปธรรมซึ่งคุณสามารถนำไปปรับใช้กับทีมของคุณได้ทันที

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

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

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

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

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

ช่องว่างในการสื่อสาร (Communication gap) ไม่ใช่แค่เรื่องของความล่าช้าในการส่งต่อข้อมูลเท่านั้น แต่สิ่งที่น่าหนักใจคือมันก่อให้เกิดปฏิกิริยาลูกโซ่ที่ทำให้เนื้อหาการนำไปใช้งาน (Implementation) ผิดพลาดไปจากเดิม โดยทั่วไปแล้วกระบวนการที่มักเกิดขึ้นคือ เริ่มจากความเข้าใจที่ไม่ตรงกัน จากนั้นจึงสะท้อนออกมาในขั้นตอนการนำไปใช้งาน และมาตรวจพบเอาในขั้นตอนการรีวิว หากปล่อยให้กระบวนการดำเนินต่อไปในช่วงเวลานี้ ขอบเขตของการแก้ไขจะต้องย้อนกลับไปถึงระดับความต้องการ (Requirements) ซึ่งจะทำให้ต้นทุนการแก้ไขงาน (Rework cost) เพิ่มสูงขึ้น

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

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

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

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

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

ระดับความละเอียดของคำจำกัดความของความต้องการ (Requirement Definition) เป็นตัวกำหนดปริมาณความคลาดเคลื่อนในการนำไปใช้งานจริง หากไม่เข้าใจจุดนี้ ต่อให้มีการทบทวนงานในขั้นตอนหลังๆ มากเพียงใด ก็ไม่สามารถลดการแก้ไขงานย้อนหลังได้

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

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

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

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

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

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

ความแตกต่างในการรับรู้เกี่ยวกับเกณฑ์คุณภาพเกิดขึ้นจากเส้นแบ่งในการตัดสินว่าสิ่งใดคือ "บั๊ก" (bug) ระหว่างฝั่งผู้ว่าจ้างและฝั่งผู้พัฒนาที่ไม่ตรงกัน เช่น จะยอมรับการแสดงผลที่ผิดเพี้ยนได้มากน้อยเพียงใด หรือต้องการความละเอียดในการจัดการข้อผิดพลาด (error handling) ในระดับไหน หากไม่มีการระบุไว้เป็นลายลักษณ์อักษร การขีดเส้นแบ่งเหล่านี้มักจะถูกปล่อยให้เป็นการตัดสินใจของแต่ละหน้างาน

หากความแตกต่างในการรับรู้นี้ยังคงดำเนินต่อไป แม้จำนวนบั๊กที่ตรวจพบจะเท่าเดิม แต่การตัดสินใจเรื่องลำดับความสำคัญในการแก้ไขจะคลาดเคลื่อน ส่งผลให้ในบางกรณีข้อผิดพลาดที่ร้ายแรงกลับถูกนำไปแก้ไขทีหลัง แนวคิดด้านการจัดการคุณภาพที่ ISO 9001:2015 ต้องการนั้น ให้ความสำคัญกับการจัดทำเอกสารเกณฑ์คุณภาพและแบ่งปันในรูปแบบที่ตรวจสอบได้ หากนำมาประยุกต์ใช้กับการพัฒนาแบบออฟชอร์ (offshore development) การตกลงเรื่องเกณฑ์การยอมรับ (acceptance criteria) และการจำแนกความรุนแรงของข้อผิดพลาดไว้ล่วงหน้า จะเป็นรากฐานในการลดความผันผวนของอัตราการตรวจพบบั๊ก

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

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

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

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

ใน "DS-121 อะไจล์พัฒนาปฏิบัติการไกด์บุ๊ก" (DS-121 Agile Development Practice Guidebook) ก็ได้แนะนำให้มีการดำเนินงานที่ทำให้เห็นความคืบหน้าและปัญหาอย่างต่อเนื่อง การจัดเตรียมกลไกนี้ในขั้นตอนการสร้างโครงสร้างพื้นฐานถือเป็นเงื่อนไขเบื้องต้นที่จะทำให้การกำหนดความต้องการและการจัดทำเอกสารมาตรฐานคุณภาพในขั้นตอนถัดไปสามารถทำงานได้อย่างมีประสิทธิภาพ

หากการกำหนดความต้องการ (Requirement Definition) ถูกแชร์ผ่านคำพูดหรือคำอธิบายแบบกระจัดกระจายในแชท ก็มีแนวโน้มที่จะเกิดความคลาดเคลื่อนในการนำไปใช้งานจริงได้ง่าย ในทางกลับกัน หากมีการทำให้เห็นภาพชัดเจนด้วยเอกสารและแผนภาพ ก็จะสามารถตรวจพบความแตกต่างของความเข้าใจได้ตั้งแต่เนิ่นๆ ในการพัฒนาแบบ Off-shore ยิ่งเป็นสเปกที่ฝั่งผู้ว่าจ้างละไว้โดยคิดว่า "น่าจะเข้าใจได้ตามสามัญสำนึก" ก็มักจะมีแนวโน้มที่จะตกหล่นไปโดยไม่ได้นำไปพัฒนาจริง

วิธีที่มีประสิทธิภาพคือการใช้การทำให้เห็นภาพด้วยแผนภาพควบคู่ไปกับเอกสารกำหนดความต้องการ ใน "แนวทางการประยุกต์ใช้ UML สำหรับการพัฒนาแบบ Off-shore" (Offshore Development UML Application Guidelines) ที่เผยแพร่โดย NPO UML Modeling Promotion Council ได้ระบุว่าการสื่อสารสเปกโดยใช้ Class Diagram และ Sequence Diagram แทนการพึ่งพาภาษาธรรมชาติเพียงอย่างเดียว เป็นวิธีการช่วยลดความคลาดเคลื่อนในการตีความ สำหรับลำดับการประมวลผลหรือเงื่อนไขข้อยกเว้นที่มักจะคลุมเครือเมื่อเขียนเป็นข้อความ การนำมาใส่ในแผนภาพจะช่วยให้ ความแตกต่างของความเข้าใจ เห็นภาพได้ชัดเจนยิ่งขึ้น

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

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

ในทางปฏิบัติ การกำหนดช่วงเวลาการทบทวนงานให้คงที่ตามรอบสปรินต์ (Sprint) หรือตามไมล์สโตน (Milestone) แทนการนัดหมายแบบเฉพาะกิจ (Ad-hoc) จะมีประสิทธิภาพมากกว่า สิ่งที่ควรนำมาทบทวนไม่ควรมีเพียงแค่โค้ดที่เสร็จสมบูรณ์แล้วเท่านั้น แต่รวมถึงผลงานระหว่างทางและเหตุผลในการตัดสินใจเชิงออกแบบด้วย ซึ่งจะช่วยให้สามารถแก้ไขงานได้ในขณะที่ขอบเขตของงานที่ต้องทำใหม่ยังไม่ใหญ่มาก ในแบบจำลองความพร้อมของกระบวนการ CMMI ได้ระบุแนวทางว่ายิ่งระดับสูงขึ้น กระบวนการตรวจสอบและยืนยันความถูกต้อง (Verification and Validation) จะยิ่งมีความเป็นมาตรฐานและเป็นเชิงปริมาณมากขึ้น ซึ่งสอดคล้องกับแนวคิดที่มองว่าการทบทวนงานเป็นกระบวนการที่มีการจัดการ ไม่ใช่เหตุการณ์ที่เกิดขึ้นเพียงครั้งเดียว

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

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

เกณฑ์การตัดสิน: การจัดทำรายการตรวจสอบเพื่อสร้างความยั่งยืนให้กับกลไกการทำงาน

รายการตรวจสอบ (Checklist) ไม่ควรเป็นการนำหัวข้อที่นึกขึ้นได้มาเรียงต่อกัน แต่ควรจัดระเบียบในรูปแบบที่สามารถตรวจสอบสถานะการดำเนินงานใน 3 ขั้นตอน ได้แก่ การกำหนดความต้องการ (Requirement Definition), ความคืบหน้า (Progress) และเกณฑ์คุณภาพ (Quality Standards) แนวคิดการจัดการคุณภาพตามมาตรฐาน ISO 9001 ให้ความสำคัญกับการบันทึกผลลัพธ์การดำเนินกระบวนการและการทบทวนอย่างต่อเนื่อง หากนำมุมมองนี้มาประยุกต์ใช้ในการออกแบบรายการตรวจสอบ จะช่วยให้การดำเนินงานมีความเสถียรยิ่งขึ้น

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

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

ตัวอย่างการตั้งค่าที่เป็นรูปธรรม สำหรับการรายงานแบบไม่ประสานเวลา (Asynchronous) ในแต่ละวัน ควรจำกัดไว้เพียง 3 หัวข้อคือ "งานที่เสร็จสิ้น งานที่กำลังดำเนินการ และปัญหาที่ขัดขวางการทำงาน (Blocker)" โดยส่งผ่านเครื่องมือแชทตามรูปแบบที่กำหนดไว้จะใช้งานได้จริงมากกว่า ส่วนการประชุมแบบประสานเวลา (Synchronous) รายสัปดาห์ ควรล็อกเวลาไว้ในช่วงที่เวลาทำงานของทั้งสองฝ่ายตรงกันโดยคำนึงถึงความต่างของเวลา และการเขียนวาระการประชุมลงในเอกสารไว้ล่วงหน้าจะช่วยให้การประชุมมุ่งเน้นไปที่การตรวจสอบงานได้โดยตรง

กฎการแจ้งเหตุการณ์สำคัญ (Escalation) ก็มีความสำคัญเช่นกัน หากเกิดข้อสงสัยเกี่ยวกับบั๊กหรือการตีความสเปก การกำหนดเกณฑ์ไว้ล่วงหน้าว่าหากไม่มีการรายงานภายในกี่ชั่วโมงจะมีการแจ้งเตือนไปยังหัวหน้าโดยอัตโนมัติ จะช่วยให้การดำเนินงานเป็นไปโดยไม่ต้องพึ่งพาการตัดสินใจของบุคคล ตัวอย่างเช่น การตั้งเงื่อนไขที่ชัดเจนว่า "หากปัญหาที่ขัดขวางการทำงาน (Blocker) ไม่ได้รับการแก้ไขภายใน 4 ชั่วโมง ให้ทำการเมนชัน (Mention) ในแชท" จะช่วยลดเวลาการรอคอยที่คลุมเครือได้

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

เราขอนำเสนอ 3 คำถามที่ได้รับบ่อยที่สุดจากผู้ปฏิบัติงานจริงในประเด็นเรื่องการควบคุมคุณภาพ (Quality Control) และช่องว่างในการสื่อสาร (Communication Gap) โดยจะขอตอบคำถามแต่ละข้ออย่างกระชับในแง่มุมของลำดับความสำคัญในการดำเนินการช่วงเริ่มต้น, ความเป็นไปได้ในการปฏิบัติงานภายใต้ความต่างของเวลา (Time Difference), และวิธีการวัดผลลัพธ์ของการปรับปรุง

เราควรเริ่มจากจุดไหนเพื่อลดปัญหาคุณภาพงานที่เกิดจากช่องว่างในการสื่อสาร (Communication Gap) ให้ได้เร็วที่สุด?

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

ในทางปฏิบัติ นอกเหนือจากข้อกำหนดด้านฟังก์ชันแล้ว ควรทำ "Definition of Done" ให้เป็นรายการตรวจสอบ (Checklist) และรวมถึงเกณฑ์การผ่านของ Unit Test และ E2E Test เพื่อแชร์ร่วมกัน ทั้งนี้ "แนวทางการประยุกต์ใช้ UML สำหรับการพัฒนาแบบ Offshore" ที่เผยแพร่โดย UML Modeling Promotion Council ได้ระบุว่าการทำให้ความต้องการชัดเจนขึ้นด้วยแผนภาพนั้นมีประสิทธิภาพในการปรับความเข้าใจโดยใช้เอกสารเป็นฐาน และถือเป็นข้อมูลอ้างอิงที่ดีสำหรับวิธีการสื่อสารที่ไม่ต้องพึ่งพาการตีความภาษาญี่ปุ่นที่กำกวม

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

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

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

ตัวอย่างเช่น หากเกิดความลังเลในการตัดสินใจระหว่างการพัฒนา หากใช้วิธีการถามผ่านแชทแล้วรอคำตอบ งานก็จะหยุดชะงักไปตามระยะเวลาของความต่างของเวลา ในทางกลับกัน หากมีการจัดทำเอกสารกำหนดความต้องการ (Requirement Definition Document), เกณฑ์การยอมรับ (Acceptance Criteria) และประวัติการอภิปรายที่ผ่านมาไว้เป็นลายลักษณ์อักษร ผู้รับผิดชอบก็จะสามารถตัดสินใจด้วยตนเองและดำเนินการในขั้นตอนถัดไปได้ ความแตกต่างนี้เองที่เป็นตัวกำหนดความถี่ของการเกิดข้อผิดพลาดในการตรวจสอบคุณภาพ

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

สิ่งที่โมเดลความพร้อมอย่าง CMMI ให้ความสำคัญไม่ใช่การสื่อสารแบบพึ่งพาตัวบุคคล แต่เป็นการสร้างมาตรฐานของกระบวนการ แม้จะตั้งอยู่บนพื้นฐานของการทำงานแบบอะซิงโครนัส แต่หากมีการปฏิบัติงานที่บันทึกบันทึกการรีวิว (Review record) และการตัดสินใจต่างๆ ไว้เป็น Log ก็จะสามารถรักษาความสม่ำเสมอในการตัดสินใจได้แม้จะมีเรื่องความต่างของเวลาเข้ามาเกี่ยวข้อง การเปลี่ยนแนวคิดจากการยอมแพ้เรื่องความเรียลไทม์ ไปสู่การสร้างกลไกที่ทิ้งร่องรอยเหตุผลในการตัดสินใจไว้ เป็นแนวทางที่ใช้งานได้จริงมากกว่า

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

ในทางปฏิบัติ วิธีที่เข้าใจง่ายคือการบันทึกข้อมูล 3 ประการเป็นรายเดือนเพื่อติดตามการเปลี่ยนแปลง ได้แก่ จำนวนครั้งที่ถูกตีกลับต่อการรีวิว 1 ครั้ง, จำนวนครั้งของการโต้ตอบในแชทเพื่อยืนยันความต้องการ และอัตราการผ่านการทดสอบยอมรับ (Acceptance Test) ในการส่งงานครั้งแรก หากจำนวนการโต้ตอบลดลงและอัตราการผ่านในครั้งแรกเพิ่มขึ้นหลังจากวางระบบแล้ว นั่นจะเป็นหลักฐานว่าโครงสร้างพื้นฐานสำหรับการสื่อสารแบบไม่ประสานเวลา (Asynchronous Communication) และการจัดทำเอกสารมาตรฐานคุณภาพนั้นใช้งานได้จริง

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

หากบริษัทไม่มีข้อมูลที่สามารถตรวจสอบได้ แนวทางที่สมเหตุสมผลคือการเริ่มบันทึกจำนวนครั้งที่ถูกตีกลับและจำนวนครั้งของการโต้ตอบในปัจจุบันเป็นเวลา 1-2 เดือน แล้วจึงเริ่มตรวจสอบประสิทธิผลโดยเปรียบเทียบกับมาตรการที่ดำเนินการหลังจากนั้น