שיתוף המשתמש המדריך

מבוא והסבר כללי

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

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

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

הבחנה בין סוגי משתמשים

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

מפת"ח מעדן את ההגדרה של משתמש ומתייחס לגורמים ולהגדרות כדלהלן:

 ·         לקוח/משתמש עיקרי

 ·         מומחה היישום

 ·         משתמש/משתמש קצה

לקוח/משתמש עיקרי

למונח לקוח יש במפת"ח מספר שימושים, בהקשרים שונים לגמרי. השימוש השכיח והעיקרי הוא בהקשר עם המערכת - עץ המערכת. לקוח הוא הגורם המזמין (מממן) ומאשר את המערכת. אין לבלבל לקוח עם משתמש. לקוח מתלכד עם "המשתמש העיקרי" ועם "מומחה היישום" ומתואר ברכיב 1.1 בעץ המערכת. כלל משתמשי המערכת מתוארים ברכיב 2.2. הלקוח הוא המאשר את הגדרת הדרישות, נכונות המפרט, סיכום הבדיקות, העברת המערכת לייצור וכו'.

שימוש אחר של המושג "לקוח" הוא בהקשר טכני של מערכות ממוחשבות מסוג שרת/לקוח (Client/Server). שימוש נוסף הוא בהקשר תקן ISO 9000, שם לקוח הוא הארגון הפונה לספק לשם קבלת שירותים.

מומחה היישום

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

 

משתמש/משתמש קצה

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

 ·         כלים למשתמש קצה

 ·         מדריך למשתמש

 

כדאי מאד לבחון גם את האפשרות של הצגת מודל הנתונים, לפחות סכימה כללית, לפני משתמשי הקצה על מנת שהם יבינו אילו דו"חות ושאילתות ניתן לבקש (ואילו לא ניתן!) - איזה מידע אגור במערכת (ואיזה לא!)

תיעוד ברכיבי עץ המערכת

הלקוח (המשתמש העיקרי) ומומחה היישום מתוארים ברכיב 1.1 בעץ המערכת. כלל משתמשי המערכת מתוארים ברכיב 2.2.

בנושא כלל המשתמשים חשוב לקבל כימות וסווג כוללים (לפי מבנה ארגוני ותפקוד) ואין תמיד צורך לרדת לרמה של רשימה שמית. מה שאין כן בלקוח ומומחה היישום. אם אין לקוח או אין מומחה יישום, היינו, אם רכיב 1.1 - הרכיב הראשון בעץ המערכת איננו מוגדר - אין מערכת! אפשר להקל, למשל, ע"י הפרדה בין הדרג הניהולי של הלקוח אשר ישתתף בפגישות רק לעתים רחוקות וייתן את האישור הסופי והכללי, לבין הדרג המקצועי אשר ישתתף בכל הפגישות (סקרים) ויאשר את הפרטים. ההנחיות המדויקות והמלאות לשיתוף מומחה היישום נמצאות איפוא בתהליך עצמו ובפרט בקיט האפיון בכרך יסודות\מחזור חיים. ראה גם קיט סקריםReviews -  בכרך איכות.

הדרג הניהולי

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

 ·         תמצית של מהות המערכת – באמצעות הצגת עץ המערכת

 ·         תמציות של תכנית העבודה ומשאבים - בעיקר עבור הנהלת יחידת המחשוב

 ·         הצבעה על הנקודות הקריטיות (CSF’s - Critical Success Factors) הדורשות הכרעת הדרג הניהולי

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

מחזור החיים והמשתמש

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

אחריות כוללת לפרויקט

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

 

 

ייזום

המצב הרצוי בייזום הוא שאחד המשתמשים (המשתמש העיקרי, הלקוח) הוא היזם ובא לבקש סיוע מיחידת המחשוב.

 

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

אפיון

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

 

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

 

בקשה להצעות

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

 

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

 

עיצוב ובנייה

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

 

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

 

בדיקות מערכת

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

 

אחריות המשתמש	אחריות יח' מערכות מידע
תכנון מבחני קבלה	כתיבת תיק בדיקות ביצוע system test כתיבת תיק סיכום בדיקות סיוע בתכנון מבחני קבלה השתתפות במבחני קבלה
עריכת סקר
ביצוע מבחני קבלה אישור (קבלה) המערכת	ליווי מבחני קבלה קבלת תוצאות מבחני קבלה הוצאת תיק סיכום בדיקות

התקנה והרצה

בשלב זה, אחריות המשתמש בארגון היא ליווי תהליך ההטמעה.

 

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

 

תפעול ותחזוקה

 

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

 

תחקור מערכת

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

 

אחריות המשתמש	אחריות יח' מערכות מידע
סיוע בתחקור	אחריות לביצוע התחקור כתיבת המסמך הפקת לקחים לפרויקט ולקחים כלליים
עריכת סקר

עץ המערכת כגורם מסייע

שימוש נבון בעץ המערכת עשוי להגביר את מעורבות המשתמשים (משתמשי-קצה ומומחי היישום) וקבלת אישורם למערכת. רכיבים רבים בעץ המערכת ממחישים למשתמש את המערכת. עץ המערכת יוצר קשר פשוט (1:1) בין המערכת לתיעוד שלה – תיק המערכת. עץ המערכת משמש גם מכנה משותף לליבון אי-הסכמות וליצירת הסכמה בסופו של דבר בין משתמשים בעלי דעות ואינטרסים מנוגדים.

בהצגת עץ המערכת למשתמש הקפד על הנקודות הבאות:

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

2.       הקפד להציג בעיקר רכיבים לוגיים/פונקציונאליים וגם אותם בצורתם החיצונית ולא הפנימית:

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

             ·         המשתמש צריך לראות ולאשר את השדות העיקריים של הקבצים הלוגיים ולהגיב גם על סוג הקשרים שבין הקבצים (אחד לאחד, אחד לרבים וכו').

             ·         המשתמש לא צריך להיות מעורב במבנה הקבצים הפיסיים ובקשר בינם לבין הקבצים הלוגיים.

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

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

הרכיבים העיקריים באמצעותם מוצגת המערכת למשתמש הם:

תמצית מנהלים

2.1.4  מילון מונחים

2.2  תיחום חיצוני

2.3  תיחום פנימי

2.4.2  מסכי פעולה

2.5  תהליכים

2.6  טרנזקציות

2.11  קבצים לוגיים

2.13  מילון פריטי מידע

2.15  דו"חות ושאילתות

2.16  קלטים

2.20  הצלבות וחיתוכים

2.22  ממשקים וקישורים

תמצית מנהלים

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

אין כאן כתיבת מסמך נוסף, אלא תמצות ועריכה של מסמכים (מקצועיים) קיימים. ראה גם פרק בנושא זה בקיט תיעוד בכרך נושאים תומכים. תמצית מנהלים טובה היא זו שאחריה "מבקשים עוד". בשלב ראשון יש להוציא תמצית מנהלים פשוטה וקצרה ביותר. חוץ מרכיבי X.0 (הבהקים), יש להוסיף מספר רכיבים המושכים תשומת לב, מדברים אל המשתמש בשפה פשוטה ומוכרת וממחישים את המערכת: מסכים, פריטי מידע מרכזיים, ציוד מחשבים וכו'. ציין בברור ש"אין זה הכל". הקפד על הסיעוף של עץ המערכת כך ש"החורים" יבלטו. תן למשתמש "לבקש עוד". הקפד תמיד להביא לפגישות את התיק המלא לצד תמצית המנהלים!

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

2.1.4 מילון מונחים

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

2.2 תיחום חיצוני

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

יש לשים לב למשתמשים חיצוניים ולמערכות משיקות.

2.3 תיחום פנימי

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

 ·         המשתמשים רואים בד"כ חלוקה ארגונית ולא פונקציונאלית

 ·         עצם המושג "תת-מערכת" אינו ברור וקשה להבנה או הסכמה

2.4.2 מסכי פעולה

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

2.5 תהליכים

ניהול ראיון דרך "תהליכים" מתאים למרואיינים שנוח לחשוב ולתאר את פעילותם דרך תהליכי עבודה וזרימת עבודה (workflow) ולחשוב פונקציונאלית.

2.6 טרנזקציות

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

 ·         בטרנזקציות מרכזיות שהן מעין תת-תהליכים מרכזיים (גם באפיון)

 ·         בשלב העיצוב כחלק מאימות עם המשתמשים

2.11 קבצים לוגיים

משתמשים רבים מעדיפים למקד את הראיון בדיון על זרימת המידע במערכת יותר מאשר על תהליכים וטרנזקציות. מקרה נוסף הוא משתמשים שנוטים לתאר את פעילותם במסכים ובמידע תוך "דילוג" על תהליכים וטרנזקציות. ראיונות בנושא זה ישמשו קלט ליצירת תרשימי זרימת המידע (DFD) במערכת  והגדרת הישויות המרכזיות (ERD).

2.13 מילון פריטי מידע

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

2.15 דו"חות ושאילתות

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

2.16 קלטים

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

 ·         אימות הטפסים עם ממשקים ודו"חות

 ·         אימות הטפסים עם מסכי הפעולה

2.20 הצלבות וחיתוכים

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

2.22 ממשקים וקישורים

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

עריכת ראיונות

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

 ·         את מי רוצים לראיין

 ·         איזה מידע רוצים לקבל ממנו

 ·         מועד רצוי

 ·         סדר ותלות בין המרואיינים

 ·         משך הראיון (הערכה) כולל "עומק" המידע הנדרש

 

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

 ·         את מי בדיוק הוא הולך לראיין

 ·         מה בדיוק הוא רוצה להשיג בראיון

 

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

 

 

ניהול הפגישה

חשוב מאד לוודא שכל פגישה בה משתתפים משתמשים, תנוהל באופן מסודר:

 ·         להחליט מי מוזמן, מי מיודע על הפגישה וכו'

 ·         להקפיד לזמן את המשתמשים בע"פ ובכתב

 ·         להתכונן כראוי לפגישה. כל פגישה דורשת עבודת הכנה ואין להתעלם מכך

 ·         לנהל נכון את הפגישה עצמה

 ·         לסכם את הפגישה בסמוך לקיומה ולהפיץ סיכום דיון

 

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

קיימות מספר גישות וטכניקות לביצוע ראיונות:

 ·         הגישה הקלאסית

 ·         התמקדות בנתונים

 ·         ראיון לפי אובייקטים

 ·         ראיון מערכות ממוכנות

הגישה הקלאסית

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

 ·         קושי אנושי/ארגוני - המעמד הארגוני והגדרת התפקיד של המרואיינים לא תמיד ברורים.

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

התמקדות בנתונים

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

ראיון לפי אובייקטים

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

ראיון מערכות ממוכנות

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

ניתוח המידע

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

 ·         פעלים הם תהליכים או שדרים וממשקים

 ·         שמות עצם הם נתונים או אובייקטים (או גורמי חוץ)

 ·         שמות תואר או לוואי הם מדדים לנפחים ושיקולי תפעול

 

כיוון שכך, אין כל סיבה להבנות את הראיון יותר מדי.

טכניקות מקובלות

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

JAD

Joint Application Development – מתודולוגיית פיתוח המתבססת על שיתוף המשתמש בעיצוב ופיתוח היישום באמצעות סדנאות משותפות למפתחים ולמשתמשים הקרויות JAD sessions. השיטה פותחה ע"י צ'אק מוריס וטוני קרופורד מחב' IBM בסוף שנות השבעים.

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

יתרונות השיטה:

 ·         מיקוד רב בנושא

 ·         מתנהלת כסדנא בסביבה ייחודית ומבודדת

 ·         חילוץ מהיר של דרישות המשתמשים בתחום פונקציונליות וממשק משתמש

 

הרכב אופייני של משתתפים בסדנא יכלול:

 ·         יזם/מארגן – מחיל חוקים, מנהל את הדיון

 ·         3-5 משתמשי קצה – נוכחות חובה בכל הפגישות

 ·         2-3 נציגי צוות הפיתוח – להבהרות ושאלות

 ·         נציג הנהלה בכיר – לפישור וקבלת הכרעות, אינו משתתף קבוע

 ·         2-3 משקיפים – אינם משתתפים פעילים בדיון

 ·         מומחה/י היישום – להבהרת נושאים עסקיים וטכנולוגיים

 

אבטיפוס

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

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