עבר חודש מאז שהצוות החדש התחיל. אתם פותחים את הדשבורד של המשימות וכל העמודות נראות פעילות, אבל כשאתם שואלים את עצמכם "האם זה בכיוון הנכון?" אין לכם תשובה בטוחה. הסטטוסים אומרים הרבה, והם לא מוכיחים כמעט כלום.
בעבודה איתנו החודש הראשון הוא חודש ניסיון בתשלום, ולכן הוא נועד בדיוק לשאלה הזו. אבל גם אם אתם עובדים עם ספק אחר, יש סימנים שאפשר לבדוק בלי להבין לעומק את הקוד. הנה חמישה שאנחנו מסתכלים עליהם.
כדאי לקבוע מראש, בשבוע הראשון, מה ייחשב הצלחה בסוף החודש. אחרת בסוף החודש מתווכחים על תחושות. שיחה של חצי שעה על חמשת הסימנים האלה מיישרת ציפיות: הצוות יודע במה ייבדק, ואתם יודעים מה עליכם לספק, כמו גישות, אדם זמין לשאלות ומסמכי רקע.
1. הסביבה רצה אצל כל מפתח בשבוע הראשון
מפתח חדש שמקבל גישה לקוד צריך להצליח להריץ את המערכת מקומית, לשנות שורה ולראות את התוצאה. אם זה מצליח תוך ימים ספורים ויש כבר PR קטן ראשון שמוזג, מצוין. אם בסוף השבוע הראשון עדיין מחכים לגישות, להסברים או ל"עוד רגע נשלח לך את הקובץ", זו תמונה של התנהלות שתימשך.
לרוב הבעיה היא בצד של הלקוח: אין README שמתאר איך מרימים את המערכת, ויש תלות במשתני סביבה שרק מפתח אחד מכיר. מה לעשות: נסו בעצמכם, על מחשב נקי, להריץ את המערכת לפי המסמכים שיש. כל מקום שנתקעתם בו הוא מקום שגם המפתח החדש ייתקע בו, ותיקון המסמך משתלם לכל מי שיצטרף אחריו.
סימן נוסף שכדאי לחפש כבר בימים הראשונים: מפתח ותיק שנתקל בהוראה שגויה ב-README מתקן אותה, ולא רק עוקף. זו התנהגות של מי שרוצה להשאיר את המקום טוב יותר ממה שמצא, והיא נראית בקלות בהיסטוריית ה-commits.
2. השאלות מגיעות מוקדם והן ספציפיות
צוות שלא שואל כלום בשבועיים הראשונים איננו מבין הכל. סביר יותר שהוא לא בטוח שמותר לשאול, או שהוא מנחש. סימן טוב נראה כמו שאלה כגון: "במסך ההזמנות, אם הלקוח מבטל אחרי שהתשלום נקלט, אנחנו מחזירים כסף אוטומטית או מחכים לאישור?" כלומר שאלה שמראה שהמפתח כבר חשב על מקרה קצה.
שאלה מוקדמת של מפתח היא אחד הסימנים הטובים ביותר לכך שהפרויקט בכיוון הנכון. היא יכולה לחשוף שתי דרישות שסותרות זו את זו, או מקרה שהאפיון לא מכסה. כשהשאלה עולה לפני שנכתבה שורת קוד, התשובה עולה שיחה אחת. כשהיא עולה אחרי, היא עולה ספרינט.
שימו לב גם למה שקורה אחרי התשובה: מפתח טוב מעדכן את ה-ticket או את האפיון, כך שהתשובה נשארת בכתב לכל מי שיגיע אחריו.
מה לעשות אם אין שאלות: שאלו אתם. בקשו מכל מפתח לסכם במילים שלו מה הוא מבין שצריך לבנות במשימה הקרובה. פערים מתגלים תוך חמש דקות. ואם הם חוזרים שוב ושוב, כדאי לחזור אל האפיון, ועל זה כתבנו באיך כותבים אפיון שמפתחים באמת מבינים.
3. כל משימה מוגדרת לפי תוצר שאפשר לראות
הסימן הוא שהעבודה מפורקת למשימות קטנות, ולכל אחת כתוב מה אמור להיות ניתן לצפייה בסופה. "מסך התחברות עובד מול שרת הבדיקות" טוב. "לעבוד על אימות" אינו טוב, כי אי אפשר לדעת מתי הוא הסתיים. פירוק טוב של מסך התחברות נראה כך: טופס ובדיקות קלט, אימות מול השרת, הודעות שגיאה, ותהליך "שכחתי סיסמה". כל חלק אפשר להדגים בנפרד, ואפשר לראות איפה העבודה עומדת.
גם הערכות הזמן אמורות להיות מפורקות. "ארבעה שבועות לכל הממשק" הוא ניחוש עגול שקשה לבדוק. הערכה שמורכבת מעשר משימות, שלכל אחת טווח, ניתנת להשוואה למציאות בסוף כל שבוע. במודל מיקור החוץ מדובר בתוכנית עבודה עם לוחות זמנים מחייבים, ואת ההתקדמות מולה בודקים כל שבוע.
גם מה שנחתך בכוונה צריך להיות כתוב. כשמחליטים לדחות פיצ'ר לשלב הבא כדי להגיע ל-MVP מהר יותר, ההחלטה נרשמת עם הסיבה. אחרת, בעוד חודש מישהו ישאל למה הפיצ'ר חסר, ואף אחד לא יזכור שזו הייתה החלטה ולא שכחה.
4. דמו עובד על staging כל שבוע, גם אם הוא מכוער
עד סוף החודש אתם אמורים לראות לפחות כמה דמואים, כל אחד של משהו שבאמת עובד בסביבה שאינה המחשב של המפתח. העיצוב יכול להיות זמני והנתונים מדומים. מה שחשוב הוא שזה רץ, ושאתם יכולים ללחוץ בעצמכם.
הסימן המטריד הוא הצגה בשקפים או בצילומי מסך במקום מערכת חיה, או הסבר מדוע "עוד אי אפשר להראות". לפעמים יש סיבה טובה, אבל אם זה חוזר שבועיים ברציפות, דרשו מהצוות תאריך.
בכל דמו אפשר לשאול שלוש שאלות: מה עוד לא עובד, מה לא נבדק, ומה הדבר הכי מסוכן בשבוע הקרוב. צוות שעונה עליהן בפתיחות נותן לכם מפת סיכונים אמיתית, וצוות שמתקשה לענות מצביע על חלק שכדאי לבדוק לעומק. בפרויקט שמתחיל ב-MVP, החלק הקטן ביותר שאפשר להפעיל כבר אמור להופיע בחודש הראשון.
5. חדשות רעות מגיעות מוקדם, בכתב, עם הצעה
כל פרויקט נתקל בהפתעות: אינטגרציה שהתיעוד שלה לא מדויק, דרישה שסותרת דרישה אחרת, משימה שהתבררה כגדולה מהצפוי. ההבדל בין צוות טוב לבינוני נקבע לפי המועד שבו אתם שומעים על הבעיה. הצוות הטוב כותב ביום שהבעיה התגלתה: מה קרה, מה ההשפעה על הלוח, ואילו שתי אפשרויות הוא מציע (למשל לקצץ פיצ'ר או להעביר אותו לשלב הבא).
אם הדבר היחיד שאתם שומעים הוא "הכל בסדר" ואז פתאום "נתעכב", יש בעיית שקיפות. הסיבה לא תמיד רצון להסתיר. לפעמים המפתח חושש שדיווח על בעיה ייראה ככישלון, ולכן חשוב להגיב לדיווח כזה בהודיה ובשאלה "מה האפשרויות", לא בביקורת. פתרו אותה בשגרה: חסם הוא שורה קבועה בעדכון היומי, כמתואר בניהול צוות פיתוח מרוחק. ועל הסיבות הנפוצות לעיכובים, למה כמעט כל פרויקט תוכנה מתעכב.
השורה התחתונה
חמשת הסימנים נבדקים בלי להסתכל בקוד: סביבה שרצה, שאלות מדויקות, משימות עם תוצר נראה לעין, דמו שבועי ודיווח מוקדם על בעיות. אם ארבעה מתוכם קיימים, זה כנראה בדרך הנכונה. אם חסרים שניים או יותר, זה הזמן לעצור ולשאול למה, עוד לפני סוף החודש. בחודש ניסיון ההחלטה אם להמשיך צריכה להתבסס על הסימנים האלה ולא על הרושם הכללי.
כשסימן חסר, כדאי לנסח אותו כבקשה ספציפית ולא כתחושת אי-נחת, למשל "לשבוע הבא, דמו של מסך ההזמנות על staging". בקשה ספציפית אפשר לעמוד בה או לא לעמוד בה, ואז מקבלים תשובה תוך שבוע ולא בסוף החודש.
רוצים לראות איך אנחנו מנהלים פרויקט מהאפיון ועד ההפעלה? במיקור חוץ הכל מנוהל מולכם לפי תוכנית עבודה.
