פתיחה

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

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

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

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

כל הסדרה

מה הערך של פיתוח טיוטה?

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

דרישות מנקודת מבט המשתמש צפות החוצה

דמיינו צוות מכירות שבונה בלואו-קוד מערכת לניהול לקוחות. האינטואיציות היומיומיות שלהם לגבי מה מרגיש “נוח” באות לידי ביטוי.

  • רמת הפירוט של שדות הקלט.
  • מה צריך להופיע במסך הרשימה.
  • מיקום הכפתורים וזרימת העבודה הטבעית.

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

זיהוי מוקדם של אי-הבנות וחוסרים

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

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

המלכודת של קידום הטיוטה לפרודקשן

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

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

“יש ערך לטיוטה” אינו אומר “מותר להעלות את הטיוטה לפרודקשן”. כך רק משחזרים את מסלול ההתרסקות של “אקסל האל”.

חלוקת תפקידים מול מומחים

כיצד צריך ארגון להתייחס לתוצרים של פיתוח אזרחי? התשובה ברורה.

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

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

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

מה צריך לשמור באמצעות ממשל

כדי שפיתוח אזרחי יישאר בריא דרושים כללי ארגון.

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

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

סיכום

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

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

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

הבא: פערי נקודת מבט מייצרים מורשת שלילית בכמויות (חלק 6 מתוך 7)