เมื่อแอปที่สร้างด้วย AI โตเกินเวอร์ชันแรก: Refactor หรือ Rewrite

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

ช่วงเวลาที่คุณรู้ตัวว่าแอปประสบความสำเร็จ

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

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

ความรู้สึกนั้นคือสัญญาณให้คุณคิดว่ามันยังเป็นแอปเดิมอยู่ไหม หรือคุณโตเกินมันไปแล้ว

refactor ให้อะไรและมีต้นทุนอะไร

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

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

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

rewrite ให้อะไรและมีต้นทุนอะไร

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

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

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

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

สามคำถามที่ช่วยเลือกระหว่างสองทาง

คำถามที่ 1: รูปร่างแกนหลักยังถูกต้องอยู่ไหม?

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

ถ้าคุณกำลังเพิ่มสิ่งที่เป็นรูปแบบย่อยของแกนหลักเดิม — “ฟอร์มสำหรับบุคคล ฟอร์มสำหรับทีม ฟอร์มที่มีฟิลด์กำหนดเอง” — นั่นก็ยังเป็นแอปเดียว refactor แล้วต่อยอดมันไป

คำถามที่ 2: ถ้า refactor วันนี้ อีกกี่เดือนกว่าแรงเสียดทานจะกลับมาอีก?

ตอบตรงๆ ถ้าแรงเสียดทานหายไปหกเดือน การ refactor คือทางที่ถูก ถ้ามันจะกลับมาเจ็บอีกในสองเดือนเพราะปัญหาไม่ได้อยู่ที่รูปร่างของโค้ดแต่อยู่ที่รากฐานเอง การ rewrite ก็ช่วยคุณประหยัดจากการประหยัดเทียมๆ ของการมานั่งปะถึงสองครั้ง ลองถาม AI builder ของคุณว่า: “ถ้าเราจัดบ้านนี้ใหม่ อีกนานแค่ไหนกว่าเราจะต้องทำแบบนี้อีก?” ถ้าคำตอบคือ “อาจไม่นานนัก” ก็ถึงเวลาสร้างใหม่แล้ว

คำถามที่ 3: จริงๆ แล้วผู้ใช้ของคุณพึ่งพาอะไรอยู่?

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

เส้นทางที่มักได้ผล

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

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

เวลาที่ถูกต้องในการตัดสินใจ

ครั้งหน้าที่คุณรู้สึกถึงแรงเสียดทาน ลองถามตัวเองว่า: “ฉันกำลังทำให้แอปนี้ทำสิ่งที่มันควรจะทำได้ดีขึ้นอยู่ไหม หรือฉันกำลังขอให้มันเป็นสิ่งที่มันไม่เคยถูกออกแบบมาเพื่อเป็น?” ถ้าเป็นอย่างแรก ก็ refactor ถ้าเป็นอย่างที่สอง ก็ไม่มีอะไรน่าอายที่จะสร้างสิ่งที่มันควรจะเป็นมาตั้งแต่ต้น แอปที่ประสบความสำเร็จส่วนใหญ่อยู่ที่แกนหลักเวอร์ชัน 2 ไม่ใช่เวอร์ชัน 1