עשרים דקות. זה כל מה שנדרש לעורך דין מנוסה מהצד שכנגד כדי לפרק חוות דעת תוכנה שהוכנה ברשלנות. ראיתי את זה קורה. הנה שלושת הכשלים שחוזרים שוב ושוב.
ההקשר: כשחוות הדעת מגיעה לאולם
כשמנהל שותפות במשרד ליטיגציה גדול מתקשר אלי אחרי ש”המומחה שלנו נשרף בחקירה”, השיחה מתחילה תמיד באותו תיאור: “הוא ידע את החומר. הוא שנים בתעשייה. אבל בחמש עשרה דקות עם עורך הדין שכנגד — הכל התפורר.”
הבעיה לא הייתה בידע הטכני של המומחה. הבעיה הייתה בחוות הדעת עצמה.
חוות דעת מומחה בתחום התוכנה, כשהיא מוגשת לבית משפט ישראלי, עוברת שני מסננים שאינם טכניים: האחד הוא השופט, שצריך להבין ולקבל את הניתוח כבסיס להחלטה עובדתית; השני הוא עורך הדין מהצד שכנגד, שמשימתו היחידה היא למצוא את נקודת השבירה של חוות הדעת ולהרחיב אותה. מומחה טכני מעולה שכותב חוות דעת טכנית מעולה — אבל לא לגלאי הזה — לא שורד חקירה.
כשל ראשון: ערבוב בין ממצאים לדעות
הכשל הנפוץ ביותר הוא שהמומחה מציג דעות כממצאים.
”המערכת לא הייתה ראויה לשימוש” — זו דעה. “בדיקת 47 מבחני קצה שהוגדרו במפרט המקורי הראתה ש-31 מהם נכשלו; שיעור כשל של 66%” — זה ממצא שניתן לעמוד מאחוריו בחקירה.
עורך דין מיומן מצד שכנגד מחפש את הרגע שבו המומחה אמר משהו שאינו מבוסס על בדיקה ישירה. ברגע שמצא אחד כזה, הוא עובד ממנו לאחור לכל שאר החוות דעת: “אם לא בדקתם זאת בעצמכם, אולי גם לא בדקתם את…” — ושם נשברת המהימנות.
כלל העבודה: כל טענה בחוות הדעת מלווה בסממן הבסיס שלה — קוד שורה X, לוג שורה Y, תיעוד גרסה Z. אם אין סממן — אין טענה.
כשל שני: מתודולוגיה בלתי ניתנת לשחזור
חוות דעת תוכנה נכשלת בחקירה כשהצד שכנגד שואל: “כיצד הגעתם לתוצאה הזו?” — והמומחה אינו יכול לתאר צעד אחרי צעד.
ראיתי מקרה כזה בעניין מחלוקת SaaS ישראלית בסדר גודל בינוני. המומחה מטעם אחד הצדדים הסיק מסקנות מתוך ניתוח ביצועים — אבל לא תיעד את סביבת הבדיקה, לא ציין את גרסת הכלים שהשתמש בהם, ולא שמר את הנתונים הגולמיים. כשנשאל להסביר כיצד הגיע לנתון המרכזי בחוות הדעת, נאלץ לומר “על סמך ניסיוני המקצועי” — ניסוח שמזמין עורך דין מנוסה לשאול בדיוק כמה שנות ניסיון נחוצות כדי לקבל תוצאה שונה.
הסכסוך הסתיים בפשרה בתנאים שלא שיקפו את עמדת הצד ששכר את המומחה. הפשרה התרחשה לאחר שחוות הדעת נפגמה, לא לפניה.
כלל העבודה: כל מתודולוגיה מתועדת כך שמומחה אחר, עם אותם חומרים, יגיע לאותה תוצאה — או יציין בדיוק היכן הוא חולק. שחזוריות היא מגן, לא הגזמה.
כשל שלישי: חוות דעת שנכתבה לקורא הטכני, לא לשופט
הכשל השלישי הוא המתוחכם ביותר: חוות דעת שכתובה נכון מבחינה טכנית — אך בשפה שרק מהנדס יבין.
שופטים בישראל, גם בבתי משפט מחוזיים שמטפלים בסכסוכי מסחר מורכבים, אינם מהנדסי תוכנה. חוות דעת שמניחה ידע בסיסי של ארכיטקטורת מחשבים, בפרוטוקולי רשת, או בשמות כלים ספציפיים — מכניסה את השופט למצב שבו הוא חייב לקבל על אמונה דברים שאינו מבין. זה מצב לא נוח עבורו, והוא מטה שופטים לדחות חוות דעת שנדמות להם כ”קופסה שחורה”.
עורך הדין מהצד שכנגד ינצל זאת: “האם יכולים לתאר את המושג הזה בשפה שאינה מקצועית?” — ואם המומחה לא מסוגל, הוא מאבד את האולם.
כלל העבודה: כל מושג טכני שאינו שגרתי מוסבר בפסקה קצרה בגוף חוות הדעת, בלי לוותר על הדיוק. ההסבר כתוב לשופט, לא לעמיתים טכניים.
מה שורד חקירה
חוות דעת שורדת חקירה נגדית כשהיא עונה על שלוש שאלות לפני שהן נשאלות:
- מה בדקתם בדיוק? — רשימת חומרים + סביבת עבודה + כלים + גרסאות.
- כיצד הגעתם לממצא? — תיאור צעד-אחרי-צעד ששופט יכול לקרוא ולהבין.
- מה לא בדקתם ולמה? — הגדרת גבולות חוות הדעת בגלוי מגינה יותר מאשר שתיקה עליהם.
חוות דעת שנבנית על עקרונות אלו עובדת לטובת לקוחכם לא רק כשמוגשת — אלא גם כשהצד שכנגד מחפש את הסדק שיפרק אותה.
פרטים מזהים שונו; כל התרחישים המתוארים משקפים דפוסים מעבודה בפועל.
אם אתם עומדים לפני מינוי מומחה תוכנה לתיק, חוות דעת מומחה — תוך שבועיים מסבירה כיצד אנו בונים חוות דעת שמחזיקות מעמד.