כך נבנים פתרונות טכנולוגיים שמתחברים לשטח שלב אחר שלב:

1. גיבוש הרעיון Ideation

זהו שלב של חקירה וגיבוש – מהי הבעיה שאותה באנו לפתור? מי הקהל? מה הפתרון שאנחנו מדמיינים? מה קיים כבר? מה חסר ובאמת נדרש? זהו שלב ראשוני, שמייצר לרוב תיאור מילולי, השראה ממודלים דומים או הצגת בעיה ופתרון בצורת מצגת או סיפור.
מה קורה כאן בפועל?
מגבשים ניסוח ראשוני של הבעיה / הכאב / הצורך, הקהל והפתרון האפשרי. זה עשוי להיות טיוטת מצגת, תיאור סיפור משתמש או מפה של אתגר והזדמנות.
מה חשוב שתעשו בשלב הזה?
~ אל תקפצו מהר מדי לפתרון לפני שיש הבנה עמוקה של ההקשר, החסמים והבעיה שאותה באנו לפתור
~ דייקו את הבעיה ממבט של קהלי היעד ולא רק מהתחושה שלכם
~ שתפו אנשי שטח ממגוון רחב של נקודות מבט בשלב מוקדם, כולל נקודת המבט של משתמשים פוטנציאליים
 משאבים שיכולים לעזור:
~ אנשי מקצוע: מנחי Design Thinking, מומחי תוכן חברתי, מומחי יזמות חברתית
~ מסגרות סיוע: סדנאות מיפוי אתגר, תוכניות ideation לעולם החברתי – דוגמת אידיאטור של הכוורת

2. הגדרת דרישות ואפיון Requirements & Specifications

בשלב זה מתחילים לתרגם את הרעיון להיגיון פעולה: אילו פונקציות המוצר צריך לכלול? איך המשתמש עובר דרכו? מהם תרחישי הקצה? אילו מגבלות יש לקחת בחשבון (פרטיות, רגולציה, תקינה)? ואילו נתונים ייאספו?
מה קורה כאן בפועל?
כותבים מסמך אפיון שמתאר את כל הדרישות: מה המערכת אמורה לעשות, אילו נתונים ייאספו, אילו תרחישים ייתכנו, ומה המגבלות שיש לקחת בחשבון.
מה חשוב שתעשו בשלב הזה?
~ תרתמו ידע מהשטח ונקודות מבט מגוונות להגדרת הדרישות
~ תוודאו שהאפיון נוגע באתגרים אמיתיים של המשתמשים ויש בו מספיק ערך שיגרום להם להשתמש בו
~ תתעדפו ותגדירו מה קריטי למוצר ראשוני והוכחת היתכנות לעומת מה "נחמד שיהיה"
משאבים שיכולים לעזור:
~ אנשי מקצוע: א.נשי מוצר, א.נשי פיתוח, יועצים/ות מהתחום החברתי הרלוונטי
~ שיתופי פעולה עם סטודנטים/ות בקורסים מעשיים באקדמיה, מתנדבים/ות עם רקע טכנולוגי, האקאתונים לפיצוח אתגרים חברתיים בשיתוף חברות טכנולוגיה לדוגמה –  האקאתון מיקרוסופט

3. ארכיטקטורה וחוויית משתמש  UI/UX

בשלב הזה מתכננים את המבנה העמוק של המערכת: מהי התשתית הטכנולוגית? איך תראה זרימת הנתונים? אילו שירותים יתחברו? ואיך ייראה המסע של המשתמש (גם מבחינה טכנית וגם מבחינה רגשית)? זהו שלב שבו נדרשת גם רגישות לתחום החברתי וגם הבנה טכנולוגית במרכיבים עליהם מתבסס הפתרון
מה קורה כאן בפועל?
מעצבים את מבנה המערכת, המסכים, והזרימה ההגיונית בין הפעולות. נלקחים בחשבון גם שיקולים טכניים וגם מאפיינים רגשיים־חווייתיים של המשתמש.
מה חשוב שתעשו בשלב הזה?
~ תוודאו שהשפה, המראה והנגישות תואמים את קהל היעד
~ תקחו בחשבון את כל התרחישים, כפי שאתם מכירים מהשטח
~ אל תסתפקו באסתטיקה ובאיך זה נראה אלא בוידוא שחוויית השימוש פשוטה ומובנת ומותאמת לקהלי היעדולכאב שבאתם לפתור להם
משאבים שיכולים לעזור:
אנשי מקצוע: מעצבי UX/UI, מומחי נגישות, אנשי תוכן
מסגרות סיוע: שיתופי פעולה עם קורסים מעשיים באקדמיה מסגרות לפיתוח עבור עמותות לדוגמת code for israel, max , הילמ"ה

4. פיתוח  Development

בשלב זה כותבים את הקוד על בסיס הדרישות והאיפיון ובהתאמה לתעדוף וללוחות הזמנים שנקבעו, תוך ביצוע בדיקות מסוגים שונים לאורך הפיתוח.
מה קורה כאן בפועל?
הפיתוח כולל כתיבה של כל רכיבי המערכת – גם החלק שנראה למשתמש (Front-end), וגם הלוגיקה הפנימית, בסיסי הנתונים, ממשקי החיבור, והניהול מאחורי הקלעים (Back-end). זהו שלב שמחייב חיבור מתמיד בין אנשי מוצר, מפתחים ונציגי השטח,  ולעיתים מצריך גם התאמות שצצות רק "תוך כדי תנועה"
מה חשוב שתעשו בשלב הזה?
~ תוודאו הנחות יסוד קריטיות: איך נשמרים ונאגרים נתונים? אילו סוגי מידע רגישים קיימים? מי שולט בהם?
~ תקפידו על מבנה גמיש (modular): שיאפשר שינויים עתידיים, עדכונים והתאמות – ולא ייצור תלות בפיתוח מחדש של כל רכיב.
~ תחשבו כבר עכשיו על תפעול: מי יתחזק את המערכת? אילו פעולות נדרשות מאחורי הקלעים? האם יש כלים לניהול משתמשים, תוכן, הרשאות?
~ תוודאו שצוות הפיתוח לא "מתנתק מהשטח": קבלת החלטות טכנולוגיות צריכה להיבחן גם מנקודת מבט של המשתמש, לא רק לפי שיקולים של קלות מימוש ולוחות זמנים
~ תדאגו להיות חלק פעיל מתהליך הבדיקות שבדרך: אל תחכו למוצר הסופי, אלא בדקו גרסאות ביניים, זהו בעיות בחוויה ווודאו שהמוצר שנבנה אכן נאמן לצרכים שהוגדרו
משאבים שיכולים לעזור:
אנשי מקצוע: א.נשי פיתוח, מנהלי/ות מוצר
מסגרות סיוע: שותפויות עם חברות פיתוח, ספקים טכנולוגים/בתי תוכנה, צוותים טכנולוגיים בארגון, כלים לפיתוח מהיר (no-code/low-code), שיתופי פעולה עם קורסים מעשיים באקדמיה או עם מסגרות לפיתוח עבור עמותות לדוגמת code for israel, max, הילמ"ה

5. השקה והטמעה  Implementation / Deployment

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

6. שלבי בשלות של מוצר טכנולוגי – הדרך ארוכה ומפותלת

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

• אב טיפוס (Prototype): המחשה ראשונית של רעיון טכנולוגי – מאפשרת בדיקת היתכנות ויצירת שיח עם שותפים פוטנציאליים. המיזם בשלב הזה מחפש בעיקר הוכחת היתכנות שהרעיון בכלל עובד. מחפש הבנה של הערך בשטח. ומחפש שותפים מתאימים מהשטח שיכולים לתת ידע, קבוצות מיקוד, חשיבה, ולאו דווקא שימוש ישיר
• גרסת MVP: מוצר בסיסי ופועל, שנועד לבחון אם המשתמשים רואים בו ערך. ארגונים יכולים לתרום תובנות, קבוצות מיקוד ונתוני שטח.
• פיילוט: הטמעה מצומצמת בשטח בסביבה מבוקרת – מאפשרת בדיקת דפוסי שימוש, תיקון תקלות והתאמה. זהו שלב מצוין לייצר שותפות עם ארגונים כשותפי פיתוח (design partners) ובכך לאפשר לארגון להשפיע על הפתרון, ליהנות מהתאמות ולעיתים לקבל גישה מוקדמת בתנאים מועדפים.
• מוצר בשל / מדף: הפתרון מגובש ומוכן להטמעה רחבה ולרוב מחפש בשלב הזה לקוחות משלמים. בשלב זה ארגון שטח יכול לתרום לחשיפה לקהלי יעד, לייצר הצעת ערך חדשה משותפת, להציע פיתוח משותף של יכולות נוספות/מותאמות, לספק מעטפת של חשיפה ויחסי ציבור דרך סיפורי הצלחה ועוד.

השורה התחתונה

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

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