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

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