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

- כדי לבחור בצורה מושכלת את מה שחשוב בתכולה הבסיסית ומאידך לדעת מה אפשר וכדאי לדחות

- כדי לא להיתקע באמצע בלי מזומנים מפני שלא לקחו בחשבון דברים הכרחיים

- כדי לייצר במידת האפשר תשתיות שיתאימו גם להמשך ולא יצריכו פיתוח מחודש

תכנית אדריכלית

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

הגישה מוסברת במאמר הקודם על Growing MVP.

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

דרישות עסקיות:

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

מחקר שוק ואסטרטגיית חדירה:

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

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

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

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

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

רוצים לבנות את המוצר שלכם עם ניצול אופטימלי של משאבים, מינימום סיכונים ומקסימום סיכויי ההצלחה? לחצו כאן!

אפיון פונקציונלי:

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

על מה צריך לחשוב?

* מהן המטרות שלי במערכת

* מי הם קהל היעד (גיל, סגנון, מיקום, שפות, באלו עוד תוכנות הם משתמשים וכן הלאה)

* אמצעי השימוש במערכת: מחשב, מחשב נייד, פלאפון, טאבלט או אייפד.

* איך המשתמשים ירשמו למערכת (לדוגמא הרשמה או log-in באמצעות פייסבוק או גוגל) ואילו נתונים ישמרו.

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

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

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

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

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

UX– UI:

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

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

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

ניהול וניטור:

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

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

מערכות קשורות וממשקים:

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

טעינות חומרים:

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

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

רוצים לבנות את המוצר שלכם עם ניצול אופטימלי של משאבים, מינימום סיכונים ומקסימום סיכויי ההצלחה? לחצו כאן!