כמה עולה לחסוך כסף?

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

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

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

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

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

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

דבר אחד שנראה ללקוחות מוזר הוא נושא ה”שעות או פיקס”. בעיקרון, אני מאוד משתדל שלא לקחת עבודות ראשוניות ב-fix price. יש לזה מכלול של סיבות, שאני מייד אתעקב עליהם. כמו שאני רואה את הנושא, כשמבקשים ממני לעבוד במודל של cost plus, כלומר תשלום על שעות העבודה שלי, אני הופך להיות חלק מהצוות. במצב כזה אין שום בעיה שאני גם אנסח מה הדרישות, אשנה כיוון באמצע או אעזור בנושאים לא קשורים שעולים בזמן שאני שם. מכיוון שהתשלום הוא על הזמן שלי, יש גמישות מאוד גדולה על מה מנוצל הזמן הזה.

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

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

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

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

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

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

שחר