หลายองค์กรมองว่าการจ้างทีม Outsource อาจจะล้มเหลวเพราะนักพัฒนาไม่เก่ง แต่จริงๆ แล้วแทบไม่ใช่สาเหตุนั้นเลย
McKinsey และมหาวิทยาลัย Oxford เคยศึกษาโปรเจกต์ไอทีกว่า 5,400 โปรเจกต์และพบว่าโปรเจกต์ขนาดใหญ่มักบานปลายเกินงบเฉลี่ย 45% และให้ผลลัพธ์น้อยกว่าที่วางแผนถึง 56% โดยมีต้นตอมาจากการที่คนในโปรเจกต์ไม่ได้อยู่บนหน้าเดียวกัน
บทเรียนชัดมาก ทีมส่วนใหญ่ไม่ได้พังเพราะเทคโนโลยี แต่พังเพราะไม่มีใครนั่งคุยให้ตรงกันตั้งแต่ต้น บริษัทหลายแห่งเลยมองว่าการ Outsource ความเสี่ยง และคิดว่ามีมีทางเลือกแค่ 2 ทางคือใช้ทีมในบริษัททำเองทั้งหมดในราคาที่แพงกว่า หรือจ้างภายนอกแล้วก็รับความเสี่ยงไป
แต่จริงๆ แล้วมันไม่ได้เป็นแบบนั้น ผลลัพธ์ขึ้นอยู่กับวิธีสื่อสารการทำงานของกับทีม Outsource มากกว่า
แผนการสื่อสารกับทีม Outsource คืออะไร?
พูดง่ายๆ มันคือเอกสารที่บอกว่าทีมแชร์ข้อมูลกันยังไง ใครคุยกับใคร บ่อยแค่ไหน ผ่านช่องทางไหน และถ้าเกิดปัญหาหรือต้องตัดสินใจอะไร จะจัดการกันแบบไหน
สำหรับทีม Outsource เอกสารนี้ไม่ใช่ของเสริม แต่จำเป็นมาก ถ้าไม่มี การสื่อสารจะกลายเป็นแบบไม่เป็นทางการ ข้อความส่งผิดคน การตัดสินใจเกิดขึ้นในบทสนทนาที่ไม่มีใครจดไว้ และอัปเดตก็มาช้าหรือไม่มาเลย
แผนการสื่อสารช่วยเปลี่ยนนิสัยที่ทุกคนแค่ “รู้กันอยู่” ให้กลายเป็นข้อตกลงที่เขียนชัดเจน ทุกคนทำตามได้เลย
สิ่งที่แผนการสื่อสารกับทีม Outsource มักพลาดไป
ปัญหาที่เจอบ่อยในโปรเจกต์ Outsource ไม่ใช่เรื่องที่สร้างมาแล้วไม่ตรงกับที่ตกลงกัน แต่เป็นช่องว่างระหว่าง “สิ่งที่ลูกค้าหมายถึง” กับ “สิ่งที่นักพัฒนาเข้าใจ” เจ้าของธุรกิจอธิบายสิ่งที่ต้องการด้วยภาษาธุรกิจ นักพัฒนารับแล้วแปลเป็นภาษาเทคนิค ทั้งคู่เดินออกมาคิดว่าเข้าใจตรงกัน แต่จริงๆ ไม่ใช่
แผนการสื่อสารที่ดีจัดการเรื่องนี้ตรงๆ มีกระบวนการเขียน Requirement ด้วยภาษาที่คนทั่วไปเข้าใจได้ และมีการเช็กอินเป็นประจำเพื่อยืนยันว่าสิ่งที่กำลังสร้างยังตรงกับเป้าหมายธุรกิจอยู่ ก่อนโปรเจกต์จะเริ่ม ทีม Vendor ควรใช้เวลาทำความเข้าใจให้ชัดว่าลูกค้าต้องการอะไร ทีมทำงานกันยังไง และ “ผลลัพธ์ที่ดี” หน้าตาเป็นอย่างไร การข้ามขั้นตอนนี้คือสาเหตุอันดับต้นๆ ที่ทำใหโปรเจกต์เดินออกนอกทาง รวมถึงต้องเข้าใจด้วยว่าโปรเจกต์นี้สร้างมูลค่าให้ธุรกิจยังไง ถ้าไม่รู้ว่าคาดหวัง ROI แค่ไหน ต่อให้สร้างได้ดีแค่ไหนก็อาจไม่ได้ผลลัพธ์ที่มีความหมายในทางธุรกิจ
สร้างแผนการสื่อสารโปรเจกต์ใน 6 ขั้นตอน
1. ระบุทุกคนที่เกี่ยวข้องและบทบาทในการสื่อสารของแต่ละคน
จดชื่อทุกคนที่ต้องส่ง รับ หรือเอาข้อมูลเกี่ยวกับโปรเจกต์ไปทำอะไรสักอย่าง ทั้งทีมภายในของคุณ นักพัฒนา Outsource PM จากทั้งสองฝั่ง และคนที่มีสิทธิ์อนุมัติการตัดสินใจ
สำหรับแต่ละคน ระบุให้ชัดเจนว่ารับผิดชอบสื่อสารเรื่องอะไร ไม่ใช่แค่บอกว่าเขาเป็นใคร เพราะถ้าไม่มีเจ้าของข้อมูลชิ้นไหน ข้อมูลชิ้นนั้นมักหล่นหายไปทุกที
2. ตกลงเรื่องเครื่องมือตั้งแต่ก่อนเริ่ม
เลือกเครื่องมือให้เสร็จก่อนโปรเจกต์จะเริ่ม แล้วยึดตามนั้น ไม่ต้องกังวลมากว่าจะเลือกอะไร สำคัญกว่าคือทุกคนต้องตกลงใช้ชุดเดียวกัน
ชุดเครื่องมือมาตรฐานที่ใช้ได้กับโปรเจกต์ทั่วไป::
- แชทประจำวัน: Slack หรือ Microsoft Teams
- ประชุมออนไลน์: Zoom หรือ Google Meet
- ติดตามงาน: Jira หรือ Linear
- เก็บเอกสาร: Notion หรือ Confluence
- การสื่อสารทางการ: อีเมล
เครื่องมือมากขึ้นหมายถึงโอกาสที่อะไรจะหลุดรอดมากขึ้น เรียบง่ายไว้ก่อนดีกว่าเสมอ
3. กำหนดตารางประชุมให้ชัดเจนและสม่ำเสมอ
ความถี่ในการประชุมควรเดินตามจังหวะของโปรเจกต์:
- ช่วง Active Development: Daily Standup วันละ 15 นาที
- รีวิวความคืบหน้า: ทุกสองสัปดาห์ พร้อมบทสรุปเป็นลายลักษณ์อักษร
- อัปเดต Stakeholder: รายเดือนหรือตามจุดสำคัญ
- Retrospective: ท้าย Sprint หรือท้ายแต่ละเฟส
ทุกการประชุมควรมีบันทึกสรุปสั้นๆ เก็บไว้ บทสรุปสั้นๆ ที่อ่านได้เลยมีประโยชน์กว่าคลิปวิดีโอที่ไม่มีใครกลับไปดูซะอีก
4. ตกลงรูปแบบการอัปเดตให้เป็นมาตรฐานเดียวกัน
Status Update อ่านง่ายและเทียบกันได้มากขึ้นเมื่อทุกคนใช้โครงสร้างเดิม รายงานรายสัปดาห์แบบง่ายๆ ก็พอ:
- ทำอะไรเสร็จแล้วสัปดาห์นี้
- แผนสัปดาห์หน้าคืออะไร
- มีอะไรติดขัดหรืออยู่ในโซนเสี่ยงบ้าง
ถ้าเกิดปัญหาระหว่างรอบอัปเดต ให้บอกทันทีเลย อย่ารอไปรายงานรอบถัดไป
5. วางแผนรับมือ Timezone ล่วงหน้า
หาช่วงเวลาที่สองทีม Overlap กันในชั่วโมงทำงาน แล้วยัดการประชุม Live ทั้งหมดไว้ในช่วงนั้น
ส่วนสิ่งอื่นๆ ที่ไม่ต้องเจอกัน Real-time ให้ตกลงกันให้ชัดว่าต้องตอบภายในกี่ชั่วโมง มาตรฐานที่สมเหตุสมผลคือ 4 ชั่วโมงในชั่วโมงทำงาน เขียนมันลงไปเพื่อจะได้ไม่ต้องมานั่งเดากัน
6. วางแผนสำหรับเมื่อเกิดปัญหาไว้ก่อนเลย
ตัดสินใจล่วงหน้าเลยว่าถ้าเกิดปัญหาขึ้น ใครคือคนแรกที่ต้องรู้? อะไรถือว่าเร่งด่วน? ควรแก้ภายในกี่ชั่วโมง?
การเขียนแผนรับมือไว้ก่อนที่จะมีอะไรพัง ช่วยให้เวลาปัญหาเกิดจริง ทุกคนรู้ว่าต้องทำอะไร ไม่ต้องเสียเวลามานั่งถกเถียงกัน
ควรมีอะไรอยู่ในเอกสารแผนการสื่อสาร?
เก็บให้อยู่แค่หน้าเดียวก็พอ ควรครอบคลุมเรื่องเหล่านี้:
- ภาพรวมโปรเจกต์: เป้าหมาย ขอบเขต และข้อจำกัดหลัก
- รายชื่อทีม: ชื่อ บทบาท Timezone และวิธีติดต่อ
- คู่มือเครื่องมือ: เครื่องมือไหนใช้ทำอะไร
- ตารางประชุม: เมื่อไหร่ ใครต้องเข้า และใครเป็นคนดำเนิน
- รูปแบบอัปเดต: รายงานหน้าตาเป็นยังไง ส่งบ่อยแค่ไหน
- กฎเวลาตอบกลับ: ต้องตอบภายในกี่ชั่วโมง
- ขั้นตอน Escalation: ถ้าเกิดปัญหาต้องทำอะไร ติดต่อใคร
เก็บไว้ที่ที่ทั้งสองทีมเข้าถึงได้ และอัปเดตเมื่อไรก็ตามที่มีอะไรเปลี่ยน
ข้อผิดพลาดที่ควรระวัง
ใช้ช่องทางสื่อสารมากเกินไป ถ้าไม่มีระบบชัดเจน คนก็จะส่งข้อความทาง Slack บ้าง WhatsApp บ้าง อีเมลบ้าง แล้วก็มีอะไรหลุดรอดไปแน่นอน เลือกแค่สองสามช่องทางแล้วใช้แค่นั้น
ไม่มี Point of Contact ที่ชัดเจน ถ้าทีมไม่รู้ว่าจะไปถามใคร ข้อความก็จะส่งผิดคนหรือไม่ส่งเลย กำหนดคนหลักสักคนจากแต่ละฝั่งให้ชัดเจน
ไม่จดอะไรเป็นลายลักษณ์อักษร ข้อตกลงปากเปล่าหายไปเสมอ ไม่ว่าจะเป็นการเปลี่ยน Scope เลื่อนกำหนดส่ง หรือ Requirement ใหม่ที่เพิ่งตกลงกัน ต้องเขียนลงไปและเก็บไว้ที่ที่ทั้งคู่ค้นหาได้
มองข้ามความแตกต่างทางวัฒนธรรม สไตล์การสื่อสารต่างกันมากในแต่ละวัฒนธรรมและองค์กร บางทีมพูดปัญหาตรงๆ ทันที บางทีมรอจนมันใหญ่โตก่อน แผนการสื่อสารควรระบุความคาดหวังให้ชัด เพื่อไม่ให้ความต่างพวกนี้ทำให้เสียเวลาโดยไม่รู้ตัว
เลือกทีม Outsource ที่ดีต้องดูจากอะไรบ้าง
สำหรับในไทย การทำงานกับทีมในประเทศช่วยลดปัญหาทั่วไปได้หลายอย่าง
การคุยกันภาษาเดียวกัน อยู่ Timezone เดียวกัน และนัดเจอตัวได้เมื่อจำเป็น สำหรับองค์กรไทยนั้นคุยได้หลายภาษา และเข้าใจการทำงานภายในองค์กรได้ดีกว่า
สำหรับบริษัทต่างชาติ สิ่งสำคัญคือต้องทำงานกับทีมที่เข้าใจวิธีคิดและมาตรฐานการทำงานแบบสากล สื่อสารตรงๆ และรักษาคุณภาพได้สม่ำเสมอ
แผนการสื่อสารจะได้ผลก็ต่อเมื่อทีม Outsource ของคุณพร้อมทำตามมัน และควรช่วยสร้างมันด้วย เวลาเปรียบเทียบทีม อย่าถามแค่เรื่องทักษะเทคนิค ถามเรื่องโครงสร้างการสื่อสารด้วย
คำถามที่ควรใช้:
- พวกเขาทำแผนการสื่อสารตั้งแต่ต้นทุกโปรเจกต์ หรือปล่อยให้ลูกค้าจัดการเอง?
- เวลาติดปัญหาพวกเขาบอกทันทีเลย หรือเงียบจัดการเองจนกลายเป็นเรื่องใหญ่?
- PM ของพวกเขาเข้าใจเป้าหมายธุรกิจ หรือแค่เข้าใจ Requirement ทางเทคนิค?
- พวกเขาจัดการกับความต่างด้านภาษาและวัฒนธรรมกับลูกค้ายังไง?
- กระบวนการจริงๆ เวลามีปัญหาเกิดขึ้นเป็นอย่างไร?
ทีม Outsource ที่ตอบคำถามพวกนี้ไม่ได้ก่อนโปรเจกต์จะเริ่ม มีโอกาสน้อยมากที่จะสื่อสารได้ดีตอนโปรเจกต์เริ่ม
Manao Software ช่วยธุรกิจของคุณได้ยังไง?
แผนการสื่อสารถูกเตรียมไว้ในวิธีทำงานของเราตั้งแต่ต้น ไม่ใช่เพิ่มเข้ามาทีหลัง
ทุกโปรเจกต์เริ่มด้วยแผนการสื่อสารที่บันทึกไว้ชัดเจน PM คนเดิมที่เข้าใจเป้าหมายธุรกิจของคุณ และเส้นทาง Escalation ที่ตกลงกันไว้ก่อนเริ่ม Dev คุณจะได้อัปเดตสม่ำเสมอ มีชั่วโมงทำงานที่ Overlap กัน และได้คำตอบตรงๆ เมื่อมีอะไรติดขัด
ถ้าคุณกำลังหาทีมซอฟต์แวร์อยู่ ลองถามว่าพวกเขาจัดแผนการสื่อสารและการส่งมอบงานตั้งแต่ต้นยังไง คำของ Outsource ทีมที่ดีจะช่วยให้คุณตัดสินใจง่ายขึ้น
คำถามที่พบบ่อย
แผนการสื่อสารโปรเจกต์คือ?
เอกสารที่บอกว่าทีมแชร์ข้อมูลกันยังไง ใครคุยกับใคร บ่อยแค่ไหน ผ่านช่องทางไหน และคาดหวังการอัปเดตแบบไหน ช่วยให้ทุกคนเดินไปทิศเดียวกันตลอดโปรเจกต์
ทำไมทำงานกับทีม Outsource ถึงต้องมีแผนการสื่อสาร?
เพราะทีม Outsource ทำงานคนละที่ ต่าง Timezone และต่างวัฒนธรรม ถ้าไม่มีแผน ความเข้าใจผิดเกิดขึ้นง่ายมาก และนำไปสู่การพลาดกำหนดส่ง งานที่เสียเปล่า หรือผลลัพธ์ที่ไม่ตรงความคาดหวัง แผนที่ชัดเจนตัดความคลุมเครือออกไปและทำให้โปรเจกต์อยู่บนเส้นทาง
ควรประชุมกับทีม Outsource บ่อยแค่ไหน?
ขึ้นอยู่กับช่วงของโปรเจกต์์ ช่วง Active Dev ทำ Daily หรือ Every Other Day Standup ก็ได้ รายสัปดาห์เหมาะสำหรับรีวิวภาพรวม รายเดือนไว้ดูภาพใหญ่ สิ่งสำคัญคือต้องสม่ำเสมอ ประชุมสม่ำเสมอและคาดเดาได้ดีกว่าประชุมแบบสะเปะสะปะเสมอ
ควรใช้เครื่องมืออะไรสื่อสารกับทีม Outsource?
ที่นิยมคือ Slack หรือ Teams สำหรับแชทประจำวัน, Zoom หรือ Google Meet สำหรับประชุม, Jira หรือ Trello สำหรับติดตามงาน และอีเมลสำหรับสื่อสารทางการ สำคัญที่สุดคือตกลงกันก่อนแล้วใช้ให้สม่ำเสมอ ช่องทางมากไปยิ่งสับสน
จัดการกับ Timezone ต่างกันยังไง?
เริ่มด้วยการหาช่วง Overlap ของสองทีม ยัดการประชุม Live ทั้งหมดไว้ในช่วงนั้น ส่วนที่เหลือให้ตั้งกฎเวลาตอบกลับให้ชัด เช่น ตอบภายใน 4 ชั่วโมงทำงาน เครื่องมือ Async อย่างบอร์ดงานร่วมและการอัปเดตเป็นลายลักษณ์อักษรก็ช่วยเชื่อมช่องว่างได้ดีมาก
