דילוג לתוכן
→ כל המאמרים · 4 דקות קריאה

מה זה שלב Discovery במוצר, ולמה הוא חוסך כסף?

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

בקצרה

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

עיקרי הדברים
  • Discovery הוא תכנון מבוסס ראיות: מטרות, משתמשים, user flows, scope, גישה טכנית, סיכונים, roadmap והערכה.
  • בדרך כלל הוא נמשך בין שבוע לכמה שבועות, לפי הגודל ורמת אי-הוודאות של המוצר.
  • בסוף צריכים להיות מסמכים ופרוטוטייפים שאפשר לעבוד איתם עם כל צוות, לא רק מצגת.
  • הוא חוסך כסף כי הוא מקדים הפתעות יקרות לרגע שבו הכי זול לתקן אותן: לפני שנכתב קוד.
  • אפשר לקצר אותו כשה-scope קטן, המשתמשים מוכרים והדרישות כבר כתובות.

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

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

מה זה שלב Discovery, במילים פשוטות?

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

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

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

מה קורה בשלב ה-Discovery?

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

  • מטרות עסקיות: מה המוצר צריך לשנות בעסק, ואיך יודעים שזה הצליח.
  • משתמשים: מי משתמש במוצר, מה הם מנסים לעשות ומה מתסכל אותם היום.
  • User flows: המסלולים המרכזיים צעד אחר צעד, כמו הרשמה, הזמנה, תשלום או אישור.
  • Scope: מה נכנס לגרסה הראשונה, מה מחכה ומה בחוץ במפורש.
  • גישה טכנית: פלטפורמות, ארכיטקטורה, אינטגרציות עם מערכות קיימות, דרישות דאטה ואבטחה.
  • סיכונים: הנעלמים שיכולים לפגוע בעלות או בלוח הזמנים, ואיך מצמצמים כל אחד מהם מוקדם.
  • Roadmap: סדר העבודה, מהגרסה הראשונה ועד השלבים הבאים.
  • הערכה: מאמץ, צוות וזמן, על בסיס ה-scope שסוכם ולא על בסיס ניחוש.

מה מקבלים בסוף, וכמה זמן זה לוקח?

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

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

  • מסמך מוצר קצר: מטרות, משתמשים, מדדי הצלחה ומגבלות.
  • User flows ו-wireframes או פרוטוטייפ קליקבילי של המסכים המרכזיים.
  • רשימת פיצ'רים מתועדפת עם scope ברור לגרסה הראשונה.
  • גישה טכנית: stack, תרשים ארכיטקטורה כללי, אינטגרציות ו-hosting.
  • רשימת סיכונים ואיך מטפלים בכל אחד.
  • Roadmap בשלבים והערכה של מאמץ, צוות ולוח זמנים.

למה Discovery חוסך כסף?

העלות של שינוי גדלה בכל שלב שהוא עובר. להזיז כפתור ב-wireframe לוקח דקות. לשנות flow של תשלום אחרי שעוצב, נבנה, נבדק ועלה לאוויר יכול לקחת שבועות, ולעיתים קרובות לשבור דברים אחרים בדרך.

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

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

מתי אפשר לדלג על Discovery או לקצר אותו?

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

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

איך מתכוננים ל-Discovery?

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

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

איך Devnori מנהלת את שלב ה-Discovery?

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

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

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

נגיד מוקדם אם אנחנו לא ההתאמה הנכונה. אם כבר יש אפיון מפורט ובדוק וצוות מוצר חזק בבית, ייתכן שכל מה שצריך הוא עוד יכולת פיתוח, ולשם כך קיים מודל ה-Extended team שלנו. אפשר לפנות אלינו ב-hello@devnori.com, ואנחנו עונים תוך 24 שעות, בימים שני עד שישי.

שאלות נפוצות.

מה זה שלב Discovery במוצר?
שלב Discovery הוא שלב תכנון קצר לפני פיתוח תוכנה, שבו העסק והצוות המפתח מסכמים מטרות, משתמשים, user flows, scope, גישה טכנית, סיכונים, roadmap והערכה, ומתעדים אותם כך שהפיתוח מתחיל מהחלטות משותפות.
כמה זמן לוקח Discovery?
Discovery נמשך בדרך כלל בין שבוע לכמה שבועות. מוצרים קטנים עם משתמשים מוכרים צריכים פחות זמן; פלטפורמות עם כמה סוגי משתמשים, תשלומים, אינטגרציות או דאטה רגיש צריכות יותר.
האם Discovery נותן מחיר קבוע לפרויקט?
Discovery נותן הערכה שמבוססת על scope מוסכם, והיא אמינה הרבה יותר מהערכה שנעשתה על סמך תקציר קצר. אם זה יהפוך למחיר קבוע תלוי בספק ובחוזה, אבל ההערכה צריכה להבהיר מה כלול ומה לא.
אפשר להשתמש בתוצרי ה-Discovery עם צוות פיתוח אחר?
צריך להיות אפשר. Discovery טוב מייצר מסמכים ופרוטוטייפים בבעלותכם, כמו מסמך מוצר, user flows, רשימת scope, גישה טכנית ו-roadmap. כדאי לוודא בחוזה, לפני תחילת ה-Discovery, שהבעלות על התוצרים שלכם.
מה ההבדל בין Discovery לאפיון?
אפיון מתעד מה המערכת צריכה לעשות. Discovery כולל את זה, וגם בודק שהדרישות נכונות דרך משתמשים, user flows, פרוטוטייפים, סיכונים טכניים ומטרות עסקיות, לפני שהדרישות ננעלות.
על Devnori

יש לכם פרויקט בראש?

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

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

מאמרים נוספים.