Posts tagged ‘contract’

מה לגבי הלקוחות?

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

אולי זה אבוד ואין שום סיכוי אמיתי למשפט האידילי וחסר האחיזה במציאות customer collaboration over contract negotiation, אולי זה בכלל רק עניין ישראלי ובעולם זה שונה? המון שאלות יש לי…

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

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

Image Detailהסעיפים הם אלה:

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

– יש לאפשר ללקוח בכל עת שמצפות להפסיק את הפרויקט ובשביל שהספק לא ״יידפק״ יהיה על הלקוח לשלם קנס מסוים שערכו לשם הדוגמה יהיה 20% מסך הפרויקט שטרם בוצע.

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

– הלקוח יהיה זמין לשאלות והבהרות שיבקש הספק ויהיה עליו לענות תוך פרק זמן סביר – נניח שבוע. זזה לא מושלם אפילו לא קרוב, אבל זה גם משהו.

אני אשמח לשמוע רעיונות שיש לכם בנושא.

שנה טובה.

חוזים אג’ילים – זה כדאי !

אחד מארבעת הערכים של ה-Agile manifesto הוא:
Customer collaboration over contract negotiation

מה זה אומר ?
איך מוציאים לפועל ערך כה מעורפל ?
|מה המשמעות של שיתוף פעולה עם לקוחות?
אז מה עושים ?

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

clip_image002שותפות אמיתית בין לקוח לספק מייצרת מצב שבו לשני הצדדים יש מה להפסיד או להרוויח מכישלון או הצלחה של הפרויקט, למשל אם בתחילתו של הפרויקט אנחנו מתחייבים ללקוח שלנו לספק לו את רשימת הדרישות שהוא דרש, באיכות גבוהה ובזמן המוקצב, הרי בעקבות אי הוודאות השגורה במשימות פיתוח תוכנה אנו לוקחים סיכון עבורו,ואם לא מספיק שאנו לוקחים את הסיכון שלו אנחנו גם בד”כ לא ממש מספרים לו שאנחנו לוקחים סיכון, הוא “משוכנע” שאנחנו נעמוד בהתחייבויות שלנו כי ככה כתוב בחוזה, שהרי אנחנו מחויבים משפטית לעמוד בחוזה, בחוזה חוזה מסוג זה נקרא חוזה קבוע מחיר – Fixed price contract.

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

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

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

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

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

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

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

כמאמר ג.יפית : זה כדאי!