מה ניתן ללמוד מנסיון של מתן חוות דעת לבתי משפט בנושא תוכנה

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

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

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

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

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

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

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

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

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

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

מסקנות עיקריות שניתן להפיק:

1. תיאום ציפיות – אחוז גבוהה מאוד מהמקרים שאני רואה מתרחשים בגלל שהלקוח והבית תוכנה לא חידדו מספיק את הציפיות שלהם מעבודה משותפת. בפרויקט תוכנה הרבה דברים יכולים ללכת לא לפי התכנון (בעיות טכנולוגיות, דברים לוקחים יותר זמן מהצפוי ועוד). רק הבנה מאוד ברורה של יעדי הלקוח ומגבלות של המצב בשטח יכולים לעזור לצדדים לצלוח את התהליך.
2. תבדקו מה מקובל בשוק/תעשיה – הרבה לקוחות מגיעים לתהליך פיתוח תוכנה בלי הבנה בתחום ועם "צדק" משלהם כפי שהם מבינים אותו. אבל בפועל כאשר יועץ מומחה צריך לכתוב את חוות דעתו הוא מסתמך על איך התעשיה פועלת וזה יכול לבוא בסתירה מוחלטת להגיון והציפיות של הלקוח. לדוגמה הלקוח החליט לשבור חוזה עקב איחור של כמה ימים , היועץ עלול לציין בחוות דעתו שרוב פרויקטי תוכנה לא מסתיימים במועד הנקוב ואיחור של כמה ימים יכול להיחשב כמהלך תקין של הפרויקט. כנ"ל לגבי כמות "באגים" בפרויקט בעת הגשתו ועוד נושאים רבים. לכן לפני שאתם מחליטים ללכת לבית משפט בדקו מה קורה בתעשיה ועד כמה המקרה שלכם חריג מהנורמה.  
3. חוזה מפורט עם דגשים – לאור מה שנכתב בסעיפים הקודמים קריטי שיהיה לכם חוזה מפורט עם הספק שיפרט את התחייבויות הצדדים ויציין במפורש דרישות ספציפיות שלכם שחורגות מהנורמה בשוק. למשל אם בגלל צרכים עסקיים שלכם , איחור של כמה ימים בלו"ז הפרויקט הופך אותו ללא רלוונטי ציינו זאת כסעיף מהותי בחוזה ותדגישו לכל אורך ההתקשרות עם הספק. זה גם יגדיל את הסיכויים שהספק יתן לזה את הפוקוס וגם אם חס ושלום תצטרכו ללכת לגורם מקצועי צד שלישי שיהווה את דעתו יש יותר סיכוי שחוות דעתו תיהיה לטובתכם.
4. תקשורת שוטפת ודיווחי התקדמות – אחת הבעיות הגדולות שאני נתקל כאשר אני מנתח את החומרים לקראת כתיבת חוות דעת זה קושי להבין מה קרה לאורך התהליך בגלל חוסר בתיעוד התקשורת בין הצדדים. במיוחד בפרויקטים ארוכי טווח חשוב לי מאוד להבין מה קרה לאורך הדרך כי ברור שהמצב עלול היה להשתנות פעמים רבות ויתכן והצדדים הגיעו להסכמות חדשות ששונות מהחוזה המקורי(הרחבת תקציב, הרחבת לו"ז, ויתור על תכולה, החלפת תכולה אחת באחרת ועוד). לכן קריטי לנהל תקשורת מסודרת בכתב, להוציא סיכומי פגישות/שיחות, לדרוש דיווחי התקדמות מפורטים בכתב ועוד. תשמרו על כל התיעוד במקום מסודר ונגיש אל תחכו ליום הדין כדי להתחיל לאסוף חומרים. בגלל שהתקשורת היום מתבצעת בערוצים שונים (איימל,Whatsapp,סמס) נושא הארגון הוא בהחלט מאתגר, אני ממליץ לכם לבחון את הכלי הבא TimelinesAI המאפשר לאסוף, לארגן ולשתף תקשורת עסקית מערוצים שונים.
5. תנסו לפתור את הבעיה לפני שמגיעים לבית משפט! הדבר העקרי שאני רוצה שתקחו מהמאמר זה לחשוב טוב טוב לפני שהולכים לבית משפט. עלויות משפטיות ועלויות נלוות כמו של קבלת חוות דעת מיועץ חיצוני הן כבדות ובהרבה מקרים משתלם לשים את האגו בצד ולנסות להגיע לפשרה בלי להכנס לתהליך יקר זה.

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

ישי טנצר

מנכ"ל איניטק- בית תוכנה לפיתוח מוצריים דיגיטליים.

www.initech.co.il/he/software-consult/

contact@initech.co.il

073-7969275