Fast Gear
שיטת אפיון טכנולוגי

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

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

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

על מנת להבין את השיטה, קודם נבין מהו תהליך אפיון…

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

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

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

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

איך משפיע האפיון על הפרויקט?

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

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

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

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

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

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

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

קראו עוד

תהליך העבודה

להבין מה אתם צריכים

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

לדעת איך לבנות - ארכיטקטורת מידע

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

Mockup

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

לראות איך זה נראה - קונספט גרפי

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

Case Study

חברת סטארטאפ בתחום
ה- online brand protection

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

נדלקנו על הרעיון המבריק ועל החזון של השניים ולאחר חתימה על NDA התחלנו בתהליך Fast Gear.

שלב ראשון – מיפינו את קהלי היעד:

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

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

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

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

שלב השני – מיפינו פלטפורמות מתחרות:

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

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

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

שלב שלישי – הגדרנו יעדים להצלחה:

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

שלב רביעי – מיפינו יישויות, קשרים וזרימת מידע:

בשלב הזה מנינו את כל הסיבות שלשמן קהל היעד עומד להיכנס לפלטפורמה ( User Stories ) והגדרנו משם את הישויות שצריכות להיות במערכת והקשרים ביניהם (ERD). מיפינו את אופן מעבר המידע במערכת כלומר את ה Data Flow ואפיינו את ה API's שנדרשים על מנת לתמוך בתהליך.

 

שלב חמישי – אפיון מסכי המשתמש  – GUI:

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

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

שלב שישי -ארכיטקטורת תשתיות – בחירת הטכנולוגיות והתאמת הסביבות לפיתוח הפלטפורמה:

דנו בשאלה האם כדאי לייצר אפליקציית Native – משיקולים של אופי השימוש והתקציב.

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

מדובר על מערכת מסוג Dashboard Management עם המון מידע וטבלאות. בנוסף, עיקר העבודה עם המערכת יהיה במשרד/מפעל ולכן הוחלט במקרה הזה להתמקד בפיתוח Web – מותאם למובייל במסכים שבהם נדרש והגיוני שיהיה שימוש מהנייד.

בחרנו במקרה הזה לפתח את הפלטפורמה בצד השרת שלה ב- NodeJS (זו שפה שאנחנו מאוד אוהבים ומתמחים בה – וחשבנו שיהיה נכון להשתמש בה במקרה הזה).

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

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

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

שלב שביעי – אבטחת מידע וסיכונים:

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

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

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

שלב שמיני – לקוחות מרוצים עם מה הם יוצאים?

ליאור ושחר, שהיו שותפים לאורך כל התהליך יצאו מקמביום עם כל מה שהם צריכים על מנת להמשיך הלאה:

  1. וודאות ברורה מאד על כלל המשמעויות בפיתוח הרעיון שלהם.
  2. סדר גודל מדויק של זמן פיתוח הפלטפורמה ועלות הפיתוח שלה.
  3. חלוקת פיתוח הפלטפורמה בהתאם לשיקולים והחלטות עסקיות.
  4. בהירות גבוהה לכלל הסיכונים הצפויים בהמשך הדרך.
  5. מסמך מפורט לפיתוח הפלטפורמה (Detailed Design) באמצעותו יוכלו לקבל הצעות מחיר מתחרות.
  6. ליאור ושחר המשיכו איתנו לסדנת UI/UX.
  7. והם נשארו בקמביום גם לשלב הפיתוח!

מה שהפך את התהליך עם ליאור ושחר למהנה ומקצועי היה תיאום הציפיות והתנהלות ברורה לאורך כל הדרך של סדנת ה- Fast Gear. חוץ מזה שהם עצמם אנשים מקסימים.

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

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

 

דילוג לתוכן