2020 ינואר 19
איך עומדים ביעדי הזמן בפיתוח תוכנה?
בעולם התוכנה נהוג לא להאמין ביעדי זמן (deadlines) שמוצבים לפיתוח פרויקטי תוכנה. במקרה טוב מסתכלים על הdeadline כנקודת ייחוס מסוימת כלומר שיש כוונה לספק משהו בערך בתאריך הנקוב.
יש הרבה הסברים וסטטיסטיקות למה פרויקטי תוכנה לא עומדים בזמנים. בגדול תחום פיתוח תוכנה נחשב לתחום בעל קבועי חוסר ודאות גבוהים מאוד לכן אין שיטות הנדסיות להערכת פרויקטים ותכולות עבודה (לעומת תחומים הנדסיים אחרים כמו תחום הבניה).
במאמר זה, בהתבסס על ניסיון של עשור בניהול בית תוכנה ועבודה מול סטארט-אפים ויזמים אני רוצה לחלוק איתכם את הגישה שלנו איך כן ניתן לעמוד בלוחות זמנים. חלק מהרעיונות הללו גובשו בעקבות קריאת ספרים של מייסדי Basecamp והבלוג הפופולרי שהם מובילים.
זו היא לא שיטת קסמים , תצטרכו הרבה משמעת ,ניסיון וויתורים כואבים כדי לעמוד בלו"ז.
השיטה מבוססת על שילוב בין שיטת המפל (waterfall) המסורתית שבה מגדירים את הכל עד הסוף בתחילת הפרויקט לבין שיטת אג'ייל (agile) בה מחליטים רק על הדברים שיהיו בעבודה לשבועות הקרובים וכל כמה שבועות (sprint) אפשר לטרוף את הקלפים ולשנות את הכל.
אנחנו מנסים לשמור על איזון בין התכנון הנוקשה לגמישות וזיגזגים כדי להבטיח תוצאה בפרק זמן סביר.
בתחום התוכנה נהוג לדבר על משולש הקסמים, ששלושת קודקודיו הם:
-
לו"ז
-
תקציב
-
תכולה
אפשר לקבוע עד שתי קודקודים אבל אזי הקודקוד השלישי יצטרך לזוז כדי לשמור על צורת המשולש.
אנחנו בחרנו לקבע את הלו"ז כי תזמון הוא המלך ואיחורים הורגים את רוב הסטארט-אפים.
להלן עקרונות השיטה :
-
תקבעו שהלו"ז הוא קשיח ולא יכול לזוז לא קדימה ולא אחורה.
-
תקבעו את התכולה המקורית שאתם מתכוונים לספק לתאריך יעד. תרשמו את התכולה – רשימת פיצ'רים (יכולות פונקציונליות)
-
מה שיכול להשתנות זאת התכולה שתספקו לתאריך יעד. התכולה יכולה רק לקטון, אל תוסיפו תכולה לתאריך יעד שכבר הגדרתם. זה בא בסתירה להנחה הרווחת שתכולת הפרויקט כל הזמן גדלה. כאן זה הזמן לעשות ויתורים כואבים ולראות איך אפשר לחיות בלי פיצ'ר מסוים.
-
רוב היזמים מאוהבים במוצר ורוצים כל הזמן ללטש אותו עוד ועוד. המוצר תמיד "לא מוכן".
-
אבל האם המשתמשים שלכם באמת חייבים את כל הפונקציונליות מהיום הראשון? האם רמת הגימור חייבת להיות מליון דולר?
-
תחשבו על מוצרי תוכנה שאתם לא יכולים בלעדיהם? האם יש בהם הכל? האם הממשק שלהם מושלם?
רובנו משתמשים במוצרים שרחוקים שנות אור משלמות כל עוד זה פותר לנו בעיה כלשהי.
-
כל מה שאמור לקחת שישה חודשים אפשר לסיים גם בשישה שבועות. השאלה באיזה רמת גימור. קבעו לעצמכם תאריכי יעד קצרים(6-10 שבועות), עמדו בהם בכל מחיר. גם על חשבון תכולה קטנה ורמת גימור נמוכה יותר.
-
תאריכי יעד נוקשים עם תכולה גמישה תאלץ אותכם לגלות הרבה קריאטיביות לא רק פתרונות טכניים אבל גם פתרונות עסקיים כדי להעמיד את המוצר הטוב ביותר שאפשר בזמן שיש ליעד. לדוגמה פתרון טכני פשוט יותר לטיפול בתשלום בכרטיסי אשראי זה להשתמש בpayment gateway (חברה חיצונית שתטפל לכם בגביית אשראי) במקום לפתח זאת מאפס. אבל הפתרון העסקי פשוט יותר לבעיה זה כלל לא להתעסק בתשלומים כל עוד אין לכם לקוחות משלמים. תמיד אפשר לגבות כסף מהלקוחות הראשונים בצורה ידנית בטלפון 🙂
-
אתם חושבים שאי אפשר לחתוך ולצמצם שום דבר במוצר שלכם? שכבר צמצמתם כל מה שאפשר? כנראה שאתם טועים. תנסו לחשוב מחוץ לקופסא ותראו מה עוד אפשר לפשט. לדוגמה כדי לבדוק עניין של גולשים במוצר מסוים מספיק לפעמים להרים עמוד נחיתה מעוצב וכלל לא לפתח את המוצר עצמו.
-
אזהרה – השיטה יכולה למרר לכם את החיים, לגרום לכם להתבייש במוצר שאתם משיקים, לריב עם השותפים בוויכוחים סוערים על מה לוותר אבל לפחות זה מקטין את הסיכוי שלכם להגיע לבית קברות של רעיונות שהפיתוח שלהם נגרר ונגרר 🙂
תשקלו את העקרונות הללו כאשר אתם שוקלים את צורת העבודה מול הבית תוכנה לפיתוח המיזם.
אנחנו באיניטק נשמח להיות כאן בשבילכם ולעזור לכם בתכנון ומימוש מוצרי תוכנה.
ישי טנצר,מנכ"ל חברת איניטק
איניטק הוא בית תוכנה המתמחה בפיתוח מוצרי תוכנה מורכבים בשילוב פתרונות AI/ML.
972-543492075+
