apple-touch-icon-144-precomposed

פיתוח מיזמים אינטרנטיים

058-4481-366

פיתוח תוכנה – טעויות שעולות עשרות אלפי שקלים אם לא מאות

 

פיתוח תוכנה

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

הגדרת צורך מול מנהלים ולא מול המשתמשים הישירים במערכת

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

התאמת המשתמשים למערכת – במקום התאמת המערכת למשתמשים

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

דילוג על חלקים מהותיים במערכת

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

התעלמות מבדיקות ביצועים

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

בעיות אינטגרציה – מערכת חדשה מכילה נתונים חלקיים או לא נכונים לעומת המערכת הישנה

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

שגיאות בהמשך התפעול

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

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

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

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

לקביעת פגישת ייעוץ ללא חיוב וללא התחייבות

צרו קשר
058-4481366

אנו כאן בשבילכם, אל תחכו התקשרו עכשיו 058-4481366