חברת פיתוח אפליקציות: שמונה שאלות לפני שחותמים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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