שוב נפל הדמו בשישי בלילה? הנה כמה טיפים לסביבת דמו יציבה

הקמה של סביבות דמו יציבות שלא דורשות תחזוקה ופיתוח היא אתגר קשה. הנה כמה דרכים לענות על כל הצרכים של צוותי המכירות מבלי להעמיס על המפתחים שלכם

אי אפשר לסגור עסקה משמעותית בלי דמו למוצר (צילום: Demostack)

מאת בן סטרנסון, Backend Team Leader בחברת Demostack

פעם בכמה שבועות אנחנו עולים לכוננות עם פרודקשן באחריותנו, מוכנים לצלצול הטלפון או הודעת ה-slack שתקפיץ אותנו. ואז הם מתקשרים: "סביבת פרודקשן למטה ויש פגישה חשובה עם מקבלי ההחלטות של הלקוח בעוד שעה". אנחנו עוזבים הכל מיד, רצים למחשב ומתחילים במסע התחקור.

סיפורים כאלה מתרחשים לא מעט. יש לנו אחריות על כך שהמוצר יהיה זמין – לא רק עבור הלקוחות הרגילים, אלא גם עבור לקוח נסתר נוסף. יש לנו משתמשים פנימיים בארגון – אנשי מכירות שעושים שימוש בסביבה בשביל להציג את המוצר באור החיובי ביותר.

אף אחד מאיתנו לא חסין מטעויות – אנחנו עושים אותן ולומדים מהן. "מתי נעשה את הטעות שתפיל את הפרודקשן" זו לא שאלה של "אם" אלא שאלה של "מתי". ובכל זאת, זה פחות מעניין את מי שאחראי להציג את המוצר ולהראות את הערך שלו ללקוחות פוטנציאליים. אנשי המכירות מחפשים את העצמאות ואת הביטחון בלהציג מוצר מקצועי עם תוכן מלא (אי אפשר שהגרפים יהיו ריקים), בסביבה נקייה שהם יכולים לסמוך עליה כדי להביא את הלקוח הבא שישתמש במוצר הנפלא שבניתם.

הצרכים בסביבת דמו

כל זה מביא אותנו לעיקר: אי אפשר לסגור עסקה משמעותית בלי דמו למוצר – המקום שבו הלקוח הפוטנציאלי רואה לראשונה את הממשק ואת הערך שהוא יקבל. אנחנו קוראים לרגע הזה Magic Moment. היכולת של הצד העסקי ליצור את אותו Magic Moment, שבו הלקוח רואה את מה שיפתור את הכאב שלו, תלויה בשני מרכיבים עיקריים:

1. סביבה יציבה ומנוהלת: הלקוח צריך לראות מוצר בלי גליצ'ים, שזמין תמיד ולא מזמן הפתעות.
2. Data ופעילות במוצר שיספרו סיפור: ככל שהדמו יותר מותאם ללקוח כך הסיפור יהיה יותר חזק, והערך שיצרנו עבור הלקוח יהיה ברור לו.

אז למה כל כך קשה להרים סביבת דמו טובה? החיכוך נוצר כשצוות הפיתוח מקבל אחריות נוספת שלרוב לא מגיעה עם המשאבים המתאימים. מדובר בצרכים נוספים שלא מגיעים מלקוחות, אלא מאנשי המכירות, וכמעט תמיד אין תשתיות מתאימות עבורם (היכולת להכניס דאטה מזויף או להחליף מידע רגיש במידע דמה, לדוגמה). לרוב זאת עבודה מאוד ספציפית שלא מחזקת את המוצר והיכולות שלו, ולכן תמיד תהיה בתעדוף נמוך. מהצד שלנו, המתכנתים, זה בעיקר מלחיץ ותופס אותנו לא מוכנים. אנחנו בונים מוצר שנותן ערך ללקוחות, ולא מוצר שנועד להדגמה.

משיחות שערכנו עם מאות מנהלי צוותי מכירות עולים כמה צרכים עיקריים מסביבת הדמו:

  • זמינות – זה נורא מעצבן לשתף מסך בזום, להתחבר למערכת ולקבל 404. או לחלופין, לבצע את ה-flow ופתאום לראות שהספינר ממשיך וממשיך להסתובב.
  • בלי הפתעות מיותרות – אנשי מכירות אוהבים סביבה ידועה מראש ולא רוצים פיצ'רים שהם לא מודעים אליהם או לא יודעים להציג.
  • מניעת חשיפת מידע רגיש של לקוחות – היום, כש-GDPR והפרטיות במרכז, הצורך הזה נהיה קריטי. לדוגמה, לחברות עם מוצרים המכילים מידע רפואי רגיש יש קושי עצום להציג את המערכת שלהם ואת היתרונות שלה. נרצה מידע אנונימי, אבל כזה שעדיין מספר סיפור.
  • אפשרות לקסטם את המידע המוצג ללקוח – אין כמו לספר סיפור טוב עם מידע אמין שאפשר לערוך ולהתאים אותו ספציפית ללקוח שמציגים בפניו.
  • מידע עדכני – מידע שיראה אמיתי עם תאריכים מעודכנים.
  • יכולת להראות פיצ'רים עתידיים – כאלה שעדיין קיימים רק בסביבות הפיתוח.
  • הפרדה בין מציגים – ככל שהחברה גדולה יש יותר משתמשים שיציגו את המוצר. משתמשים שונים עשויים ללכלך אחד לשני את סביבת ההצגה או לגרום לעודף מידע.
  • ביצועים – זה מרשים אם הסביבה עובדת בצורה חלקה ומהירה בלי ספינרים מיותרים.

להשתמש במוצר האמיתי או להפריד בין הסביבות?

עכשיו, כשאנחנו מודעים לצרכים ולדרישות, אפשר לגשת לשני פתרונות אפשריים אך לא מושלמים.

שיטה ראשונה: נשתמש בסביבת פרודקשן ונציג את הדמו על המוצר האמיתי. אף אחד לא אוהב לתחזק שתי סביבות, ואנחנו למדנו את זה על בשרנו: זה מתחיל בקטן, ומבלי לשים לב קמים בוקר אחד ומגלים שפיתחנו מוצר נוסף. אנחנו כמתכנתים שואפים ל-source of truth יחיד, ובעולם אידיאלי זה באמת יכול להיות נחמד, אבל בעולם האמיתי זה קצת יותר מסובך. אז איך עושים את זה?

ראשית, צריך לשמור על זמינות המערכת והקצאת משאבים כך שלא יפגעו בחוויית הדמו. פיצ'רים חדשים נכנסים באופן רציף לסביבת פרודקשן, ומושלמים ככל שנהיה, אנחנו בני אדם ויגיע היום שבו ייכנס באג שיעשה בעיות בדיוק בזמן ההצגה. בנוסף, שחרור גרסאות דורש תזמון ותקשור של כל תכולת הגרסה לאנשי מכירות תוך וידוא מול צוותים שעשויים להכיל עשרות ומאות אנשים, ועליהם להבין את השינויים בזמן קצר.

שנית, נצטרך לדאוג ליצירת הרשאות לאנשים הרלוונטים לפי ארגון או משתמש וכדומה, ואת המשתמשים נצטרך לייצר ולתחזק. בשיטה זו יש חסרון: מהר מאוד נמצא שאנחנו מלכלכים את סביבת פרודקשן עם מידע נוסף שנשמר בדאטה בייס – עודף המידע עלול להאט את ביצועי הסביבה, לספק חוויה שתבלבל את הלקוח, תעמיס במידע לא רלוונטי וגם המחיר עלול להיות מושפע.

בנוסף, נרצה להראות מידע אמין שמספר סיפור ללקוח. תארו לכם מה תהיה חוויית המכירה במקרה בו נטען עמוד מלא גרפים, וכל הגרפים על אפס – מיד האשליה של מוצר אמיתי נשברת. בנוסף, רצוי שהמידע המוצג לא יחשוף בטעות מידע של לקוחות קיימים. את המידע האנונימי נצטרך לייצר באמצעות סקריפטים שנתחזק ונפעיל לפי דרישה.

שיטה שנייה: נפריד בין סביבת פרודקשן לסביבת הדמו, וכל סביבה תחייה בעולם משלה. הקמת סביבה נפרדת בהחלט יכולה להיות פתרון אופציונלי. כך נוכל להמשיך לקדם את המוצר ובמקביל, בחיים כמעט נפרדים, תהיה סביבת הדמו שלנו. סביבה זו לא תושפע משינויים שנדחפים לפרודקשן ומשתמשי הדמו לא יופתעו מפיצ'רים חדשים שלא הכירו.

הקושי כמובן הוא בתחזוק הסביבות. בשיטה הזאת אנחנו יוצרים סביבה נוספת שנמצאת בפיגור מסוים מסביבת פרודקשן, ומחכים לאישור של אנשי המכירות על כל גרסה. העברה של פיצ'רים בין סביבות תהפוך למסורבלת ולא פשוטה, ותיווצר תלות בין סרביסים וגרסאות שונות. בנוסף, צריך להקים סרביסים כשהם מתווספים לפרודקשן ויש מגרציות שצריך לזכור להריץ.

לצד כל אלה, אנחנו בעידן מרובה microservices, כלי ניטור ובקרה שלכל אחד מהם תפקיד ייעודי בשמירה על סביבת פרודקשן יציבה וזמינה. כל סרביס מוסיף מורכבות ומייקר את העלויות, וכאשר משכפלים את הסביבות ודואגים לזמינות שלהן, אנחנו בקלות עלולים לחרוג מהתקציב.

נוכל לנסות לחסוך עלויות בשתי שיטות:
1. תעדוף פיצ'רים לפרונט ללא תשתית בקאנד – זה יחסוך לנו עליות גבוהות בהקמת סרביסים עם זמינות גבוהה. בשביל להראות גרף עולה לאורך כמה חודשים אין צורך למלא את הדאטה בייס בהרבה איוונטים, אבל כמובן צריך להתאים את המוצר לעבוד במוד כזה.
2. כיבוי services שאינם בשימוש או יצירה של mockים – שיטה זו דורשת הכרה של כלל המערכת והתקשורת שמתבצעת בין הסרביסים השונים. בנוסף, התחכמות כזו דורשת תחזוקה בכל פעם שהמוצר משתנה.

ליצור את הפתרון האידיאלי

לכל אחת מההצעות הללו ישנם יתרונות וחסרונות, אבל אם ניקח צעד אחורה, נזכור שהמטרה העיקרית שלנו היא לפתח דברים חדשים. הבעיה היא שבמקום לפתח דברים ללקוחות, המשאבים "מתבזבזים" בפיתוח דמו שאינו מוסיף ערך ללקוח.

אז איך נראה הפתרון האידיאלי? ננסה להגדיר אותו:

  • סביבת הדמו תתנהג בדיוק כמו פרודקשן, אבל תהיה נפרדת ממנה ולא תלויה בה.
  • סביבת הדמו תתעדכן בקלות ללא צורך בפיתוח – יהיה נחמד אם המציג יוכל לבחור מתי לשכפל את סביבת הפרודקשן בלחיצת כפתור, וכך גם ידע בדיוק מה מכילה הגרסה.
  • עריכה קלה ופשוטה, ממש כמו ב-Wix – נוכל לערוך טקסט, גרפים, תמונות וכל מה שנרצה.
  • ייצור של גרסאות מקוסטמות בפשטות, מהיום להיום, שלא ישפיעו על העמיתים שלי שמבצעים גם הם הדגמות.
  • שמירה על גרסאות קודמות בדומה ל-Git, כדי שנוכל תמיד לחזור לגרסה אחרת.
  • שיתוף הדמו וקבלת אנליטיקות בצורה קלה ונוחה, בלי לדאוג להרשאות מיותרות או דליפת מידע.
  • הדגמה פשוטה של פיצ'רים חדשים ואינטגרציות עם מוצרים.

בשוק קיימים כמה פתרונות שיכולים לעזור בהקמת סביבת דמו כזאת:

1. כלי תשתית כקוד (Infrastructure as Code) והקמת סביבה מקבילה לפרודקשן, כגון Terraform ו-Velocity.
2. כלים כגון Tonic.ai שיודעים לייצר פייק דאטה בסקייל.
3. כלים כגון Figma ו-Wix המשמשים ליצירת חוויה של אתר מקורי.
4. כלים ליצירת סביבת דמו מסביבת פרודקשן.

בעזרת כל אלה נוכל לפתור את הבעיות וליצור את הפתרון האידיאלי לפיתוח דמו. אתרים שאנחנו גולשים אליהם מכילים resources שונים כגון קבצי js ,html ו-css, שכאשר מחברים את כולם יחד הם מציגים את הדבר המופלא הזה שנקרא אתר.

אם ננתב את תעבורת הרשת דרך שרת (פרוקסי) שישמור את הקבצים הללו, נוכל למעשה להגיש את האתר ב-sandbox נפרד שייתן חוויה של אתר שמתפקד באופן זהה לאתר המקורי, רק שהוא מופרד מהבקאנד המקורי.

מעל ה-sandbox נוכל להוסיף כלי עריכה שיאפשרו לערוך את האתר בצורה המיטבית שתביא אותנו ל-Magic Moment.

הקמה של סביבות דמו יציבות שלא דורשות תחזוקה ופיתוח היא אתגר קשה. אם בחרתם להקים סביבת דמו בעצמכם, בשימוש בסביבת פרודקשן או שהלכתם על שימוש במוצר צד שלישי, המשימה הזו לא פשוטה ודורשת תכנון, מחקר והכרה של המערכת והתקשורת. השיטות והכלים שהוזכרו במאמר זה הם התחלה טובה – למדו את הצרכים ואת נקודות הכאב של המשתמשים שלכם, ועזרו להם להגיע לפגישת המכירה בצורה הטובה ביותר.

הכתבה בחסות Demostack

Demostack מציעה לחברות תוכנה כלי הדגמה (דמו) מקורי וחדשני לשימוש אנשי הפרודקט והמכירות. הטכנולוגיה שפיתחה החברה מסוגלת "להקליט" את הפרונט-אנד של כל אתר ולהפרידו מהבק-אנד ועל ידי כך ליצור הדמייה המשקפת את הגרסה המקורית. באופן הזה, אנשי המכירות יכולים לבצע שינויים על הפרונט-אנד של הלקוח הפוטנציאלי בקלות ובמהירות, לפי צורכי ההדגמה. הסטארטאפ הוקם בשנת 2020 על ידי יונתן פרידמן, אהרון בר חכים וגלעד אבידן, וגייס עד כה למעלה מ-20 מיליון דולר. החברה מתפתחת במהירות, ומעסיקה כיום יותר מ-65 עובדים בישראל, ארה"ב ואירופה. החברה ממשיכה במהלך נרחב לגיוס עשרות עובדי פיתוח נוספים.
לפרטים וצפייה במשרות הפתוחות לחצו כאן

כתב אורח

אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.

הגב

7 תגובות על "שוב נפל הדמו בשישי בלילה? הנה כמה טיפים לסביבת דמו יציבה"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי:   חדש | ישן | הכי מדורגים
עידודי
Guest

לא יותר פשוט להשתמש ב Camtasia או Youtube ודומיהם לדמו ?

בן סטרנסון
Guest

וידאו זה נחמד, אבל מה קורה אם תרצה להתאים את הוידאו ללקוח? עריכה של הודיאו יכולה להפוך ליותר מסורבלת. או איך אתה מעדכן את הוידאו אם נוסף פיצ׳ר חדש? שוב תעשה סרטון חדש?

מעבר לזה, הרעיון הוא לתת חוויה של אתר אמיתי שעובד. איש מכירות מראה את הפלטפורמה ברוב המקרים בlive ומדגים פעילות של משתמש קיים שיכול ללחוץ על עמודים שונים לאו דווקא בסדר מסוים.

מאור עסיס
Guest

אבל אז איך אתה עושה קסטומיזציה ללקוח ספציפי? תעשה וודיאו נפרד לכל לקוח ולקוח , זה יהיה לא סקיילבילי בעליל.

אבי
Guest

פיייי מעניין תודה על המידע

וולי
Guest

או פשוט להשתמש ב walnut

אביתר
Guest

השוואנו בין וולנט ודמוסטאק. וולנט מוצר נחות בהרבה. הדמו שלהם זה כמו כמה צילומי מסך, לעומת דמוסטאק שהמערכת שלך אשכרה עובדת כרגיל.

פסטיבל מספרי סיפורים
Guest
פסטיבל מספרי סיפורים

כלל פשוט. אם המוצר שלכם לא מספיק יציב לדמו הפתרון כנראה זה לא להשקיע יותר בסביבת דמו אלא לטפל במוצר. מטרת הדמו היא מכירה וכמה שיותר מהר, אז מה הטעם למכור למישהו שישתמש כל יום אם זה לא יציב ל20 דקות ?
הבעיות שמוזכרות כולו מוכרות ונכונות והן חלק מתהליך בנייה של סטארטאפ , אם שנה לתוך המוצר זה עדיין בעיה חריפה סביבת דמו יציבה זה לא מה שיעזור לסטארטאפ הזה כי כנראה גם מכירות אין ממש וזאת כבר בעיה שהורגת סטארטאפים.

wpDiscuz

תגיות לכתבה: