המדריך לאפיון פרויקט שלא נופל באמצע.

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

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

מה זה scope creep ולמה הוא מסוכן יותר מכל באג

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

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

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

שלב 1: להבין את ה-why העסקי, לא את הפיצ׳ר

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

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

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

שלב 2: למפות scope במפורש, כולל מה שלא נכלל

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

רוב הספקים כותבים רשימת פיצ׳רים ומרגישים שסיימו. הבעיה היא שכל מה שלא כתוב ברשימה נמצא באזור אפור. הלקוח מניח שזה בפנים כי זה מובן מאליו מבחינתו. הספק מניח שזה בחוץ כי לא דיברו על זה. שניהם בתום לב, ושניהם מתכוננים לוויכוח. סעיף out of scope כתוב הופך את האזור האפור לשחור-לבן.

דוגמה קונקרטית לניסוח. בפרויקט הקמת אתר תדמית, סעיף ה-scope יכלול ׳עיצוב ובניית 6 עמודים: בית, אודות, שירותים, בלוג, יצירת קשר, תודה׳. וסעיף ה-out of scope יכלול במפורש ׳אינו כולל: כתיבת תוכן שיווקי, צילום מוצרים, אינטגרציה למערכת CRM, תמיכה בשפה נוספת מעבר לעברית, ותחזוקה שוטפת לאחר העלייה לאוויר׳. עכשיו כשהלקוח יבקש עוד חודש להוסיף אנגלית, אף אחד לא צריך להתווכח. פותחים את המסמך, מראים את השורה, ומתמחרים תוספת בשקט. זה הופך את הסירוב מעימות אישי לעניין טכני.

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

שלב 3: לפרק ל-milestones עם קריטריון ׳בוצע׳ מדיד

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

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

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

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

שלב 4: לתאם ציפיות על זמן, תלויות, ושינויים

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

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

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

שלב 5: מסמך אפיון חתום, לפני שמתחילים ולפני שעובר כסף

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

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

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

הטעויות שחוזרות שוב ושוב

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

• אפיון מעורפל. ׳אני רוצה אתר יפה ומודרני׳ הוא לא אפיון, הוא הרגשה. יפה לפי מי? אם אין קריטריון, אין דרך לספק אותו ואין דרך לדעת שסיפקת.
• הבטחות בעל פה. ׳אמרת לי בטלפון שזה כלול׳ הוא תחילתו של כל סכסוך. אם זה חשוב מספיק כדי להבטיח, זה חשוב מספיק כדי לכתוב.
• דילוג על out of scope. זו הטעות היקרה מכולן, כי היא זו שפותחת את הדלת ל-scope creep. מה שלא נשלל במפורש ייחשב ככלול.
• אין הגדרת הצלחה מדידה. פרויקט בלי יעד מספרי הוא פרויקט שאי אפשר לסיים באמת, כי תמיד אפשר לטעון שהוא עוד לא ׳מספיק טוב׳.
• לקוח שלא זמין לאישורים. הכשל הזה מתחיל בצד הלקוח, אבל הוא באחריות משותפת. אם לא סיכמתם מראש מי מאשר ותוך כמה זמן, בניתם עיכוב לתוך הפרויקט.

הצ׳ק-ליסט שאפשר להשתמש בו כבר מחר

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

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

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

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