פתחתי את הבוקר* עם הקריקטורה המעולה הזו של xkcd (קומיקס הרשת האהוב עלי שאם אתם לא צורכים בקביעות, אתם מפסידים).
ואכן, תופעה מוכרת היא אתרים, תוכנות או מערכות שמיועדים לשרת קהלי יעד מסויימים, אבל מתוכננים לפי הצרכים של קהלי יעד אחרים; או מה שמאוד נפוץ – אתר שאינו לוקח בחשבון כלל את מטרות הלקוחות, אלא רק את מטרות הארגון (ובכך מפספס גם אותן).
אחד הדברים הכי קשים בניתוח מערכות, הוא להבין בצורה נכונה את הצרכים של הלקוח שמולו אני עומדת. האתגר הראשון הוא הגדרת התיחום של הפרויקט. לא מספיק בדר"כ לשאול "מה אתה צריך". צריך לדובב את הלקוח בשאלות (לפעמים על נושאים אחרים לגמרי) כדי להבין מה הבעיות שלו ולמצוא את הפתרונות עבורן. האתגר השני הוא לחבר את הצרכים האלו עם מטרות הארגון, שלפעמים אינן קשורות ואף סותרות את מטרות הלקוח. אז עלולה להיות דילמה לא פשוטה, האם להעדיף אחד על השני, או שניתן בכל זאת למצוא שביל ביניים שייתן לכל הגורמים המעורכים את מבוקשם.
בתכנון אתרים האתגר מורכב יותר, כי לעיתים קרובות אנחנו לא באמת מכירים את הלקוחות (כלומר- הגולשים) ולא יכולים לשאול אותם מה הצרכים שלהם. במקרים רבים אנחנו צריכים להסתמך על השכל הישר שלנו או על מה שהלקוח שלנו יודע (או חושב שהוא יודע) על הלקוחות שלו. אם יש אתר קיים שניתן ללמוד ממנו, זה מצויין. אם לא, כדאי להיות מוכנים לכך שהאתר החדש שנבנה יהווה בסיס ללימוד התנהגות קהלי היעד באתר. באינטרנט קל יחסית – וגם מקובל – למדוד מה עושה הגולש וכיצד הוא מתנהג. תכנון נכון של אתר האינטרנט, שכולל תשתית מספיק גמישה הניתנת לשינוי, ולצידו מערכת סטטיסטיקות טובה, יאפשרו לבנות תוכנית מימוש זהירה שתעשה שימוש במיטבי במשאבי הארגון.
ככלל, אתרים בגודל בינוני ומעלה כדאי לתכנן כך שיוקמו בשלבים**. בכנסת אנחנו עושים עכשיו משהו דומה – כרגע בעיצומו של אפיון-על שממנו תיגזר "מפת דרכים" שעל-פיה יפותח האתר החדש. שלבי המימוש יוגדרו כך שתהיה בהן תכולה מינימלית שנותנת ערך מוסף, משך קצר ככל הניתן (בכל זאת, קצב אינטרנט…) ומראש יוגדרו שלבים בהם נעצור, נבדוק את עצמנו, נמדוד מה קורה באתר ואיך הגולשים משתמשים בו, ונחליט איך להמשיך הלאה בהתאם למסקנות האלו. כדי שהתהליך הזה יהיה אפקטיבי, עוד בשלב האפיון המפורט נגדיר מה אנחנו בודקים ואיך, כמובן ביחס למטרות האתר כפי שהוגדרו באפיון העל.
התוצאות של מדידה ובדיקה יכולות להשפיע בכל מני אופנים. הו יכולות להשפיע על תמהיל, ארגון המידע ומבנה האתר, על ההחלטה לפתח חלק מסויים באתר, או על האופן שבו יפותח. הן יכולות לשנות את הסדר שבו יפותחו או יבוצעו שלבים שונים בתוכנית ההקמה של האתר. חשוב מאוד להסביר מראש ללקוח את התפיסה הזו ואת ההשלכות שלה, כדי למנוע אכזבות ואי-הבנות.
אם נחזור למערכות ארגוניות, שם הגישה הזו יותר מסובכת. בפרויקט גדול ומורכב קל יותר להכניס שלבי מדידה וכיוונון. אבל במערכות שהן יחסית קטנות וממוקדות, הלקוח מצפה לקבל מערכת עובדת שנותנת את כל מה שמצופה ממנה, ומיד. לא תמיד זה כל כך פשוט. לפני כשנה פיתחנו מערכת כזו, שתמכה בתהליך עבודה פשוט לכאורה – המשתמשים שולחים הזמנות לישיבות לאנשים וגופים שונים, אשר מתבקשים להזין את הפרטים שלהם דרך האינטרנט ולאחר מכן המשתמשים צריכים לעבור על הפרטים שהתקבלו, ולאשר או לדחות את ההזמנה שלהם לישיבה.
המורכבות בפרויקט הזה לא היתה בעיקר טכנולוגית, אלא אנושית/תהליכית. ראשית, משתמשי המערכת בארגון התקשו להבין את ההשלכות של צורת העבודה החדשה, על האופן שבו היו רגילים לעבוד עד היום. למרות שיחות רבות, הסברים והדגמות, רק לאחר שהמערכת פותחה והתחילה לעבוד בארגון, התבררו ההשפעות האמיתיות, והתגלו צרכים מהמערכת שלא היו ברורים כלל בשלב האפיון, ולא ניתן היה לצפות אותם. שנית, חלק מהמשתמשים הנם אותם מוזמנים שצריכים להזין את פרטיהם דרך האינטרנט, ולמרות שהם חלק בלתי נפרד מהתהליך, לא ניתן היה לשלב אותן בתהליך האפיון. גם מבחינתם, תקופה של שימוש במערכת הציפה כל מני בעיות והתאמות שיש לבצע במערכת.
בדיעבד, מול הלקוח היינו צריכים להגדיר מערכת כזו שתפותח בשלושה שלבים. שלב ראשון שבו תפותח הפונקציונאליות הבסיסית, ותיפתח לשימוש במסגרת פיילוט על-ידיד קבוצה קטנה יחסית של משתמשים. שלב שני שבו יתקבלו תגובות המשתמשים, ותהיה פניה לקבלת משובי שימוש מהמוזמנים שמשתמשים במערכת דרך האינטרנט. על פי משובים אלו יאופיין ויפותח השלב השלישי, בו תותאם המערכת לפי ההערות שהתקבלו, הפונקציונאליות תושלם ותועשר והמערכת תיפתח לשימוש רחב.
כמובן שגישה כזו דורשת סבלנות מהלקוח, ובעיקר מסובכת מבחינת תקצוב הפרויקט, כיוון שעלות השלב השלישי אינה ידועה מראש. מצד שני, התועלת מהמערכת ושביעות הרצון של המשתמשים, תהיה גדולה בהרבה.
* טוב, לא בדיוק – פתחתי את הבוקר בטיפול ביעל, אימון בחדר כושר, ושוב טיפול ביעל. אבל כשפתחתי את הגוגל רידר שלי, זה באמת היה האייטם הראשון 
** יש עוד סיבות למה זה מומלץ, והעיקרית בהן היא שהאינטרנט משתנה מהר מאוד, ופיתוח אתר במשך חודשים רבים, עלול לגרום לכך שכשהאתר יעלה סוף סוף לאוויר, חלקו או כולו יהיה מיושן ולא רלוונטי.
כל מי שראה אי פעם תרשים של רשת, או מערכת ממוחשבת, מכיר את ציור הענן המייצג את האינטרנט. בניגוד לרשת של מחשבים (כמו במשרד למשל), שבה המחשבים מחוברים זה לזה, או למחשב מרכזי (שרת) – באינטרנט לא מעניין אותנו לאיזה מחשבים או שרתים אנחנו מחוברים. לא מענין אותנו עד כמה מורכבת הרשת או התקשורת או כח העיבוד של המחשבים בה; לא מעניין אותנו אם אתר מסויים נמצא ע"ג שרת א' או שרת ב'; לא מעניין אותנו אם הוא ביפן, בניו יורק או בפתח תקווה; מבחינתנו אנחנו ניגשים לכתובת באינטרנט – בענן – ומקבלים תוכן או שירות. אם כך, כשאומרים "מחשוב בענן" בעצם מתכוונים "מחשוב אינטרנט".
עבודתו של מנתח המערכת נעה לעיתים קרובות בין תרגום לפסיכולוגיה. במקרה הטוב, מה שהלקוח מבקש הוא ברור, ישים והגיוני, ויש לתרגם אותו למסמך שיאפשר לצוות הפיתוח לישם על פיו את בסיס הנתונים, המסכים, התהליכים וכו'. אבל ברוב המקרים, הלקוח רואה בעיני רוחו משהו מעורפל, מבוסס על התוכנה או האתר החביבים עליו ("כמו פייסבוק, אבל שאפשר גם להכניס נוסחאות כמו באקסל". נראה אתכם שומרים על הבעה מתעניינת ומנומסת מול משפט כזה). מנתח המערכות צריך לפענח מה בעצם הלקוח מתכוון – ופה האתגר האמיתי.
תגובות אחרונות