כישלון הבחירות האלקטרוניות במפלגת העבודה השבוע היה מהדהד במיוחד. ראשית עלי לציין שאני ניזונה אך ורק ממה שקראתי באתרי החדשות ובבלוגים ואין לי מושג מה באמת קרה או שלא קרה שם. הייתי שמחה לשמוע ממישהו את כל הסיפור, אבל יש לי הרגשה שיקח זמן עד שנשמע את העובדות (אולי בבית המשפט?).בינתיים אני יכולה לחשוב על מה שאני כן יודעת ומה אפשר ללמוד על זה בנוגע לפרוייקטי מחשוב. זה מבלי להכנס כרגע לדיון בשאלת השימוש במכונות הצבעה אלקטרוניות בבחירות.
אז מה היה לנו?
חברת טלדור זכתה במכרז של מפלגת העבודה למחשוב הבחירות האלקטרוניות לפריימריז. ההצעה שלה היתה ההצעה הזולה ביותר – זולה משמעותית. התוכנה שהוצעה במכרז היתה אמורה להיות מופעלת לראשונה במסגרת הפריימריז של העבודה. לטלדור היו שבועיים בלבד, מרגע הזכייה ועד לפריימריז עצמם. ברגע האמת, הצטרפו כמה גורמים לכדי כשלון אדיר ומהדהד:
בעיות תקשורת – שמעתי כמה גרסאות למקור הכשלון, כגון בעיות ברוחב הפס של המודמים הסלולאריים, קריסה של נתבים ועוד. בעיות התקשורת לא גרמו רק לבעיה בהזרמת נתוני ההצבעות למחשב המרכזי, אלא כנראה גם מנעו מעבר נתונים חיוניים לעצם ביצוע ההצבעה, כגון אישור לבוחר על קליטת הצבעתו.
בעיות שימושיות – מצביעים רבים לא הצליחו לתפעל את המערכת כראוי. בין אם התקשו במעקב אחר ההוראות, ובין אם התקשו בהפעלת מסך המגע – למשל בהבדל בין לחיצה ארוכה וקצרה. בפועל, לא הצליחו להפעיל את המערכת כראוי ולא ידעו האם ההצבעה במחשב באמת שיקפה את כוונתם.
בעיות תפעול – מי שהיו אמורים לתפעל את הקלפיות האלקטרוניות, כנראה עובדי טלדור, לא היו מסוגלים בפועל לתת מענה לתקלות שהתעוררו.
המחיר
היו מי שכתבו שבחירה בהצעה הזולה ביותר, בהכרח מביא לתוצאה הזו. זה נכון לפעמים, אבל ממש לא תמיד. מחיר גבוה יותר היה עוזר רק אם היו מנתבים אותו להשקעה בדברים הנכונים. לדוגמא, השקעה בביצוע סימולציות של ההצבעה, בתנאי אמת. לא בתנאי מעבדה, ולא באמצעות מספר תחנות סמוכות. סימולציה שקרובה ככל הניתן לתנאי האמת של המערכת, בפריסה מבוזרת ובהתבססות על תנאי התקשורת הזהים לתנאי האמת.
לצערי, חיסכון ב-QA נפוץ מאוד בפרויקטי מחשוב. אפשר לפצות על כך באמצעות תקופת הרצה של המערכת, ותיקוני תקלות במהלכה (בדרך כלל במחיר של יצירת אנטגוניזם מפותח אצל המשתמשים, כלפי המערכת וכלפי הספק). אבל, הממ, זה לא בדיוק פרויקט שמאפשר את הגישה הזו. דרך נוספת לפצות על QA בינוני, היא הטמעה יסודית וארוכת טווח, כולל ליווי משתמשים בזמן אמיתי. אה, רגע, בחירות חסויות ואנונימיות? אז גם זה נפסל. לכן בפרויקט כזה אי אפשר לחסוך ב-QA.
אפרופו חוסר האפשרות לבצע הטמעה, עוד נושא שבישראל נוטים לוותר עליו מראש הוא בדיקות שימושיות. לא צריך מערכת מחשב מתוחכמת בשביל לבלבל משתמשים. במערכת שמופעלת בתנאים כה מגבילים, חובה לבדוק את השימושיות של המערכת מול משתמשים אמיתיים מכל האוכלוסיות, ולהשתדל לבדוק דווקא מול האוכלוסיות הבעייתיות יותר – מבוגרים, בעלי מגבלות, משתמשים שאינם מנוסים בשימוש במחשב, או משתמשים שסובלים מלקויות למידה שונות.
לחשוב אחרת
עוד השקעה חשובה, היא בתכנון והקמה של מנגנוני כשל. גם אם הקמתם מערך מחשוב מפואר, ובדקתם אותו מליון פעם, תמיד עלולות לצוץ תקלות שונות. אם נקודת תורפה אפשרית היא התקשורת, אולי נכון יותר לפתח מערכת מבוזרת שאינה עובדת באון-ליין אמיתי? למשל, שרת מקומי שמסתנכרן מול מערכת מרכזית פעם בעשר דקות, יהיה הרבה פחות חשוף לנפילות תקשורת ולא יעכב או יימנע הצבעות. זה גם מאפשר לשלוט בעומסי התקשורת בצורה מבוקרת. תצורה כזו מאפשרת במקרה של כשל תקשורת משמעותי, להשתמש במנגנוני סנכרון אחרים, עד כדי מודם טלפוני פשוט.
תכנון נוסף הוא תסריטי תגובה. אם מעמידים מאות תומכים טכניים לתמיכה באירוע חד-פעמי, אפשר לצפות שלא יהיו מנוסים ושולטים בכל רזי המערכת. צריך לצייד אותם במדריך troubleshooting שמנסה לקחת בחשבון את כל סוגי האירועים, כולל המופרכים ביותר. הנחת היסוד בכתיבת מדריך כזה צריכה להתבסס על חוקי מרפי, לא על מסמך האפיון של המערכת.
איך אני נראה?
לבסוף, צריך לזכור שמעבר לאופן שבו מנוהל ומיושם הפרויקט, יש גם היבטים עיסקיים. כל מי שניהל אי-פעם פרויקט מחשוב יודע שצריך לשמור כל סיכום דיון ומייל, ולתעד כל דבר. אבל ישנם פרויקטים שבהם זה ממש לא משנה אם המלצתם ללקוח לעשות את הדבר הנכון, והם החליטו לחסוך. אולי אתם מכוסים מבחינה משפטית, אבל זה לא עוזר לספק שנכשל בצורה כל כך מוחלטת ובעיקר כל כך מתוקשרת.
לפעמים עדיף לא להכנס לפרויקט אם התנאים העסקיים לא מאפשרים לספק את הסחורה בצורה מכובדת. אם כן מחליטים לבצע את הפרויקט, חובה לתכנן בצורה זהירה ולעשות הכל כדי שלא “לעשות טלדור”.
