הקוד כבר לא צוואר הבקבוק: הכירו את מודל RDD לפיתוח מבוסס מציאות
- לפני יומיים (2)
- זמן קריאה 4 דקות
מאת: דן ליכטנפלד | מנכ״ל משותףPeax Ideo (Ideo Digital), peax software CTO
16.08.2026
במשך שנים, תעשיית התוכנה התבססה על ההנחה שפיתוח הוא יקר ולכן נדרש אפיון ממושך לפני תחילת הבנייה. אולם כיום, הודות לכלי AI ופלטפורמות ענן, הקוד כבר אינו צוואר הבקבוק המרכזי, אלא היכולת של הארגון להבין מה נכון לבנות.
המאמר מציג את מודל RDD (Reality Driven Development) שפותח ב-Peax Ideo, אשר שואף לפתור אי-ודאות לא באמצעות עוד תיעוד, אלא על ידי בניית גרסה מוחשית מוקדמת של המערכת. החדשנות במודל היא בהפרדה בין "בנייה לטובת למידה" לבין "בנייה לייצור", תוך הפיכת התכנון למבוסס מציאות והוזלת עלויות הלמידה בשלבי הפיתוח.
הקוד כבר לא צוואר הבקבוק. ההבנה כן.
במשך שנים תעשיית התוכנה פעלה על בסיס הנחה כמעט מובנת מאליה: פיתוח הוא יקר, שינוי הוא מסוכן, ולכן צריך לחשוב, לאפיין, לתכנן ולאשר ככל האפשר לפני שמתחילים לבנות. ההנחה הזו עיצבה כמעט כל מתודולוגיה, תהליך רכש ומודל ניהולי שאנחנו מכירים. מכאן הגיעו מסמכי האפיון הארוכים, תוכניות העבודה המפורטות, חלוקת הפרויקט לשלבים, הערכות המאמץ, ועדות ההיגוי, ניהול השינויים והשאיפה המתמדת להגיע לוודאות לפני תחילת הביצוע.
הבעיה היא שהוודאות הזו כמעט אף פעם לא הייתה אמיתית. אפשר היה לאשר מסמך בן מאות עמודים ועדיין לגלות, ברגע שבו משתמש אמיתי פגש את המערכת, שהבנו את הצורך רק באופן חלקי. אפשר היה לעמוד בדרישות, בלוחות הזמנים ואפילו בתקציב, ועדיין לספק מוצר שלא באמת התאים לאופן שבו הארגון עובד.
כיום, עם AI, כלי פיתוח חדשים, פלטפורמות ענן ויכולת לייצר מערכות עובדות במהירות חסרת תקדים, הפער הזה נעשה בולט עוד יותר. הקוד כבר אינו בהכרח צוואר הבקבוק המרכזי. צוואר הבקבוק הוא היכולת להבין מה נכון לבנות, להגיע להסכמה אמיתית ולהבחין בזמן בין הנחה לבין עובדה.
מתוך ההבנה הזו פיתחנו ב-Peax Ideo את Reality Driven Development, או RDD.
מהו בעצם RDD
RDD
הוא מודל עבודה לפיתוח מוצרים ומערכות דיגיטליות שמבוסס על עיקרון פשוט:
לא מנסים לפתור אי ודאות באמצעות עוד תיעוד. פותרים אותה באמצעות מציאות שאפשר לראות, להפעיל ולבחון. במקום להתחיל מתהליך ארוך שבו הארגון מנסה לתאר במילים את המערכת העתידית, RDD שואף לייצר מוקדם ככל האפשר גרסה מוחשית של אותה מערכת. היא אינה חייבת להיות מלאה, מוקשחת או מוכנה לייצור. היא כן צריכה להיות אמיתית מספיק כדי לאפשר למשתמשים, למנהלים, לאנשי המוצר ולצוותי הפיתוח להבין כיצד הפתרון עובד בפועל.
זה יכול להיות תהליך עסקי שניתן להריץ מקצה לקצה.מסע משתמש שאפשר לעבור בו.מסך עם נתונים מציאותיים.חוק עסקי שמיושם ולא רק מתואר.תרחיש חריג שממחיש מה קורה כשדברים אינם מתנהלים כמתוכנן.
המטרה אינה להרשים באמצעות אבטיפוס יפה. המטרה היא לייצר אמת משותפת.
RDD
מפריד בין שני סוגים שונים של בנייה, שבעבר נטו להתערבב זה בזה.
הראשון הוא Build to Learn, בנייה שמטרתה ללמוד
.
בשלב הזה בונים כדי לבדוק הנחות, להשוות חלופות, לחשוף פערים, לזהות חריגים ולשפר את ההבנה המשותפת. המיקוד אינו בשלמות הנדסית, אלא במהירות ובאיכות הלמידה.
השלב השני הוא Build to Deliver, בנייה שמטרתה לספק מערכת אמינה לייצור.
כאן נכנסים כל המרכיבים שהופכים פתרון למערכת: אבטחה, ביצועים, אינטגרציות, נגישות, ניטור, התאוששות, בדיקות, תמיכה, תפעול, תחזוקה ויכולת לעמוד בעומס ובשינוי.
ההפרדה הזו חשובה משום שהיא מאפשרת לארגון לא להתחייב מוקדם מדי לבנייה מלאה של פתרון שעדיין לא הובן.
מה משתנה בפועל
השינוי הראשון הוא באופן שבו מגדירים התקדמות. בפרויקטים מסורתיים קל למדוד כמה מסמכים הושלמו, כמה משימות נסגרו וכמה קוד נכתב. קשה יותר לדעת אם הארגון באמת מבין את המוצר שהוא עומד לקבל. ב-RDD התקדמות נמדדת גם ברמת הבהירות.
כמה תהליכים כבר נבחנו?כמה החלטות הפכו מהנחה למשהו שנוסה? כמה חריגים נחשפו? כמה חלקים במוצר כבר הובנו מספיק כדי שניתן יהיה להקפיא אותם ולהתקדם?
השינוי השני הוא באופן שבו מנהלים סקופ.
במודל המסורתי מנסים להגדיר סקופ רחב בתחילת הדרך, ולאחר מכן מגנים עליו באמצעות תהליכי בקרה.
ב-RDD הסקופ מתגבש מתוך למידה. לא משום שאין משמעת, אלא משום שהמשמעת מופעלת במקום הנכון.
לא מגנים על הנחות מוקדמות רק משום שנכתבו במסמך. בוחנים אותן, משפרים אותן, ורק לאחר שהן הוכחו במידה מספקת, מקפיאים אותן ומתחייבים להן.
השינוי השלישי הוא במערכת היחסים בין הלקוח, המוצר והפיתוח.
במקום שהלקוח "ימסור דרישות", המוצר "יתרגם" והפיתוח "יבצע", כולם עובדים מול אותה מציאות. הדיון אינו עוד על מה כל אחד התכוון. הוא מתרחש סביב משהו שאפשר לראות ולהפעיל. זה מצמצם פרשנות, מקצר ויכוחים ומאפשר להעלות מוקדם נושאים שבדרך כלל מתגלים רק מאוחר: הרשאות, תלויות, חריגים, מגבלות ארגוניות, אינטגרציות, איכות נתונים והתנהגות משתמשים.
השינוי הרביעי הוא ביחס לתקציב.
בעולם הישן, כל שינוי נתפס כמעט אוטומטית כתוספת עלות.בעולם שבו ניתן ללמוד מהר ובעלות נמוכה יותר, חלק גדול מהשינויים צריך להתרחש לפני שהמערכת מוקשחת. זהו בדיוק המקום שבו הם זולים, רצויים ובעלי ערך.
RDD
אינו מבטל את עלות השינוי. הוא משנה את מועד השינוי. במקום לשלם הרבה על תיקון מאוחר, משקיעים מעט יותר בלמידה מוקדמת.
למה נדרש בכלל מודל חדש
Agile
פתר חלק מהבעיות של Waterfall, אך במקרים רבים הוא לא שינה את נקודת המוצא. גם בארגונים אג'יליים, צוותים עדיין מקבלים לעיתים backlog שמבוסס על הנחות, מפתחים אותו בסבבים קצרים ומגלים רק לאחר כמה ספרינטים שהכיוון עצמו אינו מדויק.
הקצב השתפר, אך לא תמיד איכות ההבנה.
Design Thinking
תרם רבות להבנת משתמשים ולבחינת רעיונות, אך לעיתים הוא נשאר בשלב המחקר, הסדנאות והאב-טיפוס, בלי חיבור מספיק ברור להחלטות ההנדסיות, לתפעול וליכולת לספק מערכת אמיתית.
Lean
חידד את חשיבות הלמידה והניסוי, אך בארגונים גדולים ובפרויקטים מורכבים היה קשה לעיתים ליישם את עקרונותיו מעבר למוצר דיגיטלי מצומצם.
RDD
אינו מבקש להחליף את השיטות האלה.
הוא מבקש לחבר ביניהן סביב מציאות עובדת. הוא לוקח את הלמידה של Lean, את מיקוד המשתמש של Design Thinking, את האיטרציה של Agile ואת המשמעת של הנדסת תוכנה, ומחבר אותם למודל עבודה אחד שבו בנייה משמשת גם כאמצעי להבנה.
למה עכשיו?
הסיבה ש-RDD רלוונטי עכשיו אינה משום שגילינו פתאום שאפיון אינו מושלם. ידענו זאת תמיד. הסיבה היא שכיום ניתן לייצר מציאות מהר מספיק כדי להפוך אותה לכלי ניהולי.
הבינה המלאכותית מאפשרת לצוותים ליצור ממשקים, תהליכים, מודלים, חיבורים ותרחישים בזמן קצר בהרבה. הוא מאפשר לבדוק כמה חלופות, לשנות כיוון, לייצר נתונים מדומים ולהמחיש החלטות לפני שהן הופכות להתחייבות יקרה השינוי העמוק אינו רק שמהירות הפיתוח עולה. השינוי הוא שעלות הלמידה יורדת. וכאשר עלות הלמידה יורדת, אין הצדקה להמשיך לקבל החלטות גדולות על בסיס מסמכים בלבד.
זו אולי התובנה המרכזית של RDD: AI לא רק מאיץ את הייצור. הוא משנה את הכלכלה של אי הוודאות.
על המחבר:
דן ליכטנפלד: מנכ״ל משותףPeax Ideo (Ideo Digital), peax software CTO
דואר אלקטרוני: dan@ideo-digital.com מספר נייד: 0543454451
תגובות