איך שומרים על Deadlines בפיתוח תוכנה?
מאת: ישי טנצר, 26.1.20, 16:06
 
איך ניתן לעמוד בלוחות זמנים מול סטארטאפים ויזמים, ולשמור על איזון בין תכנון נוקשה לגמישות וזיגזגים, כדי להבטיח תוצאה בפרק זמן סביר?
 
בעולם התוכנה נהוג לא להאמין ביעדי זמן (deadlines) המוצבים לפיתוח פרויקטי תוכנה. במקרה הטוב מסתכלים על ה-deadline כנקודת ייחוס מסוימת. כלומר, שיש כוונה לספק משהו בערך בתאריך הנקוב.
 
יש הרבה הסברים וסטטיסטיקות למה פרויקטי תוכנה לא עומדים בזמנים. בגדול, תחום פיתוח תוכנה נחשב לתחום של חוסר ודאות גבוה מאוד. לכן, אין שיטות הנדסיות להערכת פרויקטים ותכולות עבודה (לעומת תחומים הנדסיים אחרים כמו תחום הבניה).

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

זו לא שיטת קסמים. יש צורך בהרבה משמעת ,ניסיון וויתורים כואבים כדי לעמוד בלו"ז.
 
השיטה מבוססת על שילוב בין שיטת המפל (waterfall) המסורתית, שבה מגדירים את הכל עד הסוף בתחילת הפרויקט לבין  שיטת אג'ייל (agile), שבה מחליטים רק על הדברים, שיהיו בעבודה לשבועות הקרובים וכל כמה שבועות (sprint) אפשר לטרוף את הקלפים ולשנות את הכל. 
 
ראוי לנסות ולשמור על איזון בין התכנון הנוקשה לגמישות וזיגזגים כדי להבטיח תוצאה בפרק זמן סביר.
 
בתחום התוכנה נהוג לדבר על משולש הקסמים, ש-3 קודקודיו הם:

1. לו"ז
2. תקציב
3. תכולה

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

לקבוע את התכולה המקורית, שמתכוונים לספק לתאריך יעד. לרשום את התכולה - רשימת פיצ'רים (יכולות פונקציונליות).
 
מה שיכול להשתנות זאת התכולה שתסופק לתאריך יעד. התכולה יכולה רק לקטון. אין להוסיף תכולה לתאריך יעד שכבר הוגדר. זה בא בסתירה להנחה הרווחת, שתכולת הפרויקט כל הזמן גדלה. כאן זה הזמן לעשות ויתורים כואבים ולראות איך אפשר לחיות בלי פיצ'ר מסוים.
 
רוב היזמים מאוהבים במוצר ורוצים כל הזמן ללטש אותו עוד ועוד. המוצר תמיד "לא מוכן".
 
אבל האם המשתמשים באמת חייבים את כל הפונקציונליות מהיום הראשון? האם רמת הגימור חייבת להיות מיליון דולרים?
 
יש לחשוב על מוצרי תוכנה, שלא יכולים בלעדיהם. האם יש בהם הכל? האם הממשק שלהם מושלם? רובנו משתמשים במוצרים הרחוקים שנות אור משלמות כל עוד זה פותר לנו בעיה כלשהי.
 
כל מה שאמור לקחת 6 חודשים אפשר לסיים גם ב-6 שבועות. השאלה היא: באיזה רמת גימור? יש לקבוע לעצמכם תאריכי יעד קצרים (6-10 שבועות) ולעמוד בהם בכל מחיר, גם על חשבון תכולה קטנה ורמת גימור נמוכה יותר.
 
תאריכי יעד נוקשים עם תכולה גמישה תאלץ גילוי של הרבה קריאטיביות, לא רק פתרונות טכניים אלא גם פתרונות עסקיים כדי להעמיד את המוצר הטוב ביותר שאפשר בזמן שיש ליעד. לדוגמה: פתרון טכני פשוט יותר לטיפול בתשלום בכרטיסי אשראי זה להשתמש ב-payment gateway (חברה חיצונית, שתטפל בגביית אשראי) במקום לפתח זאת מאפס. אבל הפתרון העסקי, פששוט יותר לבעיה ,זה כלל לא להתעסק בתשלומים כל עוד אין לקוחות משלמים. תמיד אפשר לגבות כסף מהלקוחות הראשונים בצורה ידנית בטלפון. 
 
אם חושבים, שאי אפשר לחתוך ולצמצם שום דבר במוצר או שכבר צומצם כל מה שאפשר, כנראה שטועים. יש לנסות לחשוב מחוץ לקופסא ולראות מה עוד אפשר לפשט.  לדוגמה: כדי לבדוק עניין של גולשים במוצר מסוים מספיק לפעמים להרים עמוד נחיתה מעוצב וכלל לא לפתח את המוצר עצמו.
 
אזהרה - השיטה יכולה למרר את החיים, לגרום להתבייש במוצר שמשיקים ולריב עם שותפים בוויכוחים סוערים על מה לוותר. אולם, זה לפחות מקטין את הסיכוי להגיע לבית קברות של רעיונות, שהפיתוח שלהם נגרר ונגרר.
 
יש לשקול את העקרונות הללו, כאשר שוקלים את צורת העבודה מול בית תוכנה לפיתוח המיזם.
 
מאת: ישי טנצר, ינואר 2020.
מנכ"ל חברת איניטק
https://www.initech.co.il
contact@initech.co.il