טוען ענפים…
הרעיון שלכם. ההיגיון, הארכיטקטורה והקוד שלנו.
טכנולוגיה ופיתוח הם התחום שלנו. אנחנו מכירים אלגוריתמים, שפות פיתוח וצרכים טכנולוגיים, ויודעים לתרגם אותם למערכת שההיגיון שלה ברור. לפני שמתחילים לכתוב קוד, מבררים מה המיזם צריך לפתור ואיך המשתמשים יפעלו בתוכו.
מגרסה ראשונה ממוקדת ועד מערכת SaaS שמשרתת כמה ארגונים, הפיתוח מתחיל בליבה: תהליכים, נתונים והרשאות. מערכות Web, אפליקציות וחיבורים חיצוניים נבחרים לפי הצורך, עם ארכיטקטורה שמתייחסת גם למה שיבוא אחרי ההשקה.
העבודה כוללת מקום להחלטות טכנולוגיות, לבדיקות ולהעברת ידע. אפיון, ייעוץ וליווי CTO מסייעים לבחור מה נכון לבנות ומתי; התיעוד והמסירה נותנים לצוות שממשיך את הדרך בסיס ברור לפיתוח הבא.
15לקוחות בענף
משקיע לא צריך לראות את כל המערכת. הוא צריך לראות זרימה אחת מההתחלה ועד הסוף: לקוח קצה מחפש ושומר פריט, החנות רואה ומשחררת אותו, והאדמין פותח חנות חדשה. כשכל יכולת נתפסת כחיונית קשה להחליט מה נכנס לגרסה הראשונה, ובוודאי מה מציגים בפגישה עם משקיעים. באוברסייט אפיינו דמו פונקציונלי כזה כאפליקציית Android, עם נתוני דמה, התחברות מדומה ו-Backend מינימלי, ועם הגדרה ברורה של מה לא נכלל: אבטחה, נגישות ושימוש אמיתי מול לקוחות. הדמו מוכר את החזון, ומה שנשאר בחוץ מתועד כבסיס לגרסה הראשונה האמיתית.
"למה הלקוח הזה רואה את הנתונים של לקוח אחר?" שאלה שסוכנות לא רוצה לשמוע אף פעם. סוכנות מנהלת לקוחות רבים, וכל לקוח צריך לראות רק את שלו. מנהל לא אמור לשנות לעצמו את התפקיד, מייסד לא נמחק ולא מושבת, ומשתמש צופה רואה בלי לגעת. זו כבר לא רשימת תפקידים אלא שתי שכבות: הרשאות סטטיות (אילו פעולות מותרות) והרשאות דינמיות (על אילו נכסים ואילו לקוחות), ומעליהן ריסיילר שמוכר את המערכת הלאה תחת המותג שלו (White Label). ב-Lumo, שאנחנו מפתחים לסוכנויות שיווק, שתי השכבות מופרדות כבר במודל הנתונים, ולכן ארגון חדש נפתח בהגדרה ולא בגרסה חדשה של כל המערכת.
מסך תשלומים אחד מציג חבילה מול ניצול, גם חודשים אחורה, ומשם משנים חבילה, מעדכנים אמצעי תשלום ורואים היסטוריה. מאחורי המסך הפשוט עומדת מערכת חיוב אחת שהחלטנו לאפיין כך: מנוי אחיד מתאים ללקוח עצמאי, אבל סוכנות משלמת לפי כמות הלקוחות שתחתיה, וכל חבילה פותחת מודולים וחיבורים אחרים. ומעבר למנוי יש עלויות שמשתנות בשימוש: קרדיטים של מודל שפה, הודעות SMS. תכונת AI מרשימה שרצה בכל לחיצה היא הוצאה שאף אחד לא תכנן, ולכן תובנות ה-AI מופעלות פעם בחודש להשוואת החודשים האחרונים, וקרדיט נצרך בהתחשבנות.
הלקוח נרשם, ובדקה הראשונה מתברר אם יישאר. הוא מזין כתובת אתר, והמערכת מזהה אם זו WordPress או Shopify ומאמתת את החיבור בדרך המתאימה לכל פלטפורמה. אחרי הצעד האחרון באים הדברים שמשאירים לקוח: דירוג שמפנה ציון נמוך לתמיכה וציון גבוה לדף הביקורות, ומסך מפתחים עם ניהול מפתחות API ותיעוד שמפתחי הלקוח באמת קוראים. אצלנו מתכננים כל מסך כזה כחלק מהמערכת ולא כתוספת ברגע ההשקה, ומלווים אותו בבדיקות ובתיעוד שהצוות הבא יכול להמשיך ממנו.
דייר (tenant) ב-SaaS רגיל הוא שורות בטבלה. במערכת שמחזיקה חיבור חי לכל דייר, למשל סשן WhatsApp, הוא תהליך שרץ ומחזיק מצב, ועד שיש מעט דיירים אף אחד לא שם לב. עם הגידול מגיעות הבעיות: עליית שרת שטוענת את כולם ונמשכת דקות, חיבורים שמתנתקים בלי שמישהו לוחץ "רענן", נעילות (lock) שחוסמות עבודה מקבילה, ושאילתות כבדות שרצות בשרת במקום במסד. תכנית האופטימיזציה שגיבשנו מארגנת את זה מחדש: ריסטארט אוטומטי לסשן בודד בלי להפיל את כולם, לוגים לכל דייר, שאילתות שעוברות למסד, ותקרות הגנה על גודל קמפיין וייבוא רשימה.
אפליקציה משובצת (embedded) רצה בתוך חנויות עם ערכות עיצוב שונות, ולכן כל שינוי חייב לא לשבור את החנות של מישהו אחר. מעבר לזה, חנות האפליקציות של Shopify מחייבת webhooks של פרטיות שעונים בזמן, טיפול נכון בהתקנה ובהסרה, ועמידה בתקן Built for Shopify. בעברית נוסף עוד שלב: ממשק, התראות ועיצוב שעובדים מימין לשמאל, ובהמשך גם בערבית. ב-Sense Apps, המיזם של אוברסייט שמשרת אלפי חנויות, הדרישות האלה הן חלק מהארכיטקטורה, כולל חיוב לפי חבילה שמתחשב בעלויות שימוש חיצוניות. העיקרון פשוט: לא שוברים חנות של אף אחד.
מכירים את זה שלקוח מסיים הרשמה, ובמערכת אחת הוא קיים ובשנייה לא? לקוח נרשם לחבילת סיבים אופטיים: במערכת החיוב (WHMCS) נפתח מוצר, ובחברת התשתית נפתח קו. אלה שתי פעולות שחייבות להצליח יחד, ואם אחת הצליחה והשנייה נכשלה נוצר לקוח יתום. צריך בדיקת היתכנות לפי כתובת לפני היצירה, תיאום טכנאי בשעות פנויות, ושמוצר שמושעה או מנותק באחת המערכות יפעיל את הפעולה המקבילה בשנייה (Create, Suspend, Terminate). ולכן באוברסייט מתכננים מודול Provisioning שמחזיק את שני הצדדים מסונכרנים, עם הודעות שגיאה שנציג מבין ולא קוד מערכת.
מסך תפעול שמציג מכשירים ברשת מתרענן מול ה-API כל כמה שניות, ובכל זאת השורה שנפתחה נשארת פתוחה והגלילה נשארת במקומה. כל שורה נפתחת לרשימת אירועים, ופעולות מסוכנות כמו הסרת מכשיר או שחרור מבידוד (quarantine) דורשות אישור לפני שהן יוצאות. סינון לפי סטטוס וטקסט, וסמלים לפי סוג מכשיר ויצרן, מאפשרים לזהות בגרפיקה לפני שקוראים. וכאן הטוויסט: את צד הלקוח של מסך כזה בנינו מעל API שבאחריות הצוות שמנהל אותו, ובכל זאת המסך נשאר יציב גם כשהנתונים משתנים בכל רגע.
15פרויקטים שהגשמנו בענףלכל הפרויקטיםיש לכם רעיון שצריך להפוך למערכת. בואו נבנה אותו נכון.
עשו עבודה טובה ומקצעית
Nanocomלקוח
מגדירים את הבעיה, את המשתמשים ואת הפעולות שבלעדיהן הגרסה הראשונה לא נותנת מענה. משם בוחרים ליבה ומפרידים יכולות המשך, כדי שה-MVP יבחן את הרעיון ולא ינסה לפתור הכול בבת אחת.
בגרסה ראשונה מגדירים את הליבה ואת המבנה לפני הפיתוח. במערכת פעילה מתחילים בהיכרות עם הקוד, התשתית והמשתמשים, ואז בונים תוכנית עבודה שמתחשבת גם במה שכבר פועל.
ממפים מה משותף לכל הארגונים ומה דורש הפרדה או התאמה: נתונים, הרשאות, תהליכים ומסלולים. לפי זה בוחרים את מבנה המערכת. לקריאה נוספת: ריבוי דיירים מול התקנה נפרדת.
מגדירים מה המערכת צריכה לקבל או לבצע, בודקים את הממשקים הזמינים ובונים את החיבור סביב התהליך. ברכיבי AI מגדירים גם מקורות מידע, הרשאות ובקרה על התוצאות.
מתחילים בסקירת קוד, ארכיטקטורה ותהליכי עבודה. הבדיקה עוזרת להבחין בין הרחבה נקודתית לשינוי תשתית, ולהגדיר תוכנית המשך שמתאימה למערכת ולצוות.
מגדירים תחומי אחריות, תעדוף, גישות ודרך מסירה. העבודה יכולה להשתלב בצוות הקיים או להוביל תחומי פיתוח מוגדרים, עם תיעוד ועדכון על ההתקדמות.
לפי היקף העבודה, תיעוד מבנה המערכת, החלטות טכנולוגיות, תהליכי הפעלה וגישות רלוונטיות. המסירה כוללת היכרות עם הקוד והתשתית, כדי שהצוות יוכל להמשיך לעבוד מתוך הבנה.
מרכזים את מבנה המערכת, התיעוד והתלויות, ובוחנים את הקוד והארכיטקטורה מול היקף הבדיקה. הממצאים וההחלטות מתועדים, עם הבחנה בין מה שנבדק לבין מה שדורש טיפול נוסף.
יש שאלות שעדיף לשאול ישירות. נשמח לענות על השאלה שלכם באופן אישי.
דברו איתנובואו נדבר · טכנולוגיה ופיתוח
