עבודה ייעודית ללקוחות דוחה שוב ושוב את השיפורים במוצר הליבה
אנחנו מסמנים את הגבול בין מוצר להתאמה: אילו ממשקי אינטגרציה הליבה תומכת בהם, מי אחראי על כל רכיב ייעודי ללקוח, ואיך משבצים עבודה ייעודית כך שהיא מפסיקה לדחוק את מפת הדרכים.
שירותי מו"פ ופיתוח
הנדסה שמובילה את ההכרעות עד לפרודקשן
פיתוח Web, מובייל, IoT ו-API, לצד ארכיטקטורה ואספקה, בידי מהנדסים בכירים שעובדים תחת אותה הובלה טכנולוגית שקבעה את הכיוון. מהירות של פיתוח בסיוע AI, ברמה מקצועית.
נקודות פתיחה
המצבים שמובילים לכאן
לפעמים התשובה לבעיה טכנולוגית היא הכרעה. לפעמים היא הכרעה ואז העבודה לממש אותה.
- סוכמה מודרניזציה ולצוות אין קיבולת להריץ אותה
- הכרעת הארכיטקטורה התקבלה ועכשיו מישהו צריך לבנות
- צריך לחבר מערכות ואף אחד לא אחראי על התפרים
- צריך לשנות קוד קיים והאנשים שכתבו אותו עזבו
- אב טיפוס משרת לקוחות אמיתיים וצריך להפוך למוצר
- אפליקציית המובייל פותחה פעמיים בחוץ ואף גרסה לא שרדה
- ממשקי API נוצרו אחד-אחד ואין שניים שמתנהגים אותו דבר
- חומרה ותוכנה נבנות בידי צוותים שלא מדברים
הסטנדרט
Vibe coding, בסטנדרט של Kendoo
מהר זה קל היום. אמין זו העבודה.
כלי AI כותבים חלק גדול מהטיוטה הראשונה, והצוות משתמש בהם עד הסוף. כל שינוי עדיין עובר סקירה אנושית, בדיקות שבודקות התנהגות ולא חוזרות על הקוד, ומעקות בטיחות בצינור השחרור, כך שהמהירות אף פעם לא באה על חשבון נכונות או הבנה.
אתם מקבלים דוחות כתובים קבועים: מה שוחרר, מה בסיכון ומה השתנה בתוכנית, מול תמונת המצב שסוכמה בהתחלה. בעיות עולות כשהן מתגלות, לא בסוף הספרינט.
אתם מדברים ישירות עם המהנדסים והמוביל הטכני שעושים את העבודה, לא עם מנהל לקוח. העבודה נעשית במקום שבו אתם רואים אותה, במאגרים, במשימות ובצינור השחרור שלכם, וההחלטות שמאחוריה כתובות.
אינטגרציה והתרחבות
איפה הצמיחה נעשית קשה טכנית
מצבים שעולים כשחברה מוסיפה לקוחות, אתרים, מכשירים או מוצרים, והחלק בעבודה ש-Kendoo לוקחת עליו אחריות בכל אחד מהם.
שינויים במכשיר, בענן ובמובייל דורשים בדיקות ושחרור מתואמים
אנחנו לוקחים אחריות על התלויות בין קושחה, שירותי ענן ואפליקציות: ממשקים עם גרסאות ביניהם, כללי תאימות, גבול בדיקות מקצה לקצה, ורצף שחרור אחד ששלושת הצוותים עובדים לפיו.
כל התקנה דורשת הגדרה ידנית, ותקלות קשה לעקוב אחריהן בין המערכות
אנחנו הופכים הקמה של כל אתר להגדרה שחוזרת על עצמה, מגדירים מה כל מערכת רושמת ומעבירה הלאה, וקובעים את שלבי הבדיקה וההפעלה לאתר חדש, כך שאפשר לעקוב אחרי תקלה ממערכת למערכת.
שני מוצרים ושני צוותים צריכים מפת דרכים טכנית משותפת בזמן ששניהם ממשיכים לשרת לקוחות
אנחנו ממפים איפה המוצרים חופפים, מחליטים על הממשקים והנתונים המשותפים, קובעים את רצף המעבר, ומסכמים איזה צוות אחראי על מה, כך שעבודת האינטגרציה לא עוצרת התחייבויות קיימות.
יכולות
מה הצוות בונה
הטכנולוגיה נבחרת לפי מה שאתם כבר מריצים ומי צריך לתחזק אותה אחר כך.
-
ייעוץ אסטרטגיה וצמיחה
אופטימיזציה של טכנולוגיות ותהליכי הפיתוח לכיוון צמיחה ויכולת גדילה, כך שההכרעות ההנדסיות והעסקיות מתקבלות זו מול זו ולא בחדרים נפרדים.
-
ארכיטקטורת תוכנה
ארכיטקטורה חסינה, יעילה וברת-תחזוקה שמתוכננת לטווח ארוך, כולל מעבר לענן ולמיקרו-שירותים היכן שזה באמת מתאים לבעיה.
-
פיתוח Web
אפליקציות Web מותאמות ורספונסיביות, על סטאקים ותיקים ומודרניים: Java, .NET, PHP, Node.js, React, Angular ו-Vue. מערכות קיימות באותה מידה כמו חדשות.
-
אפליקציות מובייל
אפליקציות נייטיב וחוצות פלטפורמות ב-iOS, Android, React Native, Kotlin, Flutter ו-Ionic, נבחרות לפי איך שהאפליקציה באמת תתוחזק ולא לפי העדפה.
-
פיתוח API
ממשקי REST, gRPC ו-GraphQL שמחברים את המערכות, האפליקציות והשירותים שלכם, מתוכננים כחוזים שצוותים אחרים יכולים להישען עליהם ולא כנקודות קצה שנוספו אחת-אחת.
-
פיתוח IoT
אפליקציות ובקרים ל-IoT על Arduino, Raspberry Pi ופלטפורמות דומות, כולל החלק שרוב הפרויקטים מזלזלים בו: מה קורה כשמכשיר מנותק.
הטיעון
הכרעות שאיש לא מממש אינן הכרעות
חלק גדול מהייעוץ נגמר בהמלצה. המסמך נכון, כולם מסכימים, ואז הוא פוגש צוות בלי קיבולת ומפת דרכים שכבר סוכמה. חצי שנה אחר כך אותה בעיה עולה שוב, בדרך כלל עם אותו מסמך מצורף.
גם הכיוון ההפוך נכשל. כוח פיתוח בלי בעלות טכנולוגית מייצר בדיוק את מה שביקשו, כולל כשמה שביקשו היה שגוי, והארכיטקטורה נסחפת עוד קצת בכל אספקה.
השארת שניהם באותה התקשרות היא מה שהופך כל אחד מהם לשווה קנייה. מי שמקבל את הכרעות הארכיטקטורה עובד לצד מי שמממש אותן, כך שההכרעה שורדת מפגש עם הקוד והקוד משקף את ההכרעה.
איך זה מתנהל
צורת העבודה
לקרוא את מה שקיים
את הקוד, את התקלות ואת האילוצים לפני כל הצעה. רוב העבודה הזו נעשית על מערכות שמישהו אחר בנה, וזו דיסציפלינה שונה מהתחלה נקייה.
לסכם את הגבול
מה ההתקשרות בונה, מה נשאר אצל הצוות שלכם, ואיך השניים נפגשים. עמימות בתפר הזה היא המקור לבעיות אספקה.
לבנות לצד הצוות שלכם
עבודה לצד המהנדסים שלכם ולא במקביל להם, כך שהידע נשאר אצלכם וההכרעות נשארות מעוגנות.
העברה מכוונת
תיעוד, סקירה וחניכה כחלק מהעבודה. מערכת שהצוות שלכם לא יכול לתחזק לא סופקה, מה שלא יגיד לוח המשימות.
מה זה, ומה זה לא
מה זה
- מהנדסים בכירים תחת אותה הובלה טכנולוגית
- עבודה על מערכות קיימות כמו על חדשות
- טכנולוגיה שנבחרת לפי מי שיתחזק אותה
- בנייה לצד הצוות שלכם, עם ידע שנשאר
- היקף שמוגדר לפי מה שאפשר לקחת עליו בעלות
מה זה לא
- כוח אדם שנשכר לפי חודש
- צוות שמוקצה בלי בעלות טכנולוגית
- בנייה במחיר קבוע לפי אפיון שאיש לא בדק
- כל טכנולוגיה שאופנתית כרגע
- מערכת גמורה שמועברת לצוות שמעולם לא ראה אותה
כשהיקף העבודה באמת דורש ארגון פיתוח גדול, זה נאמר בשיחה. הגדרת היקף כנה זולה לכולם יותר מגילוי הגבול באמצע הדרך.
שאלות שמנהלים שואלים
זו חברת אאוטסורסינג לפיתוח?
לא, וההבדל משמעותי. המהנדסים עובדים תחת אותה הובלה טכנולוגית שקובעת את הכיוון, ולכן הכרעות הארכיטקטורה והקוד שמממש אותן נשארים עקביים. העבודה מוגדרת לפי מה שאפשר לקחת עליו בעלות אמיתית ולא לפי מי שפנוי.
אפשר לקחת אחריות על קוד קיים?
בדרך כלל כן. רוב העבודה הזו נעשית על מערכות שמישהו אחר בנה, וזו דיסציפלינה שונה מהתחלה נקייה: לקרוא את הקוד, למצוא מה הבדיקות לא מכסות, ולשנות בלי לשבור את החלקים שאיש כבר לא זוכר.
אתם עובדים לצד המהנדסים שלנו?
עדיף. עבודה לצד הצוות שלכם משאירה ידע ושומרת על ההכרעות מעוגנות במה שהמהנדסים שלכם יצטרכו לתחזק. העברת מערכת גמורה לצוות שמעולם לא ראה אותה היא הדרך שבה מתחילה כתיבה מחדש.
איך בוחרים טכנולוגיה?
לפי מה שאתם כבר מריצים ומי צריך לתחזק, ולא לפי מה שמעניין כרגע. סטאק שהצוות שלכם לא יכול לגייס אליו או לתמוך בו הוא נטל, כמה שלא יהיו יתרונותיו.
תוצאות
כך זה נראה בפועל
מקרים אמיתיים, ללא פרטים מזהים. המצב, ההחלטות ומה השתנה בעקבות העבודה.
לתוצאות מהשטחהביאו את המערכת שצריך לבנות או לשנות
שלושים דקות על מה שקיים היום ומה צריך להיות נכון כשזה ייגמר.