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