איך חברה יפנית צריכה לבחור שותף לפיתוח אופשור?

למה חברות ביפן מחפשות שותף לפיתוח אופשור?

הסיבה המרכזית היא מחסור במפתחים. בסקר היצע וביקוש של אנשי IT שפרסם ב-2019, משרד הכלכלה, המסחר והתעשייה של יפן (METI) העריך שהמחסור עלול להגיע לכ-790,000 אנשי IT עד 2030 בתרחיש הגבוה. דוחות ה-DX של המשרד הזהירו גם מהמחיר של מערכות Legacy מזדקנות, מה שמכונה צוק 2025. לא משנה מה המספר המדויק, רוב החברות ביפן מרגישות את המחסור ישירות בגיוס.

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

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

מה צריך לבדוק אצל שותף לפיתוח אופשור?

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

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

איך מנהלים דרישות ותקשורת בין שפות שונות?

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

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

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

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

למה להתחיל בפרויקט ניסיון קטן בתשלום?

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

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

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

פרויקט מוגדר או מודל מעבדה: מה מתאים?

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

במודל המעבדה (Lab-style), הלקוח שומר צוות ייעודי, בדרך כלל על בסיס חודשי, ומכוון את העבודה בעצמו. זה מתאים לפיתוח מוצר מתמשך, לדרישות שעדיין משתנות ולבתי תוכנה שצריכים קיבולת נוספת קבועה. זה דורש יותר מעורבות מצד הלקוח: מישהו בצד שלכם צריך לקבוע סדרי עדיפויות ולבדוק את העבודה.

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

מהן נקודות הכישלון הנפוצות, ואיך נמנעים מהן?

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

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

איך Devnori עובד עם חברות ביפן?

Devnori הוא סטודיו קטן ובכיר לעיצוב מוצר והנדסה שבסיסו בהודו, ועובד מרחוק עם לקוחות בכל העולם. עיצוב מוצר, UX/UI, פיתוח Web ומובייל (iOS ו-Android), AI ואוטומציה, ענן ו-DevOps ו-QA מגיעים מצוות מחובר אחד, בלי העברת מקל בין סוכנות עיצוב לבית תוכנה. הצוות השיק יותר מ-60 פרויקטים, כולל פלטפורמות Web, אפליקציות מובייל וכלים פנימיים, ובונה ומפעיל מוצרים משלו כמו Opticdigit, TrainFoxx ו-Securelyze.

אנחנו עובדים בשני המודלים שתוארו למעלה. Project הוא היקף מוגדר שנמסר מקצה לקצה: סדנת Discovery והגדרת היקף, מעצב ומפתחים ייעודיים, שיחת סנכרון שבועית, עדכונים שוטפים ומסירה עם תיעוד. Extended team נותן קיבולת חודשית גמישה בתוך הכלים והשגרות של הלקוח, קרוב למה שחברות יפניות מכנות מודל מעבדה. לסוכנויות ולבתי תוכנה אנחנו עובדים גם כשותף White-label, תחת השם שלהם ותחת NDA, והקשר עם הלקוח נשאר אצלם.

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