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

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) ובכך לאפשר לארגון להשפיע על הפתרון, ליהנות מהתאמות ולעיתים לקבל גישה מוקדמת בתנאים מועדפים.
• מוצר בשל / מדף: הפתרון מגובש ומוכן להטמעה רחבה ולרוב מחפש בשלב הזה לקוחות משלמים. בשלב זה ארגון שטח יכול לתרום לחשיפה לקהלי יעד, לייצר הצעת ערך חדשה משותפת, להציע פיתוח משותף של יכולות נוספות/מותאמות, לספק מעטפת של חשיפה ויחסי ציבור דרך סיפורי הצלחה ועוד.

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

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

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

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

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

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

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

חקר פתרונות קיימים

חיפוש יעיל וחכם של פתרונות קיימים מתחיל בשילוב של מונחים מעולמות הבעיה ומעולמות הפתרון, כמו למשל "open source volunteer management app" או "AI chatbot for mental health screening". ישנם מקורות מסורתיים אך אפקטיביים לחיפוש, כגון:

• מאגרי סטארטאפים כמו  SNC Finder, Product Hunt
• חנויות אפליקציות
• קהילות מקצועיות ומפגשי תוכן רלוונטים (מיטאפים, כנסים, ימי עיון)
• התייעצות עם מומחים או ארגונים אחרים שפועלים בתחום דומה

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

דוגמה לפרומפט מורחב – את מומחית בתחום הטכנולוגיה והחדשנות החברתית, ומכירה את השוק הגלובלי של פתרונות טכנולוגיים. אני מחפש/ת מיפוי מקיף של פתרונות טכנולוגיים בתחום [X] לפתרון בעיית [Y].
1. מפי את חמש הקטגוריות המרכזיות בתחום.
2. תני שם, מילות מפתח, ודוגמאות לכל אחת.
3. עבור כל דוגמה – צייני מודל עסקי, יתרון תחרותי, התאמה לארגונים חברתיים, ממשקי API, קיום גרסה בעברית, אפשרות להתנסות, אנשי קשר פוטנציאליים, וייעצי לי מה כדאי לבדוק לפני התקשרות.

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

מצאנו! ומה עכשיו?

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

למי בכלל יש זמן לחקור?

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

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

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