מסלולי החירום לפרויקט פיתוח בימי מגיפה
שנת המגיפה הביאה צוותי פיתוח רבים לעמוד מול משימות שהדד-ליין שלהן היה מגה-מואץ כי "אתם יודעים, קורונה, לחץ. צריך אפליקציה. עכשיו" - אבל איך עושים זאת נכון וחכם?
אלה ש"מכירים אותי מהבית" יודעים שהכי טוב לבוא אלינו לקפה בסתיו או באביב. או בקיץ, אבל רק בערב כשקריר. או בחורף, אבל רק כשחמים בחוץ. אצלנו בבית מארחים בחוץ, בחצר. לא כי הבית קטן, הוא פשוט מאורגן קצת אחרת, ובדרך כלל אין לאורחים איפה לשבת.
חלק מכם, אם תבואו לבקר, תקראו לזה בלגן. ההבדל בין בלגן לבין "סדר אחר" הוא אמיתי. זה לא רק משפט שאנשים מבולגנים המציאו.
מי שעבד בפרויקטים בשנה האחרונה מכיר את ההרגשה הזו היטב. היא מורגשת כשמגיע יועץ חיצוני לראות את האפליקציה שפיתחתם לצוות שירות הלקוחות בזמן טירוף, תוך שלושה ימים, כדי שיוכלו להתחבר ולהזין מידע למערכת הליבה הארגונית כשהם עובדים בסגר מהבית. האפליקציה נתנה מענה מהיום למחר ל-600 אנשי צוות בכל הארץ, שעד לפני שבוע עבדו על מערכת פנימית ומורכבת בתוך הארגון.
היועץ מסתכל על האפליקציה, מקשיב לתיאור הפונקציונליות, ושואל: "איפה מסמך האפיון? יש שרטוט ארכיטקטורה? יש פרוטוקול ניטור? עשיתם בדיקות עומסים?" והאמת היא ש"אין… ושלא…". וזה לא כי עבדנו לא מסודר. זה כי היינו חייבים להתארגן אחרת. "אתה יודע, קורונה, לחץ. צריך אפליקציה. עכשיו".
מתוך הבנה שאין אפשרות למימוש החלום בשלושה ימים, הדרך לייצר תוצר איכותי שיחזיק גם לטווח הארוך בקורונה שונה מבדרך כלל: מפרקים את המשימה לשני מסלולים מקבילים – מה מיידי, ומה נרצה שיהיה בעתיד. לא מוותרים על החלקים הקריטיים, ובראשם על התכנון: בונים ארכיטקטורה מקצה לקצה על לוח, ואז מגדירים ומתכננים בצורה מפורטת את החלקים שאפשר והגיוני ליישם בשלושה ימים ואיתם יוצאים לעבודה. לא לפני שמצלמים את הלוח, שומרים את התצלום במקום בטוח – ומוחקים.
השלב הבא זו קפיצת ראש וצלילה מהירה לעבודה מאומצת של צוות קומנדו שעובד 24/7, מאפיין ומפתח במקביל, והכל כדי להעלות את התוצר. והוא עולה, ועובד, ומביא תועלת מיידית למשתמשים ולארגון. כי מאז תחילת המגיפה, בנקודות בהן אי אפשר לדחות תוצרים – הדרך לבצע פרויקטים חייבת להשתנות, ולעבור לציר דו-מסלולי.
פרויקט פיתוח בימי קורונה. צילום אילוסטרציה: BigStock
שני המסלולים לפיתוח המהיר
המסלול הראשון הוא מסלול חירום. מתוך הבנה שבעיתות מצוקה סדר העדיפויות חייב להיות שונה, מפתחים מינימלי ומתחזקים את התוצר שעלה, כותבים תיק תפעול ותיק תחזוקה, ומוותרים לפעמים על עדכון מדויק של האפיון, מוסיפים שרתים ושירותים, כדי לשחרר צווארי בקבוק בלי sizing עדכני, מוסיפים תהליכים ופונקציונליות לפי דרישות דחופות שעולות מהשטח – וכל פעם קצת. ב"מנות" של שבוע. כי אין ברירה, "אתם יודעים, קורונה, לחץ. צריך אפליקציה. עכשיו".
המסלול השני הוא הדרך לאפליקציית החלום שציירנו על הלוח, והוא ייבנה על בסיס קיצורי הדרך המהירים אבל הנכונים לפיהם פעלנו במסלול הראשון: תוך כדי שאנחנו עובדים עם האפליקציה שיצרנו בתנאי לחץ, אנחנו מנסים להבין מה באמת נצטרך כשכל החירום הזה ייגמר, מה יישאר ונוכל למנף, מה צריך לבנות מחדש על קרקע יציבה יותר, ומה אפשר לקחת as Is ופשוט להנות מהתוצר.
אחרי המסלול השני, כשהלחץ קצת ייגמר או כשיהיה לנו קצת יותר זמן להשקיע במוצר שלנו, המעבר לאפליקציה החדשה יהיה טבעי ושזור בתכניות העבודה. היא תצליח להחליף את הקיימת, בלי שהמשתמשים יחוו טראומה או טלטלה. היא תבוא בתזמון נכון, ההטמעה תהיה מסודרת ולפי הספר, כל המסמכים יהיו מוכנים מראש וכל הרכיבים יהיו מתועדים לפי הספר. בדיוק כמו שהיועץ רוצה. וכמו שהיה כתוב על הלוח.
ימי הקורונה מאלצים אותנו לאלתר ולייצר דברים תחת דד-ליינים דוחקים יותר מאשר בעבר, כדי לעמוד בדרישות חדשות וצרכים מהירים שנוצרים באופן מאוד דינמי, אבל אפשר וצריך לעשות את זה נכון מבלי לוותר על המקצועיות והאיכות בדרך. וזה לא בלתי אפשרי – כאשר מתכננים עם ראייה לרחוק, מייצרים את המינימום הנחוץ במיידי, ואת התוצר המוגמר מלטשים בצורה מושלמת תוך כדי תנועה.
הכותבת היא ארכיטקטית פתרונות בכירה במטריקס פינטק ודיגיטל
נראה בסדר גמור אולם חסרה לי כאן התיחסות המתכנן לבקרת תוכנה. כיצד שומרים על גירסאות תוכנה לאחר כל עידכון וברור לכולם שעבודה הנעשית בחופזה, יתכנו שינויים ברמת סמך גבוהה. האם מוחקים גירסה ישנה או ניתן לחזור אליה בכל עת.