איך לעבוד באופן מוצלח עם חברה לפיתוח אפליקציות?

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

apps mobile

מאת ארז פייגנברג

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

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

למה זה קורה?

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

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

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

העיצוב הפך למלך החדש

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

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

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

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

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

הכותב הינו מומחה לפיתוח MVP, מנטור ליזמים והמנכ״ל של MVP HOUSE

כתב אורח

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

הגב

4 תגובות על "איך לעבוד באופן מוצלח עם חברה לפיתוח אפליקציות?"

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

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

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

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

Erez Feigenberg
Member

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

עופר
Guest
כתבה מאוד מקצועית ולעניין. כל אדם שאינו מהתחום, בבואו לבחור חברת פיתוח, צריך לקרוא אותה. אגב, מסיבות אלו (בעיקר) כדאי ליזמים לא-טכניים להכניס את המפתח הראשון (אחד או שניים) כשותף. לשותף אין ניגוד אינטרסים. היבט חשוב נוסף, שהכתבה נגעה בו במשפט אחד בהתחלה אבל לא התייחסה אליו לאחר מכן, הוא אספקטים “לא נראים” של האפליקציה – אבטחה וביצועים. היזם חייב יועץ טכני מטעמו שיידע גם להגדיר את הדרישות, וגם לוודא את ביצוען, אחרת (במקרה של כשל אבטחה) הוא עלול למצוא את עצמו במצב דומה למה שקרא ל-Remini. מישהו יום אחד ישתה לו את כל הדטהבייס עם פרטיהם יקרי-הערך של המשתמשים… Read more »
יוסי
Guest

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

wpDiscuz

תגיות לכתבה: