סליחה, אני רק שאלה...

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

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

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

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

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

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

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

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

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

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

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

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

ההבדל הוא בשפות הפיתוח. אפליקציות היברידיות מתבססות על קוד שכתוב לרוב ב-JavaScript (או Flutter), שלמעשה מהווה תרגום של קוד מבוסס C++ לקוד מבוסס Java עבור פלטפורמות אנדרואיד. במילים פשוטות, התהליך הנ''ל מאפשר למפתח בודד לפתח אפליקציה שמתאימה לשתי מערכות הפעלה, ובכך לחסוך הרבה זמן וכסף. מצד שני, אפליקציות נייטיב דורשות פיתוח של שתי אפליקציות במקביל, מה שלרוב ידרוש מעורבות ישירה של שני מפתחים.

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

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

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

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

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

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

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

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

כחלק מתהליך עיצוב חווית משתמש, חשוב תחילה להבין את משתמשי הממשק. חשוב לגלות את המשתמשים, לחקור אותם, ולהגדיר את הפרסונות. בנוסף, חשוב לשאול שאלות והרבה! שאלות מובילות לפתרון. דבר שלישי, חיפוש השראות. חשוב ללמוד כיצד ממשקים דומים מתנהגים, ולפיכך להתאים את הממשק שלנו. ככל שנחקור ונגלה יותר מקורות השראה הפתרון יגיע יותר בקלות. יצירת סקיצות ראשוניות - Wireframes: הנחת היסודות של הממשק יחסוך לנו המון זמן מבוזבז ויקל עלינו במהלך העיצוב. בניית השלד של הממשק היא אבן יסוד הכרחי במהלך העיצוב. UI - יצירת זהות היא חלק ניכר מתהליך העיצוב. עקרונות עיצוב בסיסיים יכולים לעזור לנו במהלך עיצוב הנראות של הממשק טיפוגרפיה / צבעים / איזון / קומפוזיציה. יצירת הזהות היא בעצם ניראות הממשק למשל באיזה צבע יהיה הכפתור, באיזה פונט נשתמש, אלמנטים גרפיים, ועוד. דבר אחרון הוא יצירת האב טיפוס של הממשק - Prototype: יצירת פרוטוטייפ זה בעצם השלב הסופי בתהליך העיצוב. פרוטוטייפ הינו יצירת ממשק ראשוני ללא מידע (דאטא) המדמה את התנהגות המוצר.