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

דרישות לא פונקציונליות

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

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

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

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

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

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

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

בחירת טכנולוגיות וארכיטקטורה

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

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

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

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

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

אפיון טכנולוגי מפורט

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

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

בחירת מסד נתונים

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

בשלב השני צריך לבחור את המסד עצמו בהתאם לסוג ולשאר הטכנולוגיות שנבחרו. לדוגמא: MySQL, SQLServer, MongoDB, PostgreSQL, CouchBase

תכנון חומרה, ואחסנה

חשוב לבחור באלו שרתים יש להשתמש (סוג, CPU, נפח זיכרון, תעבורה וכן הלאה), גודל מסד נתונים, האם צריך Load Balancer, האם יש צורך בשרתים נפרדים לחלקי מערכת שונים, האם המערכת תשב בענן (AWS, Azure וכדומה) או על שרת מקומי, איזו אבטחה צריכה המערכת ברמת האחסון וכן הלאה.

מידול נתונים

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

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

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

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

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

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

לסיכום,

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

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