איך לא להפסיד חצי מיליון ש"ח בפיתוח אפליקציה

אני רוצה לשתף אתכם בסיפור שחשוב שכל יזם של אפליקצייה (ולא משנה אם היא לפלטפורמת Mobile, Desktop, Tablet, Embeded) יכיר. ומקרה שהיה, כך היה…

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

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

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

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

טעות מספר אחד: חשיבה פרויקטאלית.

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

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

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

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

"ולפעמים המשא ומתן מובילים אותנו נמוך…"

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

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

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

טעות מספר שתיים: "תעשה לי ילד"

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

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

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

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

מפתחים זרוע בעסק, לא "פרויקט"

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

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

לאחר עשרות רבות של פרויקטים שבחנתי, לפתע זה היה ברור. זה לא המאפיין, המעצב, המפתח, השיווק, הלקוח, מנכ"ל החברה, חוק מרפי… הבעיה היא תהליכית!

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

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

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

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

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

התחלתי ללמוד יותר ויותר על מתודות UX, Agaile, Lean startup במטרה לפצח את התהליך האידיאלי. במקביל, התחלתי ליזום אפליקציות משלי – תוך כדי שיוף המתודולוגיה. התוצאות היו טובות, והרגשתי מספיק בטוח כדי לספק שירותי אפיון וניהול כפרילנסר. בהתחלה עוד הייתי חשדן לגבי התוצאות, אולם אחרי שראיתי את זה שוב ושוב הבנתי שזה עובד – באפליקציות בהם השתמשתי במתודות החדשות עלויות הפיתוח פחתו בממוצע פי 3, ועלויות השיווק בחלקן פחתו פי 10. הבנתי שיש כאן משהו שאני חייב להפיץ, וזו הסיבה שהקמתי את Simply Ux.

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