תהליך הפיתוח- משוב, שיפור ופיתוח פתרון מלא

תהליך הפיתוח- משוב, שיפור ופיתוח פתרון מלא

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

בשלב זה מתרחשות שתי פעילויות:

  • התנסות ומשוב משתמשים
  • שיפור הפתרון והתאמתו לשימוש

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

התנסות ומשוב משתמשים

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

  • מה המשתמש חווה בעת השימוש באב טיפוס? מה מלהיב אותו? מה מעצבן אותו? מה מתסכל אותו?
  • מה הוא מרגיש כלפי המוצר?
  • האם המוצר עונה על צורך מבוטא או סמוי של המשתמשים?
  • מה אפשר לשפר במוצר?
  • אילו תכונות/רכיבים חסרים?
  • מה המשתמש היה משמר ומה היה מבטל?
  • אילו תכונות/רכיבים הינם מיותרים ולא מוסיפים ערך?
  • אילו תכונות כדאי לשנות?
  • מה עובד היטב ומלא לא עובד במוצר?

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

שיפור הפתרון

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

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

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

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

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

תוכלו לראות דוגמאות של מוצרים ״ארוזים״ בפורטפוליו המוצרים שפיתחו אנשי המכון הדמוקרטי  בשנים 2016-2018.

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

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

גרסאות ומהדורות חדשות: הפיתוח ממשיך גם לאחר השלמתו!

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

PIVOTING – שינוי בעלילה

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

תוכן זה מוגן. יש להתחבר כדי לצפות בו:

התחברו:

דילוג לתוכן