המרת פיגמה לקוד — צוות ייעודי

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

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

אנחנו מציעים משהו אחר: צוות פרונטאנד ייעודי שמשתלב בפרויקט שלכם כאילו הוא חלק מהחברה. עובדים ב-repo שלכם, לפי ה-coding conventions שלכם, משתתפים ב-standups ובספרינטים שלכם, ועושים code reviews הדדיים עם המפתחים הפנימיים שלכם.

איך מודל הצוות הייעודי עובד

בשבוע הראשון אנחנו עוברים תהליך Onboarding כמו מפתח חדש בחברה:

• הכרת ה-Codebase: עוברים על ה-repo, מבינים את הארכיטקטורה, ה-conventions, ה-patterns. לומדים את ה-linting rules, ה-commit conventions, ואת תהליך ה-PR.
• הכרת הצוות: פגישות 1:1 עם כל חבר צוות רלוונטי — backend developers, designer, PM, QA. מבינים את הדינמיקה, את ה-communication style, ואת הציפיות.
• הכרת ה-Design System: עוברים על קבצי הפיגמה עם ה-designer, מגדירים את ה-token architecture, מתכננים את עץ הקומפוננטות, ומתאמים naming conventions בין design ל-code.
• Setup טכני: מקבלים גישה ל-repo, CI/CD, staging environments, Figma, ו-project management tools. מגדירים את ה-development workflow — branching strategy, PR process, deployment flow.

אינטגרציה מלאה ב-Agile/Scrum

אנחנו לא עובדים בבועה — אנחנו חלק מהספרינט שלכם:

• Sprint Planning: משתתפים בתכנון, מעריכים story points של משימות פרונטאנד, מזהים תלויות עם backend, ומתחייבים על deliverables לספרינט.
• Daily Standups: מעדכנים על התקדמות, חוסמים, ו-dependencies — כמו כל חבר צוות אחר. אם יש בעיה עם API שעדיין לא מוכן, אנחנו מרימים דגל מיד.
• Code Reviews הדדיים: אנחנו עושים review ל-PRs של הצוות הפנימי, וה-tech lead שלכם עושה review ל-PRs שלנו. ככה מבטיחים עקביות, ידע משותף, ואיכות קוד אחידה.
• Sprint Retrospective: משתתפים בדיון על מה עבד, מה לא, ואיך לשפר. אנחנו מביאים perspective חיצוני שלעיתים חושף blind spots שהצוות הפנימי לא רואה.

עובדים לפי ה-conventions שלכם

אנחנו לא מביאים את ה-"שלנו" — אנחנו מתאימים את עצמנו ל-"שלכם":

• Coding Style: משתמשים ב-ESLint config שלכם, ב-Prettier config שלכם, ב-naming conventions שלכם. אם אתם כותבים handleClick ולא onClick — אנחנו גם.
• Architecture Patterns: אם אתם משתמשים ב-Feature Sliced Design — אנחנו נבנה לפי זה. Atomic Design? Clean Architecture? מה שעובד אצלכם, עובד אצלנו.
• Git Workflow: trunk-based development? GitFlow? feature branches עם squash merge? אנחנו מתאימים את עצמנו לתהליך שהצוות שלכם כבר הסכים עליו.
• Testing Strategy: אם יש לכם מינימום test coverage שנדרש, מסגרות בדיקה מועדפות, או e2e testing setup — אנחנו עובדים בתוך הכללים שלכם.

גמישות בהיקף — מפיגמה בודד ועד מערכת שלמה

אנחנו מתאימים את גודל הצוות לצרכים שלכם:

• מפתח אחד (Half-Time): לפרויקטים קטנים — המרה של כמה מסכים, maintenance על ספריית קומפוננטות קיימת, או תמיכה חלקית בצוות פנימי שעמוס.
• מפתח אחד (Full-Time): לפרויקטים בינוניים — בניית flow שלם מפיגמה, feature development מתמשך, או migration של מערכת עיצוב.
• צוות 2-3 מפתחים: לפרויקטים גדולים — בניית מערכת שלמה מפיגמה, מספר features במקביל, או sprint-based delivery עם velocity גבוה.
• Scale Up/Down: מתחילים עם מפתח אחד, מגדילים ל-3 כשה-pace עולה, מקטינים חזרה כשנכנסים לתחזוקה. בלי חוזים נוקשים — גמישות מלאה עם התראה של חודש.

התהליך שלנו

1. Discovery: פגישה ראשונית להבנת הפרויקט, הצוות, ה-stack, והציפיות. מגדירים את היקף השירות ומודל ההתקשרות.
2. Onboarding (שבוע 1): הכרת ה-codebase, setup טכני, פגישות עם הצוות, והגדרת workflow. מתחילים עם task קטן כ-proof of concept.
3. Ramp-Up (שבועות 2-3): עולים ב-velocity, לומדים את ה-patterns הספציפיים של הפרויקט, מתחילים לתרום ב-code reviews.
4. Full Velocity (שבוע 4+): משתלבים במלואם בספרינטים, עם deliverables קבועים, code reviews הדדיים, ותקשורת שוטפת.
5. Review חודשי: סקירה חודשית עם ה-PM/CTO שלכם — velocity, איכות קוד, שביעות רצון, והתאמת היקף אם צריך.

מה תקבלו

• צוות פרונטאנד שעובד ב-repo שלכם, לפי ה-standards שלכם, כחלק מהספרינט שלכם
• המרת עיצובי פיגמה לקומפוננטות React/Next.js עם TypeScript — pixel-perfect ומוכן לייצור
• code reviews הדדיים שמשפרים את איכות הקוד של כל הצוות
• גמישות מלאה בהיקף — scale up כשצריך, scale down כשהפרויקט נרגע
• SLA מוגדר עם response times ו-resolution targets
• דוחות שבועיים על velocity, deliverables, ו-blockers

למה צוות ייעודי ולא outsourcing חד-פעמי

ההבדל בין outsourcing לצוות ייעודי הוא כמו ההבדל בין פרילנסר שמגיע לפרויקט לבין עובד שמכיר את ה-codebase. צוות ייעודי שעובד איתכם חודשים (או שנים) יודע איפה ה-edge cases, מכיר את ההיסטוריה של החלטות ארכיטקטוניות, ומסוגל לזהות בעיות לפני שהן קורות. אנחנו לא רק כותבים קוד — אנחנו שותפים לפיתוח המוצר שלכם.