บทเรียนจาก No Man's Sky บน iPhone สำหรับทีมซอฟต์แวร์
การเปิดตัว No Man's Sky บน iPhone ซึ่งมาถึงสิบปีหลังการเปิดตัวที่เป็นที่จดจำในแง่ลบ คือกรณีศึกษาที่ผู้บริหารสายผลิตภัณฑ์ทุกคนควรอ่านสักครั้ง แม้จะไม่เคยจับจอยเกมเลยก็ตาม เกมนี้กำลังจะมาถึง iPhone และ iPad ในวันที่ 28 ตุลาคม Hello Games สตูดิโอผู้พัฒนาเกมนี้ ยืนยันว่าเวอร์ชันมือถือคือเกมเต็มรูปแบบ ไม่ใช่เวอร์ชัน "lite" ที่ตัดทอนลง และรันได้บนอุปกรณ์เก่าถึงระดับ iPhone 11 และ iPad Air รุ่นที่ 3 นี่คือโจทย์ทางวิศวกรรมที่ยากจริง เพราะต้องสร้างจักรวาลขนาดใหญ่แบบ procedural ที่ประมวลผลสดบนโทรศัพท์ โดยมีขนาดไฟล์ดาวน์โหลดเพียงราว 5GB
เราทำธุรกิจด้านการสร้างและส่งมอบซอฟต์แวร์ ทั้งเว็บ มือถือ และระบบธุรกิจบน Odoo เรื่องนี้จึงคุ้มค่าที่ผู้บริหารสายผลิตภัณฑ์จะใช้เวลาสักสองสามนาทีทำความเข้าใจ ไม่ใช่เพราะเป็นเรื่องเกม แต่เพราะมันแสดงให้เห็นว่าทีมผลิตภัณฑ์ที่มีประสบการณ์ตัดสินใจอย่างไรว่าจะตัดอะไร เก็บอะไร และพูดความจริงอย่างไรเมื่อย้ายโค้ดเบสขนาดมหึมาอายุนับสิบปีไปยังแพลตฟอร์มใหม่ กระบวนการตัดสินใจแบบนี้ใช้ได้เหมือนกันกับบริษัทที่กำลังย้ายระบบ ERP, CRM หรือเครื่องมือภายในองค์กรไปสู่อุปกรณ์ใหม่หรือกลุ่มผู้ใช้ใหม่
การเปิดตัว No Man's Sky บน iPhone แบบเข้าใจง่าย
No Man's Sky เปิดตัวในปี 2016 ท่ามกลางความผิดหวังของผู้เล่น เพราะผลิตภัณฑ์ที่ส่งมอบจริงไม่ตรงกับที่โฆษณาไว้ หลังจากนั้น Hello Games ใช้เวลาหลายปีเพิ่มเนื้อหาฟรีอย่างต่อเนื่อง ค่อยๆ สร้างความเชื่อมั่นกลับคืนมา จนวันนี้เกมนี้ถูกยกให้เป็นหนึ่งในเรื่องราวการกอบกู้ความเชื่อมั่นที่ดีที่สุดเรื่องหนึ่งในวงการซอฟต์แวร์ ตามรายงานของทั้ง Ars Technica และ The Verge เวอร์ชัน iOS นำเนื้อหาที่สะสมมาเกือบทั้งหมดติดไปด้วย รวมถึงระบบสร้างฐานที่พัก การสำรวจ และการอัปเดตใหญ่ๆ ในช่วงไม่กี่ปีที่ผ่านมา
มีสองฟีเจอร์ที่ถูกตัดออกอย่างชัดเจนในเวอร์ชัน iOS ตอนเปิดตัว คือระบบผู้เล่นหลายคนไม่รองรับบนอุปกรณ์ iOS ใดเลย และการสร้างนิคมบนดาวเคราะห์โดยผู้เล่นจำกัดเฉพาะ iPhone 15 Pro ขึ้นไป Hello Games พูดตรงๆ ถึงเหตุผล คือจะขยายการรองรับ "ตามจำนวนคนที่เล่นจริง" ซึ่งเป็นแนวทางเดียวกับที่ใช้ตอนเกมนี้ไปลง Nintendo Switch ครั้งแรก นี่คือแผนงานที่ซื่อสัตย์และอิงจากการใช้งานจริง ไม่ใช่คำสัญญาทางการตลาด
ทำไมเรื่องนี้สำคัญเกินกว่าเรื่องเกม
มีสามประเด็นที่โดดเด่นสำหรับบริษัทใดก็ตามที่กำลังวางแผนขยายผลิตภัณฑ์ที่ซับซ้อนไปสู่แพลตฟอร์มใหม่ ประเทศใหม่ หรือกลุ่มผู้ใช้ใหม่
- กำหนดขอบเขตการพอร์ต อย่าลดทอนตัวผลิตภัณฑ์ Hello Games รักษาประสบการณ์หลักไว้ครบถ้วน และตัดเฉพาะสองฟีเจอร์ที่ติดข้อจำกัดด้านฮาร์ดแวร์หรือโครงสร้างพื้นฐาน แทนที่จะค่อยๆ ลดทอนผลิตภัณฑ์ทั้งหมดอย่างเงียบๆ
- บอกข้อแลกเปลี่ยนล่วงหน้าอย่างตรงไปตรงมา สตูดิโอระบุชัดเจนว่าขาดอะไรไปบ้าง (ผู้เล่นหลายคน การสร้างนิคมบนโทรศัพท์รุ่นเก่า) แทนที่จะปล่อยให้ผู้ใช้มาเจอช่องว่างเองหลังเปิดตัว
- ให้การใช้งานจริงเป็นตัวกำหนดแผนงาน การสนับสนุนในอนาคตผูกกับจำนวนผู้เล่น ไม่ใช่คำสัญญาตายตัว ซึ่งช่วยปกป้องทีมจากการทุ่มทรัพยากรลงแพลตฟอร์มที่อาจไม่คุ้มค่า
- เคารพขีดจำกัดของฮาร์ดแวร์รุ่นเก่า การรองรับ iPhone 11 ซึ่งเปิดตัวเมื่อเดือนกันยายน 2019 และมีอายุประมาณเจ็ดปีในวันที่เกมเปิดตัวบน iOS วันที่ 28 ตุลาคมนี้ หมายถึงการลงทุนทางวิศวกรรมจริงจังด้านอายุแบตเตอรี่และพฤติกรรมความร้อน ไม่ใช่แค่คอมไพล์ใหม่
สำหรับธุรกิจที่กำลังส่งมอบเครื่องมือภายใน พอร์ทัลลูกค้า หรือแอปมือถือคู่กับระบบ ERP หลักการทั้งสี่ข้อนี้ใช้ได้แทบทุกตัวอักษร เราเจอสถานการณ์นี้เป็นประจำเวลาลูกค้าขอให้เราทำแอปคลังสินค้า เครื่องมือสำหรับช่างบริการภาคสนาม หรือแดชบอร์ด ไปอยู่ในมือผู้ใช้ที่ถือโทรศัพท์ Android หรือ iOS รุ่นเก่าอยู่แล้ว
สิ่งที่บริษัทควรทำก่อนขยายแพลตฟอร์มจริงๆ
ก่อนอนุมัติโครงการ "ทำเวอร์ชันมือถือด้วย" เรามักพาลูกค้าไล่เช็กลิสต์สั้นๆ ชุดเดียวกับที่เราจะใช้ถ้าต้องตัดสินใจขนาดเดียวกับ No Man's Sky
| คำถาม | ทำไมถึงสำคัญ |
|---|---|
| อุปกรณ์รุ่นเก่าที่สุดที่ผู้ใช้จริงของเราถืออยู่คืออะไร | กำหนดงบประมาณด้านประสิทธิภาพและชุดทดสอบ ไม่ใช่การคาดเดาเอง |
| ฟีเจอร์ไหนที่จำเป็นต้องใช้ฮาร์ดแวร์ของแพลตฟอร์มใหม่จริงๆ | แยก "มีก็ดี" ออกจาก "ต้องมีฮาร์ดแวร์เฉพาะ" |
| เราบอกฟีเจอร์ที่ตัดออกต่อสาธารณะได้โดยไม่อายหรือไม่ | ถ้าบอกไม่ได้ แปลว่าขอบเขตงานผิด ไม่ใช่ปัญหาการสื่อสาร |
| เกณฑ์การใช้งานระดับไหนที่คุ้มค่าพอจะสร้างส่วนที่ขาดไป | ป้องกันการรับปากแบบไม่มีจุดจบ |
| โมเดลข้อมูลหลักยังคงเดียวกันในทุกแพลตฟอร์มหรือไม่ | ป้องกันตรรกะที่แตกต่างกันและงานดูแลที่ซ้ำซ้อน |
ข้อสุดท้ายนี่แหละคือจุดที่โครงการซอฟต์แวร์ธุรกิจจำนวนมากล้มเหลวจริงๆ แอปมือถือที่คุยกับฐานข้อมูลคนละชุด หรือใช้กฎทางธุรกิจคู่ขนานกับแอปเว็บ จะกลายเป็นผลิตภัณฑ์สองตัวที่ต้องดูแล ไม่ใช่ตัวเดียว เราเห็นปัญหานี้กับงาน Odoo เช่นกัน หน้าจอขายหรือคลังสินค้าบนมือถือควรอ่านและเขียนข้อมูลการเคลื่อนไหวสต็อกและผังบัญชีชุดเดียวกับระบบเดสก์ท็อป ไม่ใช่ข้อมูลจำลองแบบง่าย หากบริษัทของคุณกำลังพิจารณาเรื่องนี้ บริการ พัฒนาแอป iOS และ พัฒนาแอป Android ของเราเริ่มต้นจากการตรวจสอบฮาร์ดแวร์และข้อมูลแบบเดียวกันนี้ ก่อนจะเขียนโค้ดหน้าจอแม้แต่บรรทัดเดียว
ข้อแลกเปลี่ยนที่ควรพูดให้ชัด
แนวทาง "เปิดตัวก่อน ค่อยขยายทีหลังตามการใช้งาน" ที่ Hello Games เลือกใช้ มีต้นทุนจริงที่ต้องแลก ผู้ใช้ที่อยากได้ระบบผู้เล่นหลายคนหรือสร้างนิคมบน iPhone รุ่นเก่าวันนี้ จะไม่ได้ฟีเจอร์นั้นเลย และบางคนอาจเลิกใช้ก่อนที่ฟีเจอร์จะมาถึง ถ้ามันมาถึงจริง แผนงานที่อิงการใช้งานแบบนี้ช่วยปกป้องงบประมาณวิศวกรรมของผู้ให้บริการ แต่ก็หมายความว่าผู้ใช้กลุ่มแรกต้องแบกรับช่องว่างนั้นไปก่อน บริษัทใดที่จะลอกแนวทางนี้ ต้องซื่อสัตย์กับตัวเองว่าใครเป็นคนจ่ายต้นทุนนั้น ธุรกิจเองในรูปของต้นทุนวิศวกรรมที่เลื่อนออกไป หรือลูกค้าในรูปของประสบการณ์วันแรกที่บางกว่าที่ควร เราเลือกที่จะบอกลูกค้าเรื่องนี้ล่วงหน้าตั้งแต่ต้น ดีกว่าให้มาเจอในคิวซัพพอร์ตสามเดือนหลังขึ้นระบบจริง
จุดที่เรื่องนี้เชื่อมโยงกับการเชื่อมต่อระบบและ API
เวอร์ชัน iOS ของ No Man's Sky ยังต้องคุยกับบริการแบ็กเอนด์ชุดเดียวกับเวอร์ชันคอนโซลและพีซี สำหรับฟีเจอร์อย่าง expedition และ galaxy seed นี่คือโจทย์การเชื่อมต่อระบบผ่าน API ในระดับใหญ่ คือมีแหล่งข้อมูลจริงแหล่งเดียว แต่มีหน้าบ้านหลายช่องทาง ซอฟต์แวร์ธุรกิจก็มีข้อกำหนดแบบเดียวกันทุกครั้งที่บริษัทเพิ่มชั้นมือถือเข้าไปในระบบ ERP หรือ e-commerce ที่มีอยู่แล้ว ไม่ว่าจะเป็นหน้าร้าน Shopify เครื่อง POS หรือแท็บเล็ตของทีมช่างภาคสนาม ถ้าวางชั้นการเชื่อมต่อผิดพลาด แอปมือถือจะเริ่มไม่ตรงกับจำนวนสต็อกในคลังหรือบัญชีแยกประเภทภายในไม่กี่สัปดาห์ งานพัฒนาระบบ Odoo ERP ของเราเองก็ยึดกฎเดียวกันนี้ คือมีโมเดลข้อมูลเดียว ให้ทุกหน้าบ้านอ่านและเขียนเข้าไปในนั้น
หากทีมของคุณกำลังกำหนดขอบเขตการขยายแพลตฟอร์มมือถือให้ระบบเดิมในไตรมาสนี้ ให้เขียนรายการฟีเจอร์ที่จะตัดออกก่อนเขียนหน้าจอแรก ตัดสินใจตั้งแต่ตอนนี้ว่าตัวเลขการใช้งานระดับไหนถึงจะคุ้มค่าพอสร้างส่วนที่ขาด แล้วใส่ตัวเลขนั้นลงในแผนโครงการจริง ไม่ใช่แค่จดไว้ในบันทึกการประชุม นิสัยเล็กๆ นี้ ที่ยืมมาจากเกมอวกาศอายุสิบปีที่เพิ่งมาถึง iPhone จะช่วยให้ทีมส่วนใหญ่ไม่สร้างเกินความจำเป็นในวันแรก หรือทำให้ผู้ใช้ผิดหวังอย่างเงียบๆ ในภายหลัง



