הזכרנו את זה בפוסט קודם על בחירת התוכנה הטובה ביותר, בה התמקדנוניתוח ראשוני משלך עסק תאגידי (שבלעדיה לא ניתן לעשות בחירה נבונה). נראה גם כי למבחר טוב, יש לקחת בחשבון מספר מצומצם של ספקים. אם כן לנתח לא רק את הפתרונות מנקודת מבט "טכנית", אלא גם את השירותים שהם מציעים ואת ארגון משאבי האנוש, שבתוך החברה שלנו, יהיה צורך בכדי להפיק את המרב מהתוכנה החדשה. אחרת, בזבזנו את כספנו בצורה לא טובה על ידי אי השגת היתרונות הרצויים.
עכשיו בואו ניקח צעד אחורה ונשאל את עצמנו אילו דרישות פונקציונליות ואילו כיצד לרכוש יצטרך להציג את הפיתרון האידיאלי לצרכים שלנו: בקיצור, מהם היתרונות העיקריים שאנו מצפים למצוא בתוכנה הטובה ביותר. גם במקרה זה, באשר לניתוח המקדים של העסק שלנו, אנו לא ניקח בחשבון שום מוצר או מפרט טכני מסויםזה יהיה השלב הבא. לעת עתה, אנו ממלאים רשימת בדיקה עם הפריטים ל"תקתק "אשר יועילו בשלבים הבאים.
"אנו שואלים את עצמנו אילו דרישות פונקציונליות ואילו כיצד לרכוש יצטרך להציג את הפיתרון האידיאלי לצרכינו: בקיצור, מהם היתרונות העיקריים שאנו מצפים למצוא בתוכנה הטובה ביותר "
וגם במקרה זה, שלנו רשימת מטלות הוא מנוסח וכרוך יותר מקבלי החלטות פנימי לחברה שלנו: בטח לא רק מחלקת ה- IT.
La מבחר תוכנות ברמה ארגונית זה יכול להיות השפעה של צורך, המתבטא בסקטור פנימי של החברה שלנו, או מנדט ישיר של הנהלה גבוהה (שיש לו השקפה כוללת על האינטרסים העתידיים של החברה והאסטרטגיה הבאה). מקור המנדט עצמו תלוי במידה רבה בשאלה אם התהליך המדובר הוא הליבה או משני לעסק. לזכור שלעתים קרובות הבחירה בתוכנה חדשה היא המפתח לשינוי התהליכים.
בכל מקרה, מה שחשוב באמת זה הכל שחקנים מעורבים (כולל מי שמגלה את הצורך, מי שמקבל החלטות ברמות הגבוהות ביותר וכאלה שיש להם כישורים טכניים ופונקציונליים לביצוע משא ומתן עתידי). מיושרים במטרה הבחירה ועל מאפייני הפיתרון לרכוש.
רק עם הנחות אלה אנו יכולים למעשה לנסח את רשימת דרישות פונקציונליות. באופן אידיאלי, שלושת השחקנים שלנו (משתמשים, מנהלים מובילים ואנליטיקאים טכניים-פונקציונליים) יגיעו יחד לעסק משותף של סיעור מוחות. אין ספק, אפשרות זו תלויה במשתנה טֶמפּוֹ (יש צורך לקחת בחשבון את העלויות הפנימיות עבור defiהקמה וניהול של א progetto).
ופעילות יישור זו חשובה עוד יותר אם ניקח בחשבון היבט נוסף של הבחירה: כמו בכל "מסע הקונה", זהו תהליך הרכישה שמתחיל מצורך ועובר דרך שליפת המידע על הצעת השוק, יתכנו כמה "אזורים אפורים". זה לא נדיר כי ההנהלה הבכירה, או פונקציית החברה שתפיק תועלת מהפתרון, מוצאים עצמם בעלי ידע כללי על הפיתרון שיש לאמץ: היא יודעת מה היא רוצה, לא כיצד לומר זאת בצורה ברורה ומפורשת. גם זה כן מועיל תמיכה מומחית בתחום ה- IT, אם הוא מאויש על ידי אנליסטים פונקציונליים טובים שמפעילים את הכישורים הנכונים.
הנה אז כמה שאלות שהצוות ישאל: מהי רשימת הדרישות המפורטת? האם כל נקודה ברורה לכל הצוות שחיבר את הרשימה? האם מי שיבצע את המשא ומתן מתחשב במנדט שלו? והאם המנדט עצמו ספציפי ומפורט או שיש בו פערים? אסטרטגיה טובה לאמץ יכולה להיות שיטת Scrum: מי שמשתתף בפרויקט מספר סיפור כך שהאקספוזיציה, מסוג דיסקורסיבית, מעדיפה defiהמושגים שישמשו לעבודה.
לעתים קרובות הפתרונות הארגוניים בשוק אין לך את כל הפונקציות הנדרשות על ידי הרוכש. מנהלי החברה יודעים זאת מההתחלה. וזו הסיבה, ברגע שרשימת הבדיקה נערכה, אנו ממשיכים להקים מדד של עדיפות: לכל חברה, ברגע שהיעדים נקבעים, יש לה.
"לעתים קרובות הפתרונות הארגוניים בשוקאין לך את כל הפונקציות הנדרשות על ידי הרוכש. מנהלי החברה יודעים זאת מההתחלה. וזו הסיבה, ברגע שרשימת הבדיקה נערכה, אנו ממשיכים להקים מדד של עדיפות"
יש המציעים להתאגד לכל דרישה ציון שונה של חשיבות: הציון הכולל של כל פיתרון שנבדק יהיה סכום הדרישות הנוכחיות וחשיבותן היחסית. זו עצה של השכל הישר, בתנאי שאינך סכמטי מדי בהערכה הסופית: זה טבעי שבתוך הייחוס של דירוג ישנם גם גורמים חיצוניים לתוכנה, יותר מכל מה שקשור לספק. נראה אותם בפוסט מאוחר יותר.
להעריך את המהותי איכות תוכנה יש צורך להקים כמה מדדים אובייקטיביים (לפיכך מעבר לדרישות התפקודיות, הסובייקטיביות בלבד, הנדרשת על ידי החברה).
אי ידיעת אילו משתנים למדוד את המוצר פירושה אי היכולת להיות מודעים אליו ערך. שוב, אנו רוצים להרכיב רשימה א לבחינת הפתרונות האישיים: אנו נשתמש בו כמטר בזמן הבחירה בפועל.
יש ספרות רחבה בנושא: למעשה, פשוט הקלד מנוע חיפוש "איכות תוכנה" לגלות פוסטים וספרים בנושא. נקודת פתיחה שימושית היא הקול ויקיפדיה, המפרט קבוצה של פרמטרים חיצוני (כלומר לגבי האיכות הנתפסת על ידי המשתמש), כדי להעריך את איכות הפיתרון שיירכש. בין אלה: נכונות, אמינות, איתנות, יעילות. אבל גם פניםניתן לאמת על ידי צוות של מפתחים: תחזוקה, יכולת לשימוש חוזר, מודולריות הם כמה מהדוגמאות המפורטות.
גם במקרה זה הצוות מחליט אינדקס עדיפות לפרמטרים השוניםלדוגמא: הנהלת החברה, בעלת החזון האסטרטגי של הפרויקט, יכולה לייחס חשיבות משנית לשימוש חוזר בתוכנה. וכמובן, בשלב זה של בחירת התוכנה, טוב לדעת את דעתו של ה- פונקצית איכות של החברה (היכן שהיא קיימת).
זה משתנה מהותי: לפני שתתחיל במשא ומתן עליך לזכור את תקציב סך הכל שעומד לרשותך רכישת תוכנה (הן עבור התוכנה עצמה והן עבור עלויות שעת העבודה הדרושות לפעילות הבחירה). כדי לקבוע סכום ריאלי, לחלקם יש כבר מדד של פתרונות שנרכשה בעבר על ידי החברה, אחרים מסתמכים על מפה לאוזן בקרב עמיתים מאותו סקטור (או מאותה קבוצה תעשייתית). בדיקת כמה הוצא בעבר לפתרונות דומים מקלה על תהליך בחירת התוכנה.
"עליך לזכור את התקציב הכולל שעומד לרשותך רכישת תוכנה: בדוק כמה הוצא בעבר על פתרונות דומים, למעשה מאפשר את תהליך בחירת התוכנה "
כמובן, מחיר תוכנה ברמת הארגון הוא תוצאה ישירה לא רק מאיכותה המהותית, אלא גם מהעבודה שעשה הספק כדי לתכנן ולפתח אותה: להפחתת העלויות יש צורות רכישה גמישות (נראה אותם בנקודה 6).
לעולם לא יהיו מספיק דיבורים על זה: כל חברה מוצאת את עצמה מתעסקת כמות הולכת וגדלה של נתונים בהתייחס לעסקיו ולקוחותיה. יחד עם זאת, אנו יודעים שבשנים האחרונות מספר האנשים גדל התקפות סייבר על בסיסי נתונים של החברה. הגנה על המידע שלך היא אפוא אחריות ישירה ובלתי נמנעת של מי שמנהל אותם.
אחת המשימות של מי שמנהל את המשא ומתן תהיה איפוא לדעת את ההגנות שהציב הספק. בינתיים, ידיעה בסיסית של סיכונים ופתרונות לא יכולה לפגוע: מנהל מחלקת תקשוב הוא יוכל ליידע את אנשי הקשר בחברה שלו על שני ההיבטים.
החלט אם אתה מעדיף פיתרון בענן (על תשתית מרוחקת) או במתחם (המותקנת על שרתי החברה) אינה סתם מוזרה: התקציב וסוג ניהול הנתונים משפיעים ישירות עליהם אופן ניהול התוכנה.
עבור מנהלים רבים, אחד פתרון מקומי זה עדיין קשור לתפיסה של יציבות ושליטה: עם זאת, יש לקחת בחשבון את ההשקעות המהותיות ביותר. מצד שני, הענן זה גמיש יותר ופחות יקר מבחינת מחיר, אך הוא מחייב את הספק לתת ערבויות גדולות יותר מבחינת אבטחת מידע וביצועי הערוצים (כלומר מהירות ההעברה והביצוע של התוכנית).
אופן ההנחה של עלויות משתנה גם הוא: המחיר המקומי מבוסס בדרך כלל על תשלום של רישוי, עלויות התאמה אישית, התקנה ראשונית, עלויות תחזוקה עוקבות וכן הלאה. הענן הוא מודל לשלם לשימושפרי גדול יותר, עלות גבוהה יותר. בדרך כלל, במצב הענן, כל החיובים המרכיבים את העלות הופכים לתשלום שמסכם אותם, בדרך כלל נמוך יותר (בהשוואה להתחייבות חוזית רב שנתית, לרוב משלוש לחמש שנים).
זה אולי נראה פרדוקס, אבל זה רק לכאורה: רשימת בדיקות טובה של הציפיות שאנו מציבים לפיתרון החדש ... ניתוח של התוכנה שצריך לשנות. כמובן שאיננו מתכוונים למצב של התקנה ראשונה.
"רשימת בדיקות טובה של הציפיות שאנו מציבים לפיתרון החדש ... לא מתעלמת ניתוח של התוכנה שצריך לשנות"
ראשית, המטרה היא לציין את חולשותהם המוזרויות שהובילו אותנו לחפש מוצר אחר. אפילו הגילאים בתוכנה והטיפול האגרסיבי בו יכולים להוכיח כצעד שגוי.
עם זאת, יתכן ונצטרך לרשום כמה נקודתי חוזק: לא נאמר, למעשה, כי ניהול התהליך עם הפיתרון הישן לא היה שלם בכל היבט.
גם במהלך ניתוח זה, כדאי לבצע עבודה משותפת: ידע פונקציונלי e ידע טכני הם הולכים יד ביד ושניהם תורמים להערכה קונקרטית יותר של איכות התוכנה. אפילו זה שישתנה!
באופן אישי, אני חושב שכאשר התוכנה כבר לא מספקת זו בהחלט לא אשמתם של אלה שעשו את הבחירה באותה תקופה. פשוט השוק השתנה והתוכנה אינה מגיבה לצרכים עסקיים חדשים. זו הסיבה שהנטייה האחרונה הולכת וגוברת כלפי א refactoring יישומים רציפים.
מחבר Paolo Ravalli
המגזר הימי הוא מעצמה כלכלית עולמית אמיתית, שניווטה לקראת שוק של 150 מיליארד...
ביום שני האחרון הודיע הפייננשל טיימס על עסקה עם OpenAI. FT נותנת רישיון לעיתונאות ברמה עולמית שלה...
מיליוני אנשים משלמים עבור שירותי סטרימינג, משלמים דמי מנוי חודשיים. הדעה הרווחת היא שאתה…
Coveware מבית Veeam תמשיך לספק שירותי תגובה לאירועי סחיטה בסייבר. Coveware תציע יכולות זיהוי פלילי ותיקון...
