מדריך מהיר לביצוע פיילוטים ו-PoCs

מבוא

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

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

אז איך אתה יכול לעשות הכל בחוכמה ולגרום להכל לקרות?

הדרכה

מטרות הטייס

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

בסך הכל, בסופו של דבר נקבל שלושה סוגים עיקריים של בדיקות פיילוט, וכמקרה מיוחד של פיילוט, הוכחת קונספט (PoC - proof of concept):
* בדיקת עומס (+ מדרגיות)
* בדיקה פונקציונלית
* בדיקת סובלנות תקלות

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

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

Оборудование

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

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

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

תוכנית בדיקות

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

אנשים

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

תחומי אחריות/גישה

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

טיס

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

סיום הפיילוט

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

מקור: www.habr.com