יש בדיחה עתיקה שפגשתי כשהתחלתי לעבוד בתחום המחשוב – מה היה קורה אם אדריכלים היו צריכים לעבוד כמו מפתחי אתרים. הגילגול שאני פגשתי לראשונה לא התייחס כמובן לאתרי אינטרנט, אלא לפיתוח מערכות, אבל הבדיחה לא השתנתה, רק הכותרת. עוד דבר שלא השתנה, זה הלקוחות.
הבדיחה הזו היא בכלל לא על מפתחי אתרים, או תוכניתנים, היא בעצם על מנתחי מערכות. נכון שעדיין יש מנהלים רבים שחושבים שאפשר לוותר על ניתוח המערכת, ולדלג ישר מדרישות המשתמש אל מסמך האפיון הטכני (או באתרי אינטרנט- היישר אל היישום). אבל לתפישתי, ניתוח המערכת הוא שלב קריטי בהקמה של כל מערכת, תהה אשר תהה.
אגב מנתח מערכת, נתקלתי כמה פעמים בשם אחר לתפקיד הזה: “מְאַפְיֶין”, מהשורש “אפיון”. אני מניחה שזה על אותו משקל של “מְפָתֶחַ” במקום תוכניתן. את המילה “מפתח” שמעתי בעיקר בהקשר של יישום מערכות או אתרי אינטרנט מעל סביבת פיתוח עשירה בכלים ורכיבים. מי שבעיקר כותבים קוד עדיין נקראים תוכנתנים או מתכנתים. על אותו משקל, נראה לי ש”מאפיין” הוא מי שמספק הגדרות להקמה של מערכת מחשוב או אתר אינטרנט בתוך סביבה (או תפישה) מוגדרת מראש. מי שצריך לתכנן את המערכת מאפס, יישאר תמיד מנתח מערכת.
עבודתו של מנתח המערכת נעה לעיתים קרובות בין תרגום לפסיכולוגיה. במקרה הטוב, מה שהלקוח מבקש הוא ברור, ישים והגיוני, ויש לתרגם אותו למסמך שיאפשר לצוות הפיתוח לישם על פיו את בסיס הנתונים, המסכים, התהליכים וכו’. אבל ברוב המקרים, הלקוח רואה בעיני רוחו משהו מעורפל, מבוסס על התוכנה או האתר החביבים עליו (“כמו פייסבוק, אבל שאפשר גם להכניס נוסחאות כמו באקסל”. נראה אתכם שומרים על הבעה מתעניינת ומנומסת מול משפט כזה). מנתח המערכות צריך לפענח מה בעצם הלקוח מתכוון – ופה האתגר האמיתי.
כבר קרה לי שהלקוח ביקש ממני מערכת workflow מתוחכמת בעלות מטורפת שתחייב משרה שלמה רק לצורך תחזוקה שלה. אחרי שלושה ימים של פגישות שכנעתי אותו שהוא בעצם צריך מערכת לניהול ומעקב אחרי משימות – פשוטה יותר, נוחה יותר, גמישה יותר – וזולה יותר. יש כמובן גם מקרים הפוכים, ופה הבעיה גדולה בהרבה. פרויקט מסויים שהגעתי אליו בשלב מתקדם יחסית, היה פרוייקט פשוט של אתר בפורטל הארגוני. לכאורה הכל היה ברור, אפילו קיבלנו מהלקוח מסמך עם תרשים סכמאטי של האתר שהוא רוצה. גם התשתית היתה ברורה וידועה (בארגון יש MOSS) ואפשר להתחיל מיד ולפתח. כשהאתר היה מוכן והוצג ללקוח, התברר שהתוצאה רחוקה מאוד ממה שהלקוח ראה בעיני רוחו, וככל שנשאלו יותר שאלות והתקבלו יותר הערות, התברר שהלקוח מעוניין במשהו מתוחכם בהרבה, רחוק ממה שהתשתית מספקת לו, ומחייב עבודה רבה נוספת [1]. בשלב הזה, כשהצטרפתי לפרוייקט, ביצענו אפיון מפורט של האתר, אשר גם קיבל את אישור הלקוח, אבל כבר באווירה עכורה ועצבנית עקב הזמן הרב שעבר והעבודה שהושקעה לשווא.
השאלה שאנחנו צריכים לשאול את הלקוח היא לא מה הוא רוצה, אלא מה הוא צריך. מלכודת נפוצה מאוד היא לשמוע מהלקוח מה הוא רוצה, ולתת לו בדיוק את זה. יש לנסות ולהבין את תהליכי העבודה שלו, ומה הוא מעוניין להשיג באמצעות המערכת. מי ישתמש בה? איזה מידע יוזן דרכה? ומתי. מתוך הבנת הצרכים האלו, אפשר להציע ללקוח את הפתרון המתאים לו.
[1] זה נושא לפוסט נפרד – יתרונות וחסרונות של פיתוח על תשתיות תוכנה.
