ראיתי שלושה אנשים שונים מתמודדים לא נכון עם אותו מסך של שלושים שניות - כרטיס התוכנית שמופיע בין ההנחיה שלכם לבנייה - וכל אחד מהם שילם על כך במטבע שונה. אחד שילם בבנייה מחדש. אחד שילם בהקלדה מבוזבזת. אחד שילם במוצר שלא יכול היה לעשות את מה שהוא באמת היה צריך. כרטיס התוכנית הוא הרגע הזול ביותר בכל התהליך לשנות את דעתכם, ומשום מה בדיוק זה מה שהופך אותו לקל כל כך לדלג עליו בחיפזון.
טעות ראשונה: אישור אוטומטי ללא בדיקה
זו הטעות הנפוצה. השלד נראה תקין, לוחצים אישור, ממשיכים הלאה - עשיתי את זה במשך שבועות לפני שזה נשך אותי. הבנייה שסוף סוף שברה את ההרגל חזרה עם קופת תשלום של Stripe שחוברה לאתר סטטי שלא היה בו מקום לאחסן את מצב החשבון ש-Stripe נזקק לו. התוכנית אמרה סוג מוצר: אתר סטטי בטקסט רגיל, ממש שם על הכרטיס, ואני דילגתי על זה כי רשימת העמודים נראתה בסדר והייתי בחיפזון.
ההריסות מהטעות הזו תמיד באות באותה צורה: כל מה שבמורד הזרם מהתוכנית נכון בהינתן התוכנית, כך שהכשל לא מתגלה כשגיאה, הוא מתגלה כבנייה עובדת שהיא שגויה מבחינה מבנית. אף אחד לא מסמן את זה כי שום דבר לא שבור - אתר סטטי עם כפתור תשלום פשוט עושה את הדבר הלא נכון בשקט, או נכשל ברגע היחיד שבו משתמש אמיתי לוחץ על "שלם". מגלים את זה בבדיקה, שזה המקום היקר ביותר לגלות בו.
טעות שנייה: פירוט יתר כדי להימנע מסיבוב שני
הכשל ההפוך נראה אחראי יותר ואינו כזה. חלק מהאנשים, אחרי שנכוו מהטעות הראשונה, מתקנים יתר על המידה על ידי כתיבת פסקה שלמה של דרישות מדויקות בשלב התוכנית - טקסט מדויק, העדפות ריווח, אילו תכונות בהחלט צריכות ולא צריכות להתקיים, מנוסח כמו מסמך מפרט. גם אני עשיתי את זה, מתוך חרדה מעורפלת שדילוג על פרטים עכשיו פירושו "בזבוז" של סיבוב בנייה מאוחר יותר.
זה הפוך, והנה למה: התוכנית עומדת להיערך מחדש שוב ברגע שתראו את העמודים בפועל, לא משנה כמה זהירים הייתם בפעם הראשונה. וכשהיא נערכת מחדש, אתם לא מקבלים דיף של מה שהשתנה - אתם מקבלים כרטיס חדש שכבר משלב את העריכה שלכם, וזהו, בלי הערות שינוי. אז הדיוק שהקלדתם בסיבוב הראשון לא שורד בשלמותו לסיבוב השני בכל מקרה; אתם קוראים את הכול מחדש בכל מקרה. שני-שלושה סיבובים של "לא, ככה" מביאים אתכם לתוצאה טובה יותר, מהר יותר בזמן שעון קיר, מבריף מקיף אחד - למרות שכתיבת הבריף מרגישה יעילה יותר בזמן שעושים אותה.
העריכות בשפה פשוטה שבאמת עובדות הן קצרות:
- "תוריד את הבלוג, תוסיף עמוד תמחור" - מחליף את רשימת העמודים בצורה נקייה.
- "תהפוך את זה לדו-שחקנים במקום שחקן יחיד" - גדול יותר משנשמע. זה יכול לגעת במודל הנתונים, שעכשיו עוקב אחרי שני משתתפים במקום אחד, והתוכנית המעודכנת תציג את האפקט המתגלגל הזה במקום להסתיר אותו.
- "זה צריך חשבונות משתמש" - אם התוכנית הנוכחית היא אתר סטטי, זה המשפט שכופה את שאלת סוג המוצר בצורה מפורשת.
טעות שלישית: התייחסות לסוג המוצר כשדה גמיש
זו הטעות היקרה, והיא יקרה כי כל דבר אחר בכרטיס באמת ניתן לתיקון. עמודים, תכונות מוסקות, רוב ההסתעפויות בשאלות - כולם ניתנים לתיקון עם איטרציית גרסה אחרי שהבנייה נוחתת. סוג המוצר לא. יש ארבע קטגוריות:
| סוג המוצר | מה זה אומר |
|---|---|
| אתר סטטי | פשוט, ללא לוגיקת שרת. |
| אפליקציה להתקנה | בסגנון PWA - עובדת אופליין, ניתנת להוספה למסך הבית, עדיין ללא לוגיקת שרת. |
| בנייה מבוססת מסגרת עבודה | בסגנון React/Next, אינטראקטיביות לקוח כבדה יותר, עדיין ללא backend קבוע. |
| אפליקציה מגובה שרת | היחיד מבין הארבעה עם מסד נתונים אמיתי ומערכת חשבונות מאחוריו. |
אישרו תוכנית של אתר סטטי, ובעוד שלוש גרסאות תחליטו שאתם רוצים התחברות, וזה לא עדכון גרסה - זו בנייה מחדש מסוג מוצר שונה, ואתם מאבדים את הרציפות שהיסטוריית הגרסאות סיפקה לכל השאר.
אנשים טועים בזה בשתי דרכים. ראשית, הם לא בודקים את ההנחיה שלהם עצמם מול השדה - אם ההנחיה שלכם מכילה "חשבונות", "התחברות", "שמירה", "לוח מחוונים שמתעדכן", "תשלומים", או "מספר משתמשים עורכים את אותו דבר", והכרטיס לא אומר מגובה שרת, זו העריכה היחידה ששווה לעשות לפני שאתם מאשרים, ללא יוצא מן הכלל. שנית, הם מבלבלים בין אפליקציה להתקנה לבין בנייה מבוססת framework, כי שתיהן מרגישות כמו "אפליקציה" בשיחה יומיומית. הן לא ניתנות להחלפה: אפליקציה להתקנה מתאימה לכלי שכל המצב בו חי במכשיר של המשתמש - מחשבון טיפים, טיימר אימונים. בנייה מבוססת framework אומרת אינטראקטיביות ומבנה רכיבים רבים יותר אבל עדיין שום דבר לא נשמר בצד השרת בין הפעלות או מכשירים. אף אחת מהן היא לא "אפליקציה" במובן של חשבונות ונתונים שעוקבים אחריכם בין מכשירים - רק מגובה שרת עושה זאת. ופרספת יתר למגובה שרת "ליתר ביטחון" עבור אתר תיק עבודות או עמוד תיעוד גם היא לא הבחירה הבטוחה; שדרוג לאחור מאוחר יותר הוא בדיוק אותה מידה של בנייה מחדש כמו שדרוג קדימה.
מה נשאר אחרי שמפסיקים לעשות את שלוש הטעויות האלה
ברגע שאתם לא עוברים במהירות על שורת סוג המוצר, לא כותבים מפרט בשלב התוכנית, ולא מתייחסים לשפת חשבון/נתונים/תשלום בהנחיה שלכם עצמכם כאל דבר הניתן למשא ומתן, מה שנשאר זו בדיקה מהירה וממוקדת:
- קראו את סוג המוצר.
- השוו אותו מול ההנחיה שלכם.
- עברו על רשימת התכונות המוסקות ותפסו כל דבר שהייתם דוחים במבט ראשון.
הרשימה קיימת בדיוק בגלל שהנחיה כמו "כלי תזמון למספרות" מושכת דברים שלא הקלדתם - תצוגת לוח שנה ותזכורות SMS ורשימת לקוחות, חלק מהם התכוונתם אליהם וחלק זו התרחבות היקף שהמודל הוסיף כי תכונות אלה נוטות סטטיסטית להופיע יחד. גזמו את מה שלא שייך במשפט, כאן, במקום אחרי שזה כבר נבנה.
כל השאר - טקסט, ריווח, איזה גוון של צבע הדגשה, האם הכפתור אומר "התחילו" או "נסו בחינם" - לא מופיע בכרטיס בכלל, בכוונה. אלה זולים לראות ולתקן על בנייה עובדת, אז הכרטיס לא מבזבז את תשומת הלב שלכם עליהם, וגם אתם לא צריכים. זה אולי חמש עשרה שניות של שיקול דעת אמיתי בתוך שלושים השניות שלוקח לקרוא את זה.
