เริ่มโครงการพัฒนาระบบในไทยด้วย PoC

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

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

สิ่งที่ PoC ใช้ตรวจสอบ

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

สิ่งที่เราอยากตรวจสอบเป็นพิเศษในโครงการที่ประเทศไทย คือการออกแบบเข้ากับการทำงานหน้างานจริงหรือไม่ (ไม่ใช่ "ตรงกับสมมติฐานของสำนักงานใหญ่"), พนักงานไทยรับการทำงานได้โดยไม่ต้องอธิบายหรือไม่, กรณียกเว้นที่หน้างานเจอเป็นประจำ (แบบฟอร์มเลอะ, Wi-Fi หลุด, คนไม่มาโดยไม่คาดคิด) ส่งผลอย่างไร, และเชื่อมกับ workflow และระบบเดิมอย่างไร ทั้งหมดนี้ไม่ปรากฏในเอกสารข้อกำหนด เห็นได้เฉพาะเมื่อของจริงถูกวางที่หน้างานแล้ว

การกำหนดขอบเขต PoC

แทนที่จะตัดขอบเขตตามฟีเจอร์ ให้ตัดตาม "หน่วยงานที่เล็กที่สุดที่ครบวงจร" สำหรับระบบ QC สายส่งของ อย่าสร้างแค่ "ฟังก์ชันตรวจ Part No" แต่สร้าง "1 ประเภทกล่องผ่านการสแกน ตรวจสอบ บันทึก จนถึงการออกรายงานวันถัดไป" แบบครบวงจร การสร้างแบบครบวงจรทำให้เห็นปัญหาที่ปรากฏเฉพาะเมื่อฟีเจอร์เชื่อมต่อกัน

ขนาดที่เรามักใช้: ระยะเวลา 2-4 สัปดาห์, ขอบเขต 1 แบบฟอร์ม 1 สาย 1 ไซต์

ออกแบบ PoC ในฐานะการทดลอง

ผลลัพธ์ของ PoC ไม่ใช่โค้ด แต่คือวัสดุตัดสินใจว่าจะไปสู่การพัฒนาเต็มรูปแบบหรือไม่ กำหนดเกณฑ์ความสำเร็จก่อน เช่น "พนักงานไทย 4 จาก 5 คนรับการทำงานได้ภายในการอธิบาย 30 นาที" รูปแบบที่ให้เรามองย้อนกลับและตัดสินได้ในภายหลัง กำหนดเกณฑ์ความล้มเหลวพร้อมกัน "ถ้าได้ยินว่า 'ใช้ไม่ได้' จากหน้างานมากกว่า 3 ครั้งใน 1 สัปดาห์ ถือว่าล้มเหลว"

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

การย้ายจาก PoC สู่ production

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

เหตุผลมี 3 ประการ โค้ด PoC เขียนขึ้นเพื่อทิ้ง ดังนั้นการยืนยันตัวตน การมอนิเตอร์ และการจัดการข้อผิดพลาดถูกตัดออก การสร้างคุณภาพ production ทับสิ่งนั้นช้ากว่าการเริ่มจากโครงกระดูก production ที่เหมาะสม การเพิ่มการเปลี่ยนแปลงข้อกำหนดที่ PoC เผยลงบนโค้ด PoC เดิมสร้าง technical debt ความรู้จาก PoC (การตัดสินใจ UI, business flow, การจัดการข้อยกเว้น) ถ่ายทอดไปยังการพัฒนาเต็มรูปแบบแม้ว่าโค้ดจะไม่ ค่านั้นถูกรักษาไว้

"ส่ง PoC code เป็น production เลย" มักเป็นจุดเริ่มต้นของปัญหา จึงตัดสินใจตั้งแต่ต้นว่ามันทิ้งได้

เมื่อ PoC ไม่เหมาะ

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

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

ที่เกี่ยวข้อง: ระบบสแกน QC สายการส่งของโรงงาน / OCR ที่ใช้ AI สำหรับผู้ผลิตญี่ปุ่นในประเทศไทย / การออกแบบระบบหน้างานโรงงานในไทยให้ทำงานแบบออฟไลน์

หากคุณกำลังพิจารณาโครงการพัฒนาระบบในประเทศไทย ติดต่อเราได้เลย