הצעת מחיר לאוטומציה בלי הגדרה מדויקת היא ניחוש משני הצדדים. 15 השאלות שחייבות תשובה - נתונים, חריגים, נפח, בעלות ותחזוקה.
עיקרי הדברים
- רוב חריגות התקציב באוטומציה נובעות מנתונים, לא מלוגיקה.
- חריג שלא הוגדר מראש הופך לפיתוח נוסף אחרי ההשקה, בכל פעם.
- נפח הוא שאלה טכנית עם השלכת מחיר - 50 רשומות ו-50,000 אינן אותו פרויקט.
- מי מחזיק את הגישות ומי מתחזק אחרי המסירה הן שאלות שצריך לענות לפני, לא אחרי.
- תשובה "עוד לא יודעים" היא תשובה לגיטימית - בתנאי שהיא נרשמת כהנחה.
הצעת מחיר לאוטומציה שניתנת אחרי שיחה של עשרים דקות היא ניחוש, ושני הצדדים יגלו זאת באמצע. מה שמייצר את הפער אינו חוסר מקצועיות אלא שאלות שלא נשאלו - כמעט תמיד אותן שאלות, וכמעט תמיד באותם שלושה תחומים: נתונים, חריגים ותחזוקה.
חמש שאלות על התהליך
- מה קורה היום, צעד אחר צעד, כולל מי עושה כל צעד.
- מה הטריגר - מה מתחיל את התהליך, ומתי בדיוק.
- מה התוצאה הסופית, במונחים שאפשר לבדוק.
- מי משתמש בתוצאה, ומה הוא עושה איתה.
- מה קורה כשזה נגמר - תיעוד, הודעה, או כלום.
שווה לענות על החמש בכתב ולא בשיחה. תשובה מדוברת נשמעת שלמה גם כשהיא אינה, ותשובה כתובה חושפת מיד היכן חסר שלב - וזה בדיוק מה שמחפשים בשלב הזה.
השאלה הראשונה נשמעת מיותרת והיא החשובה מכולן. תיאור צעד-אחר-צעד של המצב הקיים חושף בממוצע שניים-שלושה שלבים שאיש לא הזכיר בשיחה הראשונה, כי הם "מובנים מאליהם" - והם בדיוק אלה שמייצרים את הפער בהערכה.
חמש שאלות על הנתונים
| השאלה | מה היא חושפת |
|---|---|
| מאיפה הנתונים מגיעים? | האם יש ממשק בכלל |
| באיזה מבנה? | קובץ, API, או מסך שצריך לקרוא |
| כמה רשומות, ובאיזה קצב? | מגבלות קצב ועיצוב שונה לחלוטין |
| מה מזהה רשומה ייחודית? | בלי מפתח אין מניעת כפילויות |
| כמה נקיים הנתונים היום? | לרוב זו העבודה האמיתית |
השורה האחרונה היא המפתיעה. בפרויקטים רבים ניקוי והתאמת הנתונים גדולים מהבנייה עצמה, וההיקף שלהם מתברר רק כשמסתכלים על הנתונים האמיתיים - לא על תיאור שלהם. לכן שווה לבקש דגימה לפני ההצעה, וההיגיון המלא של ניקוי מתואר בניקוי נתוני לקוחות.
חמש שאלות על החריגים והתחזוקה
- מה קורה כשהנתון חסר - לעצור, לדלג, או להתריע?
- מה קורה כשהמערכת השנייה לא זמינה - לנסות שוב, כמה פעמים, ואז מה?
- אילו חריגים ידועים קיימים היום, ומי מטפל בהם?
- מי מקבל התראה כשמשהו נכשל, ובאיזה ערוץ?
- מי מתחזק אחרי המסירה, ומה כלול?
שתי השאלות הראשונות הן ההבדל בין אוטומציה לבין סקריפט. תהליך שלא הוגדר לו מה קורה בכישלון ייכשל בשקט, וזה המצב היקר ביותר - מתגלה שבועות אחר כך, אחרי שהנתונים כבר לא מסונכרנים.
מה שאלת הנפח באמת קובעת
"כמה רשומות" נשמעת כשאלה טכנית שאין לה השלכה עסקית, והיא אחת השאלות שמשנות מחיר יותר מכל אחרת. תהליך שמטפל ב-50 רשומות ביום יכול לרוץ בפשטות מלאה: אחת אחרי השנייה, בלי תורים ובלי ניהול כישלונות מורכב.
אותו תהליך על 50,000 רשומות הוא פרויקט אחר לחלוטין. נכנסות לתמונה מגבלות קצב של הצד השני, צורך בעיבוד במנות, המשך מנקודת הכישלון במקום התחלה מחדש, וניטור שמראה התקדמות. אף אחת מהדרישות האלה אינה מיותרת בנפח הזה, וכולן מיותרות בנפח הקטן.
לכן שאלת הנפח שייכת לשיחה הראשונה, יחד עם שאלה משלימה: האם הנפח צפוי לגדול, ובאיזה קצב. בנייה שמתאימה בדיוק להיום ולא לשנה הבאה היא החלטה לגיטימית - בתנאי שהיא התקבלה ולא קרתה במקרה.
מה לכתוב במסמך ההגדרה
חמישה חלקים מספיקים: התהליך הקיים, התהליך הרצוי, מקורות הנתונים, רשימת החריגים והתנהגותם, ומה מחוץ להיקף. החלק האחרון חשוב לא פחות מהראשון - "מה לא נעשה" הוא מה שמונע את הוויכוח בסוף.
מי שמזמין פרויקט בלי מסמך כזה משלם עליו בכל מקרה, רק מאוחר יותר ובצורת שינויים. ההחלטה הרחבה יותר בין רכישת כלי לבין בנייה נדונה בלקנות כלי או לבנות אוטומציה.
מה קורה כשחלק מהתשובות מגיע ממערכת שאינה שלכם
חלק ניכר מפרויקטי האוטומציה נוגע במערכת שהעסק אינו מפעיל בעצמו - תוכנת החשבוניות, מערכת השילוח, או מערכת של לקוח גדול. במקרים האלה יש שאלה נוספת שקובעת יותר מכל השאר: מי מספק את הגישה, ובאיזה לוח זמנים.
הפער הנפוץ הוא שהעסק מניח שהגישה קיימת, והיא דורשת בפועל פנייה לספק, לעיתים שדרוג חבילה, ולעיתים המתנה. פרויקט שתוכנן לשבועיים ומחכה עשרה ימים למפתח אינו פרויקט שאיחר - הוא פרויקט שלא שאל.
לכן שווה לברר שלושה דברים לפני תחילת העבודה: האם קיים ממשק, מי מוסמך לאשר את הגישה, וכמה זמן לקח הדבר בפעם האחרונה. התשובה השלישית היא הכי שימושית, מפני שהיא היחידה שמבוססת על ניסיון ולא על הבטחה.
מה שואלים את הספק, ולא רק את עצמכם
- מה לא ברור לך אחרי שקראת את ההגדרה?
- מה הסיכון הגדול ביותר בפרויקט הזה לדעתך?
- על מה אתה מניח שלא נאמר במפורש?
- מה קורה אם מתגלה שהנתונים גרועים ממה שחשבנו?
- מה כלול בחודש הראשון אחרי המסירה?
השאלה השנייה היא המבחן המעשי. ספק שעונה "אין סיכון" או לא מצביע על שום נקודה לא ניתח את הפרויקט; ספק שמצביע על הנתונים, על מערכת שאין לה ממשק או על חריג שלא הוגדר - קרא את ההגדרה באמת.
מה אם עדיין אין תשובות?
זה מצב נפוץ ולגיטימי, והתגובה הנכונה אינה לנחש אלא לרשום. כל שאלה שאין לה תשובה נרשמת כהנחה מפורשת במסמך, עם השלכה: "מניחים שהנתונים מגיעים כקובץ יומי; אם יידרש ממשק, זו תוספת".
הנחות כתובות משנות את אופי הדיון בהמשך. כשמתגלה שההנחה לא נכונה, יש מסמך שמראה על מה הסתמכה ההערכה - וזו שיחה על התאמה, לא על אשמה. עסקים שלא רושמים הנחות מנהלים את אותה שיחה כוויכוח.
מקורות
שאלות נפוצות
כמה זמן לוקח אפיון כזה?
לתהליך בודד, שעה עד שעתיים של שיחה ועוד שעה כתיבה, ועוד סבב קצר של הערות מהצד שמבצע את התהליך כיום. פרויקט שדורש שבועות של אפיון הוא בדרך כלל כמה פרויקטים שכדאי להפריד, ולא פרויקט אחד מורכב.
האם הספק צריך לגבות על אפיון?
זה משתנה, ושני המודלים לגיטימיים. מה שחשוב הוא שהמסמך יהיה שלכם בכל מקרה - אפיון ששייך לספק כובל אתכם אליו גם כשההצעה אינה מתאימה.
מה אם התהליך שונה בכל לקוח?
אז מגדירים את הגרסה הנפוצה ומציינים את השונות כחריג מוגדר. תהליך שבאמת שונה לחלוטין בכל מקרה אינו בשל לאוטומציה, והכלל הזה מוסבר ב[אוטומציה של הדברים הלא נכונים](/he/blog/automating-the-wrong-things).
מי צריך להיות בפגישת האפיון?
מי שמבצע את התהליך היום, ולא רק מי שמנהל אותו. בעסק שבו שני אנשים מבצעים את אותו תהליך שווה לשמוע את שניהם, כי לעתים קרובות מתברר שהם עושים אותו אחרת. רוב השלבים החסרים בתיאור הראשוני מגיעים ממי שעושה את העבודה בפועל, והם בדיוק אלה שקובעים את ההיקף.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.