POC לפרויקט מציאות מדומה: מה הוא חייב להוכיח

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

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

POC, פיילוט או MVP: איזו שאלה השלב הנוכחי שואל

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

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

לבחור את ההנחה המסוכנת ביותר

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

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

הנחה שכולם בטוחים בה לא צריכה POC. הנחה שאף אחד לא יודע לענות עליה היא המועמדת הראשונה.

לבדוק על המכשיר ובמקום השימוש

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

את הביצועים מודדים על המכשיר עצמו. ב-Meta Quest, לפי Meta - מדידת ביצועים ב-Quest Developer Hub, הכלי Performance Analyzer מציג מדדים מהמכשיר בזמן אמת. הכלי מודד, אבל את הסף קובע הצוות. במשקפיים עצמאיים, סיכון שקל לפספס הוא ריצה ממושכת: הביצועים עלולים לרדת אחרי שהמכשיר מתחמם. לכן מודדים את זמן הפריים ביחס לקצב הרענון של המכשיר, בסצנה הכבדה ביותר, לאורך משך שנקבע מראש וגם אחרי שהמכשיר התחמם. על אבחון מפורט ראו אבחון ביצועים על Quest 3.

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

ב-AR, המרחב הוא חלק מהניסוי. לפי התיעוד של Google ARCore - עיגון אובייקטים במרחב לטלפונים, עוגנים מקשרים תוכן וירטואלי לסביבה ככל שההבנה שלה מתעדכנת, ועיגון מקומי, עיגון מתמשך ועיגון משותף הם דרישות נפרדות. במשקפי MR המנגנון שונה, אבל אותן שלוש שאלות נשארות: האם התוכן נשאר במקומו, האם הוא שם גם מחר, והאם שני משתמשים רואים אותו באותו מקום. אם הפרויקט מניח אחת מהן, ה-POC בודק אותה.

לכתוב את הסף לפני שמתחילים

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

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

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

מה לא לבנות בהוכחת היתכנות

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

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

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

מה לבקש מהספק בסוף POC למציאות מדומה

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

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