ผมได้เห็นสามคนที่แตกต่างกันจัดการหน้าจอเดียวกันผิดพลาด — การ์ดแผนงานที่ปรากฏขึ้นระหว่างพรอมต์ของคุณกับการสร้าง — แต่ละคนต้องจ่ายราคาในสกุลเงินที่ต่างกัน คนหนึ่งจ่ายด้วยการสร้างใหม่ อีกคนจ่ายด้วยการพิมพ์ที่เสียเปล่า อีกคนจ่ายด้วยผลิตภัณฑ์ที่ทำสิ่งที่พวกเขาต้องการจริงๆ ไม่ได้ การ์ดแผนงานคือช่วงเวลาที่ถูกที่สุดในกระบวนการทั้งหมดที่จะเปลี่ยนใจ และนั่นเองที่ทำให้มันง่ายที่จะข้ามผ่านไปโดยไม่ทันสังเกต
ข้อผิดพลาดที่หนึ่ง: อนุมัติแบบขอไปที
นี่คือข้อผิดพลาดที่พบบ่อยที่สุด โครงสร้างดูถูกต้อง กดอนุมัติ แล้วไปต่อ — ผมทำแบบนี้อยู่หลายสัปดาห์ก่อนที่มันจะย้อนกลับมากัดผม การสร้างที่ทำให้ผมเลิกนิสัยนี้ในที่สุดคือ Stripe checkout ที่เชื่อมต่อกับเว็บไซต์แบบสแตติกที่ไม่มีที่เก็บสถานะบัญชีที่ Stripe ต้องการ แผนงานระบุไว้ว่า ประเภทผลิตภัณฑ์: เว็บไซต์แบบสแตติก เป็นข้อความธรรมดา อยู่ตรงนั้นบนการ์ด และผมก็เลื่อนผ่านมันไปเพราะรายการหน้าดูโอเค และผมกำลังรีบ
ซากปรักหักพังจากข้อผิดพลาดนี้มีรูปแบบเดียวกันเสมอ: ทุกอย่างที่อยู่หลังแผนงานถูกต้อง ตามแผนงานนั้น ดังนั้นความล้มเหลวจึงไม่ปรากฏเป็นข้อผิดพลาด แต่ปรากฏเป็นการสร้างที่ทำงานได้แต่ผิดโครงสร้าง ไม่มีใครตั้งข้อสังเกตเพราะไม่มีอะไรพัง — เว็บไซต์แบบสแตติกที่มีปุ่มเช็คเอาต์ก็แค่ทำสิ่งผิดๆ อย่างเงียบๆ หรือล้มเหลวในช่วงเวลาเดียวที่ผู้ใช้จริงกด "จ่ายเงิน" คุณจะพบมันในขั้นตอนรีวิว ซึ่งเป็นจุดที่แพงที่สุดที่จะค้นพบ
ข้อผิดพลาดที่สอง: ระบุรายละเอียดมากเกินไปเพื่อหลีกเลี่ยงรอบที่สอง
ข้อผิดพลาดที่ตรงกันข้ามดูมีความรับผิดชอบมากกว่าแต่ไม่ใช่ บางคนหลังจากโดนพิษจากข้อผิดพลาดที่หนึ่งก็แก้ไขมากเกินไปด้วยการเขียนข้อกำหนดที่แม่นยำเป็นย่อหน้าในขั้นตอนแผนงาน — ข้อความที่แม่นยำ ความชอบเรื่องระยะห่าง ฟีเจอร์ที่ควรและไม่ควรมีอย่างแน่นอน เขียนในลักษณะเอกสารสเปก ผมเองก็เคยทำแบบนี้เช่นกัน จากความกังวลคลุมเครือว่าการข้ามรายละเอียดตอนนี้หมายถึงการ "เสียเปล่า" รอบการสร้างในภายหลัง
มันกลับตาลปัตร และนี่คือเหตุผล: แผนงานจะถูกแก้ไขอีกครั้งเมื่อคุณเห็นหน้าจริง ไม่ว่าคุณจะระมัดระวังแค่ไหนในครั้งแรก และเมื่อมันถูกแก้ไข คุณจะไม่ได้รับ diff ของสิ่งที่เปลี่ยนแปลง — คุณจะได้การ์ดใหม่ที่รวมการแก้ไขของคุณไว้แล้ว จบ ไม่มีบันทึกการแก้ไข ดังนั้นความแม่นยำที่คุณพิมพ์ในรอบที่หนึ่งก็ไม่รอดมาถึงรอบที่สองแบบสมบูรณ์อยู่ดี คุณต้องอ่านทุกอย่างใหม่อีกครั้งไม่ว่าจะทางไหน สองหรือสามรอบของ "ไม่ใช่ แบบนี้ต่างหาก" จะทำให้คุณได้ผลลัพธ์ที่ดีกว่า เร็วกว่าในแง่เวลาจริง เมื่อเทียบกับบรีฟที่ครอบคลุมทุกอย่างเพียงชิ้นเดียว แม้ว่าการเขียนบรีฟจะรู้สึกมีประสิทธิภาพมากกว่าในขณะที่กำลังทำอยู่ก็ตาม
การแก้ไขด้วยภาษาธรรมดาที่ได้ผลจริงๆ มักจะสั้น:
- "ตัดบล็อกออก เพิ่มหน้าราคา" — สลับรายการหน้าได้อย่างเรียบร้อย
- "เปลี่ยนเป็นสองผู้เล่นแทนที่จะเป็นผู้เล่นคนเดียว" — ใหญ่กว่าที่ฟังดู มันสามารถส่งผลต่อโมเดลข้อมูล ตอนนี้ต้องติดตามผู้เข้าร่วมสองคนแทนที่จะเป็นหนึ่งคน และแผนงานที่แก้ไขแล้วจะแสดงผลกระทบต่อเนื่องนั้นแทนที่จะซ่อนมันไว้
- "สิ่งนี้ต้องการระบบบัญชีผู้ใช้" — ถ้าแผนงานปัจจุบันเป็นเว็บไซต์แบบสแตติก นี่คือประโยคที่จะบังคับให้เกิดคำถามเรื่องประเภทผลิตภัณฑ์โดยตรง
ข้อผิดพลาดที่สาม: ปฏิบัติต่อประเภทผลิตภัณฑ์เป็นฟิลด์ที่ยืดหยุ่นได้
นี่คือข้อผิดพลาดที่แพงที่สุด และมันแพงเพราะทุกอย่างอื่นบนการ์ดสามารถกู้คืนได้จริง หน้า ฟีเจอร์ที่อนุมาน คำถามแยกส่วนใหญ่ — ล้วนแก้ไขได้ด้วยการทำเวอร์ชันซ้ำหลังจากการสร้างเสร็จสิ้น ประเภทผลิตภัณฑ์ทำไม่ได้ มีสี่หมวดหมู่:
| ประเภทผลิตภัณฑ์ | หมายความว่าอย่างไร |
|---|---|
| เว็บไซต์แบบสแตติก | แบบธรรมดา ไม่มีตรรกะฝั่งเซิร์ฟเวอร์ |
| แอปที่ติดตั้งได้ | รูปแบบ PWA — ใช้งานออฟไลน์ได้ เพิ่มลงหน้าจอหลักได้ ยังคงไม่มีตรรกะฝั่งเซิร์ฟเวอร์ |
| บิลด์แบบเฟรมเวิร์ก | รูปแบบ React/Next มีปฏิสัมพันธ์ฝั่งไคลเอนต์มากขึ้น ยังคงไม่มีแบ็กเอนด์ถาวร |
| แอปที่มีเซิร์ฟเวอร์รองรับ | หนึ่งเดียวในสี่หมวดหมู่ที่มีฐานข้อมูลและระบบบัญชีจริงๆ อยู่เบื้องหลัง |
อนุมัติแผนงานเว็บไซต์แบบสแตติก แล้วสามเวอร์ชันต่อมาตัดสินใจว่าต้องการระบบล็อกอิน นั่นไม่ใช่การอัปเดตเวอร์ชัน — มันคือการสร้างใหม่จากประเภทผลิตภัณฑ์ที่ต่างออกไป และคุณจะสูญเสียความต่อเนื่องที่ประวัติเวอร์ชันมอบให้กับทุกอย่างอื่น
ผู้คนทำผิดพลาดเรื่องนี้ในสองแบบ อย่างแรก พวกเขาไม่ตรวจสอบพรอมต์ของตัวเองกับฟิลด์นี้ — ถ้าพรอมต์ของคุณมีคำว่า "บัญชี" "ล็อกอิน" "บันทึก" "แดชบอร์ดที่อัปเดต" "การชำระเงิน" หรือ "ผู้ใช้หลายคนแก้ไขสิ่งเดียวกัน" และการ์ดไม่ได้ระบุว่ามีเซิร์ฟเวอร์รองรับ นั่นคือการแก้ไขหนึ่งเดียวที่คุ้มค่าที่จะทำก่อนอนุมัติ ไม่มีข้อยกเว้น อย่างที่สอง พวกเขาสับสนระหว่างแอปที่ติดตั้งได้กับการสร้างด้วยเฟรมเวิร์ก เพราะทั้งสองอย่าง รู้สึก เหมือนเป็น "แอป" ในการสนทนาทั่วไป แต่มันใช้แทนกันไม่ได้: แอปที่ติดตั้งได้เหมาะกับเครื่องมือที่สถานะทั้งหมดอยู่บนอุปกรณ์ของผู้ใช้ — เครื่องคำนวณทิป ตัวจับเวลาออกกำลังกาย การสร้างด้วยเฟรมเวิร์กหมายถึงปฏิสัมพันธ์และโครงสร้างคอมโพเนนต์ที่มากขึ้น แต่ก็ยังไม่มีอะไรคงอยู่ฝั่งเซิร์ฟเวอร์ข้ามเซสชันหรืออุปกรณ์ ทั้งสองอย่างไม่ใช่ "แอป" ในความหมายที่มีบัญชีและข้อมูลที่ติดตามคุณข้ามอุปกรณ์ — มีเพียงแบบมีเซิร์ฟเวอร์รองรับเท่านั้นที่เป็นเช่นนั้น และการจัดสรรเกินความจำเป็นไปเป็นแบบมีเซิร์ฟเวอร์รองรับ "เผื่อไว้ก่อน" สำหรับเว็บไซต์พอร์ตโฟลิโอหรือหน้าเอกสารก็ไม่ใช่ทางเลือกที่ปลอดภัยเช่นกัน การลดระดับในภายหลังก็เป็นการสร้างใหม่เท่ากับการอัปเกรดเช่นกัน
สิ่งที่เหลืออยู่เมื่อคุณเลิกทำสามอย่างนั้น
เมื่อคุณไม่ได้อ่านผ่านๆ บรรทัดประเภทผลิตภัณฑ์ ไม่ได้เขียนสเปกในขั้นตอนแผนงาน และไม่ได้ปฏิบัติต่อภาษาเกี่ยวกับบัญชี/ข้อมูล/การชำระเงินในพรอมต์ของคุณเองว่าต่อรองได้ สิ่งที่เหลืออยู่คือการตรวจสอบที่รวดเร็วและแคบ:
- อ่านประเภทผลิตภัณฑ์
- ตรวจสอบข้ามกับพรอมต์ของคุณ
- อ่านผ่านรายการฟีเจอร์ที่อนุมานเพื่อหาอะไรก็ตามที่คุณจะปฏิเสธทันทีที่เห็น
รายการนี้มีอยู่ก็เพราะพรอมต์อย่าง "เครื่องมือจัดตารางนัดหมายสำหรับร้านทำผม" จะดึงเอาสิ่งที่คุณไม่ได้พิมพ์เข้ามาด้วย — มุมมองปฏิทินและการแจ้งเตือนทาง SMS และรายชื่อลูกค้า บางอย่างคุณตั้งใจให้มี และบางอย่างคือขอบเขตที่บวมขึ้นซึ่งโมเดลเพิ่มเข้ามาเพราะฟีเจอร์เหล่านั้นมักปรากฏร่วมกันทางสถิติ ตัดสิ่งที่ไม่เข้าพวกออกในประโยค ที่นี่ แทนที่จะทำหลังจากมันถูกสร้างไปแล้ว
ทุกอย่างอื่น — ข้อความ ระยะห่าง สีเน้นแบบไหน ปุ่มจะเขียนว่า "เริ่มต้นใช้งาน" หรือ "ลองใช้ฟรี" — ไม่ได้อยู่บนการ์ดเลย โดยตั้งใจ สิ่งเหล่านั้นเป็นเรื่องที่ดูและแก้ไขได้ง่ายบนการสร้างที่ใช้งานได้จริงแล้ว ดังนั้นการ์ดจึงไม่เสียความสนใจของคุณไปกับมัน และคุณก็ไม่ควรทำเช่นนั้นเหมือนกัน นั่นคือประมาณสิบห้าวินาทีของการตัดสินใจที่แท้จริงภายในสามสิบวินาทีที่ใช้อ่านสิ่งนั้น
